On Sat, 25 Aug 2012, David Ranch wrote: > Hello Alan, > > Ok... I've uploaded the DEBUG enabled 3.5.2 kernel logs as requested and > I'm working on getting the USB snooping going on the old Athlon 1.1Ghz > Windows XP machine (yuk!). > > http://www.trinityos.com/SCRATCH/ > > > Regardless of getting this possible high-speed hack working, could you > explain a bit by what you meant by: > > "The problem is caused by the ehci-hcd driver's not-so-great support > for scheduling periodic transfers to full-speed devices. That's why the > HP and Dell systems have no trouble but your Gateway laptop can't handle > it. " > > To me if I'm doing the math right, 2 (two stereo channels) * 24 (bit) * > 96,000 (sampling) == 4.6Mb/s which is only a third of the USB port's > speed when even running in FULL speed mode! Why would it be complaining > when there isn't anything else on this bus? Well, for one thing the available full-speed bandwidth is less than 15 Mb/s. Periodic transfers (such as audio data) are not allowed to consume more than 90% of the total bandwidth. In addition, USB uses bit stuffing to prevent more than six 1's appearing consecutively on the bus; this means everything has to be assessed 7/6 more bandwidth than the nominal value. And then there's protocol overhead. But even so, a full-speed bus can handle something like 1100 bytes of periodic data per ms, and your device only needs 585 (3 bytes of interrupt data and 582 bytes of isochronous audio data). However this isn't a question of bandwidth; it's a question of limitations in the driver. ehci-hcd's support for periodic split transactions (which includes full-speed isochronous and interrupt transfers, which includes what's going on with your audio device) is really very poor. The best that can be said is that it sort of works most of the time. But there are plenty of cases where it doesn't work, and you are facing one of them. > What are the chances > when/if this EHCI driver will get some fixes for this issue? A real fix will not come quickly because doing this right is very difficult. The patch below is sort of a band-aid; I'm not promising anything but it might help. By the way, now that you've got CONFIG_USB_DEBUG enabled, there's something I'd like to see. I'm assuming you've got a debugfs filesystem mounted on /sys/kernel/debug. Go into /sys/kernel/debug/usb/ehci/0000:00:1d.0/ (that's the directory corresponding to the controller your device is plugged into, bus 2) and post a copy of the "periodic" file in that directory -- this is with your test program running, of course (using a smaller sampling rate so that it doesn't fail immediately). In fact, do the same thing both with and without the patch below. I'd like to verify that it does make a difference. Alan Stern Index: usb-3.5/drivers/usb/host/ehci-sched.c =================================================================== --- usb-3.5.orig/drivers/usb/host/ehci-sched.c +++ usb-3.5/drivers/usb/host/ehci-sched.c @@ -840,7 +840,7 @@ static int qh_schedule(struct ehci_hcd * for (i = qh->period; status && i > 0; --i) { frame = ++ehci->random_frame % qh->period; - for (uframe = 0; uframe < 8; uframe++) { + for (uframe = 8; uframe-- > 0; ) { status = check_intr_schedule (ehci, frame, uframe, qh, &c_mask); -- 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
