<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>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:127.0.0.1:2222-:22 -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? <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 <Pellescours>It failed… big words, it failed to find the partition on wd0 <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 <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>for some reason there is a regression with wd0 disk detection <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>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>it seems that when pci-arbiter is started at boot, rump does not work <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 <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>possibly pci-arbiter just crashes <Pellescours>so yes probably crash at boot, this would explain why rump fails to see sata disk <Pellescours> --multiboot-command-line='${kernel-command-line}' \ <Pellescours> --exec-server-task='${exec-task}' -T typed '${root}' \ <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 have libpciaccess and libpciaccess-dev installed and configures says no to HAVE_LIBPCIACCESS…