Haiku won't boot on Asus M3A78-EMH HDMI: USB Problems

[jedie]

I tried: haiku-nightly-hrev33411-x86gcc4-cd.zip Boot hangs with USB problems.

[jedie]

boot debug screenshot

[mmlr]

Broken hardware...

applying AMD SB600/SB700 USB freeze workaround

It's a quirk. Did you try disabling legacy support in the BIOS?

[jedie]

Replying to mmlr:

Did you try disabling legacy support in the BIOS?

Yes, than i can boot haiku, thanks.

[silentjohn]

I have the same problem on my motherboard (Gigabyte MA78LM-S2, AMD780G/SB700) with hrev41249 and only the turning off the whole USB subsystem helps to prevent this issue.

[korli]

Silentjohn, could you please attach the output of "lspci -nv" on Linux if you have it installed?

[silentjohn]

lspci -nv output

[silentjohn]

Replying to korli:

Silentjohn, could you please attach the output of "lspci -nv" on Linux if you have it installed?

Sure, attached.

[korli]

Linux seems to use some quirks with this chipset, but it applies them only when it has taken ownership, which seems to fail on Haiku. These quirks won't probably help.

From the screenshot DSC01034.JPG, it looks like ehci tries to take ownership whereas the check for bios ownership failed (message is absent).

Which messages do you observe? The source code isn't in sync with the screenshot of this bug anymore. A nice screenshot would help.

[korli]

Silentjohn, do you build Haiku yourself? If so, could you patch with this and test whether there is a difference?

Index: src/add-ons/kernel/busses/usb/ehci.cpp
===================================================================
--- src/add-ons/kernel/busses/usb/ehci.cpp	(revision 41255)
+++ src/add-ons/kernel/busses/usb/ehci.cpp	(working copy)
@@ -215,10 +220,10 @@
 			sPCIModule->write_pci_config(fPCIInfo->bus, fPCIInfo->device,
 				fPCIInfo->function, extendedCapPointer + 4, 4, 0);
 		} else {
-			TRACE("extended capability is not a legacy support register\n");
+			TRACE_ALWAYS("extended capability is not a legacy support register\n");
 		}
 	} else {
-		TRACE("no extended capabilities register\n");
+		TRACE_ALWAYS("no extended capabilities register\n");
 	}
 
 	// disable interrupts

[silentjohn]

No, I don't, I don't have an unused machine for this task. I'll get a suitable configuration on Thursday and then I'll do the patching and compiling work (on weekend in worst case). Is it suitable for you?

[korli]

It's committed anyway in hrev41270. Please test with it.

[silentjohn]

Replying to korli:

It's committed anyway in hrev41270. Please test with it.

Everything is the same (output, result) :(

[korli]

OK. If that's possible for you, try to enable tracing in src/add-ons/kernel/bus_managers/usb/usb_private.h by uncommenting #define TRACE_USB, build an iso and check if any ehci related messages are displayed.

[mmlr]

Replying to korli:

If that's possible for you, try to enable tracing in src/add-ons/kernel/bus_managers/usb/usb_private.h by uncommenting #define TRACE_USB, build an iso and check if any ehci related messages are displayed.

Let's be cautious not to mix things here. The original bug report is old and the attached picture doesn't reflect the current state of the code. A similar problem was tracked in #2083 and has been fixed in hrev35780. Therefore the original issue in this bug report is most likely fixed as well.

So silentjohn needs to provide an updated output to see what's actually going on. Please consider the most likely case of this being another duplicate of #5551 i.e. the generic interrupt problem on SBx00 chipsets. Since the ATA driver in use by linux seems to be the atiixp one (according to the attached output), this might even be the even more generic timer interrupt / interrupt configuration problem seen in #2342 (I suspect those two issues to overlap anyway).

If it is a duplicate of an existing bug then please add a comment there. If it is a new issue then please open a new ticket, as this ticket should really be closed as fixed in hrev35780.

[korli]

As the problem seems to resolve itself by "turning off the whole USB subsystem", I tend to investigate a bit more in this direction. An updated screenshot screenshot1.JPG was provided already. Nothing appears in the syslog except ohci related messages.

Having more traces by enabling them will give us more insights on whether classify this bug as a duplicate or not. And you're right, let's not mix things here :)

[mmlr]

Replying to korli:

As the problem seems to resolve itself by "turning off the whole USB subsystem", I tend to investigate a bit more in this direction. An updated screenshot screenshot1.JPG was provided already. Nothing appears in the syslog except ohci related messages.

I missed that screenshot for some reason, but it makes it obvious that this is an OHCI legacy handover problem. It therefore definitely belongs into another bug report. There might be one already, otherwise please create a new one. I'll close this one as the issue in this report was fixed.

Having more traces by enabling them will give us more insights on whether classify this bug as a duplicate or not. And you're right, let's not mix things here :)

Highly unlikely. The next step after that output is writing the ownership change request. If it hangs there it is the BIOS messing things up, most probably causing a system management interrupt storm. So you can't really put any more output there but need to add a quirk workaround like others do. Quite possibly the freeze workaround linux applies concerns exactly this problem. Please open a new bug report with the relevant info so we can work from there as this report is getting long again.