umass0: BBB reset failed, TIMEOUT (again)

[Hans Petter Selasky]

On Friday 22 September 2006 00:04, Juergen Lock wrote:
> On Wed, Sep 20, 2006 at 11:18:32AM +0200, Hans Petter Selasky wrote:
> > On Wednesday 20 September 2006 03:11, Juergen Lock wrote:
> > > Today for the first time since this box got a new board I tried to
> > > copy data onto the usb cardreader, and after copying for a while it
> > > suddenly stopped (led stopped flashing, no further io), and after
> > > some time i had the above in dmesg.  And that was it, cp process
> > > hung, no way to kill it.  Unplugged the thing, and got the expected
> > > panic: vinvalbuf: dirty bufs.  Tried the same thing from linux (after
> > > dosfsck), and there copying stopped for a while too, but it then
> > > continued and finished.  Is this is some kind of new hardware quirk of
> > > the new board's ehci controller, that linux recovers from?  (via,
> > > there already is a `dropped interrupt' fix for it, which helped with
> > > my last board...) 

We can easily check for dropped interrupts. If you run:

sysctl hw.usb.ehci.debug=15
sysctl hw.usb.umass.debug=-1

When your device hangs. And then send me the log again.

>
> Ok.  This time writing worked, but reading back to verify (cmp) seemed
> to hang.  Did the sysctl (see below), then a while later I got an IO error.
> Tried to umount, got another IO error, tried umount -f, got a panic
> (probably expected.)  I have now installed mtools and won't mount umass
> devices on this box anymore... :/  (Btw when I later tried to mcopy the
> file off the thing using the original kernel I noticed the led was off
> after it hung, dunno if that also was the case when I tried it with the
> new code but I would suspect so.  At least this time, since it wasnt
> mounted, I could unplug it without getting a panic...)
>
>  Oh, one thing that occured to me: Even when you may be able to get
> around (what appars to be) hardware quirks like this by retrying IO
> or resetting the device, that probably wont work when you have an
> umass tape drive (sa), since with tape you can't just retry a read/write,
> and resetting it may even rewind, with the next write erasing everything
> on the tape.  Just a thought...
>
>  Anyway, here's the syslog of the `experiment', beginning after the sysctl:
>
From the log I see that it looks like the statemachine of your device has 
locked up. Even the reset command is timing out. That should not happen. We 
could try to reconfigure the device, when reset fails.

--HPS