On Sun, 21 Aug 2005, David Relson wrote: > Hi Alan, > > Easy enough. See below. If you'd rather have the full 190K of output, > I'll be glad to email it to you.
No thanks, this is fine. > Aug 21 12:21:44 osage kernel: khubd D C043C3E0 0 1349 1 > 4445 791 (L-TLB) > Aug 21 12:21:44 osage kernel: df0d3e74 00000046 df0b7530 c043c3e0 0005e51d > df0d3e74 c045e0e0 0000007b > Aug 21 12:21:44 osage kernel: bbf5801e df0d3e88 dd0310a0 00000091 > bd8e024a 0005e51d df0b7680 62eb123e > Aug 21 12:21:44 osage kernel: df0d3e88 dfd440f0 df0d3eb0 c033c74a > df0d3e88 62eb123e df076180 c045dbf8 > Aug 21 12:21:44 osage kernel: Call Trace: > Aug 21 12:21:44 osage kernel: [schedule_timeout+90/176] > schedule_timeout+0x5a/0xb0 > Aug 21 12:21:44 osage kernel: [<c033c74a>] schedule_timeout+0x5a/0xb0 > Aug 21 12:21:44 osage kernel: [pg0+540734441/1068971008] > ehci_endpoint_disable+0xa9/0x147 [ehci-hcd] > Aug 21 12:21:44 osage kernel: [<e083a3e9>] ehci_endpoint_disable+0xa9/0x147 > [ehci-hcd] > Aug 21 12:21:44 osage kernel: [pg0+540990735/1068971008] > usb_disable_device+0x3f/0x100 [usbcore] > Aug 21 12:21:44 osage kernel: [<e0878d0f>] usb_disable_device+0x3f/0x100 > [usbcore] > Aug 21 12:21:44 osage kernel: [pg0+540968617/1068971008] > usb_disconnect+0xa9/0x140 [usbcore] > Aug 21 12:21:44 osage kernel: [<e08736a9>] usb_disconnect+0xa9/0x140 > [usbcore] > Aug 21 12:21:44 osage kernel: [pg0+540975666/1068971008] > hub_port_connect_change+0x2f2/0x400 [usbcore] > Aug 21 12:21:44 osage kernel: [<e0875232>] > hub_port_connect_change+0x2f2/0x400 [usbcore] > Aug 21 12:21:44 osage kernel: [pg0+540976330/1068971008] > hub_events+0x18a/0x3c0 [usbcore] > Aug 21 12:21:44 osage kernel: [<e08754ca>] hub_events+0x18a/0x3c0 [usbcore] > Aug 21 12:21:44 osage kernel: [pg0+540976949/1068971008] > hub_thread+0x35/0x100 [usbcore] > Aug 21 12:21:44 osage kernel: [<e0875735>] hub_thread+0x35/0x100 [usbcore] > Aug 21 12:21:44 osage kernel: [kernel_thread_helper+5/16] > kernel_thread_helper+0x5/0x10 > Aug 21 12:21:44 osage kernel: [<c0101305>] kernel_thread_helper+0x5/0x10 It appears that khubd is stuck in ehci_disable_endpoint, which points to a bug in the EHCI driver. If you get multiple stack traces, with varying time intervals in between, does the khubd entry always end up looking like this one? What this means is that the hub driver has detected that your drive disconnected and is trying to clean up after it. During that clean-up period it locks the device -- that's what prevents usbview and lsusb from doing their thing. I can't tell what's going on with the badblocks program, but maybe once this issue is solved the program will fail gracefully rather than hang. If you're more interested in preventing this sort of thing, I still suggest you try a 2.6.13-mm kernel. If nothing else, it would help me to know whether the error recovery in there works adequately. Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
