Most recent kernel where this bug did not occur:2.6.14-rc4 Distribution:Debian unstable Hardware Environment:i386 Software Environment: Linux zmei 2.6.13 #1 SMP Mon Oct 3 14:58:00 CEST 2005 i686 GNU/Linux Gnu C 4.0.2 Gnu make 3.80 binutils 2.16.91 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre9 e2fsprogs 1.38 reiserfsprogs line reiser4progs line PPP 2.4.3 nfs-utils 1.0.7 Linux C Library 2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 udev 070 Modules Loaded isofs nfsd exportfs nfs lockd sunrpc parport_pc parport pcspkr tuner tvaudio bttv video_buf firmware_class i2c_algo_bit v4l2_common btcx_risc tveeprom i2c_core videodev rtc Problem Description: When I boot into 2.6.14-rc[3,4] (rc2 not tested yet) the console boot messages end with: [4294687.294000] usb usb3: Manufacturer: Linux 2.6.14-rc4 uhci_hcd [4294687.300000] usb usb3: SerialNumber: 0000:00:1d.2 [4294687.321000] hub 3-0:1.0: USB hub found [4294687.326000] hub 3-0:1.0: 2 ports detected [4294689.363000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 20 [4294689.372000] ehci_hcd 0000:00:1d.7: EHCI Host Controller [4294689.378000] ehci_hcd 0000:00:1d.7: debug port 1 and the machine hangs. USB debugging is enabled but it spits no more than that. Steps to reproduce:
bugme-daemon@kernel-bugs.osdl.org wrote: > > Most recent kernel where this bug did not occur:2.6.14-rc4 Could you please correct this?
Most recent kernel where this bug did not occur:None
*** Bug 5433 has been marked as a duplicate of this bug. ***
Just out of curiosity, does this happen if you boot with "acpi=off" on the boot command line?
Created attachment 6294 [details] early ehci irq disable This patch tweaks some BIOS-related behavior that can appear during initialization or with kexec(); it's in the 2.6.15 queue. It might explain the problem you're seeing. You might also try booting with "usb-handoff" set on the kernel command line.
Test results: 1. booting 14-rc4 with acpi=off doesn't help. 2. patching the kernel so that the ehci controller is halted before reboot doesn't help alone but... 3. the patched kernel with the "usb-handoff" boot option booted just fine. Tell me if you need more info.
Looks like your BIOS just demands the usb-handoff to be done early; there are some systems that need that. In fact, enough that we'll probably make that the default at some point. Since you now know about that flag, I'll close this bug.
is this patch going to enter 2.6.14 or it remains in the 2.6.15 queue?
Bug 5433 was marked as a duplicate of this bug, but I know for certain that my machine has worked without problems in the past and as such should not require any special kernel options. Please consider reopening the bug or making usb-handoff the default asap. I will be testing if it fixes my problem.
I applied the patch and added usb-handoff in the grub menu but it did not solve the problem.
To Petteri R
To Borislav Petkov ... the patch shouldn't be needed if you're using usb-handoff and the only issue you're seeing is at boot time. So it should be no problem for you that it won't be merged quite yet.
... however, I booted this morning with usb-handoff and it crashed at the same point again... maybe useb-handoff with the patch doesn't work OK. Should I remove the patch and use _only_ usb-handoff as a boot option?
2.6.14-rc5 doesn't boot with 'usb-handoff' and the machine halts at the same point in the boot process.
correction: the usb-handoff boot option helps only when you reboot. Otherwise, on initial boot, the machine hangs. For 2.6.14-rc5-mm1 this is also the case.
Closing this again. (a) 2.6.13 worked, contrary to comment #2, but most importantly (b) after a BIOS update, 2.6.14 works too.