The device is an usb magneto-optical drive called "FUJITSU DynaMO 2300 U2". Mainboard is ASUS P4P800 Deluxe with Pentium4 2.8GHz. The problem: When this drive is on and connected to an usb-port before pc power-on, the system (2.6.16.13-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 2.6.16.20-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: /var/log/messages: 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, idProduct=101e Jun 10 21:32:09 linux99 kernel: usb 1-5: new device strings: Mfr=73, Product=82, SerialNumber=109 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 scanning 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 Rev: 0030 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 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.