PROBLEM: USB isochronous urb leak on EHCI driver
stern at rowland.harvard.edu
Tue Jan 6 03:00:06 AEDT 2015
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.
> > 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.
More information about the Linuxppc-dev