Zhaoming Luo, le mar. 29 avril 2025 11:06:47 +0800, a ecrit: > On Tue, Apr 29, 2025 at 02:19:30AM +0000, Damien Zammit wrote: > > Hi, this is very interesting and probably indicating that we need to fix > > race between previous servers starting up and next ones, as you mentioned.
I don't think it's such kind of race. The output getting mixed doesn't help to see what happens, of course (both rump and ACPI should buffer per-line with setlinebuf() to avoid this), but provided that rump itself doesn't touch ACPI registers or such, it can initialize in parallel with ACPI, that's fine. What is needed is only that ACPI's RPC for providing IRQ numbers waits for the acpi initialization to be over. > > What happens if you put a sleep(5) before rump_init() in rumpdisk, does > > ahci boot? > > Just tried it. Log: https://paste.debian.net/1372174/ > It seems to me that it's not the issue with ACPI. The log of ACPI (the > log before `PASS!`) is tidy. Assume ACPI has got enough time from > sleep(5) to finish initialization. It seems there is something else > having data race with rumpdisk. > > In: > ``` > rumpdisk r[a n 1.000000d0] Copyrighot (c) 1996m, 19i97n, i19t98, 1999, > 2000, 20o01, 2002,p 2e00n3, > [ f a1.00i000l00e] 2d00 > ``` There is more ACPI initialization going on here, see later on "aluation : _SB.PCI0._PRT (Method)" > We can see 'random init open faile`. No idea where does it come from. I'm getting that in my box too, so that probably doesn't harm. What is more concerning is: piixide0:0:0: lost interrupt So the user-level interrupt mechanism should be checked. But overall it seems it only sees cd0, the CD drive, plugged on piixide, so not AHCI. Did you check that your AHCI controller is actually supported by rumpdisk (e.g. running lspci in Linux and check that the PCI vendor/product showing up there do show up in the rumpdisk code)? Samuel
