Re: Data loss with usb dvb tuners that is "fixed" by spinning a cpu - how to debug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan Stern wrote:

By comparing the arrival times of the packets.  usbmon will tell you
exactly which microframe an isochronous packet was scheduled for, if
you understand its output.  If there are any gaps in the isochronous
stream, you'll be able to see them.

Ok, so I found https://www.kernel.org/doc/Documentation/usb/usbmon.txt

I temporally re-enabled xhci and managed to get a dump with

cat /sys/kernel/debug/usb/usbmon/0u > ....

I notice it doesn't show data counts - only the first 5 out of 64 x 940
"packets".

The loss I see is on a much smaller level than this maybe just one 188
byte ts packet - though sometimes more.

This capture was on an eight meg mux and out of 1735792 ts packets I
lost 13, probably "batched" as 2 2 2 1 1 2 2 1.



Output is 12 meg and looks like -

ffff8800a893a800 3430469394 S Zi:1:004:4 -115:1:14246 64 -18:0:940 -18:940:940 -18:1880:940 -18:2820:940 -18:3760:940 60160 < ffff8800a893a000 3430477362 C Zi:1:004:4 0:1:14310:0 64 0:0:188 0:940:188 0:1880:188 0:2820:0 0:3760:188 60160 = 47044d17 c82b0ff2 018f0420 070d1130 0788700c c9802bde a2fba040 fcd4b803 ffff8800a893a000 3430477398 S Zi:1:004:4 -115:1:14310 64 -18:0:940 -18:940:940 -18:1880:940 -18:2820:940 -18:3760:940 60160 < ffff8800a893c000 3430485362 C Zi:1:004:4 0:1:14374:0 64 0:0:0 0:940:188 0:1880:188 0:2820:188 0:3760:0 60160 = 47083514 52ac0679 c6608c82 25eff309 403c0187 02816eba d980c023 002144a1 ffff8800a893c000 3430485398 S Zi:1:004:4 -115:1:14374 64 -18:0:940 -18:940:940 -18:1880:940 -18:2820:940 -18:3760:940 60160 < ffff8800a893b800 3430493362 C Zi:1:004:4 0:1:14438:0 64 0:0:0 0:940:188 0:1880:188 0:2820:188 0:3760:0 60160 = 47044d10 a1f45086 d2feb6b7 43d996cf 76fb3b51 b6a7db7f a8db55f6 dfea50e9 ffff8800a893b800 3430493398 S Zi:1:004:4 -115:1:14438 64 -18:0:940 -18:940:940 -18:1880:940 -18:2820:940 -18:3760:940 60160 < ffff8800a893b000 3430501362 C Zi:1:004:4 0:1:14502:0 64 0:0:188 0:940:0 0:1880:188 0:2820:188 0:3760:188 60160 = 47044d1f 6e88d6f0 25378a50 b84fffc6 db1d7894 f788ded0 e5ff1e9e d1fc908d


I am thinking I've gone wrong somewhere - I can't see how
to analyse this at a fine enough level to show where a single ts packet has gone.

Is 0u the wrong thing to do?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux