On Wednesday 12 January 2005 7:18 am, Olav Kongas wrote:
> Hi David,
>
> I've got usbtest running on top of isp116x-hcd, the
> periferal end is net2280 chip.
Good! I see it's already helped you find an issue... ;)
> When running test #10 subtest #10, the driver is in
> trouble. This is the case, where 1KiB data is requested,
> while URB_SHORT_NOT_OK flag is set for urb. The device
> returns 32 bytes, IIRC, and then keeps NAK-ing further
> attempts to squeeze data out of it. The current isp116x
> driver implementation is such that the driver just keeps
> retrying. The urb is stuck as the usbtest waits for its
> completion, while the driver does not complete it.
>
> As other HCDs run test #10 fine, I conclude that I haven't
> just understood, how such SHORT_NOT_OK urbs should be
> handled. USB 2.0 spec Ch 9.2.6.4 states that devices may NAK
> the requests for hundreds of milliseconds before sending the
> next data packet, therefore doing usual error_count>=3 test
> in HCD seems to be inadequate to finish the urb with
> -EREMOTEIO. How this situation is supposed to be handled by
> HCD? Setting up a timer?
No timer. This should be detected by checking the packets
sent by the device. There are basically two cases when
reading any IN (*) packet (not just control transfers):
- Peripheral sends N = maxpacket bytes ... this particular
packet wasn't "short", so the transfer proceeds (unless
urb->transfer_buffer was just filled).
- Peripheral sends N < maxpacket bytes ... this one was
short, the transfer terminates.
Now for net2280, ep0 maxpacket == 64 so once you receive
32 bytes, you know that IN stage terminated. And when
URB_SHORT_NOT_OK is set _and_ the URB buffer isn't full,
that eventually gets reported as -EREMOTEIO, which is
what that test insists on seeing.
The tricky bit with control transfers is that at this point
it's time to move from the control DATA stage into the
control STATUS stage (OUT DATA1 zero-length packet), even
if urb->status will later be reporting a "short" fault.
But if you got a Real Error (-EPIPE/stall, etc) you'd be
skipping that STATUS stage.
The _really_ tricky bit is that if your HCD skips the
DATA stage it'll usually work. Except ... that some
peripherals will misbehave (badly) when you do that,
leading to some mysterious failures later on, but only
with certain devices.
> I looked into sl811-hcd in 2.6.10 and it seems like it just
> retries like my current isp116x-hcd. But how does it survive
> the usbtest #10 then? Tried to look at other HCDs as well,
> but there the Done queues are filled by HCs and the code
> didn't reveal much on this issue.
That particular bit of USB logic may seem a bit "hidden"
since it's probably implicit ... every place where an IN
transfer needs to be processed needs to have that logic.
- Dave
(*) And if you're writing a USB peripheral Controller
driver, there's a corresponding issue reading OUT
transfers. Except that usb_request.status won't
indicate an error (making the API much simpler!);
the transfer still ends right away.
> Thanks in advance,
> Olav
>
>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
