IRC channel logs

<damo22>sigttou: you need to run "/sbin/smp command" to run on other cores

<damo22>otherwise your stress test only runs on master processor

<GNU_Hurd_Rocks>oh wait so there is multi processor ?!

<damo22>yeah gnumach-image-smp

<GNU_Hurd_Rocks>sam_: is this supported by Gentoo?

<damo22>its still experimental because sometimes it hangs if we turn it on fully

<sam_>GNU_Hurd_Rocks: https://codeberg.org/thesamesam/gentoo-hurd/src/branch/master/TODO.md

<GNU_Hurd_Rocks>ah right, I should have looked at that

<sam_>(the rumpnet item is obsolete, I dropped that now)

<damo22>so we hid the rest of the cores in a secondary processor set

<damo22>so it boots with just 1 core but the rest are available with a command

<damo22>we need to fix all the races

<damo22>then we can enable full smp

<GNU_Hurd_Rocks>installing guix with hurd :3

<GNU_Hurd_Rocks>HOPEFULLY it can at least boot to something useable enough even if tty only and no network

<paculino>What is the current restriction on fs size with hurd? It isn't quite the same as regular ext2, is it?

<damo22>paculino: the gnumach i386 linux ahci driver has a 128GB limit on partition offset, but if youre using rumpdisk i think it can support up to 2TB

<paculino>I think that's just big enough for me

<paculino>Now I just need a replacement drive for that old laptop...

<damo22>so what i did was create 50G for / and 50G for /home and then nothing breaks in any combination

<damo22>but i eventually moved away from gnumach i386 ahci so i increased to 400G for home

<damo22>GNU_Hurd_Rocks: childhurd (qemu) or native guix?

<GNU_Hurd_Rocks>damo22: on hardware :3

<damo22>nice

<damo22>what model?

<GNU_Hurd_Rocks>unfortunately did "part:1:device:wd0: No such device or address" so I'm not certain...

<GNU_Hurd_Rocks>It's just an HP that happens to support BIOS via CSM if I got the name right

<damo22>ok

<damo22>you might need to set SATA mode = AHCI in the cmos

<GNU_Hurd_Rocks>I'm probably unable to do that unfortunately

<damo22>uh why not??

<GNU_Hurd_Rocks>It's only the stock firmware on the device

<GNU_Hurd_Rocks>very limiting...

<damo22>they usually have sata mode

<GNU_Hurd_Rocks>I know the CPU supports SATA but it could also be on PCIe

<damo22>is this x86?

<GNU_Hurd_Rocks>pentium silver N5030 :3

<damo22>you will find the sata mode if you look closer

<damo22>it would be buried in the menu settings

<GNU_Hurd_Rocks>HP firmware settings are basically stripped down and bare minimum...

<damo22>look up the manual for your mainboard, it will be in there

<GNU_Hurd_Rocks>well I guess I have the system board ID and CT number so I will go look at what those mean

<GNU_Hurd_Rocks>damo22: there is no point using kinder words for this, HP is fucking ass

<GNU_Hurd_Rocks>will have to check the firmware settings on my other system because that MIGHT allow for AHCI SATA, and I know they use the SATA port rather than being on M.2 or something else

<GNU_Hurd_Rocks>damo22: it listed Native IDE but I couldn't change that

<GNU_Hurd_Rocks>also, I have zero understanding what sata is lol, because so far I get very confused reading documentation on things

<sigttou>damo22: ok, that explains some instabilities. I moved all CPUs into the default pset for testing

<GNU_Hurd_Rocks>WHY IS IT WHEN I WANT TO USE HURD ALL OF MY DISKS ARE TAKEN FOR OTHER THINGS

<GNU_Hurd_Rocks>damo22: I am going to go find out more on how the interface used by the device

<GNU_Hurd_Rocks>tried saying two different things lol

<GNU_Hurd_Rocks>damo22: it's a cursed M.2 SATA apparently, since the device model is shown as "SSSTC CVB-8D128"

<sigttou>sam_: talking about rumpdisk, I had an issue that bridged devices aren't enumerated. Not sure if that's a config issue or a bug in rump.

<GNU_Hurd_Rocks>there is this PDF that gives some information about it :3 https://www.ssstc.com/upload/catalog_files/enL_catalog_24E27_h3NeVzCfNM.pdf

<damo22>the disk itself should not matter it exposes a sata interface

<damo22>but the controller needs to be supported by rumpdisk

<GNU_Hurd_Rocks>I found a little more information, trying to sort it out

<damo22>GNU_Hurd_Rocks: its the HP mainboard you need to look up

<GNU_Hurd_Rocks>for "subsystem" under lspci is lists a value of "85F5" (if that's useful at all)

<damo22>lspci -nn

<GNU_Hurd_Rocks>would that be '8086:31e3' or '0106' (perhaps both?)

<GNU_Hurd_Rocks>looks right, found some more information

<GNU_Hurd_Rocks>of course Intel gets 8086 as part of their thing though lol

<damo22>can you paste the whole line relating to the controller?

<GNU_Hurd_Rocks>will ssh quick

<GNU_Hurd_Rocks>damo22: "00:12.0 SATA controller [0106]: Intel Corporation Celeron/Pentium Silver Processor SATA Controller [8086:31e3] (rev 06)"

<GNU_Hurd_Rocks>however 8086:31e3 is enough to point in the right direction ;3

<GNU_Hurd_Rocks>the module used by linux is ahci though

<damo22>looks like #define PCI_DID_INTEL_GLK_SATA 0x31e3

<GNU_Hurd_Rocks>what's that defined in?

<damo22>coreboot

<GNU_Hurd_Rocks>ah, I've wanted to use coreboot or libreboot for a while now

<GNU_Hurd_Rocks>giving me ideas is sometimes a bad idea ;3

<damo22>Gemini Lake SATA

<GNU_Hurd_Rocks>at least tomorrow is thursday yippee

<damo22>looks like rump does not mention it except in a define

<GNU_Hurd_Rocks>If there isn't a driver for it, then honestly that's a hell yes I would write it :3

<damo22>you probably can make it work in rump by adding the pci id

<damo22>to the ahcisata driver

<GNU_Hurd_Rocks>uh is /bin supposed to be empty on a guix install, or is something wrong?

<GNU_Hurd_Rocks>damo22: where is the define specifically?

<GNU_Hurd_Rocks>found

<damo22> https://code.zammit.org/damo22/rumpkernel-debian/src/branch/develop/buildrump.sh/src/sys/dev/pci/ahcisata_pci.c#L261

<damo22>that function needs to return correctly

<damo22>otherwise your controller wont be probed

<damo22>can you check the output of your rumpdisk log, see if it probes the controller

<damo22>ahcisata0

<GNU_Hurd_Rocks>tried my best to type this, https://bpa.st/HBRQ

<damo22>ah ok, the controller was detected, but the disk is not working

<damo22>seems like the IRQ is wrong

<damo22>intnull(6) means you got an interrupt on IRQ 6 but nothing handled it

<damo22>probably the disk

<damo22>ACPI is probably broken on your board?

<GNU_Hurd_Rocks>I have used it fine under a linux kernel

<damo22>yeah but linux has all kinds of fallbacks for pci irq

<damo22>mptables etc

<damo22>we assume the acpi info is correct and just use that so we dont have to support all the legacy stuff

<damo22>you could try booting into grub and capturing the output of lsacpi

<damo22>maybe there are override clues there

<damo22>there is a linux kernel command line option to force pci irqs from acpi, i bet that fails too

<GNU_Hurd_Rocks>damo22: what even is the thing for the command line option?

<GNU_Hurd_Rocks>tried pci=acpi, device shows up fine, and can be mounted :3

<damo22>acpi=noirq

<GNU_Hurd_Rocks>oh yikes I have a keyboard problem now

<damo22>acpi=noirq pci=noacpi

<damo22>wait no

<damo22>what you already did

<damo22>pci=noacpi

<GNU_Hurd_Rocks>combine both?

<damo22>^ just try the last one i posted

<damo22>it might fail to detect the disk

<damo22>or will succeed but somehow use mptables to figure it out

<GNU_Hurd_Rocks>super slow to boot...

<GNU_Hurd_Rocks>somehow stuck in grub right now lol

<GNU_Hurd_Rocks>pci=noacpi causes it to never leave from GRUB

<damo22>maybe you have "quiet" so you cant see the lof

<damo22>log

<GNU_Hurd_Rocks>did not look to be set

<damo22>try earlyprintk=vga

<damo22>as well

<GNU_Hurd_Rocks>"linux /boot/gentoo dokeymap nodhcp root=live:CDLABEL=Gentoo-amd6420260913 rd.live.dir=/ rd.live.squashimg=image.squashfs cdroot" (the default before editing)

<GNU_Hurd_Rocks>not seeing any difference with earlyprintk=vga unfortunately

<GNU_Hurd_Rocks>damo22: I have a feeling it might be related to the SATA controller somehow, for Hurd

<GNU_Hurd_Rocks>damo22: oddly enough linux has no definition for 8086:31E3

<damo22>yes the sata controller driver is using the wrong irq most likely

<GNU_Hurd_Rocks>damo22: I'm going to look into acpi later, perhaps an excuse to write a quick and dirty driver to detect and then try interacting with the controller, not certain if UEFI provides functions for to help any of this

<GNU_Hurd_Rocks>this has given me another idea, write a UEFI implementation for the Pico2, specifically for RISC-V, even if it's entirely useless

<damo22>sneek: later tell GNU_Hurd_Rocks please don't throw the baby out with the bathwater, our existing code is almost working - it just needs debugging, it doesn't need a brand new implementation from scratch just because your device isn't fully detected. Of course, you are free to do what you want, but please keep this in mind.

<sneek>Got it.

IRC channel logs

2026-09-17.log