On Monday 14 February 2005 9:17 am, Steve Hosgood wrote:
>
> qh/cf49c100 dev2 hs ep2 42002202 40000000 (8a00ad80* data1 nak0)
> da98f360 in len=0 00004d00 urb d6189b00
> da98f480*in len=12288 b0008d80 urb d6189b00
> da98f420+in len=20480 50000d80 urb d4452680
> da98f540 in len=12288 b0008d80 urb d4452680
> da98f4e0#in len=20480 50000d80 urb d6189900
> da98f600 in len=12288 b0008d80 urb d6189900
> ...
>
> Now for the non-working situation of 800x600 images @ 40fps:
And this is "non-working" in that you verified, using a
CATC or equivalent, that the host wasn't sending any IN
tokens to the device at all?
> qh/cf49c100 dev2 hs ep2 42002202 40000000 (0400ad80* data0 nak3)
> da98f360 in len=0 00004d00 urb d6189b00
> da98f480*in len=12288 b0008d80 urb d6189b00
> da98f420+in len=20480 50000d80 urb c2609a80
> da98f540 in len=12288 b0008d80 urb c2609a80
> da98f4e0#in len=20480 50000d80 urb d6189a00
> da98f600 in len=12288 b0008d80 urb d6189a00
The thing that's obviously striking here is that your urbs
have 32KB buffers, so each one stretches into two qTDs:
the first is five pages, the second is three. (And nothing
looks obviously wrong in those parts of the queue heads.)
Now while that's normally a fine thing, it's also a mode
that doesn't usually kick in ... AND it's one where some
shenanigans have to be used to patch up short reads. AND
you're seeing problems after some short reads.
Specifically, when the first TD (len=20480) triggers any
kind of short read, it enters a special patch-up mode
(flagged by the '#') where instead of going to the next
TD, it goes to a magic "alternate" dummy that just stops
the whole queue ... and the queue scanning logic has to
detect that magic dummy, and restart it.
==> HYPOTHESIS: there's a bug in how the queue scanning
handles that special case. It's very rare; QED.
==> PLEASE TEST BY: trying buffers of no more than 5KB
in your bulk-IN urbs. This will completely avoid
those special cases.
If it checks out, there can be a couple ways to fix it.
The "slow" way would just identify how that special casing
is goofed, and resolve the issue. The "fast" way would be
to use that "alternate" in a smarter way, so the hardware
immediately jumps to the next URB. (And change how the
single-URB unlink logic works, too.)
Also
==> HYPOTHESIS: this is more hardware that behaves oddly
with the "park" mode. A recent patch disabled that,
improving behavior on some NForce2 boards.
==> TEST BY: using 2.6.11-rc4, which turns off that
park mode.
In general, reporting test results with a vendor kernel is
not going to be as useful as reporting ones with the most
current www.kernel.org code ... unless you're dealing with
the vendor.
- Dave
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
