On Sun, 21 Aug 2005 16:57:14 -0400 (EDT) Alan Stern wrote:
> 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 Hi Alan, I have downloaded 2.6.13-rc6 and built it. I've not yet tried running it as I figured preserving the current b0rked state might provide additional info for you. It sounds like there are 3 paths now: 1 - continue with 2.6.12 2 - use 2.6.13-rc6 3 - switch to 2.6.13-mm Which would be more valuable to you? Using badblocks was of value since one goal was to distinguish between driver and file system (ReiserFS) problems. I can restart my machine and run badblocks and get multiple khubd stack traces. Is there any particular pattern for getting them that would be must useful? Regards, David ------------------------------------------------------- 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
