--- On Thu, 5/13/10, Oliver Neukum <oliver@xxxxxxxxxx> wrote: > From: Oliver Neukum <oliver@xxxxxxxxxx> > Subject: Re: g_serial and cdc_acm communications > To: "Ron Madrid" <ron_madrid@xxxxxxxxxxxxx> > Cc: linux-usb@xxxxxxxxxxxxxxx > Date: Thursday, May 13, 2010, 1:41 AM > Am Mittwoch, 12. Mai 2010 20:50:52 > schrieb Ron Madrid: > > I have written a pair of applications that open each > device > > (ttyGS0 and ttyACM0) and transfer data back and > forth. > > However when I'm running the apps the gadget > side will send > > (or think it sent) all appropriate data to the host > side, > > but the host will only receive part of the > transmission and > > time out in the select() call. I am not seeing > any errors > > from the gadget side kernel but occasionally this will > lock > > up my host system. Small data transfers of > around 200 bytes > > or less seem to work fine, but when I try larger > transfers > > (1k or greater) I will see it fail (timeout in > select()). > > Difficult to say anything. You'd better get an usbmon > trace. So, I've been trying to learn how to interpret this and I think I've made some progress and see where my app correlates to this information. This is the last (failing) transfer that occurs. The third line is my app receiving information about the data it should expect, and the size of the transfer in dwords, 0x7d0 (8000 bytes). I then see, in subsequent lines, 7 * 1024 bytes received (Bi) followed by 832 bytes received which totals up to 8000 bytes. e688c140 962341472 S Bi:011:01 -115 1024 < f74526c0 962341962 C Bo:011:01 0 18 > e688c9c0 962348087 C Bi:011:01 0 22 = 00680000 00020000 00000000 07d00000 00000000 0000 e688c9c0 962348093 S Bi:011:01 -115 1024 < e688c1c0 962348462 C Bi:011:01 0 1024 = 11918199 19189999 46466666 66666666 99999999 99999999 66666666 66646666 e688c440 962348464 C Bi:011:01 0 1024 = 99999999 19999899 62666666 66666666 90999999 99099999 46266666 66664666 e688c6c0 962348466 C Bi:011:01 0 0 e688c1c0 962348475 S Bi:011:01 -115 1024 < e688c440 962348477 S Bi:011:01 -115 1024 < e688c6c0 962348479 S Bi:011:01 -115 1024 < e688ccc0 962348587 C Bi:011:01 0 1024 = 66666466 66666466 99199999 89999999 66666666 67664666 99999999 99999999 e688c2c0 962348589 C Bi:011:01 0 1024 = 66666666 66666666 89999999 99999999 66666666 66666666 99999999 99999999 e688c240 962348591 C Bi:011:01 0 0 e688c540 962348593 C Bi:011:01 0 1024 = 66666666 66666666 99999999 81999999 64446666 47666666 99999999 89999999 e688ccc0 962348604 S Bi:011:01 -115 1024 < e688c2c0 962348606 S Bi:011:01 -115 1024 < e688c240 962348608 S Bi:011:01 -115 1024 < e688c540 962348610 S Bi:011:01 -115 1024 < e688cec0 962348712 C Bi:011:01 0 1024 = 66666666 26666666 99119999 99891999 06666266 66666666 91999899 91999999 e688cf40 962348714 C Bi:011:01 0 0 e688ca40 962348716 C Bi:011:01 0 1024 = 99999999 99999999 46666666 66666666 99999899 99999999 66666666 66646666 f7452a40 962348718 C Bi:011:01 0 832 = 89999999 89919999 66666666 66666666 99999999 99999999 66666666 66666666 e688cec0 962349368 S Bi:011:01 -115 1024 < e688cf40 962349370 S Bi:011:01 -115 1024 < e688ca40 962349373 S Bi:011:01 -115 1024 < And here is the 20 second timeout built into select() where the device times out and closes the fd. 982349394 - 962349375 = 20000000 microsec = 20 sec. f7452a40 962349375 S Bi:011:01 -115 1024 < f686d740 982349394 S Co:011:00 s 21 22 0000 0000 0000 0 f686d740 982350216 C Co:011:00 0 0 e688cd40 982350292 C Ii:011:02 -2 0 f7452a40 982350338 C Bi:011:01 -2 0 e688ca40 982350587 C Bi:011:01 -2 0 So it appears that the hardware and driver are receiving all of the information, yet as previously mentioned my app will timeout during a select() call. After a timeout I check the buffer with ioctl(fd, FIONREAD, &bytes) and bytes comes back as 0. So, why isn't the data hitting my application? Thanks for all the help. Ron -- 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
