IRC channel logs
2026-10-08.log
back to list of logs
<damo22>sigttou: good job finding those bugs <sigttou>damo22: trying to get a Hurd lab spin up for students. it's a bit messy :) <bigmike-sit>i managed to get download speeds over rumpnet wm0 on x86-64 from the old 75ish kb/s to 5mb/s! :D <bigmike-sit>hwpplayer1: actually, no i seem to jsvr just hit 10mb/s <bigmike-sit>basically, the issue appeared to be that it was aligning words entirely incorrectly on x86-64 causing packets to be dropped like crazy <etno>bigmike-sit: great find about the rumpnet alignment issue ! The performance increase sounds huge :) <bigmike-sit>etno: For amd64 only unfortunately (or fortunately?) Came down to a mismatch with taking the sizeof int and long, meaning they were semi-consistently 4 bytes off from where expected, as NetBSD uses sizeof (long) for padding of BPF reads, and Mach (well, net-rump.c) uses sizeof (int) for that alignment. on i386 both are 4bytes so its like whatever, but on x86_64 long is 8 and int is 4. sneaky... <bigmike-sit>the sneaky part is, the first packet of every read got parsed correctly like 100% of the time <bigmike-sit>only when they all came together did the mismatch occur <bigmike-sit>though I do think there is more performance to be eeked out of this. just not right now <etno>I think that I understand how this makes the packets unaligned, and that leads to alignment issues when using packed structs to access fields. <etno>But I fail to understand how this leads to packet drop? <bigmike-sit>etno: well, its more a misparsing than a literal packet drop. after a full frame rumpnet advances 1540 bytes, but the kernel puts the header at 1544 causing it to be read 4 bytes early. so the length lands on the top half of a 64-bit timestamp and the length gets mangled that looks like a truncated fragment to the code, so the rest of the readbuffer is just kinda thrown away <etno>Oh wow, now I get it. Thanks bigmike-sit <bigmike-sit>etno: np! i saw a few other people had this same exact issue a while ago so hopefully this can like actually be of use! 😅 <gnu_srs>However, rumpdisk is not used on 32-bit images?? <etno>gnu_srs, I have a fresh debian i386 install here, and while rumpdisk is running, the root filesystem is obtained at `typed:part:2:device:hd0` <gnu_srs>etno: But on amd64 it is ...device/wd0?? <etno>This is what I use on the amd64 VM I use everyday, but I tweaked it so much that I couldn't tell whether this is the default (I think that I changed it a long time ago) <etno>But then, it can only work if the gnumach ahci support is disabled, and I have no "noide" directive on the gnumach cmdline <etno>So I would conclude that the CONFIG_BLK_DEV_IDE config is undef for amd64 <etno>gnu_srs, sorry to bother you with this question (again), and if I am adding some salt on a wound, simply tell me and I will stop : there was this attempt at some point to fix the DRM headers so that a newer version of MESA would build ; what happened then ? Was the patch refused ? <etno>damo22: to your knowledge, is the rumpkernel pci stuff doing some reconfiguration of the PCI tree ? When I create a 9PFS device in qemu, its BAR4 (64bits) is configured at the BIOS stage, but seems to be unconfigured later, and I am suspecting rump. <GNU_Hurd_Rocks>I spent a couple days on Gentoo installation media doing random things :3 <hwpplayer1>Any C++ developer at kernelspace here ? I want to learn how to manage memory allocation efficiently... <etno>GNU_Hurd_Rocks: the Gentoo stuff is very intriguing to me, especially since I am ignorant of Gentoo itself :D <Darelelve>gnu_srs: Hello. The issue may be that storeio is returning an incorrect file type and its mapping is not working correctly. Fixes to address these problems have already been submitted. <GNU_Hurd_Rocks>also it seems my git provider has temporarily made it so login is required because of scraping <damo22>etno: sorry i have been in bed sick for 2 days <etno>Oh no! I hope you get better soon 🍵 <damo22>i think acpi might reconfigure the interrupts im not sure about BARs <etno>Could the initialization in rumpkernel redo the PCI bus BAR allocations ? <etno>I dug a bit, and there is definitely PCI allocation code, which could reset BARs if the allocation fail (which could happen only for >4G (the default for 64b)) <etno>But just a guts feeling for now <damo22>i dont think it removes the base address does it? <etno>It starts by reading the size, which involves writing ~0 <etno>It should restore the initial value in case of error; except if the range allocator fails <GNU_Hurd_Rocks>damo22: damn, sickness sucks, can't do what you actually want to do <etno>But I am not even sure that this code runs <GNU_Hurd_Rocks>I'm in a similar state (sort of) where I don't have an OS to use right now <damo22>you dont want my fever, luckily you cant catch it over IRC <etno>ACTION sprays some alcool on the screen, in case <etno>GNU_Hurd_Rocks: did you lose an OS recently? <GNU_Hurd_Rocks>TRYING to keep it together by not reinstalling yet again because of not liking one random thing during install <etno>I supposed that you were talking about Gentoo Hurd, earlier. But I am not so sure now 