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