Re: new mail: USB controller problem on MIPSEL embedded board

On Fri, 24 Aug 2007, Paolo Giarrusso wrote:

> > The stick gets disconnected because the EHCI host controller has
> > crashed!
> 
> Interesting - I did note that "HALT" message. However, it does not
> crash always, but it always disconnects the stick.

Yeah, okay, it's more accurate to say that the two events seem to be 
closely related and caused by a bug in the host controller.

> I'm attaching separately the logs from a testing session where it
> crash at first - I plug the card, try using it and get a disconnection
> of the card, unplug and replug it, the hub crashes, I disconnect it,
> then I remove and reload the DVB-USB modules (it kept sending message
> for status request, i.e. 84 and/or 81), and the controller was working
> again (without unbind/bind).
> 
> I should have added which is the USB controller. To my surprise, it
> seem this board is using a standard VIA controller. And the controller
> in the original mail was from VIA too (with the same chip!). Btw, this
> is an old revision of this controller - do you think it is worth
> looking for an errata datasheet? (I've seen revision 80-82 on this and
> other webpages http://kerneltrap.org/node/5500#comment-130854, while
> the one I have is 61-63).

I don't know -- it won't hurt to look.  BTW, I've got an older VIA card 
with revision 50-51!  But I have never stress-tested it.

It is certainly true that the older VIA parts (VT6202) were much less
reliable than the newer ones (VT6212), but I don't know the revision 
numbers where the changeover was made.

> And since this is a common controller, do you think this problem is
> somehow workaroundable, or at least worth investigating more? Because
> it is not totally broken - it usually works.

I have no idea.  It seems unlikely we'd make any progress in the 
absence of decent errata information from VIA.

> From this thread I've seen that they have in practice a single USB hub
> chip which they evolve, and that they do not release errata any more;
> but they also give technical answers (and there is a forum for Linux
> support), so I wonder if it is worth contacting them.
> 
> http://forums.viaarena.com/messageview.aspx?catid=16&threadid=73502&enterthread=y

Go ahead and try.  In the past we have not had much success getting
technical information from VIA.

> Also, I wonder (as a wild guess) if the PCI bus busmaster feature
> supports "bus parking" or not - that thread mentions this requirement
> and "park" often appears in log messages.

No, that refers to something different, not related to PCI 
busmastering.

> > When using those other high-speed USB devices, do you still get the
> > "Start ASS: 8000" messages?
> 
> Yes, indeed. I've connected my external HD and they happen, too. And
> anyway, they happen even long before the problem; the status also goes
> back to 0 at times, and I've been reading my HD content. For instance,
> while doing this:
> 
> # time cat /local_storage/media/usb-a2/kubuntu_7_04_dvd_amd64.iso > /dev/null
> 
> (that is a 4GB file), this is an excerpt of the kernel output (note
> the three "Start ASS: 0" out of many more "Start ASS: 8000").
> 
> [24394.245322] Start ASS: 8000
> [24394.885947] End ASS: 8000
> [24396.309774] Start ASS: 0
> [24396.501180] End ASS: 8000
> [24443.204281] Start ASS: 8000
...
> So that is not enough to cause the root problem. Note however that
> during the execution only Bulk transfers are used, while the DVBT case
> mixes more transfer types.

Nevertheless it indicates an error.  Whether it means the status bit is 
incorrect and the controller really has stopped doing DMA, or the 
status bit is right and the controller continues to do DMA when it 
shouldn't, is very difficult to tell.

But there is a hint.  In the past people have sent in bug reports
saying that their VIA EHCI controllers caused a large slowdown in
overall system operation.  It turned out they had the same sort of
problem: Async Enable wasn't turning off when it was supposed to.

> > It has nothing to do with the stick.  The problem is in the controller.
> 
> Yep, but it is "triggered" by something in the communication (say, it
> work perfectly until you try to do X transfers with certain params,
> say interrupt transfers with x, y and z). Because it works otherwise
> (see above with the HD).

That's undoubtedly true, but it isn't much to go on.

> After resurrecting the controller by
> rmmod dvb-usb-dtt200u
> rmmod dvb-usb
> and reloading them, I have instead (note the "lost" field):
> 
> # cat /sys/class/usb_host/usb_host1/registers
> bus pci, device 0000:00:01.2 (driver 10 Dec 2004)
> EHCI Host Controller
> EHCI 1.00, hcd state 1
> ownership 00000001
> SMI sts/enable 0xc0080000
> structural params 0x00002204
> capability params 0x00006872
> status 8008 Async FLR
> command 010009 (park)=0 ithresh=1 period=256 RUN
> intrenable 37 IAA FATAL PCD ERR INT
> uframe 2cac
> port 1 status 001000 POWER sig=se0
> port 2 status 001000 POWER sig=se0
> port 3 status 001000 POWER sig=se0
> port 4 status 001000 POWER sig=se0
> irq normal 550418 err 13 reclaim 2079 (lost 1403)
> complete 4361 unlink 398

I wouldn't trust that "lost" number too much.  But it could be 
indicative of the larger problem.

> We'll see. Thanks for the prompt answer, hope you can suggest
> something with these additional infos.

At the moment nothing occurs to me.  When the hardware misbehaves, it's
very hard to cope unless you have a good idea of exactly _how_ it is
misbehaving -- which we don't!

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel