Boot hangs at ohci ownership change when C1E is enabled

[meianoite]

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...

[meianoite]

Before hitting the power button

[meianoite]

After hitting the power button

[meianoite]

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

[meianoite]

Verbose 'dmesg' output from FreeBSD

[mmlr]

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?

[meianoite]

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.

[meianoite]

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

[meianoite]

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

[meianoite]

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 :)

[meianoite]

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.

[mmlr]

Repurposing this for the C1E problem.

[mmlr]

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

[augiedoggie]

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

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

AMD PhenomII X4

[Mictlantecuhtli]

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

[scottmc]

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

[meianoite]

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.

[Mictlantecuhtli]

C1E still broken here in hrev42192.

[yongcong]

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"

[tqh]

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

[mks]

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)

[tqh]

Thx for the feedback. Closing.