Opened 15 years ago

Last modified 6 years ago

#3999 closed bug

Boot hangs at ohci ownership change when C1E is enabled — at Version 6

Reported by: meianoite Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers Version: R1/pre-alpha1
Keywords: Cc: cpr420@…
Blocked By: Blocking:
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...

Change History (12)

by meianoite, 15 years ago

Attachment: before.jpg added

Before hitting the power button

by meianoite, 15 years ago

Attachment: after.jpg added

After hitting the power button

by meianoite, 15 years ago

Attachment: syslog.txt added

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

by meianoite, 15 years ago

Attachment: dmesg.txt added

Verbose 'dmesg' output from FreeBSD

comment:1 by mmlr, 15 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, 15 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, 15 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, 15 years ago

Attachment: syslog_no_ohci.txt added

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

by meianoite, 15 years ago

Attachment: syslog_msmouse.txt added

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

comment:4 by meianoite, 15 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, 15 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, 13 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.

Note: See TracTickets for help on using tickets.