On Sat, 4 Jul 2015, Andy Furniss wrote: > 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". That's right. The text-mode interface for usbmon deliberately cuts down the amount of data it presents, so as to avoid overwhelming the person reading the output. > 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 - Note that you can expect the output of the binary-mode interface to be about 460 times larger than this. In other words, it would have amounted to around 5.5 GB rather than 12 MB. That's what I meant about overwhelming the reader. > 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 I don't know if this is relevant, but this particular line shows that of the 64 packets requested, the first five were received with lengths 188, 188, 188, 0, and 188. In other words, the fourth packet either wasn't received or had length 0. Is that expected? > 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 Here the first and fifth packets had length 0. > 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 Same here. > 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 And in this group of 64 packets, the second had length 0. > 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? It depends on what you want. If you want complete details (all the packets, all the data) then you need to use the binary interface, i.e., wireshark or dumpcap. But if it helps to know that roughly one packet in every four is received with length 0 (or possibly is not received at all), then maybe your usbmon capture has served a useful purpose. Alan Stern -- 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
