On Sat, Nov 7, 2009 at 9:05 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 7 Nov 2009, Shivdas Gujare wrote: > >> Hi All, >> >> I captured usbmon data from my USB CDC-ACM modem, and seen some behavior >> which I am not able to understand. Need some help.. >> Hi Alan, Thanks for all your help. Basically, I am trying to parse usbmon data writing a shell script for it, http://gitorious.org/usbmon-parser/usbmon-parser/blobs/master/parse_usbmon.sh I am not sure if it is expected for modem, I seen, if typed AT commands, every character from bulkout ept gets echoed with bulk in ept data, similar as below, ed295e00 92.948637 S Bo:1:008:1 - 1 = 41 ed295e00 92.948704 C Bo:1:008:1 0 1 > ed295700 92.949843 C Bi:1:008:1 0 1 = 41 ed295700 92.949868 S Bi:1:008:1 - 1024 < ed295e00 93.160237 S Bo:1:008:1 - 1 = 54 ed295e00 93.160329 C Bo:1:008:1 0 1 > ed295880 93.161467 C Bi:1:008:1 0 1 = 54 ed295880 93.161502 S Bi:1:008:1 - 1024 < Is it a expected for modem? or my modem configuration is wrong? I am using Pete's userspace usbmon to capture logs after removing 32 byte limitation, I hope this is a valid question, why do we need 32 byte limitation for Control endpoint also? Since we are not able to capture descriptors(response to get config descriptor) of more than 32byte data. Thanks for the help. Thanks and Regards, Shivdas Gujare >> >> f61f9b80 2839510516 S Co:1:007:0 s 21 22 0003 0000 0000 0 >> f61f9b80 2839510740 C Co:1:007:0 0 0 >> f61f9b80 2839510794 S Co:1:007:0 s 21 20 0000 0000 0007 7 = 80250000 000208 >> cd3edf80 2839510809 S Bi:1:007:1 -115 1024 < >> cd3ede80 2839510816 S Bi:1:007:1 -115 1024 < >> cd3ed580 2839510821 S Bi:1:007:1 -115 1024 < >> cd3ed680 2839510826 S Bi:1:007:1 -115 1024 < >> >> What does the "1024" indicates in above line, since there is no any >> actual data/callbacks with "1024" bytes data?? > > It means that the URB was submitted with its transfer_buffer_length set > to 1024. In other words, the URB can receive up to 1024 bytes of data. > >> cd3ed180 2839510831 S Bi:1:007:1 -115 1024 < >> cd3edd80 2839510835 S Bi:1:007:1 -115 1024 < >> cd3ed100 2839510841 S Bi:1:007:1 -115 1024 < >> cd3ed280 2839510845 S Bi:1:007:1 -115 1024 < >> cd3edc80 2839510850 S Bi:1:007:1 -115 1024 < >> cd3ed600 2839510854 S Bi:1:007:1 -115 1024 < >> cd3edb80 2839510859 S Bi:1:007:1 -115 1024 < >> cd3ed980 2839510864 S Bi:1:007:1 -115 1024 < >> cd3ed700 2839510869 S Bi:1:007:1 -115 1024 < >> cd3edc00 2839510873 S Bi:1:007:1 -115 1024 < >> cd3ed500 2839510878 S Bi:1:007:1 -115 1024 < >> cd3ed080 2839510883 S Bi:1:007:1 -115 1024 < >> f61f9b80 2839511110 C Co:1:007:0 0 7 > >> cd3edf00 2839630507 C Ii:1:007:2 0:512 10 = a1200000 00000200 0300 >> cd3edf00 2839630519 S Ii:1:007:2 -115:512 16 < >> >> What does "16" indicates from above line.. since 10 from "10 =" in >> callback indicates that its a "notify_serial_state" >> request with 8 byte request + 2 byte data, but it doesn't actually >> matches to "16" from submission. > > The "16" is like the "1024" earlier. It means the URB's buffer can > hold up to 16 bytes. The "10" is the number of bytes actually > received. > >> cd3edf00 2839694507 C Ii:1:007:2 0:512 10 = a1200000 00000200 0200 >> cd3edf00 2839694526 S Ii:1:007:2 -115:512 16 < >> >> How does urb->interval "512 from above line" relates with >> "ept->interval" from endpoint descriptor? > > Normally urb->interval will be equal to ep->interval. But under some > circumstances it might be different; the driver or the host controller > might want to poll more rapidly than the interval specified in the > endpoint descriptor. > >> f61f9000 2845715548 S Co:1:007:0 s 21 22 0000 0000 0000 0 >> f61f9000 2845716379 C Co:1:007:0 0 0 >> cd3edf00 2845716475 C Ii:1:007:2 -2:512 0 >> >> Thanks for all your help. > > You're welcome. > > 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
