Patrick Boettcher <patrick.boettcher at desy.de> writes:
> I think you simply made a mistake extracting the firmware from the log.
Definitely. One particularly stupid mistake seems to be that the fw
loader wants addresses to be little endian but in the trace they show
as big endian. So the addresses in my fw are swapped :-)
> OK. Than a babble is not a problem. So the disconnect is because of more
> than 3 XactErr in a row?
Well, not that either. The CERR never goes to one. The transaction
errors associated with a disconnect have always token values like the
following:
[17180428.952000] ehci_hcd 0000:03:0c.2: XactErr, ep3in, token=8038c948
[17180428.952000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=80008148
I.e. first we get a token with CERR=2 (and transfer length is always
56) and in the next token the CERR has "jumped" to zero. The USB traffic
associated to this kind of token values looks something like:
f755f140 2568107736 C Bi:002:03 -32 40448 = 47023110 26e11251 26435261 0ce78c29
44235a42 35b08108 94a956b2 f58cb55d
f7546ec0 2568107748 S Co:002:00 s 02 01 0000 0083 0000 0
f79c1cc0 2568108697 C Co:002:00 -71 6 >
The token with CERR=2 is associated with EPIPE, i.e. halt/stall and
after that we get protocol error (CERR=0 in token).
So at least the ehci driver does not see CERR counting from 3 to zero,
but I guess the field is supposed to be managed by the controller. So
should the echi driver ever even see values other than 3 or zero?
I looked again at the usbmon logs and the submit to which we get the
EPIPE is often quite far before the callback and there is always some
control traffic between the bulk submit and the bulk callback so it
does really look like the control traffic is somehow causing the
streaming to fail.
--
http://www.iki.fi/~ananaza/