PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

> > > > 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.

According to your knowledge, how much time would you think it takes to
change the EHCI driver with an OHCI one? And can you tell if the OHCI driver
will work on my hardware given that the Host controller of the i.MX512 is
a USB2.0 host controller? (OHCI was implemented for USB 1.x from what I
understand) I tried to do so several days ago with the built-in configurator
(I am using "ltib"), but the configurator does not allow selecting the
OHCI driver; I tried manually but it turned into compiler errors...

> 
> > > 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.

Good point. I'll try that for sure. This will at least let me know if this
issue has been corrected in the latest kernel.

Michael Tessier