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.
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 ?
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 ?
- after 30 seconds timeout the urb is aborted and a port reset follows.
- the aborted urb reports 46592 bytes transferred ==> 91 sectors.
So it looks like the 92th packet is not seen by the HC.
The bus analyser is sitting between HC + hub, an can see the packet
without any errors.
In this case, since the bug appear to lie in the storage device, you
should monitor the segment between the hub and the device.
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.
In the error case I see the next interrupt IN to the usblp 12200ns after
the data packet. (Data: 21.429 533 200, IN: 21.429 45 467).
Why do you say "interrupt IN"? According to your debugging log, the
URBs sent to the printer are all async, either bulk or control.
Sorry, bulk in ofcourse.
The usblp device also sitting on the root hub sometimes responds with
100ms(!) worth of NAKs (Ellisys USB explorer trace).
Could this somehow be choking the ehci queues ?
It should not. It doesn't affect the NEC controller, right?
No, the NEC Controller is OK.
But i can't reproduce the transfer error without the usblp on the same ehci.
It could be some sort of electrical crosstalk issue.
electrical problem maybe, but not crosstalk. There is more that enough
time between the missing ACK on one device
and the last/next NAK to the other (12200ns).
According the the bus trace, the NAK's on the usblp device come every 25
uSec. Is there an easy way to loosen this polling rate ?
No. It already is loose; if the controller weren't throttling its
transmissions those NAKs would come every 2 to 4 us, or even faster.
Thats actually also what we've observed unter win. 3 us. inter-NAK timing.
...
There's a few things you should know. First, don't use the system log
for reporting kernel debugging info. Use dmesg instead; it doesn't
drop data the way the syslog daemon does. Second, it's a good idea to
turn on CONFIG_PRINTK_TIME to get high-precision timestamps in the log.
Third, for debugging USB problems, it's generally better to use usbmon
instead of the verbose debugging in the controller driver.
Alan Stern
Many thanks for those pointer. I'll check out usbmon.
- 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
