On Mon, 5 Jan 2015, Michael Tessier wrote: > > > Hi, > > > > > > I am dealing with a USB EHCI driver bug. Here is the info: > > > > > > My configuration: > > > ----------------- > > > > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) > > > Linux kernel: 2.6.31, using EHCI USB driver > > > > As mentioned by other people, the age of that kernel makes any bug report completely irrelevant. It's hard to count the number of non-trivial changes that have > been made to the isochronous code in ehci-hcd since 2.6.31, but there have been quite a few. > > > > > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) > > > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) > > > > > > Note: each codec is being used in R/W access, so with 4 codecs, I have > > > 4 playback and 4 capture streams. > > > > > > My problem: > > > ----------- > > > > > > I have usb urb leaks when connecting more than 1 codec to the USB 1.1 > > > Hub. > > > > What do you mean by "urb leak"? Normally, people use the word "leak" > > to refer to memory that is dynamically allocated and never deallocated, but you seem to mean something else. > > You are right. What I mean by leak is the following: At application level, > all my calls to "Read" or "Write" operation to the codec driver will return > with the correct amount of bytes read/written, with a "choppy" sound. Then > when looking at lower levels: > > snd_pcm_oss_write (pcm_oss.c) -> OK > snd_pcm_lib_write (pcm_lib.c) -> OK > usb_submit_urb (urb.c) -> FAIL with 3 codecs > > The "FAIL" here indicates that the total amount of bytes transferred does > not correspond to what was expected. And indeed the sound is "choppy" when > using more than a certain amount of bandwidth. However this amount of > bandwidth is higher when connecting only 1 codec with different settings > (48khz-stereo 16-bits instead of 32 khz-mono 16-bits).So at some point it > looks like the bug is in the scheduler, only with several isochronous links. Agreed. > > The amount of bandwidth available is usually not as much of an issue as the ability of the scheduling alogorithm to divide the bandwidth among the streams. The > > algorithm is not very smart and it often runs into a wall even when lots of physical bandwidth is still available. > > That is interresting, however, I have an older kernel running an OHCI > driver which is able to handle 4 codecs. Same usb hardware (codecs and > hub), but older kernel on a different CPU, with much less power. This makes > me believe that there's a solution to make it work... Of course there is: Install an OHCI host controller and use it to drive your codecs. It should work fine. The periodic scheduling algorithm for OHCI is very different from the algorithm for EHCI. > > How does your hardware connect the host controller to a full-speed device? Is there an internal hub (Intel motherboards have used this approach)? Is there a > > companion USB-1.1 controller (older motherboards from Intel and other companys have used this approach)? Does the EHCI controller have a built-in Transaction > > Translator (some SOC systems use this approach)? > > The CPU is a Freescale i.MX512, with 3 USB 2.0 Host controllers. My hub > is connected to the main CPU board with a standard USB cable, so it's easy > to swap my 4-port hub from a USB 1.1 to a USB 2.0. My codecs are always > the same: USB 1.1 Texas Instruments PN# pcm2901. I don't believe there's > a built-in Transaction Translator. How can I check that? You can tell by seeing what shows up in the "lsusb -t" output when you plug in the USB-1.1 hub. If the hub's parent is the EHCI controller then there must be a built-in TT. Also, if you enable CONFIG_USB_DEBUG in your kernel then the dmesg log for boot-up should say whether or not the controller has a built-in TT. > > > Question: > > > --------- > > > > > > Before attempting to upgrade to an earlier kernel driver (this is > > > > "upgrade to an earlier kernel driver" is a contradiction in terms. > > Moving to an earlier driver would be a _downgrade_. > > Sorry, I meant to say "newer"... > > > > a fairly big amount of work), I would really like to know if this > > > problem would still be in the 3.x kernels. Has anyone seen that issue > > > in 3.x kernels? > > > > It depends a lot on the system hardware. Many people are using USB audio in 3.x kernels with no problem. On the other hand, some people have reported a bug > > (quite different from yours) so recently that the patch to fix it has not yet been merged. > > I understand. However, if one could test the following with a 3.x kernel: > - CPU with USB 2.0 Host controller (using EHCI-hcd driver) > - 4-port USB 1.1 Hub > - 4x USB codecs (configured at 32khz-mono, 16-bits audio) > > Then try to stream audio on each of the 4 codecs at the same time (this > includes one Read and one Write stream on each codec, so total of 4 "Read" > and 4 "Write" streams. Then listen to the output... The result is likely to depend on what other USB hardware is attached. > If sound is ok when using only 1 codec and becomes choppy when adding a > second codec, then it means that this issue is still in the 3.x kernel. This > answer will tell me if it is worth working on using a newer kernel or not. > I have to say that I'm not a linux expert, so I see the migration to a newer > kernel as a quite big amount of work... Why don't you try this yourself? It's easy to do; borrow a regular PC with a USB-2 host controller, boot it from a Live-CD version of Linux, plug in your hub with the codecs, and see what happens. Alan Stern -- 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
