On Fri, 2 Nov 2007, Brad Schick wrote: > I'm getting occasional timeouts for interrupt OUT writes and IN reads, > and I have a theory but I'm looking for some input from people with > more experience. > > The device is an Atmel AT90USB162 chip running on a STK526 development > board. The firmware is a slightly modified version of a generic hid > example from Atmel. This is connected to a Linux host running Kernel > 2.6.22-12-generic (under Ubuntu 7.10 32bit). The host machine has usb > 1.1 only. I have a test program on the host build on libusb. > > This is what happens: After reseting my device, the a timeout happens > on the first read or write if the previous run of the test program > ended on an odd number of reads or writes since reset. Lets say I have > one read operation per run of my test program. On the first run after > device reset it will work, 2nd run will timeout, 3rd will work, 4th > timeout, etc. If I change the test program to make two read requests, > they never timeout. Same pattern for writes. > > I'm USB newbie, but my best theory is that the DATA0/DATA1 toggle on > the device or the host is getting out of sync when the test program > starts or ends, causing the host controller to throw away one good > packet until it gets back in sync (meaning the linux driver never sees > the data).
Your theory sounds right. > There is little traffic on the bus, so it is easy to view with usbmon. > This is the kernel's output for one run of the test program with two > writes and a read just after device reset (all is working): > > cfc4ea80 2533411848 S Io:073:02 -115 8 = 01010000 00000000 > cfc4ea80 2533424482 C Io:073:02 0 8 > > cfc4ec00 2534643656 S Io:073:02 -115 8 = 9d050000 00000000 > cfc4ec00 2534656329 C Io:073:02 0 8 > > d78b5000 2534861031 S Ii:073:01 -115 8 < > d78b5000 2534864299 C Ii:073:01 0 8 = 059d0000 00000000 > cfc4e840 2535867107 S Co:073:00 s 01 0b 0000 0000 0000 0 > cfc4e840 2535868186 C Co:073:00 0 0 > > Now run again without resetting the device. Two working writes and a > read timeout: > > cb8a2420 2513765604 S Io:073:02 -115 8 = 01010000 00000000 > cb8a2420 2513778931 C Io:073:02 0 8 > > cb8a2c60 2514993749 S Io:073:02 -115 8 = 11050000 00000000 > cb8a2c60 2515010776 C Io:073:02 0 8 > > cb8a28a0 2515214664 S Ii:073:01 -115 8 < > cb8a28a0 2517219497 C Ii:073:01 -2 0 > cb8a2ea0 2518219870 S Co:073:00 s 01 0b 0000 0000 0000 0 > cb8a2ea0 2518221382 C Co:073:00 0 0 > > So does my theory sound reasonable? Any other? Is there a way to tell > what the host controller is expecting the DATA0/DATA1 state to be at > any given time (I could make the device firmware set a LED to indicate > which state it is sending or reading with)? It's possible, requiring more or less effort depending on which host controller driver you are using. > And why is the following > sent each time the test program ends: > > cfc4e840 2535867107 S Co:073:00 s 01 0b 0000 0000 0000 0 > cfc4e840 2535868186 C Co:073:00 0 0 > > I believe this is the kernel telling interface 0 to use alternate > setting 0. Would that come from the USBDEVFS_RELEASEINTERFACE IOCTL > sent by libusb upon release the interface? Would you expect this to be > resetting the host controllers data toggle to 0? I can look into the > firmware to see what it is doing in response. Yes and yes. See section 9.1.1.5 of the USB 2.0 specification. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
