The requested patch is as follows:
diff -Nru a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2004-12-21 18:02:48.921708256
-0500
+++ b/drivers/usb/host/ehci-sched.c 2004-12-21 18:25:41.130100872
-0500
@@ -1796,6 +1796,7 @@
{
unsigned frame, clock, now_uframe, mod;
unsigned modified;
+ u8 uncompleted_td = 0;
mod = ehci->periodic_size << 3;
@@ -1874,8 +1875,10 @@
q = *q_p;
break;
}
- if (uf != 8)
+ if (uf != 8) {
+ uncompleted_td = 1;
break;
+ }
/* this one's ready ... HC won't cache
the
* pointer for much longer, if at all.
@@ -1894,6 +1897,7 @@
hw_p = &q.sitd->hw_next;
type = Q_NEXT_TYPE
(q.sitd->hw_next);
q = *q_p;
+ uncompleted_td = 1;
break;
}
*q_p = q.sitd->sitd_next;
@@ -1925,12 +1929,17 @@
// FIXME: likewise assumes HC doesn't halt mid-scan
+ /* We must start the next scan cycle at the first
+ * uncompleted TD so that TDs are not lost.
+ */
+ if ((!uncompleted_td) && (HCD_IS_RUNNING
(ehci->hcd.state)))
+ ehci->next_uframe = now_uframe;
+
if (now_uframe == clock) {
unsigned now;
if (!HCD_IS_RUNNING (ehci->hcd.state))
break;
- ehci->next_uframe = now_uframe;
now = readl (&ehci->regs->frame_index) % mod;
if (now_uframe == now)
break;
-----Original Message-----
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Friday, January 07, 2005 12:48 PM
To: [email protected]
Cc: Torsten Landschoff; Oliver Brandt; Craig Nadler
Subject: Re: [linux-usb-devel] Re: USB 1.1 Soundcard on USB 2.0 HUB
On Friday 07 January 2005 4:23 am, Torsten Landschoff wrote:
> Hi Oliver,
>
> On Fri, Jan 07, 2005 at 12:37:26PM +0100, Oliver Brandt wrote:
>
> [USB Audio problems over USB 2.0 hub]
>
> > I've read that iso transfer and transaction translation have
> > something to do with it and that transaction translation is not
> > fully implemented yet (I'm using kernel 2.6.10). Are there any
> > patches available I should use?
>
> Actually the problem AFAIU is that the audio device is managed by a
> transaction translator in the hub. Therefore isochronous data transfer
> at full speed gets more complicated.
That bug's been there for a while, but not many folk have reported it.
However, a couple weeks back Craig Nadler <[EMAIL PROTECTED]>
turned up what could be the root cause:
>>> the scanning loop for the periodic list misses completed SITDs
due
>>> to a race condition. The missed SITDs have not been marked as
>>> completed at the time they were scanned then the frame counter
>>> advanced before the scanning loop was finished. In this case the
>>> scanning loop will not rescan TDs in that frame and the EHCI driver
>>> will hang waiting for the TD to be removed by the scanning loop.
>>> There are two fixes that I've looked at. The first one stops the
>>> next_frame field in the ehci structure from being incremented passed
a frame with an uncompleted TD.
>>> The second fix would stop the next_frame field from being
>>> incremented passed the frame that's current at the beginning of the
scanning loop.
Which could be what's causing this; when I saw similar problems they
were (a) intermittent == race-like, (b) never on the very regular stress
loads I used to test that those split ISO transfers, and (c) only on ISO
transfers which were split up over several microframes. (When going
through a transaction translator, an ISO-OUT transfer gets split up into
188 byte fragments, one per microframe. So transfers of 189 bytes or
more would be affected.)
That second approach to a fix sounds straightforward. Anyone feel like
trying to provide a patch?
- Dave
periodic_scan.patch
Description: periodic_scan.patch
