Patrick Boettcher <patrick.boettcher@xxxxxxx> 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/ _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
