umass0: BBB reset failed, TIMEOUT (again)

[Juergen Lock]

On Fri, Sep 22, 2006 at 08:34:29AM +0200, Hans Petter Selasky wrote:
> 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.

OK. I applied the umass_transfer_start(sc, UMASS_T_BBB_STATUS);
patch in your other message and tried mcopy'ing off it again.
This time I got a bunch of errors when first connecting it
(well, more than usual) and /dev/da2s1 didnt appear, so I had to
replug. (This may be a quirk of the device not of the board, since,
unlike the IO problems, it also happened sometimes with my old board.)
Anyway, I have left logs of that in, just in case...
The first read this time hung with the led on, I did the sysctls,
and soon after that (after messages were logged) the mcopy command
exited without any error, leaving a truncated copy!  Just in case,
I did an fsck_msdos, but it found nothing wrong.  Changed the sysctls
back to 0 and tried another copy, this time it hung with the led off.
Turned the sysctls back on and waited until mcopy exited, this time
with an IO error (led was still off.)  Unplugged, and bzip2'd the log
(its big, probably because I left the sysctls on while doing the fsck.)

 I guess the usb controller on this board is just weird... :/

 cheers,
	Juergen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: messages.bz2
Type: application/octet-stream
Size: 11079 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20060923/f5d418a8/messages.obj