00:31:55 <RhodiumToad> hm. well, I can't see any issue from just reading the code
00:32:29 <RhodiumToad> are you able to compile a small linux binary to test with?
00:32:48 <gzar> I guess
00:32:57 <RhodiumToad> sec, I'll write something
00:33:15 <gzar> i'd have to switch kernels back and forth tho
00:36:26 <gzar> can't a macro be at fault? with clang and gcc behaving differently when expanding it?
00:40:21 <RhodiumToad> https://dpaste.org/Cj4rR   <-- try that
00:40:23 <VimDiesel> Title: dpaste/Cj4rR (Plain Code)
00:40:40 <RhodiumToad> compile as a linux binary and run it inside and outside the chroot
00:41:07 <RhodiumToad> all sorts of things could be at fault
00:45:06 <gzar> in this working kernel, both return the value 0
00:45:17 <gzar> both in chroot and non-chroot
00:45:25 <gzar> i will now reboot into the faulty kernel, and report back
00:45:30 <RhodiumToad> the address isn't the right one for the working kernel, it's based on the non-working one
00:48:10 <gzar> RhodiumToad: [0x7fffffffe928] = 7fff00000000
00:48:19 <gzar> inside chroot
00:48:33 <gzar> and also outside chroot
00:48:52 <gzar> (sh works but not bash, so i was able to chroot and run it from inside too)
00:49:15 <gzar> both report the same large value
00:51:56 <gzar> it looks to me like a register is not being fully set to 0
00:52:06 <gzar> clang sets it and gcc does not
00:52:13 <RhodiumToad> no
00:52:44 <RhodiumToad> the value is supposed to be 7fffffffxxxx for some xxxx which I can't easily predict
00:52:54 <gzar> ooh
00:53:29 <RhodiumToad> it was 0 on the working kernel because the address is wrong there, since the code sizes change
00:53:44 <RhodiumToad> I picked the address out of your gdb output
00:54:00 <gzar> oooh
00:54:21 <RhodiumToad> I don't understand why the chroot makes any difference though
00:55:08 <gzar> you're right, it doesnt
00:55:20 <RhodiumToad> though from this output, it seems like the bug is present outside the chroot too, it's just not being hit
00:55:20 <gzar> segfaults without a chroot too...
00:55:28 <RhodiumToad> aha
00:55:35 <RhodiumToad> progress.
00:55:47 <gzar> thats weird, when i ran a linux java runtime no problems happened
00:55:56 <RhodiumToad> maybe a static binary?
00:56:01 <gzar> possibly
00:56:08 <RhodiumToad> this problem _probably_ only hits dynamic binaries
00:56:22 <gzar> yeah
00:56:31 <gzar> well if you want core file i can generate plenty
00:56:37 <gzar> s
00:57:12 <RhodiumToad> core files are not much use now. the next question is why is the value not being set, and that's going to need kernel debugging
00:57:32 <RhodiumToad> actually before that, there is one check that can be done
00:57:46 <RhodiumToad> let me write a quick program for you
00:58:04 <gzar> alright, but i gotta be going to bed soon
00:59:38 <gzar> i have aslr enabled, if thats important
01:03:27 <RhodiumToad> https://dpaste.org/eazw2
01:03:29 <VimDiesel> Title: dpaste/eazw2 (Plain Code)
01:03:50 <RhodiumToad> compiled and run for linux, that should dump out the linux vdso to a file "dump.out" in the current dir
01:04:27 <RhodiumToad> that should allow inspecting the ELF headers and symbol table of the vdso to see if anything is incorrect
01:05:34 <gzar> alright well, this kernel has a non-working linux compat
01:05:44 <gzar> so i'll leave this for tommorow if thats ok
01:05:52 <gzar> really need to head off to bed
01:06:10 <RhodiumToad> if it runs ok, can you pastebin both  hd dump.out   and  b64encode dump.out dump.out
01:06:14 <RhodiumToad> ok, whenever
01:06:55 <gzar> yeah alright, i'll do it tommorow and let you know
01:07:03 <gzar> thanks, it was fun
07:19:57 <trev> ok, i am going to wipe current and go back to release. wish me luck
07:21:03 <la_mettrie> bonam fortunam habetis!
09:08:00 <Lovis_IX> Whaou, we need to speak and write latin to FreeBSD now? Need to learn it before.
09:16:18 <RhodiumToad> Quidquid latine dictum sit, altum videtur
09:23:30 <RhodiumToad> ("Whatever is said in latin, seems profound")
09:39:10 <trev> do more, do more!
09:44:36 <paulf> whatever is said in latin, sounds like that total twat Rees-Mogg
09:47:22 <meena> καὶ σὺ τέκνον τῆς ἀρχῆς ἡμῶν παρατρώξῃ.
09:48:59 <RhodiumToad> and now I don't know whether that's just a lot of ?s or whether it's something my irc client can't decode
09:52:59 <meena> RhodiumToad: it's Greece
09:53:12 <meena> Greek, even
09:53:59 <meena> You too, son, will take a bite of my rule. / You too, son, will take a taste of my power.
09:54:53 <meena> this is where the "you too, my son" from Caesar's last words comes from
09:56:53 <gzar> RhodiumToad: http://dpaste.com/EBF7WH646
09:56:54 <VimDiesel> Title: dpaste: broken_linux_ko.dump.b64.txt
09:57:05 <gzar> RhodiumToad: http://dpaste.com/BHDKJQCJE
09:57:07 <VimDiesel> Title: dpaste: broken_linux_ko.dump.hd.txt
09:58:20 <RhodiumToad> gzar: oh, and can you also run the same program under the working kernel?
09:58:44 <gzar> oh yeah, i did, was about to ask if you want the working ones too
09:59:53 <gzar> RhodiumToad: http://dpaste.com/H74LUCM76
09:59:54 <VimDiesel> Title: dpaste: working_linux_ko.dump.hd.txt
10:00:26 <gzar> RhodiumToad: http://dpaste.com/FJEYBL7RU
10:00:29 <VimDiesel> Title: dpaste: working_linux_ko.dump.b64.txt
10:05:43 <gzar> if desired i can also tar-up the kernel, modules and symbols and upload it somewhere
10:06:08 <RhodiumToad> that wouldn't be useful to me at present
10:09:18 <RhodiumToad> hm. interesting.
10:10:11 <RhodiumToad> so the way this is supposed to work is that the linux vdso is mapped at 0x7fffffffe000-0x7fffffffffff,
10:10:39 <RhodiumToad> and the freebsd shared page at 0x7fffffffd000 (i.e. the previous page)
10:11:29 <RhodiumToad> (this is for linux images, obviously, for freebsd images there's just the freebsd page at 0x7ffffffff000 or 0x7fffffffe000 depending on cpu type)
10:13:03 <RhodiumToad> so, the linux vdso has to have a pointer to the freebsd shared timer info (in the freebsd page),
10:13:18 <RhodiumToad> and it's exactly that pointer which is broken
10:13:28 <RhodiumToad> here it is in the good image:
10:13:38 <RhodiumToad>  09a0 10d6ffff ff7f0000
10:13:59 <RhodiumToad> and here in the broken one:
10:14:06 <RhodiumToad>  0920 00000000 00000000 00000000 ff7f0000
10:14:41 <RhodiumToad> (it's at offset 928 in the broken one)
10:15:20 <gzar> thats the value that is in RSI before it segfaults
10:15:26 <RhodiumToad> yes
10:15:52 <RhodiumToad> so the next question is why is it not filled in correctly
10:16:37 <gzar> the weirder thing is, why is it correct when compiled with clang and not when compiled with gcc
10:17:32 <RhodiumToad> the entry in the dynamic symbol table looks the same on both
10:19:38 <gzar> could the linker somehow botch this up?
10:28:47 <RhodiumToad> I don't think so.
10:30:52 <gzar> then how come the same code produces different results with different compilers? could the optimizer be at fault?
10:31:34 <RhodiumToad> what happens is that the vdso is compiled separately to a .so file, and then that's included into the linux module as a data blob
10:32:30 <RhodiumToad> the kernel is responsible for doing the adjustment of the pointer to point to the right place, and clearly it's not happening
10:33:43 <gzar> well, it is when clang is used
10:33:49 <RhodiumToad> right
10:34:47 <gzar> unless the fact that it works happens to be a lucky coincidence due to some offset/alignment happenstance
10:46:37 <RhodiumToad> can you do  objdump -x linux64.ko | grep kern_timekeep_base    on the bad kernel's linux64.ko
11:13:09 <gzar> yeah, one sec
11:14:28 <gzar> RhodiumToad: https://dpaste.com/E7MBXK64G
11:14:30 <VimDiesel> Title: dpaste: E7MBXK64G
11:18:20 <meena> 11:33 <gzar> well, it is when clang is used ⬅️ that seems like a pretty bad bug
11:20:17 <gzar> yeah but i cant help but blame the compiler, since thats the only difference between a working linux64.ko and a busted one
11:20:24 <RhodiumToad> gzar: can you get a disassembly of linux_exec_sysvec_init from kgdb linux64.ko  (make sure the /usr/lib/debug subdirs are in the correct places as before)
11:20:39 <gzar> yeah, one sec
11:21:07 <RhodiumToad> unless I'm misreading this code, there are two separate places that both think it's their job to be initializing this,
11:21:16 <RhodiumToad> and they may not be actually doing the same thing
11:21:57 <gzar> RhodiumToad: https://dpaste.com/DLUMPVS9D
11:21:58 <VimDiesel> Title: dpaste: DLUMPVS9D
11:22:03 <RhodiumToad> but without instrumenting the kernel to get details it's hard to tell
11:22:31 <gzar> that is why i asked if you wanted the busted compiled kernel binaries and modules
11:22:44 <gzar> do run through qemu or bhyve
11:29:36 <RhodiumToad> I'd have to modify the code anyway, so having your compiled version wouldn't help much
11:29:51 <RhodiumToad> maybe someone else would use a different approach
11:31:17 <meena> RhodiumToad: dtrace kinst not Good enough?
11:34:16 <RhodiumToad> that's in -current, no?  (I have not been using dtrace)
11:36:34 <gzar> i dont think i have dtrace support enabled
11:36:35 <meena> it's in current, yes, not sure it's been MFC'd
11:37:07 <meena> gzar: 😒
11:37:48 <meena> if you're building an adventures new system, you better enable all the bells and whistles to make it debugable
11:38:33 <gzar> i got a bunch of undefined symbol errors and i didnt expect gcc to break the kernel
11:39:00 <gzar> its a generic kernel, i didnt consider switching a compiler would cause anything
11:39:09 <gzar> to malfunction
11:39:41 <meena> do you know how long Linux took to build under clang?
11:39:55 <gzar> no
11:39:58 <rustyaxe> about 12 minutes?
11:40:47 <meena> I mean, how long did Linux devs work on making Linux build with clang
11:41:41 <gzar> i have no idea, honestly. Its the same language and both compilers should produce code that behaves the way it is described in the .c file
11:42:45 <gzar> and besides the linux compat, the rest of the system seems fine
11:47:23 <meena> C is a weird language. and C compilers are very complex machinery
11:49:20 <rustyaxe> doesnt help linux kernel uses a lot of gcc extension :)
11:49:41 <RhodiumToad> freebsd uses a lot of clang-extensions-copied-from-gcc
11:52:07 <RhodiumToad> gzar: I probably won't be able to do more on this today.
12:34:51 <gzar> its fine RhodiumToad , i didnt expect anything at all from this
13:46:47 <RoyalYork> Is there a way I can automate or manage FreeBSD upgrades in a better way? I have 2 VPS plus one local server running FreeBSD. When 13.2-RELENG was released, I had to upgrade all three servers manually. Is there a better way to upgrade/update my machines? The names of programs or directions to man pages would be great
13:55:53 <vkarlsen> RoyalYork: I like to use tmux-xpanes when I want to make the same mistake on several servers at the same time
13:56:52 <RoyalYork> 😂
13:57:11 <RoyalYork> ;-)
13:57:26 <RoyalYork> So you're saying manual is better?
13:59:08 <vkarlsen> I find that manually using freebsd-update isn't too much work, and I don't trust an automated process out of the box here because manual intervention is sometimes necessary to merge changed files
14:00:13 <RoyalYork> Understod. I'm not a sysadmin or network expert (just some shlep interest in BSD). In the real world, so sysadmins manualy update each server?
14:00:19 <vkarlsen> And that running freebsd-update between releases doesn't take up a lot of my time
14:01:18 <vkarlsen> It depends on many things. Try pinging AllanJude if you want to hear how he manages large amounts of servers, I remember him having a clever way of doing this
14:01:59 <RoyalYork> Was just wondering out of curiosity. But I hear your point. A few servers, doesn't take a lot of time.
15:23:29 <meena> RoyalYork: if instead of 3 servers, you had 30, i would recommend to reimage then. but 3 is like pets, not a cattle farm, so you can do whatever you want
15:25:17 <meena> I was gonna link that three minutes gif titled running your blog in kubernetes, that has someone build a sandwich with heavy duty tools in a carpentry shop
15:25:57 <meena> but all I'm finding is just graphs of the architecture of a blog run in kubernetes, so that joke is now reality
15:27:52 <meena> tho, for me, personally, the cutoff point isn't 30, it's more like 4
16:19:02 <RoyalYork> thanks meena
17:10:01 <gzar> hello, i am once again asking for your support. I can't load vboxdrv kernel module, the error i am getting is this: linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
17:27:20 <meena> gzar: what's the file type? and what are the other modules' file type(s)?
17:28:14 <gzar> /boot/modules/vboxdrv.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), BuildID[sha1]=bc1e7274194b94bd7aad4f7fd11747772e907271, not stripped
17:28:24 <gzar> /boot/modules/nvidia.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), BuildID[sha1]=75b022797682ef490cf72ef03e54f0cee20fea17, not stripped
17:29:43 <meena> that looks very much the same, tho
17:30:49 <gzar> i know
17:30:57 <gzar> i'll try compiling it from ports
17:38:49 <gzar> alright, it worked
17:39:07 <gzar> the message indicates that the module wont load on different kernel versions
17:39:46 <gzar> this is exactly why i like freebsd
17:39:58 <gzar> or just bsds in general
17:44:41 <meena> unsupported file type isn't very intuitive
20:01:53 <luna_> https://i.imgur.com/X0CpRQ5.png
20:04:05 <yuripv> looks like... linux
20:06:10 <luna_> yuripv: so it is sorry but the talk is about BSD atleast
20:06:29 <luna_> https://www.youtube.com/watch?v=Oq_1KHE6eZk&
20:06:30 <VimDiesel> Title: Profesjonell bruk av fri programvare med Peter Hansteen - YouTube
20:07:03 <meena> luna_: what's it mean?
20:07:12 <polyex> what's best simple image viewer?
20:07:19 <polyex> like jpg gif
20:07:28 <schillingklaus> feh is simple
20:07:36 <luna_> +1 for feh
20:08:17 <meena> display from imagemagick?
20:08:49 <la_mettrie> i often use browser
20:13:50 <schillingklaus> maybe somethiong on the lines of professional usage of free software
20:14:27 <luna_> schillingklaus: yep in norweigan
20:21:31 <meena> Indo-European.