On Fri, 23 Dec 2005, Scott D. Davilla wrote: > Disconnect after 6 days, 4 hours. Here's the log. It looks like the > familiar sporadic root hub disconnect. I suspect that there is a > sporadic condition where the root hub indicates a disconnect but the > disconnect is bogus. Can someone explain or give pointers of how the > disconnect is propagated from the ehci hardware to where the hub code > indicates the disconnect. I want to add some debug messages to figure > out if the disconnect occured under a real interrupt from the > hardware or from some watchdog timers or what.
The hub driver periodically queries ehci-hcd to get port status changes. When the hardware reports a connect status change, the hub driver processes the change. There aren't any hardware interrupts involved; it's driven by a kernel timer. But the change notification is genuinely coming from the hardware. > Dec 16 14:21:33 USE Server user.debug kernel: usb-storage: device scan > complete > Dec 22 18:10:08 USE Server user.debug kernel: hub 4-0:1.0: state 5 > ports 6 chg 0000 evt 0014 > Dec 22 18:10:08 USE Server user.debug kernel: ehci_hcd 0000:00:10.3: > GetStatus port 2 status 00180b POWER sig=j PEC CSC CONNECT The CSC above stands for Connect Status Change. There's no question that the EHCI hardware detected a connection change. If it was bogus, then there's a hardware problem. > Dec 22 18:10:08 USE Server user.debug kernel: hub 4-0:1.0: port 2, > status 0501, change 0003, 480 Mb/s > Dec 22 18:10:08 USE Server user.info kernel: usb 4-2: USB disconnect, address > 4 > Dec 22 18:10:08 USE Server user.debug kernel: usb 4-2: > usb_disable_device nuking all URBs > Dec 22 18:10:08 USE Server user.debug kernel: usb 4-2: unregistering > interface 4-2:1.0 > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: > storage_disconnect() called > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: > usb_stor_stop_transport called > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: -- > usb_stor_release_resources > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: -- sending > exit command to thread > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: -- dissociate_dev > Dec 22 18:10:08 USE Server user.debug kernel: usb 4-2:1.0: hotplug > Dec 22 18:10:08 USE Server user.debug kernel: usb 4-2: unregistering device > Dec 22 18:10:08 USE Server user.debug kernel: usb 4-2: hotplug > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: *** thread > awakened. > Dec 22 18:10:08 USE Server user.debug kernel: usb-storage: -- exiting > Dec 22 18:10:08 USE Server user.debug kernel: hub 4-0:1.0: debounce: > port 2: total 100ms stable 100ms status 0x501 > Dec 22 18:10:08 USE Server user.debug kernel: ehci_hcd 0000:00:10.3: > port 2 high speed > Dec 22 18:10:08 USE Server user.debug kernel: ehci_hcd 0000:00:10.3: > GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT > Dec 22 18:10:08 USE Server user.info kernel: usb 4-2: new high speed > USB device using ehci_hcd and address 5 > > At this point khubd is in a DW state and the USB system is hung until reboot. A stack trace (Alt-SysRq-T) showing exactly _where_ the khubd process is hung would be a big help. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
