Distribution: Debian unstable Hardware Environment: Sony Vaio C1 Picturebook Software Environment: console Problem Description: Complete system stall on probing uhci-hcd The laptop is a Transmeta based X86 machine. On probing 'uhci-hcd' I get the following three lines of output (had to manually copy this so it may contain typos): PCI: Found IRQ 9 for device 0000:00:07.2 PCI: Sharing IRQ 9 with 0000:00:08.0 uhci-hcd 0000:00:07.2: UHCI Host Controller And then the machine is dead (test5-mm4 showed the same behaviour). Pressing Alt+SYSRQ keys does nothing. Using "acpi=off" has no effect - probing with/without devices attached to USB has no effect either. The hardware worked flawlessly with 2.4's 'uhci' module (with ACPI enabled). I'll attach lspci, config and interrupts. Steps to reproduce: modprobe uhci-hcd
Created attachment 955 [details] lspci -v output
Created attachment 956 [details] cat /proc/interrupts
Created attachment 957 [details] kernel config
*** This bug has been marked as a duplicate of 1186 ***
Marking this as a dupe of 1186 suggests this is related to ACPI. However: 1. The patch (903) attached to Bug 1186 doesn't fix this. 2. I compiled 2.6.0-test6 with ACPI disabled - same lockup. 3. ACPI never really was enabled (it claims BIOS is too old) Overriding with acpi=force works, but results in same lockup I recompiled 2.6.0-test6 with USB_DEBUG enabled: no extra output. I have to correct my claim that this happens with and without devices connected - the laptop has a memory stick reader built-in that is of course always connected to the USB bus. So I cannot test without devices connected at all. Any chance you can point me to the patch that fixed 1186 for you so I can confirm this is a dupe? I tried some goolging but to no avail.
Applying the "acpi_pci_link_allocate" patch as suggested for #1186 doesn't fix this (*). The system will still stall with acpi=force and acpi=off. The behaviour before stalling is slightly different however: with ACPI disabled you see PCI: Found IRQ 9 for device 0000:00:07.2 PCI: Sharing IRQ 9 with 0000:00:08.0 when probing uhci-hcd (as in the original report comment) - with ACPI enabled these two lines are missing (as the PCI interrupts get assigned at boottime (I assume)). (*): The patch neither applies to test5 nor test6 - if I read the patch correctly it only moves the relevant for loop into the else statement above - which I did manually.
To ensure I haven't made a mistake with the original patch I just tested 2.6.0-test6-mm2 that has the "acpi-pci-irq-fix-439.patch" from Linus' tree included - which closed Bug #1186. However this bug remains - the system still locks up with "acpi=force" and with "acpi=off". So I think it should be OK to reopen this bug. Is it possible to output and validate the IRQ vector that is being assigned to uhci-hcd? Is there any additional debug information I can provide? All other PCI devices work flawlessly.
I failed to trace down which patch actually fixes this issue, but 2.6.0-test6-mm4 resolves this bug. Probing uhci-ecd works without problems.
Submitter said this bug is fixed in recent kernels.