PROBLEM: USB isochronous urb leak on EHCI driver

[Peter Chen]

> 
> My configuration:
> -----------------
> 
> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) Linux
> kernel: 2.6.31, using EHCI USB driver
> 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.
> (the result is that some of the audio data is not transferred, part of the sound is
> simply missing) No problem when using only 1 of the 4 codecs connected to the
> hub; When I connect a second codec, the sound quality starts to degrade. With
> 3 codecs, we just cannot recognize a speach.
> 
> Tests and observations:
> -----------------------
> 
> Since I have 3 usb ports available on the i.MX512, I tried to connect
> 3 codecs directly on USB ports: the sound is perfect on each of the three ports.
> 
> I bought a consumer USB 2.0 Hub: no problem when using 3 codecs connected
> to that Hub, however, the audio will completly stop on all channels when
> connecting the 4th codec.
> 
> I checked the communication between the Hub (USB 1.1) and the Host
> controller (USB 2.0) with a scope and concluded that the communication speed
> is 1.5 MBytes/s has expected (so the communication is downgraded to USB 1.1,
> since codecs and hub are USB
> 1.1 devices).
> 
> Also, I know that there is physically enough bandwidth to transfer the data for
> two reasons:
> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI driver),
> using the same hub and the same codecs: works like a champ, using less than
> 50% of the available bandwidth (observed with a
> scope)
> 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s,
> 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s)
> 
> I noticed that my sound problem starts happening with only 2 codecs
> (4 streams, 256 kB/s). I first thought that it was a bandwidth limitation, so I
> decided to connect only 1 codec using more bandwidth.
> I configured it to 48khz-stereo (16-bits), using 384 kB/s for both read and write
> streams: no problem. With that configuration, the scope shows about 30% of
> total bandwidth usage (300us used out of 1ms periods). Then, I added a second
> codec (48khz-stereo-16bits): very strange, now the total bandwidth usage felt
> down to about 200us, which seems to keep the same, whatever the number of
> codec I add (I also tried 3 and 4...). So it looks like the scheduler is not able to
> properly allocate Isochronous time slots when more than one device is
> connected to the hub. However, without the hub, it works perfectly.
> 

I am wonder if it is similar problem I met when using multiple interrupt transfers,
when you find you lose the data, try to run 'top' to show cpu utilization, if it is
close to 100%, it means the ehci can't queue request in time, so the host can't send IN
token in time.

Using a USB bus analyzer can also verify it.

Peter

> Another interresting fact is that at application level, the Read and Write
> operations are returning the good amount of bytes read/written.
> This is not the case at kernel level: I noticed that function "usb_submit_urb"
> (from /drivers/usb/core/urb.c) will only tranfer part of the "urbs" when the
> sound is degraded. I tried to figure out where the leak comes from without
> success. Also, there are no error messages from kernel so everything appears
> to work well, excepted that part of the sound is missing!
> 
> I can't change my hardware (this is in the hand of customers), so the only
> possible solution for me is to correct the software.
> 
> I tried to change my ehci driver with the one from kernel 2.6.39.4 but did not
> work, same problem.
> 
> Question:
> ---------
> 
> Before attempting to upgrade to an earlier kernel driver (this is 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?
> 
> I am pretty new to USB driver debugging, so any ideas of where/how to find
> solutions will be appreciated. Thank you very much in advance for the support.
> Also don't hesitate to redirect me if I'm not at the right place to ask these
> questions. I can also provide some code if someone need it to help.
> 
> Attached is a dump of my "dmesg" after startup.
> 
> Michael Tessier
> 
> 
> 
> 
> 
>