This is even more bizarre, the output below is from usbmon when I do two 12-byte writes/reads within the same program (in the previous example I posted I did 2 12-byte writes/reads by calling my program twice).
--- (2x 12-byte writes/reads within the same program) eb0e9cc0 1713314624 S Co:030:00 s 00 09 0001 0000 0000 0 eb0e9cc0 1713314818 C Co:030:00 0 0 c4e774c0 1713317388 S Bo:030:02 -115 12 = 00000000 00000000 00000000 c4e774c0 1713317551 C Bo:030:02 0 12 > c4e774c0 1713317729 S Bi:030:06 -115 12 < c4e774c0 1713317798 C Bi:030:06 0 12 = 00000000 00000000 00000000 c4e774c0 1713317974 S Bo:030:02 -115 12 = 00000000 00000000 00000000 c4e774c0 1713318049 C Bo:030:02 0 12 > c4e774c0 1713318179 S Bi:030:06 -115 12 < c4e774c0 1713318298 C Bi:030:06 0 12 = 00000000 00000000 00000000 c4e774c0 1713319643 S Co:030:00 s 01 0b 0000 0000 0000 0 c4e774c0 1713319801 C Co:030:00 0 0 --- If 2x12-byte tx/rx work within the same program but not when I do 1x12-byte tx/rx twice (by running the code twice), I suspect some 'state' gets messed up between closing the usb handle and opening up again. - Stephan > Pardon the very long lines. This has been fixed now. > > My usbmon shows the following: > > --- (1) Test for 12 bytes TX/RX _without_ writing the extra 1 byte bulk > --- packet --- > (12 byte tx/rx: run program for first time) > eb13c640 4268765364 S Co:028:00 s 00 09 0001 0000 0000 0 > eb13c640 4268765473 C Co:028:00 0 0 > eb13c640 4268767715 S Bo:028:02 -115 12 = 00000000 00000000 00000000 > eb13c640 4268767847 C Bo:028:02 0 12 > > eb13c640 4268767994 S Bi:028:06 -115 12 < > eb13c640 4268768094 C Bi:028:06 0 12 = 00000000 00000000 00000000 > eb13c640 4268771222 S Co:028:00 s 01 0b 0000 0000 0000 0 > eb13c640 4268771347 C Co:028:00 0 0 > (12 byte tx/rx: run program for 2nd time) > eb149740 4271189686 S Co:028:00 s 00 09 0001 0000 0000 0 > eb149740 4271189871 C Co:028:00 0 0 > c4e77ac0 4271197255 S Bo:028:02 -115 12 = 00000000 00000000 00000000 > c4e77ac0 4271197366 C Bo:028:02 0 12 > > c4e77ac0 4271197507 S Bi:028:06 -115 12 < > c4e77ac0 4271698658 C Bi:028:06 -2 0 > c4e77ac0 4271698758 S Co:028:00 s 01 0b 0000 0000 0000 0 > c4e77ac0 4271698902 C Co:028:00 0 0 > > --- (2) Test for 12 bytes TX/RX and writing the extra 1 byte bulk packet --- > (12 byte tx/rx: run program for first time) > f7a2c440 233557145 S Co:029:00 s 00 09 0001 0000 0000 0 > f7a2c440 233557308 C Co:029:00 0 0 > f745b840 233559123 S Bo:029:02 -115 12 = 00000000 00000000 00000000 > f745b840 233559164 C Bo:029:02 0 12 > > f745b840 233559314 S Bi:029:06 -115 12 < > f745b840 233559413 C Bi:029:06 0 12 = 00000000 00000000 00000000 > f745b840 233559549 S Bo:029:02 -115 1 = 58 > f745b840 233559664 C Bo:029:02 0 1 > > f745b840 233562976 S Co:029:00 s 01 0b 0000 0000 0000 0 > f745b840 233563166 C Co:029:00 0 0 > (12 byte tx/rx: run program for 2nd time) > c4e77ac0 234733610 S Co:029:00 s 00 09 0001 0000 0000 0 > c4e77ac0 234733742 C Co:029:00 0 0 > c4e77ac0 234734315 S Bo:029:02 -115 12 = 00000000 00000000 00000000 > c4e77ac0 234734355 C Bo:029:02 0 12 > > c4e77ac0 234734524 S Bi:029:06 -115 12 < > c4e77ac0 234734607 C Bi:029:06 0 12 = 00000000 00000000 00000000 > c4e77ac0 234734749 S Bo:029:02 -115 1 = 58 > c4e77ac0 234734857 C Bo:029:02 0 1 > > c4e77ac0 234739116 S Co:029:00 s 01 0b 0000 0000 0000 0 > c4e77ac0 234739234 C Co:029:00 0 0 > --- > > It appears that test 1 (without the 1 extra byte bulk packet) fails on the > bulk read with error -2: -ENOENT(?). I still think this might not be where > the problem lies because if I do _not_ do that second read and check the > FX2 status registers I find that the 2nd OUT packet never arrived at the > FX2's EP. > > - Stephan > > > On Fri, 9 Feb 2007, Stephan Esterhuizen wrote: > > > > > I'm using Cypress bulkloop.hex firmware on an fx2lp (CY7C68013A) with > > > simple host-side user-land code to transmit data to EP2 (out endpoint) > > > and read the 'echo' on EP6 (in endpoint). The very first time the code > > > is run it writes, say, 60 bytes to EP2 and reads the echo (60 bytes) > > > from EP6. When the host code is run again I get a timeout on EP6. > > > Further digging shows that during the second time the program was run > > > EP2 never actually received any data even though a URB trace shows it > > > was successfully sent: > > > > > > ehci_hcd 0000:00:1d.7: ehci_urb_done 3 urb efd87840 ep2out status 0 > > > len 60/60 > > > > > > This can be 'fixed' by forcing an extra 1-byte bulk out packet to EP2 > > > at the end of the code (before closing the handle). When the program > > > is _then_ run the next time it sends 60 bytes and receives 60 bytes > > > just fine (whatever happened to that extra 1-byte packet I don't know) > > > > ... > > > > > I'm using the 2.6.19 kernel on an Intel 82801G ICH7 controller. I > > > reproduced this on older kernels and on a 2.6.17 AMD64 system with a > > > VIA chipset. > > > > > > Any insights would be very helpful. > > > > Try using the usbmon facility (instructions in the kernel source file > > Documentation/usb/usbmon.txt) to see what's really happening. > > > > [And please instruct your email client to wrap lines at 74 columns or > > thereabouts.] > > > > Alan Stern > > > > -- > -- ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
