On Mon, 5 Dec 2011, Sancho Dauskardt wrote: > Hi, > > we're still wrestling with this one, but no major advances. > > Most important: with a little libusb helper to get the usblp to heavily > NAK IN's, SD-transfers break down on win7-x64 as well. > > One hardware setup was 'magically cured' - after running under windows. > Booting the same harddisk on another identical hardware setup didn't > cure that one. Fresh windows install + all hotfixes didn't help either. > This must be some very minor hardware change that we have missed. Can you get in touch with the technical support people at the company that sells the disk drive's USB interface? (You may have to tell them about the problem you see under Windows; many companies claim not to support Linux.) > So what we have: > - when 'under NAK load' SB710 EHCI misses an incomming data packet and > thus doesn't send an ACK. > - AU63xx doesn't handle the missing ACK properly. > - we also have some usb-sticks that don't react mit missing ACK's properly. > > Could this be related to the current Webcam issue ? I don't think so. That problem clearly lies in the host controller, not the device. The controller takes an excessively long time (up to 8 ms instead of no more than 1 ms) to shut down the periodic schedule. > On 17.11.2011 17:29, Alan Stern wrote: > > On Thu, 17 Nov 2011, Sancho Dauskardt wrote: > > > >> Ok, finally managed to get a usefull bus capture + match URB_TRACE. See > >> below for the urb trace. > >> > >> What happens: > >> - usb-storage requests 240x 512 Byte sectors. > >> - the 92th transfer doesn't get an ACK from the HC. > >> - after the missing ACK the HC keeps on sending IN's which are NAK'ed by > >> the storage device. > >> > > That's a bug in the storage device -- it should resend the packet which > > wasn't ACK'ed. (Unless for some reason it thought the packet _did_ get > > an ACK.) > > > Yes, understand that now. But i'd guess there are a LOT of (storage) > devices with this type of bug ? Maybe -- I have no idea. It's not an easy thing to test for. > >> Normally an ACK would come 9100ns after the data packet (Data: 21.429 > >> 518 444 vs. ACK: 21.429 527 517). > >> > > That seems awfully long. According to the USB-2 spec (section > > 7.1.18.2), high-speed inter-packet delays are supposed to be no more > > than 192 bit times. That's less than half a microsecond. Did you ever figure this out? 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
