HDA removing MSIs breaks XHCI on 32 bit Haiku on Asus X570-Plus

[Illen]

This issue seems to be similar to #19160, however it's another problem that happens only on the 32 bit x86 build. The difference is that it happens regardless of the USB port being used for boot and debug output seems different.

[waddlesplash]

Did this always happen or is it a recent regression?

[Illen]

I don't know, because I couldn't boot older 32 bit Haiku revisions on this system (due to #19009).

[waddlesplash]

You should be able to work around #19009 by choosing "Ignore memory above 4GB" in the bootloader options.

[Illen]

That workaround didn't work for hrev58209 or hrev56737:

using 32 bit paging (PAE not available)
PANIC: error allocating early page!

Welcome to Kernel Debugging Land...
Thread 0 "" running on CPU 0
stack trace for thread 0 ""
    kernel stack: 0x00000000 to 0x00000000
frame               caller     <image>:function + offset
 0 81004d94 (+  32) 80158acf
 1 81004da0 (+  12) 8014602a
 2 81004dd0 (+  48) 800af890
 3 81004e20 (+  80) 800b0c90
 4 81004e60 (+  64) 800b101f
 5 81004e80 (+  32) 800b132f
 6 81004ed0 (+  80) 8012551a
 7 81004f30 (+  96) 80132fa4
 8 81004fd0 (+ 160) 8012ba17
 9 81004ff0 (+  32) 80062368
kdebug>

But it worked for r1beta4 and older.

So far I have tested:

• r1beta4 - can reach the installer but USB input doesn't work, xHCI error spam in log
• r1beta3 - can boot to desktop and works fine
• r1beta1 - kernel panics before even reading from the boot device

So it indeed seems to be a regression possibly introduced somewhere between beta3 and beta4.

[waddlesplash]

Can you try and narrow down where things broke between beta3 and beta4 a bit further? In case there aren't sufficient nightly builds to bisect, I will take a look and try and guess what commits might be interesting to try and revert from between beta3 and beta4. The first one I see is 6fd4a3eea980b268b17565fba8b287b0e306a9c3.

[Illen]

Unless I am missing some way to fetch older images, the oldest one still available is hrev56737. Unfortunately building is still broken for 32 bit x86 target on my host, is this a known problem?

../configure --cross-tools-source ../../buildtools --build-cross-tools x86_gcc2 --build-cross-tools x86 -j25 
creating cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... i586-pc-haiku
checking build system type... x86_64-unknown-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -fcommon ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

Will probably need to setup a Haiku VM for compiling 32 bit builds.

[waddlesplash]

GCC2 only works properly when compiled for 32-bits, so you'll need a 32-bit toolchain environment.

Though it's very strange this issue only happens on 32-bit Haiku and not 64-bit Haiku. I guess it could be a random timing issue (x86_64 is generally faster), but otherwise it seems pretty odd.

[Illen]

Ok, I've tried latest master with 6fd4a3eea980b268b17565fba8b287b0e306a9c3 reverted. Seems like there is no difference, any other commits to try?

[korli]

Did you try to boot with on-screen syslog enabled in the bootloader? It can help USB booting.

[Illen]

I tried now with and without on screen paging, doesn't affect this issue.

[waddlesplash]

Some more things to try:

• Disabling ACPI in the bootloader.
• Disabling SMP.

And other commits to try reverting (but there may be conflicts, so it may not be easy):

• 6c675bab59e4c6f45cef294271ff5ffeb2494a92
• d66430ec52ad6e56fce9c89ef30e5e13f4e69d7d
• 3a71862e998410fd3b2b823b26281be81dfa5b70

[Illen]

• Disabling ACPI made Haiku boot to desktop, one xHCI stall is still logged but it goes through fine
• Disabling SMP had no effect
• Disabling IO-APIC had similar effect as disabling ACPI

Now for the reverts:

• 6c675bab59e4c6f45cef294271ff5ffeb2494a92 - reverted 94d33dcbb61edd96d6090f4b02b1d2c448f1e829 first for clean revert - had no effect
• d66430ec52ad6e56fce9c89ef30e5e13f4e69d7d - had no effect
• 3a71862e998410fd3b2b823b26281be81dfa5b70 - reverted 4d21f567e77bd131fdb1afb3f9bc40acc52ad9fc first for clean revert - had no effect

[waddlesplash]

The problem likely isn't any of the changes to the XHCI loader then, but to ACPI somehow.

[waddlesplash]

Alternatively, the USB audio device may be messing things up somehow. Can you try a normal boot without the USB audio device attached; or the USB audio driver blocklisted?

[Illen]

The problem still happens with usbaudio disabled, the only difference is that "Missing service" spam in log is gone.

[waddlesplash]

Another interesting thing is that the problems start right after HDA frees its MSI vector. Can you try blocklisting HDA and see if that changes anything?

[Illen]

Without HD Audio Haiku was able to reach deskbar and seemed to work fine, but there is still massive xHCI spam in log and keyboard input is unresponsive.

[waddlesplash]

The spam is from the USB audio driver, please see if blocklisting that as well as HDA gets the keyboard working.

Since we can get to the desktop without HDA, this sounds like a problem with MSI routing.

[Illen]

Yep, the spam is gone and keyboard works fine when usbaudio is disabled too.

[waddlesplash]

This is probably two bugs then: USB audio endpoints don't get uninitialized properly on errors (probably a USB audio driver bug), and then HDA removing its MSI causes USB interrupts to stop working. Let's make this ticket about the latter.