Hi Antti, beside the XactErr which is not OK, there is maybe the chance to fix the disconnect issue: Can you please try to increase the URB buffer size by 1KB? in the define DIB0700_DEFAULT_STREAMING_CONFIG you change .buffersize = 39480, to 40504. thanks, Patrick. On Wed, 28 Feb 2007, Antti P Miettinen wrote: > Antti P Miettinen <ananaza@xxxxxx> writes: > > But anyway - I'll be power cycling the machine real soon now :-) > > I'd say the dvb-usb-dib0700-02-rc2.fw makes the transaction errors > more frequent for me me. Here's the latest kernel log: > > [17179744.028000] ehci_hcd 0000:03:0c.2: XactErr, ep3in, token=8000cd08 > [17179788.896000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17179790.004000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=00004d08 > [17179836.196000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17179881.444000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17179926.528000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17179927.636000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=0000cd08 > [17179972.716000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17179973.836000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17180018.896000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180020.004000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=8000cd08 > [17180065.084000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180110.264000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180156.488000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180157.596000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17180202.708000] ehci_hcd 0000:03:0c.2: XactErr, ep0in, token=00000d08 > [17180203.816000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=8000cd08 > [17180248.940000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180250.048000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17180295.128000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180296.236000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=00004d08 > [17180341.416000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17180386.496000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180387.608000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=00004d08 > [17180433.800000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 > [17180478.940000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180480.052000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=0000cd08 > [17180525.116000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 > [17180526.228000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=00004d08 > [17180571.420000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=00004d08 > [17180616.484000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=80000e08 > [17180617.596000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=8000cd08 > [17180662.676000] ehci_hcd 0000:03:0c.2: XactErr, ep3in, token=8038c948 > [17180662.676000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=80008148 > [17180662.676000] ehci_hcd 0000:03:0c.2: devpath 1 ep0out 3strikes,t=80008148 > > About usbmon logs. Does anyone know of tools for parsing them? > Decoding by hand with the USB 2.0 spec is quite time consuming. > > Anyway - one way to find the disconnect is to look for transactions > addressed to device one, endpoint zero, which is the control endpoint > of the hub on the bus. For example: > > f7723ac0 30344798 S Ci:001:00 s a3 00 0000 0001 0004 4 < > f7723ac0 30344798 C Ci:001:00 0 4 = 01050000 > > is a port status query. What seems to be in my logs before hub access > is often a lot of (sometimes just a few) zero length callbacks with > status -71 to submits with request length 39480 (which seems to be the > dib0700 streaming buffer size) for endpoints 2 and 3. So is this -71 here > -EPROTO? Is that normal? The pattern seems pretty consistent. Soon > after starting to get -71 status callbacks, we will be talking to the > hub (and logs that do not contain a disconnect do not contain -71 > status). Hmm.. looks like there is also always one callback with > status -32 (-EPIPE?) before those -71 status callbacks. And the data > length for those callbacks is 39424 which is 39480-56 and 56 is the > transfer length in the token preceding the hard failure.. hmm.. > > -- > http://www.iki.fi/~ananaza/ > > > _______________________________________________ > linux-dvb mailing list > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
