IRC channel logs


back to list of logs

<gnu_srs1>damo22: Congrats :) I saw your slides, still remains to watch the presentation.
***janneke_ is now known as janneke
<youpi>damo22: I'm trying rumpdisk again but I'm not getting any wd0
<youpi>[ 1.0200050] vendor 8086 product 2922 (SATA mass storage, AHCI 1.0, revision 0x02) at pci0 dev 4 function 0 not configured
<youpi>that's all it says about my qemu sata drive
<youpi>I tried to make sure to have the same options as you have (q35, ich9-ahci)
<youpi>ah but do I need the qemu patches?
<youpi>it'd be really good to get them upstreamed at last
<Pellescours>youpi: I’m able to start qemu with sata & rump
<Pellescours>qemu-system-x86_64 -m 2048 -drive id=disk,if=none,format=raw,cache=writeback,file=dev.rump.img -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 -nic user,hostfwd=tcp: -k fr --enable-kvm -serial stdio -smp 4 -cpu host
<youpi>what vendor/product/revision do you get?
<youpi>even with the qemu patches I'm not getting any ahci enabled
<youpi>Pellescours: which version of qemu are you using?
<Pellescours>6.2.0 I’m on archlinux
<Pellescours>I don’t have any patch on my qemu
<youpi>Pellescours: which version of the hurd package are you using?
<Pellescours>the packaged one on debian. But I just tried to re-setup my rump vm and start it and it failed
<youpi>"the packaged one" is not precise enough :) there are various versions
<youpi>that's why I'm asking
<Pellescours>It failed… big words, it failed to find the partition on wd0
<Pellescours>Let me check
<youpi>but it found wd0 itself?
<Pellescours>yes I think I probably miss-configured my fstab
<Pellescours>hurd 1:0.9.git20211230-5+b1
<youpi>whcih version of the seabios do you have?
<Pellescours>In my boot logs I have: "vendor 8086 product 2922 (SATA mass storage, AHCI 1.0, revision 0.02) at pic0 dev 4 function 0 not configured
<Pellescours>how do I know 1.15 (on my archlinux)
<youpi>same here
<youpi>no idea what else could be different
<Pellescours>currently I have ext2fs: part:2:device:wd0: No such device or address <<< I don’t understand why, because before I succeed to make it working
<youpi>but does the boot log talk about wd0 before that?
<Pellescours>I don’t think so, but logs move too fast and I don’t remember how to backlog in the boot messages in qemu
<youpi>it really looks like you are just having the same issue as I have
<youpi>(remembering again: the qemu patches are needed for cdrom support IIRC)
<Pellescours>but I’m using a copy of my normal hurd image to do my rump tests, so I don’t need cdrom support
<Pellescours>youpi: when I boot my rump disk with the "normal" grub entry (the one not using rump) the kernel correctly detect my sd0 drive
<Pellescours>so qemu is working
<Pellescours>for some reason there is a regression with wd0 disk detection
<Pellescours>can it be due to pci changes?
<youpi>no idea
<Pellescours>because last time I tested was in november and it was working
<Pellescours>youpi: I build gnumach with ide but without sata and I attached a second disk to my vm (a sata one) and now I can see that rump see’s it
<Pellescours>I have the ahcisata logs appearing
<Pellescours>And I’m even able to mount it
<Pellescours>so for some reason the sata disk is not detected correctly when rump is started at boot but after it works…
<youpi>what happens if you put the pci-arbiter in the boot process?
<youpi>so that it's that one that does the pci arbitration
<Pellescours>I use the damo22 command to boot, so it start the pci-arbiter
<Pellescours>Ah ok, I understand
<Pellescours>let me try
<Pellescours>it seems that when pci-arbiter is started at boot, rump does not work
<Pellescours>my bad I booted using wrong kernel
<youpi>perhaps also try with pci-arbiter.static used after boot
<youpi>to make sure whether it's starting at boot or not, or using the staticcally-linked or not, that matters
<Pellescours>the kernel is probing sata disk so rump don’t do anything, I retry with my custom kernel
<Pellescours>rump is seeing ahcisata disk
<Pellescours>wd0 is seen
<youpi>with pci-arbiter started at boot?
<youpi>it's that one that remains in the ps output ?
<youpi>also, try rumpdisk vs rumpdisk.static
<Pellescours>root 732 0.0 0.0 165M 1.35M - S<o 10:00PM 0:00.02 /hurd/pci-arbiter
<youpi>that's not the boot one
<youpi>possibly pci-arbiter just crashes
<Pellescours>yep, and I don’t see the one at boot
<Pellescours>so yes probably crash at boot, this would explain why rump fails to see sata disk
<Pellescours>module /hurd/pci-arbiter.static pci-arbiter \
<Pellescours> --host-priv-port='${host-port}' \
<Pellescours> --device-master-port='${device-port}' \
<Pellescours> --next-task='${fs-task}' \
<Pellescours> '$(task-create)' '$(task-resume)'
<Pellescours> module /hurd/ext2fs.static ext2fs --readonly \
<Pellescours> --multiboot-command-line='${kernel-command-line}' \
<Pellescours> --exec-server-task='${exec-task}' -T typed '${root}' \
<Pellescours> '$(fs-task=task-create)'
<Pellescours>my command line to boot (without the exec) sorry for wild paste
<Pellescours>And I can see in the boot lines, that the pci-arbiter is starting before the ext2fs
<Pellescours>I restarted, and without looking do rump device (so rump does not start) I cannot see any pci-arbiter process. The one started at boot is not here
<youpi>I'd say put debugging mach_print()s in libpciaccess to check that it properly finds out how it's supposed to work, and in the initialization paths of pci-arbiter
<Pellescours>I will try
<Pellescours>so many patches in the debian package :')
<Pellescours>I have libpciaccess and libpciaccess-dev installed and configures says no to HAVE_LIBPCIACCESS…