IRC channel logs

<azeem>(wow it finished now)

<damo22>how big is the partition?

<damo22>generally i keep my partitions only around 50GB in size currently because disk access is fairly slow

<damo22>also gnumach ahci cannot read beyond 128G boundary?

<azeem>9GB

<azeem>but a lot of files got created and deletes while the VM was running, and /lost+found is now 3GB

<damo22>ouch

<damo22>do you mount with -o sync=5

<damo22>i find that helps

<azeem>ok, I'll try that, thanks

<Pellescours>I have a 64bits hurd (bootstraped with cross-hurd), and while trying to compile a software I got a double fault. The last log befor the double fault is "checking whether integer division by zero raises SIGFPE...".

<Pellescours>My gnumach is the latest commit from master

<Pellescours>I just tried with the debian built 64 bit image, and it seems to work correctly

<youpi>so bisection could be useful information

<Pellescours>yes

<Pellescours>I was able to reproduce it with the debian image

<Pellescours>to do so I needed to configure with "--enable-kdb --enable-pae --enable-apic --enable-kmsg" (maybe some option is uneeded but with them, the 1/0 triggers the double fault)

<Pellescours>also c6181cdba8b26358c23c2a8bb714d2c5a3ea1ebb is the first commit where I see the double fault

<Pellescours>If I configure gnumach with default options only, the double fault does not appear. I will play with different configure options to determine the one that are effectively needed

<youpi>Pellescours: so the commit before that doesn't have the issue?

<youpi>that's very useful information

<youpi>though it's also very surprising, since that commit is supposed to be essentially a no-op for non-smp kernels

<Pellescours>with the commit before that, when I do the 1 / 0 it seems to hang instead

<youpi>what hangs? the program? the kernel?

<Pellescours>the program I think (on my machine), on the debian image I get the crash handler displaying a message and the programs get killed

<Pellescours>I will test on the debian image the bissect

<youpi>I guess on your machine your /servers/crash is still symlinked to crash-dump-core, you want it symlinked to crash-kill

<Pellescours>yeah

<Pellescours>on gnumach master, debian 64 bit image. Just compiling with "--enable-kdb" is enough to trigger the double fault when doing a 1 / 0

<Pellescours>I’m gonna redo the bissect on the debian image

<Pellescours>youpi: I confirm that it’s this commit that introduce the double fault when kdbg is enabled

<youpi>Pellescours: perhaps print irq_nr before the assertion on it

<youpi>perhaps it's getting >= NINTR for whatever reason

<youpi>and in the context we don't manage to get useful info from the assert

<youpi>and it's just the migration from the ndisabled_irq array to nested_irqs array of structs that ends up dereferencing way further in memory

<youpi>(and crash)

<Pellescours>the fact that the previous array was static and that this struct is not declared as static, is it a thing?

<youpi>that shouldn't matter since in both cases it's static allocation

<youpi>you can try to add "static", but that shouldn't really change anything

<youpi>and would not be a proper fix anyway

<youpi>just a very odd workaround

<azeem>was __hurd__ ever defined?

<azeem>I only see __gnu_hurd_ in https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu.h#L25

<azeem>Roland removed __HURD_ in '95: https://github.com/gcc-mirror/gcc/commit/784ea0746840571732d9ed23bc8c3b88034ebe27 - are those case-sensitive?

<youpi>I don't know, possibly only in xmkmf compilations

<youpi>they are sensitive yes

<azeem>ok

<azeem>what's the proper syntax to add --sync=5 to the / options in /etc/fstab? Just --sync=5 instead of default in the fourth column?

<youpi>I'd say rather sync=5

<azeem>thx

<Pellescours>youpi: I wasn’t able to get the message being displayed, so I commented the irq_loq and irq_unlock in the enable/disable and it fixed it (I noticed that the locking was the main impactful change it the diff)

<Pellescours>the problem is in the lock implementation

<youpi>there's no lock in the non-smp case

<youpi>try to replace that with spl/splx like it was before the commit

<youpi>(splhigh actually)

<Pellescours>with splhigh/splx it double fault

<youpi>I'm not surprised, since really simple_lock_irq is just like splhigh in the non-smp case

<Pellescours>Ah, it’s not related to the lock actually. I just retried with the lock commented and it doubled fault

<Pellescours>I’m gonna retry the previous commit multiple time to see if the problem did not already exists but was "harder" to trigger

<youpi>that could be, by just pushing variables around because of the additionnal room

<Pellescours>I think that maybe the problem was already there but, just by luck the previous memory layout hid it

<Pellescours>running the 1/0 in a loop to see, for now it behave correctly (no double fault)

<gnucode>well I just sold my T43 on ebay for $50 (I'm giving $20 of that to damo22) I've been hoping to sell Hurd computers for a while now.

<gnucode>I guess it's time to figure out what model I should sell next. T400, T410 ?

<gnucode>I also need to set up a mirror of hurd.gnu.org ... that way I can still see the Hurd site when darnassus is down.

<gnucode>and I should update hurd.gnu.org so that it is the latest version of the site.

<gnucode>I invite you all to compete with me in selling hardware running Debian GNU/Hurd!

<Franciman>gnucode: can i buy one?

<gnucode>sure why not! I'll contact you off list.

<gnucode>actually let's keep the conversation here.

<gnucode>The T43 I can probably sell you the cheapest. 2 GiB max RAM. 32 bit.

<gnucode>T60 has 4GiB max RAM with working internet. You shouldn't really use SSDs just yet, because the rumpdisk has issues with swapping and a 4 GiB RAM hurd should enable swapping.

<gnucode>T400 support 8 GiB max RAM. It should be possible to run the 64 bit version of the Hurd, but I don't know that anyone has dared to do that yet!

<gnucode>The T400 should be safe to use SSDs. You'll have no swap, so you'll have to be careful not to run out of memory. But 8 GiB is hard to use up that much RAM. Especially if you're using something lightweight: i3, Xfce, ice-wm.

<gnucode>Or you could buy a much recent machine and use Xen. This will let you run the Hurd and Linux at the same time.

<gnucode>Franciman: Do you want a laptop that could use libreboot ? Or do you care about that?

<gnucode>Also where do you live? USA area or across the pond ?

<gnucode>My next laptop I personally want to run a T400 or newer machine. That opens up the possibility of using the 64-bit version of the hurd.

<Franciman>i do care gnucode

<Franciman>aand i live in italy

<gnucode>ok, what do you care/what do you want?

<Franciman>ah i mean i care about libreboot

<gnucode>Also, internationally shipping is probably gonna be fairly expensive right?

<gnucode>gotcha.

<gnucode>I do too.

<Franciman>eh yes

<Franciman>but do you also have wifi working on t400?

<gnucode>Nope. There is no working wifi on the Hurd at the moment.

<gnucode>Damien is the person who is working on rumpnet. You can donate to him at zamaudio.com

<Franciman>cool

<gnucode>And I personally have only run the Hurd on a T43. I'm going to try it on the T400 soon.

<gnucode>I'd sell you a T400 librebooted laptop 8 GiB RAM, an SSD for $350 + $40 - 75 shipping. I'd probably donate $20 - $50 to Damien.

<gnucode>also it looks like the T480 is mostly librebooted.

<gnucode> https://minifree.org/product/libreboot-t480.html

<gnucode>If I take too long to get back to you, you could reach out to Leah and ask to buy a one of those laptops with Debian GNU/Hurd installed. FYI, the hurd does NOT support nvme yet.

IRC channel logs

2025-08-26.log