On Mon, 22 Aug 2005 10:15:45 -0400 (EDT) Alan Stern wrote: > On Sun, 21 Aug 2005, David Relson wrote: > > > 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. > > Well, you could get a couple more stack dumps right now and compare the > khubd entries. If it's still hung up in ehci_disable_endpoint then we can > be pretty sure that's where the trouble spot it. Apart from that, I can't > think of anything useful. > > > 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? > > The only reason for mentioning 2.6.13-mm was because I wasn't sure if the > new error-recovery code is present in 2.6.13-rc6. I just checked, and it > is present. So there's no need to consider -mm. > > > 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? > > Not especially. Just wait until badblocks hangs and then see what's > happening. Presumably it will end up hanging in the spot each time, but > you never know until you try it. > > Having done that, go ahead and boot up 2.6.13-rc6. There's a good chance > its behavior will be very different. > > Alan Stern
Hi Alan, I took a shot at building 2.6.13-rc6 and running it. Unfortunately it complained on reboot - "unable to mount root fs on unknown-block(3,1)". As a guess, it's complaining because my root fs is ext3 and that's built as a module. In any case I've not yet had a chance to experiment more. I _did_ start badblocks at yesterday. Between 20:00 yesterday and 17:00 today, it applied its 4 bit patterns to the 48M blocks of the drive, didn't hang, and found zero errors Tonight I'll run full backups of my 2 machines, a process that usually produces a "drive disconnect" state. More later :-> 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 _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
