On Wed, 2 May 2001, Johannes Erdfelt wrote:
> I suggest you go and read the UHCI docs and understand how the schedule
> is processed.
Ok, seems I should check that. My reading of UHCI-1.1 docs, p32 was, the
HC would never advance to the next QH on NAK (or other error)...
> This fix will fail for any device which NAK's a single packet. It will
> then continue onto the next "queued" urb and start processing that
> before the first one is finished. This is guaranteed to corrupt the
> data being sent to the device.
Well, that would kill it for sure.
What you describe would only corrupt data in case there are several queued
urb for one endpoint - right? My impression was in that case data might
get mixed anyway - due to the "always assume breadth first" approach.
Wouldn't this cause the HC to advance to the next QH after the first TD
from the current has been processed?
Anyway - chances are the observation that uhci_append_queued_urb() makes
significant contribution to the problem might be helpful. Probably the
eurb which was determined much earlier with status==EINPROGRESS might be
racy: all active TD of eurb might meanwhile been transmitted. This might
even be true from the very beginning - eurb is determined inside
spin_lock_irqsave, so status might be outdated (i.e. all its TD's
already inactive at this point). So we end up connecting the new QH's TD
to a lltd->link, which is now out-of-reach for the HC?
This would at least be consistent with both observations: we are stuck
with status==-EINPROGRESS forever and this "Element != First TD" warning
from /proc/driver/uhci/hc0.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
