Date: Fri, 22 Sep 2006 08:34:29 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: freebsd-usb@freebsd.org Subject: Re: umass0: BBB reset failed, TIMEOUT (again) Message-ID: <200609220834.30428.hselasky@c2i.net> In-Reply-To: <20060921220447.GA10135@saturn.kn-bremen.de> References: <20060920011107.GA9379@saturn.kn-bremen.de> <200609201118.33321.hselasky@c2i.net> <20060921220447.GA10135@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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...)=20 We can easily check for dropped interrupts. If you run: sysctl hw.usb.ehci.debug=3D15 sysctl hw.usb.umass.debug=3D-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 erro= r. > 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 sysct= l: > =46rom the log I see that it looks like the statemachine of your device has= =20 locked up. Even the reset command is timing out. That should not happen. We= =20 could try to reconfigure the device, when reset fails. =2D-HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609220834.30428.hselasky>