Kernel Bug Tracker – Bug 6679
early boot hang with USB MO disk present, unless acpi=off
Last modified: 2008-09-22 16:40:11 UTC
The device is an usb magneto-optical drive called "FUJITSU DynaMO 2300 U2".
Mainboard is ASUS P4P800 Deluxe with Pentium4 2.8GHz.
When this drive is on and connected to an usb-port before pc power-on, the
system (220.127.116.11-4-smp from SuSE 10.1) freezes immediately after the linux
kernel was selected from grub boot menu (no output on screen at all and no
change of num-led by hitting num-key). It's 100% reproducible.
If booting is done with "acpi=off" there is no freeze and everything is fine.
Bad sideeffect: usual two cpu instances are visible in /proc/cpuinfo when
hyperthreading is enabled. With "acpi=off" only one cpu is visible.
Upgrading to kernel 18.104.22.168-smp or using boot-option "nosmp" or "acpi=noirq"
instead of "acpi=off" didn't solve the problem.
When this drive gets connected to an usb-port after booting, the kernel detects
the device and it is usable without any problem:
Jun 10 21:32:09 linux99 kernel: usb 1-5: new high speed USB device using
ehci_hcd and address 2
Jun 10 21:32:09 linux99 kernel: usb 1-5: new device found, idVendor=04c5,
Jun 10 21:32:09 linux99 kernel: usb 1-5: new device strings: Mfr=73, Product=82,
Jun 10 21:32:09 linux99 kernel: usb 1-5: Product: USB Magneto-Optical Device
Jun 10 21:32:09 linux99 kernel: usb 1-5: Manufacturer: FUJITSU
Jun 10 21:32:09 linux99 kernel: usb 1-5: SerialNumber: 0047015070251000
Jun 10 21:32:09 linux99 kernel: usb 1-5: configuration #2 chosen from 1 choice
Jun 10 21:32:09 linux99 kernel: Initializing USB Mass Storage driver...
Jun 10 21:32:09 linux99 kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Jun 10 21:32:09 linux99 kernel: usb-storage: device found at 2
Jun 10 21:32:09 linux99 kernel: usb-storage: waiting for device to settle before
Jun 10 21:32:09 linux99 kernel: usbcore: registered new driver usb-storage
Jun 10 21:32:09 linux99 kernel: USB Mass Storage support registered.
Jun 10 21:32:14 linux99 kernel: Vendor: FUJITSU Model: MCJ3230UB-S
Jun 10 21:32:14 linux99 kernel: Type: Direct-Access
ANSI SCSI revision: 04
Jun 10 21:32:14 linux99 kernel: sd 2:0:0:0: Attached scsi removable disk sdc
Jun 10 21:32:14 linux99 kernel: sd 2:0:0:0: Attached scsi generic sg2 type 0
Jun 10 21:32:14 linux99 kernel: usb-storage: device scan complete
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 22.214.171.124-4-smp and 126.96.36.199-smp gives a
system freeze as described before.
Following your request a new kernel 188.8.131.52-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 184.108.40.206-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 220.127.116.11-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 18.104.22.168-4-smp,
22.214.171.124-smp and 126.96.36.199-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)
What do I need for that? I have a second pc with linux and some sort of serial
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?