Bug 6708
| Summary: | ehci_hcd hangs on insertion of usb device | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | dev |
| Component: | USB | Assignee: | David Brownell (dbrownell) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | bunk, greg, protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.16 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 5089 | ||
| Attachments: |
/proc/bus/usb/devices
output of lspci -v dmesg output from the 1.) case dmesg output from the 2.) case lsusb -v (uhci only) |
||
|
Description
dev
2006-06-18 05:09:11 UTC
On Mon, 19 Jun 2006 19:21:50 -0700 David Brownell <david-b@pacbell.net> wrote: > On Monday 19 June 2006 3:47 pm, Andrew Morton wrote: > > > > yaregression > > Or at least a severe problem between brain and keyboard. > > Get this: a system with VIA kt-400 hardware, > which ** DOES NOT INCLUDE OHCI ** is getting some > problem ... which is then blamed on the OHCI driver. > > And the "bug report" doesn't show anything having > to do with OHCI either. > > Even if this _were_ a problem with that driver, > this is a completely unusable bug report. > OK, but "rmmod ohci_hcd and the device works just fine with uhci_hcd" seems pretty unambiguous. So the reporter appears to be saying that the mere presence of that module makes the machine fail, despite (or because of?) the absence of that driver's hardware? Reply-To: david-b@pacbell.net On Monday 19 June 2006 7:48 pm, Andrew Morton wrote: > > So the reporter appears to be saying that the mere presence of that module > makes the machine fail, despite (or because of?) the absence of that > driver's hardware? Which would mean some problem in PCI or the module loader, not USB. And yet the bug report showed no evidence that the OHCI driver was even loaded ... like, say, its banner message. Hence the comment that the bug report is broken. There are FAQs on how to make a bug report, including one focussed on USB; this one ignores them all. Well not exactly brain failure but somewhat blind and typing from memory. To clearify I meant the ehci_hcd driver making troubles. Please be so kind to query-replace all occurences of ohci_hcd with ehci_hcd. As to the rest of the missing information ill attach it shortly. If u need more information feel free to ask. Created attachment 8349 [details]
/proc/bus/usb/devices
Created attachment 8350 [details]
output of lspci -v
does this still happen with 2.6.18-rc6?
Missing information includes descriptors of the device
that appears to be triggering the problem ('lsusb -v'
is best) ... notice that the /proc/bus/usb/devices info
doesn't show that device!!
Missing information also includes dmesg traces, from the
initializaiton of USB to after the problem appears, with
CONFIG_USB_DEBUG enabled.
Still hangs with 2.6.18_rc6 but sometimes succeeds. Though even if it succeeds
running lsusb -v always hangs the device. Going to attach 2 dmesg outputs and
lsusb -v output from only running with uhci module loaded.
dmesg outputs:
1.) a) Bootup sequence
b) Connected device, succeeded
c) Unplugged device
d) Reconnected device, this time failed
2.) a) rmmoded ehci_hcd module & run dmesg -c
b) modprobe ehci_hcd
c) connected device, succeeded
d) run lsusb -v, which hung
e) disconnected device, lsusb -v unfroze at this point
Created attachment 8981 [details]
dmesg output from the 1.) case
Created attachment 8982 [details]
dmesg output from the 2.) case
Created attachment 8983 [details]
lsusb -v (uhci only)
Good chance the problem has been resolved in newer kernels especially 2.6.22-rc4. Can you please give it a try? Thanks, --Natalie Please reopen this bug if it's still present with kernel 2.6.22. |