Opened 10 years ago

Closed 7 years ago

Last modified 15 months ago

#3999 closed bug (fixed)

Boot hangs at ohci ownership change when C1E is enabled

Reported by: meianoite Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers Version: R1/pre-alpha1
Keywords: Cc: cpr420@…
Blocked By: Blocking: #7478, #8983
Has a Patch: no Platform: All

Description (last modified by mmlr)

See comment:5 for the distilled problem.

When I boot Haiku, the bootloader hangs on the third icon indefinitely. The first time I saw this I intended to reboot and enable the onscreen debug console, but for some reason I hit the power button instead of the reset one. And the boot continued!!

Puzzled, I rebooted, enabled the debug console, hit "p" to disable paging, and arrived at the text shown on the two attached pictures. "before" shows the kernel hung at the "usb ohci -1: smm is in control of the host controller" message. "after" shows what happens immediately after I hit the power button.

Syslog with timestamps is attached as well. But it's from a different session, as when I boot with onscreen debugging Haiku will hang on a black screen at the very end of the boot instead of going to the desktop (and that I tried using a FAT-formatted USB stick, but it KDL'd when I copied the syslog to it). Notice that for some unknown (to me) reason, the timestamps are within the same second, instead of being apart by the several minutes I waited between taking both screenshots (and hitting the power button, consequently). For example, JPEG EXIF data shows the "before" picture was taken at 16h18m44s, and the "after" picture at 16h21m18s. I guess what is timestamped is the buffer, and not the message itself.

Also attached is the output from dmesg from a verbose boot of FreeBSD on the same machine. Hope it helps.

I can of course change any compilation options to help debug this. The image is build on FreeBSD, but I've built Haiku on Haiku proper (yay!) and the same symptom shows. Makes no difference if I'm booting from a USB stick or from the hard drive (syslog is from a HD boot).

The motherboard BIOS is flashed to the latest version found on Asus' site. I have *no* idea why ACPI is showing _ASUS_ Notebook as the vendor identifier, as this is straight from Asus, flashed scratch with bootblock rewriting, ESCD cleared, CMOS cleared and everything I could think of to make it as pristine as possible, and not any modded/hacked BIOS.

I tried both with USB peripherals attached or detached; made no difference. Also tried inserting and removing peripherals while the boot is hung, no difference as well. There's one peripheral I couldn't detach, which is the RTL8187 WLAN interface that's build in on the motherboard; it connects straight to a special, internal USB header. I hope it's not the culprit, but still, only Haiku refuses to boot/requires hitting the power button in the middle of the boot process to continue loading, so...

Attachments (6)

before.jpg (432.7 KB ) - added by meianoite 10 years ago.
Before hitting the power button
after.jpg (427.2 KB ) - added by meianoite 10 years ago.
After hitting the power button
syslog.txt (168.2 KB ) - added by meianoite 10 years ago.
Syslog, unfortunately not from the same session, but same symptoms
dmesg.txt (49.7 KB ) - added by meianoite 10 years ago.
Verbose 'dmesg' output from FreeBSD
syslog_no_ohci.txt (162.3 KB ) - added by meianoite 10 years ago.
Syslog with ohci removed; PS/2 kb/mouse became unusable
syslog_msmouse.txt (162.8 KB ) - added by meianoite 10 years ago.
What syslog says when I re-enable ohci and plug my USB mouse

Download all attachments as: .zip

Change History (26)

by meianoite, 10 years ago

Attachment: before.jpg added

Before hitting the power button

by meianoite, 10 years ago

Attachment: after.jpg added

After hitting the power button

by meianoite, 10 years ago

Attachment: syslog.txt added

Syslog, unfortunately not from the same session, but same symptoms

by meianoite, 10 years ago

Attachment: dmesg.txt added

Verbose 'dmesg' output from FreeBSD

comment:1 by mmlr, 10 years ago

It's not entirely surprising actually. It's not a problem of UHCI though, as you don't have UHCI controllers at all ;-) I think it's also not a problem in OHCI though. It cannot really do other than it does. What I'd find more likely is that it's because of ACPI enabling/expecting IO-APIC interrupt routing while we don't do that yet. In that case generating an interrupt (by hitting the power-button ACPI is signaled) it could unjam whatever loop it was in, waiting for interrupts. Does it work when you have ACPI disabled?

comment:2 by meianoite, 10 years ago

Summary: Boot hangs (with a twist) as uhci driver tries to take ownershipBoot hangs (with a twist) as ohci driver tries to take ownership

comment:3 by meianoite, 10 years ago

Doh, sorry, sure it was "ohci" and not "uhci". Changed the title of the ticket accordingly.

Rebooting with ACPI disabled did nothing. Removing the "ohci" driver did allow the boot to continue without requiring me to hit the power button, though! But at the end of the boot I couldn't use neither keyboards nor mice, USB or PS/2.

Another thing that doesn't work is a USB mouse that I have here.

Really strange.

Attached now are syslogs of booting without the "ohci" driver and booting back with the "ohci" driver in place and with the USB mouse attached, but unable to be used. Might shed a light on the cause of those issues. Of course, I'm still available for compiling with any debugging options you'd like me to.

by meianoite, 10 years ago

Attachment: syslog_no_ohci.txt added

Syslog with ohci removed; PS/2 kb/mouse became unusable

by meianoite, 10 years ago

Attachment: syslog_msmouse.txt added

What syslog says when I re-enable ohci and plug my USB mouse

comment:4 by meianoite, 10 years ago

By the way, this is what FreeBSD has to say when I plug the USB mouse:

ugen0.3: <Microsoft> at usbus0 ums0: <Microsoft Wireless Optical Mouse 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 3> on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=17

An educated guess is that the relevant line on the Haiku syslog (the one I just attached) regarding this mouse is:

2009-06-06 06:33:12 KERN: usb_hid: unsupported device type 0x01090c05

In this case, it's just usb_hid not getting the device type (doh), and nothing related to the problem at hand. Still, it would be nice to support this mouse :)

comment:5 by meianoite, 10 years ago

I just found out that disabling C1E (option AMD CPU C1E Support) on the BIOS allows the boot to proceed. So yes, some interrupt is being missed with C1E turned on.

Info on C1E: http://ixbtlabs.com/articles2/intel-thermal-features-2/ehs.html

Feel free to repurpose this ticket to the appropriate component/owner if that's the case; still, if ohci is disabled the boot continues as well, and this might hint at the reason.

comment:6 by mmlr, 8 years ago

Description: modified (diff)
Summary: Boot hangs (with a twist) as ohci driver tries to take ownershipBoot hangs at ohci ownership change when C1E is enabled

Repurposing this for the C1E problem.

comment:7 by mmlr, 8 years ago

Blocking: 7478 added

(In #7478) As per comment:7 this is a duplicate of #3999.

comment:8 by augiedoggie, 8 years ago

Cc: cpr420@… added

comment:9 by augiedoggie, 8 years ago

Mine also suffers from this problem and is fixed by disabling C1E.

ASUS M4A89GTD Pro/USB3 (AMD 890GX/SB850)

AMD PhenomII X4

comment:10 by Mictlantecuhtli, 8 years ago

Same here, disabling C1E helps. AMD 890FX/SB850 chipset & Phenom II X6.

comment:11 by scottmc, 8 years ago

Can you recheck this with a recent Haiku build? It may have been fixed recently.

comment:12 by scottmc, 8 years ago

Blocking: 7665 added

in reply to:  11 comment:13 by meianoite, 8 years ago

Replying to scottmc:

Can you recheck this with a recent Haiku build? It may have been fixed recently.

No dice, unfortunately. Even sadder is that the machine I just tested doesn't take the power button workaround :(

Disabling C1E takes the boot as far as the blue desktop with cursor, then something else hangs. Not sure what, yet.

hrev41945, latest available anyboot build. Will try a more recent build when one is uploaded.

Last edited 8 years ago by meianoite (previous) (diff)

comment:14 by Mictlantecuhtli, 8 years ago

C1E still broken here in hrev42192.

comment:15 by yongcong, 7 years ago

Dear all,

would you please try the patch in #8111. I think the patch may fix the problem.

I hit the power button instead of the reset one. And the boot continued!!

Because the CPUs are waken up once the power button hit ;)

Dear meianoite,

AMD C1E is different with intel C1E. AMD C1E is a BIOS controlled C3 state. The difference between C1E and C3 is that transition into C1E is not initiated by the operating system. system will enter C1E state automatically when both cores enters C1 state.

As for intel C1E, it means "reduce CPU voltage before entering corresponding Cx-state"

comment:16 by tqh, 7 years ago

The patch is applied in hrev44025. Please test with nightly that has this change.

comment:17 by mks, 7 years ago

I had the same bug (although I couldn't continue booting by pressing the power button) and can confirm that the patch fixes it. My system boots fine now. (Actually tested with 44030)

comment:18 by tqh, 7 years ago

Resolution: fixed
Status: newclosed

Thx for the feedback. Closing.

comment:19 by anevilyak, 7 years ago

Blocking: 8983 added

comment:20 by waddlesplash, 15 months ago

Blocking: 7665 removed
Note: See TracTickets for help on using tickets.