Bug 1286

Summary:	System stall on probing uhci-hcd
Product:	Drivers	Reporter:	Alexander K (alex)
Component:	USB	Assignee:	Greg Kroah-Hartman (greg)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	acpi-bugzilla
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.0-test6	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	lspci -v output cat /proc/interrupts kernel config

Description Alexander K 2003-09-29 05:06:31 UTC

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

Comment 1 Alexander K 2003-09-29 05:08:18 UTC

Created attachment 955 [details]
lspci -v output

Comment 2 Alexander K 2003-09-29 05:08:56 UTC

Created attachment 956 [details]
cat /proc/interrupts

Comment 3 Alexander K 2003-09-29 05:09:39 UTC

Created attachment 957 [details]
kernel config

Comment 4 Greg Kroah-Hartman 2003-09-29 10:01:15 UTC


*** This bug has been marked as a duplicate of 1186 ***

Comment 5 Alexander K 2003-09-29 13:31:41 UTC

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.

Comment 6 Alexander K 2003-10-02 09:33:37 UTC

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.

Comment 7 Alexander K 2003-10-03 06:43:46 UTC

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.

Comment 8 Alexander K 2003-10-05 06:32:23 UTC

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.

Comment 9 Adrian Bunk 2004-07-17 17:32:44 UTC

Submitter said this bug is fixed in recent kernels.