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: linux-usb-devel@lists.sourceforge.net >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 2k bytes
periodic_scan.patch
Description: Binary data
