Opened 10 years ago

Closed 8 years ago

#4718 closed bug (fixed)

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

Reported by: jedie Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/USB Version: R1/Development
Keywords: Cc: dev.haiku-os.org@…
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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

Attachments (7)

lshw.txt (17.5 KB) - added by jedie 10 years ago.
lspci.txt (1.8 KB) - added by jedie 10 years ago.
lsusb.txt (487 bytes) - added by jedie 10 years ago.
dmesg.txt (39.4 KB) - added by jedie 10 years ago.
DSC01034.JPG (199.8 KB) - added by jedie 10 years ago.
boot debug screenshot
lspcioutput (5.5 KB) - added by silentjohn 8 years ago.
lspci -nv output
screenshot1.JPG (316.0 KB) - added by silentjohn 8 years ago.

Download all attachments as: .zip

Change History (22)

Changed 10 years ago by jedie

Attachment: lshw.txt added

Changed 10 years ago by jedie

Attachment: lspci.txt added

Changed 10 years ago by jedie

Attachment: lsusb.txt added

Changed 10 years ago by jedie

Attachment: dmesg.txt added

comment:1 Changed 10 years ago by jedie

Cc: dev.haiku-os.org@… added

Changed 10 years ago by jedie

Attachment: DSC01034.JPG added

boot debug screenshot

comment:2 Changed 10 years ago by mmlr

Broken hardware...

applying AMD SB600/SB700 USB freeze workaround

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

comment:3 in reply to:  2 Changed 10 years ago by jedie

Replying to mmlr:

Did you try disabling legacy support in the BIOS?

Yes, than i can boot haiku, thanks.

comment:4 Changed 8 years ago by 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.

comment:5 Changed 8 years ago by korli

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

Changed 8 years ago by silentjohn

Attachment: lspcioutput added

lspci -nv output

comment:6 in reply to:  5 Changed 8 years ago by silentjohn

Replying to korli:

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

Sure, attached.

comment:7 Changed 8 years ago by 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.

Changed 8 years ago by silentjohn

Attachment: screenshot1.JPG added

comment:8 Changed 8 years ago by 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

comment:9 Changed 8 years ago by 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?

comment:10 Changed 8 years ago by korli

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

comment:11 in reply to:  10 Changed 8 years ago by silentjohn

Replying to korli:

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

Everything is the same (output, result) :(

comment:12 Changed 8 years ago by 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.

comment:13 in reply to:  12 Changed 8 years ago by 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.

comment:14 Changed 8 years ago by 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 :)

comment:15 in reply to:  14 Changed 8 years ago by mmlr

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.