On Mon, 14 Nov 2005, Jan Kiszka wrote: > Hi, > > on a VIA Eden box, I'm getting sporadic USB disconnects after longer > operation times. Typically, there is no USB load when it disconnects. > The kernel output is like this: > > kernel: hub 4-0:1.0: state 5 ports 6 chg 0000 evt 0008 > kernel: ehci_hcd 0000:00:10.3: GetStatus port 3 status 00180b POWER > sig=j PEC CSC CONNECT > kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s > kernel: usb 4-3: USB disconnect, address 2 > kernel: usb 4-3: usb_disable_device nuking all URBs > kernel: ehci_hcd 0000:00:10.3: shutdown urb c633cc20 pipe 80000280 ep0in > kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 > > Attached are either a rt2570-based USB WLAN stick (via native driver) or > a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both > cases the USB subsystem locks up in some nasty way (deadlock, rest of > system still alive) so that no resetting/unloading of the involved > drivers is possible. Only a hard reboot helps. I'm watching this effect > for quite a while now, so far with 2.6.8 kernels, now also with a recent > 2.6.14.2. > > I could live with the fact that my hardware may have some sporadic > problems and I have to reset/reload parts of my system from time to > time; it's easy to setup a watchdog script for this. But the hanging USB > stack prevents this. > > Any ideas? Any additional information required? I could instrument the > code and reproduce this if it helps to track the reason down.
I can give you the kernel developer's point of view. According to those log messages, there was an interruption of the USB connection which made it look as though device 4-3 had been physically unplugged. This could be caused by device problems, cable problems, controller problems, or an actual disconnect. The -16 (-EBUSY) message at the end is just an unimportant warning; it means that the USB core failed to unlink an URB because something else (probably the device driver) had already unlinked it. The hang is almost certainly caused by the device's driver. Apparently its disconnect method is not returning. Since that routine is called by the main hub driver and with a lock held, this means that most other major activities of the USB stack will be blocked as well. To get more information when you see these messages in the log and things are hung up, get a stack trace with Alt-SysRq-T. The entry for khubd is of particular interest; others may be important also depending on the driver. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
