On Fri, 22 May 2009, Dwayne Fontenot <dwayne.fontenot@xxxxxxx> wrote:
> > I had an idea. This information shows that all of your interrupt
> > transfers are queued for the same microframes. It might help to
> > stagger them.
>
> That sounds promising. I admit I cannot completely interpret the above;
> what part shows which microframe an interrupt transfer is queued for?
Let's take a typical example:
255: qh256-0001/f44cc080 (h18 ep1in [1/0] q1 p1)
"255" is the frame number (but not the uframe within the frame).
"qh256" means this is a QH (i.e., an Interrupt transfer) with period
256 frames.
"0010" is the hexadecimal Cmask (8 bits) and Smask (8 bits); the Smask
bits indicates which uframes the transfer is scheduled for within the
frame.
"f44cc080" is the address of the QH (Queue Head) structure.
"h" means High speed and "18" is the device address. "ep1in" is
self-explanatory.
"[1/0]" means that the transfer is budgeted 1 microsecond for starting
and 0 for completing (completions are needed only for transfers to
Full- or Low-speed devices, where the start and the completion are
carried out in separate transactions).
"q1" means there is one URB currently queued for this endpoint.
"p1" means the maxpacket size is 1.
> > You should try changing your driver so that it delays by one
> > millisecond after submitting each of the initial interrupt URBs. Then
> > different URBs will be processed during different frames and the queue
> > depths will never get very big. The NEC controller might be able to
> > handle this with no problem.
> >
> > Alan Stern
>
> I configured CONFIG_PRINTK_TIME=y and ran the test again.
> The interrupt URB submissions look like this:
>
> [ 951.701316] usb 4-4.4.2: submitted intr urb for ru100
> [ 951.702951] usb 4-4.4.3: submitted intr urb for ru101
> [ 951.703770] usb 4-4.4.5: submitted intr urb for ru102
...
> The initial interrupt URB submissions are in the probe routine of the RU driver.
> It appears that they are already staggered over approx. 64 mS (?).
>
> The periodic schedule for the above looks like this (first six entries are the hubs):
>
> size = 256
> 255: qh256-0001/f68e5100 (h2 ep1in [1/0] q1 p1) qh256-0001/f68e5500 (h9 ep1in [1/0] q1 p1) qh256-0001/f68e5600 (h10 ep1in [1/0] q1 p1) qh256-0001/f68e5d00 (h23 ep1in [1/0] q1 p1) qh256-0001/f68e5e00 (h24 ep1in [1/0] q1 p1) qh256-0001/f543f580 (h37 ep1in [1/0] q1 p1) qh256-0001/f68e5980 (h44 ep1in [2/0] q1 p64) qh256-0001/f68e5780 (h45 ep1in [2/0] q1 p64) qh256-0001/f68e5700 (h46 ep1in [2/0] q1 p64) qh256-0001/f68e5680 (h47 ep1in [2/0] q1 p64) qh256-0001/f68e5900 (h48 ep1in [2/0] q1 p64) qh256-0001/f68e5880 (h49 ep1in [2/0] q1 p64) qh256-0001/f68e5800 (h50 ep1in [2/0] q1 p64) qh256-0001/f68e5400 (h51 ep1in [2/0] q1 p64) qh256-0001/f68e5380 (h52 ep1in [2/0] q1 p64) qh256-0001/f68e5300 (h53 ep1in [2/0] q1 p64) qh256-0001/f68e5280 (h54 ep1in [2/0] q1 p64) qh256-0001/f68e5200 (h55 ep1in [2/0] q1 p64) qh256-0001/f68e5180 (h56 ep1in [2/0] q1 p64) qh256-0001/f561c000 (h57 ep1in [2/0] q1 p64) qh256-0001/f561c080 (h58 ep1in [2/0] q1 p64) qh256-0001/f561c100 (h59 ep1in [2/0] q1 p64) qh256-0001/f561c180 (h60 ep1in [2/0] q1 p64) qh256-0001/f561c200 (h61 ep1in [2/0] q1 p64) qh256-0001/f561c280 (h62 ep1in [2/0] q1 p64) qh256-0001/f561c300 (h63 ep1in [2/0] q1 p64) qh256-0001/f561c380 (h64 ep1in [2/0] q1 p64) qh256-0001/f561c400 (h65 ep1in [2/0] q1 p64) qh256-0001/f561c480 (h66 ep1in [2/0] q1 p64) qh256-0001/f561c500 (h67 ep1in [2/0] q1 p64) qh256-0001/f561c580 (h68 ep1in [2/0] q1 p64) qh256-0001/f561c600 (h69 ep1in [2/0] q1 p64) qh256-0001/f561c680 (h70 ep1in [2/0] q1 p64) qh256-0001/f561c700 (h71 ep1in [2/0] q1 p64) qh256-0001/f561c780 (h72 ep1in [2/0] q1 p64) qh256-0001/f561c800 (h73 ep1in [2/0] q1 p64) qh256-0001/f561c880 (h74 ep1in [2/0] q1 p64) qh256-0001/f561c900 (h75 ep1in [2/0] q1 p64) qh256-0001/f561c980 (h76 ep1in [2/0] q1 p64) qh256-0001/f561ca00 (h77 ep1in [2/0] q1 p64) qh256-0001/f561ca80 (h78 ep1in [2/0] q1 p64) qh256-0001/f561cb00 (h79 ep1in [2/0] q1 p64)
>
>
> Maybe a USB scheduler bug is causing them to all be queued for the same
> microframe?
No, it's not a bug -- it was my oversight. I didn't notice that the
scheduler tries to put all interrupt transfers as early as possible.
There's no particular reason for this as far as I can see; that was
just the easiest way to do it.
The patch below will cause things to be more spread out. You won't
even have to include the 1-ms delays in your driver!
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci-sched.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-sched.c
+++ usb-2.6/drivers/usb/host/ehci-sched.c
@@ -760,8 +760,10 @@ static int qh_schedule(struct ehci_hcd *
if (status) {
/* "normal" case, uframing flexible except with splits */
if (qh->period) {
- frame = qh->period - 1;
- do {
+ int i;
+
+ for (i = qh->period; status && i > 0; --i) {
+ frame = ++ehci->random_frame % qh->period;
for (uframe = 0; uframe < 8; uframe++) {
status = check_intr_schedule (ehci,
frame, uframe, qh,
@@ -769,7 +771,7 @@ static int qh_schedule(struct ehci_hcd *
if (status == 0)
break;
}
- } while (status && frame--);
+ }
/* qh->period == 0 means every uframe */
} else {
Index: usb-2.6/drivers/usb/host/ehci.h
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci.h
+++ usb-2.6/drivers/usb/host/ehci.h
@@ -116,6 +116,7 @@ struct ehci_hcd { /* one per controlle
struct timer_list watchdog;
unsigned long actions;
unsigned stamp;
+ unsigned random_frame;
unsigned long next_statechange;
u32 command;
--
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
