IRC channel logs

<damo22>i fixed SMP gnumach on my AMD

<damo22>patch coming shortly

<ZhaoM>damo22: congrat \o/

<damo22>now AHCI is still not working on my AMD, but thats a problem with rump not gnuamch

<ZhaoM>quite lucky my laptop is also AMD

<damo22>youpi: thanks for review, i am addressing the comments now, but i cannot locate documentation for correct mode of STARTUP IPI

<damo22>it boots on a x220

<damo22>but same issue with AHCI

<damo22>so smp is working on qemu, intel hw and amd hw

<damo22>i cant tell if acpi is failing or rumpdisk because the log prints too fast on real hw

<damo22>thats why i need serial console

<damo22>Pellescours: ping

<damo22>503 Backend is unhealthy [IP: 151.101.82.132 80]

<damo22>deb.debian.org/debian-ports/....

<damo22>works now

<damo22>youpi: https://paste.debian.net/plain/1340861

<damo22>boot log from AMD fam16h with 2 cores

<damo22>i upgraded the system using unreleased and ports, but it seems not to have acpi changes?

<damo22>i dropped in gnumach from master

<damo22>"TODO: add interrupt handler for acpi"

<damo22>rumpdisk random init open failed

<damo22>[ 1.0800050] vendor 1022 product 7801 (SATA mass storage, AHCI 1.0, revision 0x40) at pci0 dev 17 function 0 not configured

<damo22>heres log with UP and newer acpi / rumpdisk https://paste.debian.net/plain/1340863

<damo22>solid_black: See above log

<damo22>irqhelp: cannot start this irq thread

<damo22>some race i think

<solid_black>where's the caller of irqhelp_server_loop?

<damo22>in my new pci-userspace changes

<damo22>note i am using my branch with rump 10.99.12

<damo22>thanks to Pellescours

<damo22>solid_black: https://git.zammit.org/rumpkernel-debian.git/log/

<damo22>i think my version of rumpdisk expects acpi to be already ready to run

<damo22>but they are starting almost at the same time

<damo22>im not sure how to in general start up services in a sequence when the next one relies on the previous one being up

<damo22>what we have now is clumsy at best

<damo22>solid_black: https://paste.debian.net/plain/1340871 i put in a 3 second delay into rumpdisk but it still fails even though it boots in the right sequence now

<azert>damo22: does netbsd boots on that machine?

<damo22>no idea

<Pellescours>damo22: pong

<damo22>Pellescours: something is failing in ahcisata_pci.c ahci_pci_match() we need to debug this

<damo22>even with rump 10.99.12

<youpi>damo22: ? acpi starts before rumpdisk and unleashes it only after setting up

<youpi>thanks to the next-task parameter

<damo22>well its not working that way

<damo22>i think rump_init() is called too early

<youpi>to early compared to what?

<damo22>somehow the acpi translator has not reached "PASS" before rump_init is called

<youpi>if some acpi initialization is too late, then move it up inside acpi

<damo22>so the end of acpi_init()

<youpi>it's called after machdev_trivfs_init so that would need shifting indeed

<youpi>in pci-arbtier too, probably

<youpi>that being said, all acpi & pci-arbiter need to have done is just to have allocated ports etc. to be able to receive messages

<youpi>they don't need to have initialized the rest, they'll answer the messages when they are ready

<damo22>perhaps this race is causing rumpdisk to fail overall even with a delay i added to debug

<youpi>if you have added a delay and it still fails, it's not due to a arce

<damo22>i havent added a delay to acpi

<damo22>maybe pci-arbiter and acpi have the same bug

<youpi>I don't mean a delay to acpi

<youpi>but a delay to rumpdisk to avoid initializing before acpi is done

<damo22>yeah i did that and it still fails

<youpi>so it's not a race

<youpi>and the bug is somewhere else

<damo22>what if acpi cannot talk to pci

<damo22>because pci is not ready

<youpi>ah, that, yes, possibly

<youpi>then put a delay there too for that other kind of race

<damo22>ok

<damo22>PASS!

<damo22>irqhelp: cannot start this irq thread

<damo22>rumpdisk

<damo22>random init open failed

<damo22>we see the same problem on qemu with -smp 2

<damo22>bed

<Pellescours>damo22: ok, I'll took at it

<gnu_srs>Hi, still no hurd-amd64 visible at: https://buildd.debian.org/stats/graph-ports-week-big.png?

<youpi>I've asked for it yesterday

<gnu_srs>OK

IRC channel logs

2024-12-22.log