umass0: BBB reset failed, TIMEOUT (again)

[Hans Petter Selasky]

On Saturday 23 September 2006 16:57, Juergen Lock wrote:
> 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... :/

From what I can see your device stops responding:

Sep 23 16:26:55 saturn kernel: QTD(0xc54d55c0) at 0x2b9895c0:
Sep 23 16:26:55 saturn kernel: next=0x2b989580<> altnext=0x00000001<T>
Sep 23 16:26:55 saturn kernel: status=0x00001100: toggle=0 bytes=0x0 ioc=0 
c_page=0x1
Sep 23 16:26:55 saturn kernel: cerr=0 pid=1 stat=NOT_ACTIVE
Sep 23 16:26:55 saturn kernel: buffer[0]=0x2bd15600
Sep 23 16:26:55 saturn kernel: buffer[1]=0x2bd98000
Sep 23 16:26:55 saturn kernel: buffer[2]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer[3]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer[4]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[0]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[1]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[2]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[3]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[4]=0x00000000


Sep 23 16:26:55 saturn kernel: QTD(0xc54d5580) at 0x2b989580:
Sep 23 16:26:55 saturn kernel: next=0x2b989540<> altnext=0x00000001<T>
Sep 23 16:26:55 saturn kernel: status=0x10000180: toggle=0 bytes=0x1000 ioc=0 
c_page=0x0
Sep 23 16:26:55 saturn kernel: cerr=0 pid=1 stat=ACTIVE
Sep 23 16:26:55 saturn kernel: buffer[0]=0x2bd98600
Sep 23 16:26:55 saturn kernel: buffer[1]=0x2c077000
Sep 23 16:26:55 saturn kernel: buffer[2]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer[3]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer[4]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[0]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[1]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[2]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[3]=0x00000000
Sep 23 16:26:55 saturn kernel: buffer_hi[4]=0x00000000

You see here that a transfer is waiting to be transferred. That is why it 
times out. If you had a missing interrupt problem, the "stat=ACTIVE" transfer 
whould would be "HALTED" at least, or "stat=ACTIVE" cleared and bytes != 0, 
to indicate a short transfer. Neither of this is the case so:

a) Your EHCI controller stopped.
b) Your USB device got some kind of unrecoverable error.

Right now I am a little short of time, but I have some more patches that you 
can try. For example I want to see what happens when you try to re-set the 
configuration value.

--HPS