Bug 6679
| Summary: | early boot hang with USB MO disk present, unless acpi=off | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | peter.schlaf |
| Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | acpi-bugzilla, bunk, protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.16.13-4-smp, 2.6.16.20-smp | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 5089 | ||
| Attachments: |
output "dmesg -s64000" with acpi on and drive added after boot
output "dmesg -s64000" with acpi=off and drive added before boot output "cat /proc/interrupts" with acpi on and drive added after boot output "cat /proc/interrupts" with acpi=off and drive added before boot |
||
|
Description
peter.schlaf
2006-06-11 13:52:42 UTC
you can get your 2nd logical cpu back with "acpi=ht" What happens if you exclude USB from the kernel build, does it boot with ACPI then? Booting with "acpi=ht" on kernels 2.6.16.13-4-smp and 2.6.16.20-smp gives a system freeze as described before. Following your request a new kernel 2.6.16.20-smp was build with USB support disabled (make menuconfig: changed "Device Drivers->USB support->Support for Host-side USB" from "M" to "N") and it was confirmed that this kernel couldn't detect any usb device. With this kernel and the drive connected and on the system freezes. No matter on which of the 4 available onboard usb ports this drive is connected to. No matter if there is a formatted medium inserted or not. The computer doesn't freeze, if: - drive is connected AFTER pc power-on (or reboot, respectively) and BEFORE appearance of grub menu. - drive is connected to an usb port of an additional inserted usb pci card. During boot mainboard BIOS (ASUS P4P800 ACPI BIOS Revision 1019) says: USB Device(s): 1 Storage Device This drive was connected to an onboard usb port of another PC (Gigabyte 6BXE Rev 1.9 mainboard, SuSE 10.1, kernel 2.6.16.13-4-smp) and there was no freeze. It seems that when this drive is present upon BIOS initialization, the BIOS does something evil that kills an ACPI-enabled Linux so early that it will be very difficult to figure out why. Indeed, it must be in the table parsing code, because you found that "acpi=ht" still hangs, and the only part of ACPI that "acpi=ht" runs is the table parsing code. Are there any BIOS options, perhaps related to boot order or USB that have an effect on this failure? Please attach the output from dmesg -s64000 and paste the output from /proc/interrutps for a successful ACPI-enabled boot with the drive later added. Please do the same for the drive-present acpi=off boot. Created attachment 8749 [details]
output "dmesg -s64000" with acpi on and drive added after boot
Created attachment 8750 [details]
output "dmesg -s64000" with acpi=off and drive added before boot
Created attachment 8752 [details]
output "cat /proc/interrupts" with acpi on and drive added after boot
Created attachment 8754 [details]
output "cat /proc/interrupts" with acpi=off and drive added before boot
OK. Booting is done with this basic configuration: Kernel 2.6.16.21-0.13-smp (SuSE 10.1 Linux) with kernel options "resume=/dev/md2 splash=silent showopts" and MO-drive connected and on. Mainboard-BIOS has 3 entries for ACPI: ACPI 2.0 support -> Yes/No ACPI APIC support -> Enabled/Disabled BIOS -> AML ACPI table -> Enabled/Disabled 3 entries, each has 2 selections => 8 combinations. Every combination gave a freeze. After that every entry was set back to Yes/Enabled. USB has 5 entries in mainboard-BIOS and these are the settings that gave a freeze: USB Function -> Disabled/2/4/6/8 USB Ports (set: 8 USB Ports) Legacy USB Support -> Auto/Enabled/Disabled (set: Auto) USB 2.0 Controller -> Enabled/Disabled (set: Enabled) USB 2.0 Controller Mode -> FullSpeed/HighSpeed (set: HighSpeed) USB Mass Storage Device Configuration: Emulation Type -> Auto/Floppy/Forced FDD/Hard Disk/CDROM (set: Auto) I took the settings above as default and changed one entry only for each test: Test 1: USB Function set to "Disabled" -> boot ok Test 2: Legacy USB Support set to "Disabled" -> boot ok Test 3: USB 2.0 Controller set to "Disabled" -> boot ok Test 4: USB 2.0 Controller Mode set to "FullSpeed" -> boot ok Test 5: Emulation Type set to "Hard Disk" -> freeze Test 6: Emulation Type set to "Floppy" -> freeze Note: Disabling "USB Function" removes the other 4 entries from the BIOS menu. Disabling "USB 2.0 Controller" removes "USB 2.0 Controller Mode". It looks strange to me that HighSpeed (480 Mbps) freezes, but FullSpeed (12Mbps) is ok (???). The requested 4 files are attached (dmesg + /proc/interrupts for acpi on/off). Clearly this is a platform specific bug that is related to the BIOS USB support. Can Linux still access the disk if the BIOS USB support is disabled? But is isn't clear how that is killing Linux boot. In particular, I'm really surprised that the system works with "acpi=off" but does not work with just "acpi=ht". Can you double check that? This really shouldn't be the case -- maybe we broke "acpi=ht" along the way -- not many people use it anymore. We could comment out the things we do with acpi=ht one by one until it is equivalent to "acpi=off", and find out what part is stepping on this landmine... We could also insert some beeps to make sure the kernel is getting where it should be. eg. does it get to acpi_boot_table_init()... and then move the beeps back until they are after the hang. Is it possible to hook up a serial console to see if we can capture the boot messages that way? just for grins, please also try "hpet=disable" Oh bugger! You are right! The system boots perfectly with acpi=ht on kernels 2.6.16.13-4-smp, 2.6.16.20-smp and 2.6.16.21-0.13-smp. And both cpus are visible with "cat /proc/cpuinfo". I really don't know what went wrong with my previous tests with acpi=ht. With no mo-drive and acpi=on it takes 3 seconds between kernel image being selected in grub boot menu and the first appearance of boot messages on screen. With mo-drive and acpi=ht it takes 11 seconds before boot messages show up. So I suppose I simply had no patience to wait longer than the usual black-screen-period I'm familiar with and hit the reset button too early. And finally I draw the wrong conclusion, that acpi=ht is freezing the system. Anyway. That was my fault. Sorry. acpi=ht is OK! But with acpi=on and this drive there REALLY is a freeze. That's for sure! -> BIOS USB support: If "USB Function" is set to "disabled", there is no access to this drive from Linux. "lspci" shows no usb-controller on the system. If "USB 2.0 Controller" is set to "disabled", the drive is still accessible from Linux. "lspci" shows: 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) but the line 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) has disappeared. Serial console: What do I need for that? I have a second pc with linux and some sort of serial cable. hpet=disable gave a freeze. > acpi=ht is OK! okay, sanity prevails then. > hpet=disable gave a freeze. you mean it had no effect on the existing freeze, yes? Based on your results from playing with the BIOS SETUP USB options, it seems that there is some bad interaction between the BIOS USB emulation and Linux. I don't know why it goes away with "acpi=ht". You are running IOAPIC mode with and without ACPI. > HighSpeed (480 Mbps) freezes, but FullSpeed (12Mbps) So if you set BIOS SETUP for USB to run fullspeed, then you can boot and run with no kernel parameters? I'm going to bounce this over to the USB guys for their opinion. Any updates on this problem? Thanks. |