On Fri, 2 Mar 2012, Edwin Mercado wrote: > > I wonder why the lsusb output doesn't show the right string > > descriptors. �If you mount a debugfs filesystem on /sys/kernel/debug, > > what do you see in /sys/kernel/debug/usb/devices? > > T: Bus=02 Lev=02 Prnt=02 Port=06 Cnt=02 Dev#= 19 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 > P: Vendor=0525 ProdID=a4a0 Rev= 2.29 > S: Manufacturer=Gadget Zero > S: Product=Gadget Zero > S: SerialNumber=0123456789.0123456789.0123456789 > C:* #Ifs= 1 Cfg#= 3 Atr=e0 MxPwr= 2mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbtest > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > C: #Ifs= 1 Cfg#= 2 Atr=c0 MxPwr= 2mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver= > E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms This has the right string descriptors, so it looks like something's wrong with your copy of lsusb. > > # ./testusb -a -c 1 -v 1 -t 8 > > # ./testusb -a -c 1 -v 1 -t 8 > > # ./testusb -a -c 1 -v 1 -t 8 > > > I'm not going to be able to get the LeCroy display tool working on my > > Linux-based computer any time soon. �Can you describe what the trace > > shows? > > (attached pictures showing the traces) > > The usb enumeration occurs after the device is reset. > > Next, three transfers follow with size of 576B, 640B, and 640B, > respectively. Each transfer correspond to ./testusb -a -c 1 -v 1 -t 8 > command. Okay, now I see the problem. To understand what's going on, you have to know how Test 8 works and what the parameters mean. Test 8 involves scatter-gather transfers, with 32 sg blocks by default (you can change that by using testusb's -g option). You specified only one iteration (the -c 1 option), with varying block sizes (the -v 1 option). The initial block size defaults to 512 (controlled by the -s option). This means the host tries to carry out a single bulk-IN transfer, expecting to receive 32 blocks of data having lengths equal to 512, 1, 2, ..., 31. The number increases by 1 for each block because you specified -v 1, and it wraps when it hits the maximum (512). When you ran the test, the first 512-byte block was received okay. For the second block, the host expected to receive only one byte, but Gadget Zero sent a 64-byte packet. Hence the test terminated with a -75 error, and the bus trace showed a total transfer amount of 512+64 bytes. Subsequent tests probably behaved exactly the same, except that the endpoint data toggle values were not synchronized. Hence at the start of each test, the device sent a 64-byte packet which the host ignored. Thus the bus trace indicated a total transfer amount of 512+64+64 bytes. To make the test work properly, you should tell testusb to vary the block sizes by multiples of 64 instead of multiples of 1, i.e., specify -v 64 instead of -v 1. Then each block would be an exact multiple of the packet size, so there would be no overflow errors. 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
