On 05.12.2011 17:38, Alan Stern wrote:
On Mon, 5 Dec 2011, Sancho Dauskardt wrote:
[...]
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 far we are only talking to the hub guys, as the chain AMD SB7xx +
SMSC251x + bad storage device is needed to trigger the fault - plus the
NAK'ing usblp.
AMD - anybody here ?
makrSo 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.
True, but to me it seems like the HC is busy with the last NAK and thus
missing the incomming data for the next one.
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?
The timing includes the actual transfer of the data packet - which then
makes sense, right ?
- sda
--
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
