PROBLEM: USB isochronous urb leak on EHCI driver

PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

[-- Attachment #1: Type: text/plain, Size: 4156 bytes --]

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








[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 9134 bytes --]

<5>Linux version 2.6.31-770-g0e46b52-0897 (michael.tessier@vsvr-compile-01.pocatec.com) (gcc version 4.1.2) #12 PREEMPT Mon Nov 24 18:34:19 EST 2014
<4>CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f
<4>CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
<4>Machine: MX51 Xanthus Board
<4>Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 65536
<7>free_area_init_node: node 0, pgdat c02f137c, node_mem_map c0307000
<7>  DMA zone: 128 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 16256 pages, LIFO batch:3
<7>  Normal zone: 384 pages used for memmap
<7>  Normal zone: 48768 pages, LIFO batch:15
<4>Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
<5>Kernel command line: console=ttymxc2,115200 CNFGmagic=XATS CNFGversion=1.0.0.0 vendorID=EXPT platformID=LINX productID=XATS mac1=00:1D:9E:00:17:2e mac2=00:1D:9E:00:17:2f XanthusPart=8100050 XanthusSerial=51 XanthusRevLevel=-- UnitPart=0 UnitSerial=0 UnitRevLevel=0 ip= UBversion=1.5.0.0 ethcpu=eth0 root=/dev/ram rw ramdisk_size=55000
<4>PID hash table entries: 1024 (order: 10, 4096 bytes)
<6>Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Memory: 256MB = 256MB total
<5>Memory: 254000KB available (2660K code, 208K data, 104K init, 0K highmem)
<6>SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:368
<6>MXC IRQ initialized
<6>MXC_Early serial console at MMIO 0x7000c000 (options '115200')
<6>console [ttymxc2] enabled
<4>Console: colour dummy device 80x30
<6>Calibrating delay loop... 575.07 BogoMIPS (lpj=2875392)
<4>Mount-cache hash table entries: 512
<6>CPU: Testing write buffer coherency: ok
<6>NET: Registered protocol family 16
<6>i.MX IRAM pool: 128 KB@0xd0840000
<6>IRAM READY
<6>CPU is i.MX51 Revision 3.0
<6>MXC GPIO hardware
<4>XANTHUS FPGA irq controler :197
<4>ks8851: mac(00:1d:9e:00:17:2f)
<4>XANTHUS FPGA VERSION: 0.1.0.0
<6>Using SDMA I.API
<6>MXC DMA API initialized
<4>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<7>libata version 3.00 loaded.
<6>CSPI: mxc_spi-0 probed
<6>mxc_spi mxc_spi.0: registering loopback device 'spidev'
<6>mxc_spi mxc_spi.0: registering loopback device 'spidev'
<6>mxc_spi mxc_spi.0: registering loopback device 'spidev'
<6>MXC I2C driver
<6>MXC HS I2C driver
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
<7>Switched to high resolution mode on CPU 0
<6>TCP established hash table entries: 8192 (order: 4, 65536 bytes)
<6>TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
<6>TCP: Hash tables configured (established 8192 bind 8192)
<6>TCP reno registered
<6>NET: Registered protocol family 1
<6>Trying to unpack rootfs image as initramfs...
<6>rootfs image is not initramfs (no cpio magic); looks like an initrd
<6>Freeing initrd memory: 2604K
<6>LPMode driver module loaded
<6>msgmni has been set to 501
<6>io scheduler noop registered (default)
<4>Class created!
<6>Triggered GPIO driver. Boundary Devices
<6>XANTHUS Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
<6>serial8250.0: ttyS0 at MMIO 0xb0100000 (irq = 352) is a 16550A
<6>Serial: MXC Internal UART driver
<6>mxcintuart.0: ttymxc0 at MMIO 0x73fbc000 (irq = 31) is a Freescale i.MX
<6>mxcintuart.1: ttymxc1 at MMIO 0x73fc0000 (irq = 32) is a Freescale i.MX
<6>mxcintuart.2: ttymxc2 at MMIO 0x7000c000 (irq = 33) is a Freescale i.MX
<6>console handover: boot [ttymxc2] -> real [ttymxc2]
<6>brd: module loaded
<6>loop: module loaded
<3>pata_fsl pata_fsl: rchan=29 wchan=28
<6>scsi0 : pata_fsl
<6>ata1: PATA max UDMA/100 irq 70
<6>FEC Ethernet Driver
<3>FEC: fec_probe name:fec, id:0, net name:eth0, index:0
<3>FEC: mac(00:1d:9e:00:17:2e)
<6>ata1.00: CFA: TRANSCEND, 20100202, max UDMA/66
<6>ata1.00: 994896 sectors, multi 0: LBA 
<6>ata1.00: configured for UDMA/66
<5>scsi 0:0:0:0: Direct-Access     ATA      TRANSCEND        2010 PQ: 0 ANSI: 5
<5>sd 0:0:0:0: [sda] 994896 512-byte logical blocks: (509 MB/485 MiB)
<5>sd 0:0:0:0: [sda] Write Protect is off
<7>sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
<5>sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
<6> sda: sda1 sda2 sda3 sda4
<5>sd 0:0:0:0: [sda] Attached SCSI disk
<6>fec_enet_mii_bus: probed
<4>IEEE1588: ptp-timer is unavailable
<6>rtc-ds1307 3-0068: rtc core: registered ds1340 as rtc0
<6>i2c /dev entries driver
<6>Xanthus WatchDog Driver 1.2
<4>clk: Unable to get requested clock: wdog_clk
<6>XANTHUS Boot - WDOG Rst - Soft Reset (10010,1)
<6>Xanthus Watchdog # 0 Timer: initial timeout 60 sec
<6>TCP cubic registered
<6>NET: Registered protocol family 17
<6>VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2
<6>rtc-ds1307 3-0068: setting system clock to 2000-01-01 00:00:44 UTC (946684844)
<5>RAMDISK: gzip image found at block 0
<4>VFS: Mounted root (ext2 filesystem) on device 1:0.
<6>Freeing init memory: 104K
<6>XANTHUS ks8851_mll: Driver version 1.00.
<6>XANTHUS: ks8851_probe name:ks8851_mll, id:0, net name:eth1, index:0
<6>ks8851 hard reset
<6>ks8851_mll ks8851_mll.0: message enable is 31
<6>KS_CIDER:8872
<6>ks8851_mll ks8851_mll.0: the selftest passes
<6>XANTHUS: ks_soft_reset
<6>XANTHUS: KS8851 mac(00:1d:9e:00:17:2f)
<6>ks8851_mll Found chip, family: 0x88, id: 0x7, rev: 0x1
<6>Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
<6>bonding: MII link monitoring set to 100 ms
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<6>fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
<6>fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
<6>fsl-ehci fsl-ehci.0: irq 18, io base 0x73f80000
<6>fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
<6>usb usb1: configuration #1 chosen from 1 choice
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
<6>fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
<6>fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
<6>fsl-ehci fsl-ehci.1: irq 14, io base 0x73f80200
<6>fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 1 port detected
<6>fsl-ehci fsl-ehci.2: Freescale On-Chip EHCI Host Controller
<6>fsl-ehci fsl-ehci.2: new USB bus registered, assigned bus number 3
<6>fsl-ehci fsl-ehci.2: irq 16, io base 0x73f80400
<6>fsl-ehci fsl-ehci.2: USB 2.0 started, EHCI 1.00
<6>usb usb3: configuration #1 chosen from 1 choice
<6>hub 3-0:1.0: USB hub found
<6>hub 3-0:1.0: 1 port detected
<6>Initializing USB Mass Storage driver...
<6>usb 2-1: new full speed USB device using fsl-ehci and address 2
<6>usbcore: registered new interface driver usb-storage
<6>USB Mass Storage support registered.
<6>usb 2-1: configuration #1 chosen from 1 choice
<6>hub 2-1:1.0: USB hub found
<6>hub 2-1:1.0: 4 ports detected
<6>usb 2-1.1: new full speed USB device using fsl-ehci and address 3
<6>kjournald starting.  Commit interval 5 seconds
<4>EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
<6>EXT3 FS on sda3, internal journal
<6>EXT3-fs: recovery complete.
<6>EXT3-fs: mounted filesystem with ordered data mode.
<6>usb 2-1.1: configuration #1 chosen from 1 choice
<6>eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
<4>expio_set_type_irq IRQF_TRIGGER_LOW
<6>XANTHUS: ks_update_link_status
<6>usb 2-1.2: new full speed USB device using fsl-ehci and address 4
<6>usb 2-1.2: configuration #1 chosen from 1 choice
<6>usb 2-1.3: new full speed USB device using fsl-ehci and address 5
<6>usb 2-1.3: configuration #1 chosen from 1 choice
<6>PHY: 0:00 - Link is Up - 100/Full
<6>eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
<6>bonding: bond0: making interface eth0 the new active one.
<6>bonding: bond0: first active interface up!
<6>bonding: bond0: enslaving eth0 as an active interface with an up link.
<6>ks_net_stop
<6>ks8851_mll ks8851_mll.0: eth1: shutting down
<4>expio_set_type_irq IRQF_TRIGGER_LOW
<6>XANTHUS: ks_update_link_status
<6>XANTHUS: KS8851 mac(00:1d:9e:00:17:2e)
<6>bonding: bond0: enslaving eth1 as a backup interface with a down link.
<6>kjournald starting.  Commit interval 5 seconds
<4>EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
<6>EXT3 FS on sda2, internal journal
<6>EXT3-fs: recovery complete.
<6>EXT3-fs: mounted filesystem with ordered data mode.
<6>kjournald starting.  Commit interval 5 seconds
<4>EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
<6>EXT3 FS on sda4, internal journal
<6>EXT3-fs: recovery complete.
<6>EXT3-fs: mounted filesystem with ordered data mode.
<6>PHY: 0:00 - Link is Up - 100/Full
<6>usbcore: registered new interface driver snd-usb-audio
<4>axiodrv: module license 'Proprietary' taints kernel.
<4>Disabling lock debugging due to kernel taint
<6>io: registered with major 250 and delay 1000

Re: PROBLEM: USB isochronous urb leak on EHCI driver

[Greg KH]

On Mon, Dec 15, 2014 at 08:53:20PM +0000, Michael Tessier wrote:
> <5>Linux version 2.6.31-770-g0e46b52-0897 (michael.tessier@vsvr-compile-01.pocatec.com) (gcc version 4.1.2) #12 PREEMPT Mon Nov 24 18:34:19 EST 2014

That is a _very_ old and obsolete kernel version, you need to get
support from the company that is forcing you to stay on that version, as
you are paying them for this.

There is nothing the community can do with a kernel version like this,
sorry.

best of luck,

greg k-h

Re: PROBLEM: USB isochronous urb leak on EHCI driver

[Fabio Estevam]

On Mon, Dec 15, 2014 at 6:53 PM, Michael Tessier
<michael.tessier@axiontech.ca> wrote:

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

In fact it is very simple to test USB on a 3.18 kernel with your hardware.

You only need a minimal dts file with the usb/serial nodes enabled.

Take a loot at arch/arm/boot/dts/imx51-babbage.dts for a reference.

I tested USB earlier today on this board with 3.18 and it worked fine.
You need this patch:
http://www.spinics.net/lists/arm-kernel/msg385739.html

Regards,

Fabio Estevam

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Peter Chen]

=20
>=20
> My configuration:
> -----------------
>=20
> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) Linu=
x
> 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)
>=20
> Note: each codec is being used in R/W access, so with 4 codecs, I have
> 4 playback and 4 capture streams.
>=20
> My problem:
> -----------
>=20
> 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 th=
e 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.
>=20
> Tests and observations:
> -----------------------
>=20
> 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.
>=20
> 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.
>=20
> 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 sp=
eed
> 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).
>=20
> Also, I know that there is physically enough bandwidth to transfer the da=
ta for
> two reasons:
> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI dri=
ver),
> using the same hub and the same codecs: works like a champ, using less th=
an
> 50% of the available bandwidth (observed with a
> scope)
> 2) 1 audio stream is 32khz-mono, 16 bits =3D 64 kB/s,
> 4 codecs =3D 8 streams(R/W) x 64 kB/s =3D 512 kB/s (out of 1.5MB/s)
>=20
> 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 a=
nd write
> streams: no problem. With that configuration, the scope shows about 30% o=
f
> total bandwidth usage (300us used out of 1ms periods). Then, I added a se=
cond
> 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.
>=20

I am wonder if it is similar problem I met when using multiple interrupt tr=
ansfers,
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 c=
an'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 Writ=
e
> 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 withou=
t
> success. Also, there are no error messages from kernel so everything appe=
ars
> to work well, excepted that part of the sound is missing!
>=20
> I can't change my hardware (this is in the hand of customers), so the onl=
y
> possible solution for me is to correct the software.
>=20
> I tried to change my ehci driver with the one from kernel 2.6.39.4 but di=
d not
> work, same problem.
>=20
> Question:
> ---------
>=20
> Before attempting to upgrade to an earlier kernel driver (this is a fairl=
y 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?
>=20
> I am pretty new to USB driver debugging, so any ideas of where/how to fin=
d
> solutions will be appreciated. Thank you very much in advance for the sup=
port.
> Also don't hesitate to redirect me if I'm not at the right place to ask t=
hese
> questions. I can also provide some code if someone need it to help.
>=20
> Attached is a dump of my "dmesg" after startup.
>=20
> Michael Tessier
>=20
>=20
>=20
>=20
>=20
>=20

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

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

Thanks Peter, I did it, the CPU usage varies between 0% and 4% so this is n=
ot the case here.

Re: PROBLEM: USB isochronous urb leak on EHCI driver

[Alan Stern]

On Mon, 15 Dec 2014, 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.

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

Above you said the sound started to degrade when the second codec was 
connected; here you say there is no problem when using 3 of them.  
Which is it?  Do you mean that the high-speed hub works better than the 
full-speed hub?

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

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.

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

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)?

> 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

"upgrade to an earlier kernel driver" is a contradiction in terms.  
Moving to an earlier driver would be a _downgrade_.

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

Your first step should be to use an up-to-date kernel, as recommended 
by other people.

Alan Stern

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

>
> On Mon, 15 Dec 2014, Michael Tessier wrote:
>
> > Hi,
> >=20
> > I am dealing with a USB EHCI driver bug. Here is the info:
> >=20
> > My configuration:
> > -----------------
> >=20
> > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller)=20
> > 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 chang=
es 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)
> >=20
> > Note: each codec is being used in R/W access, so with 4 codecs, I have
> > 4 playback and 4 capture streams.
> >=20
> > My problem:
> > -----------
> >=20
> > I have usb urb leaks when connecting more than 1 codec to the USB 1.1=20
> > Hub.
>
> What do you mean by "urb leak"?  Normally, people use the word "leak" =20
> to refer to memory that is dynamically allocated and never deallocated, b=
ut 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 result is that some of the audio data is not transferred, part of=
=20
> > the sound is simply missing) No problem when using only 1 of the 4=20
> > codecs connected to the hub; When I connect a second codec, the sound=20
> > quality starts to degrade. With 3 codecs, we just cannot recognize a=20
> > speach.
> >=20
> > Tests and observations:
> > -----------------------
> >=20
> > 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=20
> > three ports.
> >=20
> > I bought a consumer USB 2.0 Hub: no problem when using 3 codecs=20
> > connected to that Hub, however, the audio will completly stop on all=20
> > channels when connecting the 4th codec.
>
> Above you said the sound started to degrade when the second codec was con=
nected; here you say there is no problem when using 3 of them. =20
> Which is it?  Do you mean that the high-speed hub works better than the f=
ull-speed hub?
>
Yes, that's it. Using the high-speed hub will allow for more data throughpu=
t
before starting to "miss" some usb packets (and result in a choppy sound).

> > I checked the communication between the Hub (USB 1.1) and the Host=20
> > controller (USB 2.0) with a scope and concluded that the communication=
=20
> > speed is 1.5 MBytes/s has expected (so the communication is downgraded=
=20
> > to USB 1.1, since codecs and hub are USB
> > 1.1 devices).
> >=20
> > Also, I know that there is physically enough bandwidth to transfer the=
=20
> > data for two reasons:
> > 1) I have an older CPU with a USB 1.1 host controller (using the OHCI=20
> > driver), using the same hub and the same codecs: works like a champ,=20
> > using less than 50% of the available bandwidth (observed with a
> > scope)
> > 2) 1 audio stream is 32khz-mono, 16 bits =3D 64 kB/s,
> > 4 codecs =3D 8 streams(R/W) x 64 kB/s =3D 512 kB/s (out of 1.5MB/s)
>
> The amount of bandwidth available is usually not as much of an issue as t=
he ability of the scheduling alogorithm to divide the bandwidth among the s=
treams.  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...

> > 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=20
> > 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=20
> > read and write streams: no problem. With that configuration, the scope=
=20
> > shows about 30% of total bandwidth usage (300us used out of 1ms=20
> > periods). Then, I added a second codec (48khz-stereo-16bits): very=20
> > strange, now the total bandwidth usage felt down to about 200us, which=
=20
> > seems to keep the same, whatever the number of codec I add (I also=20
> > tried 3 and 4...). So it looks like the scheduler is not able to=20
> > properly allocate Isochronous time slots when more than one device is=20
> > connected to the hub. However, without the hub, it works perfectly.
>
> 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=20
> companion USB-1.1 controller (older motherboards from Intel and other com=
panys have used this approach)?  Does the EHCI controller have a built-in T=
ransaction=20
> 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?

> > Another interresting fact is that at application level, the Read and=20
> > Write operations are returning the good amount of bytes read/written.
> > This is not the case at kernel level: I noticed that function=20
> > "usb_submit_urb" (from /drivers/usb/core/urb.c) will only tranfer part=
=20
> > of the "urbs" when the sound is degraded. I tried to figure out where=20
> > the leak comes from without success. Also, there are no error messages=
=20
> > from kernel so everything appears to work well, excepted that part of=20
> > the sound is missing!
> >=20
> > I can't change my hardware (this is in the hand of customers), so the=20
> > only possible solution for me is to correct the software.
> >=20
> > I tried to change my ehci driver with the one from kernel 2.6.39.4 but=
=20
> > did not work, same problem.
> >=20
> > Question:
> > ---------
> >=20
> > Before attempting to upgrade to an earlier kernel driver (this is
>
> "upgrade to an earlier kernel driver" is a contradiction in terms. =20
> 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=20
> > problem would still be in the 3.x kernels. Has anyone seen that issue=20
> > 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 repor=
ted a bug=20
> (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...

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. Thi=
s
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 newe=
r
kernel as a quite big amount of work...

> > I am pretty new to USB driver debugging, so any ideas of where/how to=20
> > find solutions will be appreciated. Thank you very much in advance for=
=20
> > the support. Also don't hesitate to redirect me if I'm not at the=20
> > right place to ask these questions. I can also provide some code if=20
> > someone need it to help.
>
> Your first step should be to use an up-to-date kernel, as recommended by =
other people.
>
> Alan Stern

Thank you for your prompt response.

Michael Tessier

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Alan Stern]

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

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

> > > > Hi,
> > > >=20
> > > > I am dealing with a USB EHCI driver bug. Here is the info:
> > > >=20
> > > > My configuration:
> > > > -----------------
> > > >=20
> > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host=20
> > > > controller) Linux kernel: 2.6.31, using EHCI USB driver
> > >
> > > As mentioned by other people, the age of that kernel makes any bug re=
port completely irrelevant.  It's hard to count the number of non-trivial c=
hanges 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)
> > > >=20
> > > > Note: each codec is being used in R/W access, so with 4 codecs, I=20
> > > > have
> > > > 4 playback and 4 capture streams.
> > > >=20
> > > > My problem:
> > > > -----------
> > > >=20
> > > > I have usb urb leaks when connecting more than 1 codec to the USB=20
> > > > 1.1 Hub.
> > >
> > > What do you mean by "urb leak"?  Normally, people use the word "leak"=
 =20
> > > to refer to memory that is dynamically allocated and never deallocate=
d, but you seem to mean something else.
> >=20
> > You are right. What I mean by leak is the following: At application=20
> > level, all my calls to "Read" or "Write" operation to the codec driver=
=20
> > will return with the correct amount of bytes read/written, with a=20
> > "choppy" sound. Then when looking at lower levels:
> >=20
> > 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
> >=20
> > The "FAIL" here indicates that the total amount of bytes transferred=20
> > does not correspond to what was expected. And indeed the sound is=20
> > "choppy" when using more than a certain amount of bandwidth. However=20
> > this amount of bandwidth is higher when connecting only 1 codec with=20
> > different settings (48khz-stereo 16-bits instead of 32 khz-mono=20
> > 16-bits).So at some point it looks like the bug is in the scheduler, on=
ly with several isochronous links.
>=20
> Agreed.
>=20
> > > The amount of bandwidth available is usually not as much of an issue=
=20
> > > as the ability of the scheduling alogorithm to divide the bandwidth a=
mong the streams.  The algorithm is not very smart and it often runs into a=
 wall even when lots of physical bandwidth is still available.
> >=20
> > That is interresting, however, I have an older kernel running an OHCI=20
> > driver which is able to handle 4 codecs. Same usb hardware (codecs and=
=20
> > hub), but older kernel on a different CPU, with much less power. This=20
> > makes me believe that there's a solution to make it work...
>=20
> Of course there is: Install an OHCI host controller and use it to drive y=
our codecs.  It should work fine.
>=20
> The periodic scheduling algorithm for OHCI is very different from the alg=
orithm 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 drive=
r
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 configurato=
r
(I am using "ltib"), but the configurator does not allow selecting the
OHCI driver; I tried manually but it turned into compiler errors...

>=20
> > > How does your hardware connect the host controller to a full-speed=20
> > > device?  Is there an internal hub (Intel motherboards have used this=
=20
> > > approach)?  Is there a companion USB-1.1 controller (older motherboar=
ds from Intel and other companys have used this approach)?  Does the EHCI c=
ontroller have a built-in Transaction Translator (some SOC systems use this=
 approach)?
> >=20
> > The CPU is a Freescale i.MX512, with 3 USB 2.0 Host controllers. My=20
> > hub is connected to the main CPU board with a standard USB cable, so=20
> > it's easy to swap my 4-port hub from a USB 1.1 to a USB 2.0. My codecs=
=20
> > are always the same: USB 1.1 Texas Instruments PN# pcm2901. I don't=20
> > believe there's a built-in Transaction Translator. How can I check that=
?
>=20
> You can tell by seeing what shows up in the "lsusb -t" output when you pl=
ug in the USB-1.1 hub.  If the hub's parent is the EHCI controller then the=
re must be a built-in TT.
>=20
> Also, if you enable CONFIG_USB_DEBUG in your kernel then the dmesg log fo=
r boot-up should say whether or not the controller has a built-in TT.
>=20
> > > > Question:
> > > > ---------
> > > >=20
> > > > Before attempting to upgrade to an earlier kernel driver (this is
> > >
> > > "upgrade to an earlier kernel driver" is a contradiction in terms. =20
> > > Moving to an earlier driver would be a _downgrade_.
> >=20
> > Sorry, I meant to say "newer"...
> >=20
> > > > a fairly big amount of work), I would really like to know if this=20
> > > > problem would still be in the 3.x kernels. Has anyone seen that=20
> > > > issue in 3.x kernels?
> > >
> > > It depends a lot on the system hardware.  Many people are using USB=20
> > > 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 patc=
h to fix it has not yet been merged.
> >=20
> > I understand. However, if one could test the following with a 3.x kerne=
l:
> > - 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)
> >=20
> > Then try to stream audio on each of the 4 codecs at the same time=20
> > (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...
>=20
> The result is likely to depend on what other USB hardware is attached.
>=20
> > If sound is ok when using only 1 codec and becomes choppy when adding=20
> > a second codec, then it means that this issue is still in the 3.x=20
> > kernel. This answer will tell me if it is worth working on using a newe=
r kernel or not.
> > I have to say that I'm not a linux expert, so I see the migration to a=
=20
> > newer kernel as a quite big amount of work...
>=20
> Why don't you try this yourself?  It's easy to do; borrow a regular PC wi=
th a USB-2 host controller, boot it from a Live-CD version of Linux, plug i=
n 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

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Alan Stern]

On Tue, 6 Jan 2015, Michael Tessier wrote:

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

I don't understand the question.

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

The OHCI driver works with OHCI hardware and the EHCI driver works with 
EHCI hardware.  OHCI is USB-1.1 and EHCI is USB-2.  They are not 
interchangeable.

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

It looks like the configurator is smart; it won't let you select the 
wrong driver for your hardware.

Alan Stern

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

> > > > That is interresting, however, I have an older kernel running an=20
> > > > OHCI driver which is able to handle 4 codecs. Same usb hardware=20
> > > > (codecs and hub), but older kernel on a different CPU, with much=20
> > > > less power. This makes me believe that there's a solution to make i=
t work...
> > >=20
> > > Of course there is: Install an OHCI host controller and use it to dri=
ve your codecs.  It should work fine.

What do you mean by that? The host controller is embedded in the i.MX CPU..=
.
Changing the CPU is not really an option to me. Unless I am missing
something?

> > >=20
> > > The periodic scheduling algorithm for OHCI is very different from the=
 algorithm for EHCI.
> >=20
> > According to your knowledge, how much time would you think it takes to=
=20
> > change the EHCI driver with an OHCI one?
>
> I don't understand the question.
>
> >  And can you tell if the OHCI driver
> > will work on my hardware given that the Host controller of the i.MX512=
=20
> > is a USB2.0 host controller? (OHCI was implemented for USB 1.x from=20
> > what I
> > understand)
>
> The OHCI driver works with OHCI hardware and the EHCI driver works with E=
HCI hardware.  OHCI is USB-1.1 and EHCI is USB-2.  They are not interchange=
able.

That was what I thought first...

>
> > I tried to do so several days ago with the built-in configurator (I am=
=20
> > using "ltib"), but the configurator does not allow selecting the OHCI=20
> > driver; I tried manually but it turned into compiler errors...
>
> It looks like the configurator is smart; it won't let you select the wron=
g driver for your hardware.
>
> Alan Stern

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Alan Stern]

On Tue, 6 Jan 2015, Michael Tessier wrote:

> > > > > 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.
> 
> What do you mean by that? The host controller is embedded in the i.MX CPU...
> Changing the CPU is not really an option to me. Unless I am missing
> something?

I didn't realize you were talking about an i.MX-based system.  On a
computer with a free PCI slot, it's easy to add an OHCI controller.  
iMX isn't as accomodating.

If there's no way to add an extra USB controller to your system then 
the only choice is to upgrade the driver software.

Alan Stern

Re: PROBLEM: USB isochronous urb leak on EHCI driver

[Peter Chen]

On Wed, Jan 7, 2015 at 2:22 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 6 Jan 2015, Michael Tessier wrote:
>
>> > > > > 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.
>>
>> What do you mean by that? The host controller is embedded in the i.MX CPU...
>> Changing the CPU is not really an option to me. Unless I am missing
>> something?
>
> I didn't realize you were talking about an i.MX-based system.  On a
> computer with a free PCI slot, it's easy to add an OHCI controller.
> iMX isn't as accomodating.
>

iMX uses chipidea controller which TT is build-in, and it does NOT support
OHCI controller.

> If there's no way to add an extra USB controller to your system then
> the only choice is to upgrade the driver software.
>
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
BR,
Peter Chen

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

> > > > > > That is interresting, however, I have an older kernel running=20
> > > > > > an OHCI driver which is able to handle 4 codecs. Same usb=20
> > > > > > hardware (codecs and hub), but older kernel on a different=20
> > > > > > CPU, with much less power. This makes me believe that there's a=
 solution to make it work...
> > > > >=20
> > > > > Of course there is: Install an OHCI host controller and use it to=
 drive your codecs.  It should work fine.
> >=20
> > What do you mean by that? The host controller is embedded in the i.MX C=
PU...
> > Changing the CPU is not really an option to me. Unless I am missing=20
> > something?
>
> I didn't realize you were talking about an i.MX-based system.  On a compu=
ter with a free PCI slot, it's easy to add an OHCI controller. =20
> iMX isn't as accomodating.
>
> If there's no way to add an extra USB controller to your system then the =
only choice is to upgrade the driver software.
>
> Alan Stern

Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015) on an =
i.MX51 plattform and the problem is still there. Unless an important change=
 occured in V3.19, it appears that the latest kernel is not the solution fo=
r us. So we're still not able to use 4 codecs on our i.MX plattform.

So just to make things clearer:
- We have customers waiting for a solution with that hardware (this hardwar=
e is already delivred AND used);
- We have important comittments and severe penalties ($$$) if we're not abl=
e to deliver on time (due for March 15th);
- We've already looked at a hardware solution, which corresponds to replace=
 current units ($$$$$), so that is not really an option for us;

So as a last resort, I'm wondering, where is the USB expert who could help =
us solving our problem? Any suggestions?

If we are to get into debugging the USB driver, we would do it with the cur=
rent kernel used (V2.6.31). What are the better tools to get into that? I g=
uess a USB analyzer (hardware) would be the smart thing? Any brand name to =
suggest?

Any other ideas for a solution will be really appreciated.

Regards,
Michael Tessier.

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Alan Stern]

On Mon, 9 Feb 2015, Michael Tessier wrote:

> Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015)
> on an i.MX51 plattform and the problem is still there. Unless an
> important change occured in V3.19, it appears that the latest kernel
> is not the solution for us. So we're still not able to use 4 codecs
> on our i.MX plattform.
> 
> So just to make things clearer:
> - We have customers waiting for a solution with that hardware (this
> hardware is already delivred AND used);
> - We have important comittments and severe penalties ($$$) if we're
> not able to deliver on time (due for March 15th);
> - We've already looked at a hardware solution, which corresponds to
> replace current units ($$$$$), so that is not really an option for
> us;
> 
> So as a last resort, I'm wondering, where is the USB expert who could
> help us solving our problem? Any suggestions?

That would be me.

> If we are to get into debugging the USB driver, we would do it with
> the current kernel used (V2.6.31). What are the better tools to get
> into that? I guess a USB analyzer (hardware) would be the smart
> thing? Any brand name to suggest?

It really would be better to start by debugging the most recent kernel
possible.  Once the problem has been solved there, it should be fairly
straightforward to port it back.

> Any other ideas for a solution will be really appreciated.

You should begin by using usbmon during a short test (one or two 
seconds ought to be enough).  See the instructions in the kernel source 
file Documentation/usb/usbmon.txt.

Alan Stern

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

> > Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015)=20
> > on an i.MX51 plattform and the problem is still there. Unless an=20
> > important change occured in V3.19, it appears that the latest kernel=20
> > is not the solution for us. So we're still not able to use 4 codecs on=
=20
> > our i.MX plattform.
> >=20
> > So just to make things clearer:
> > - We have customers waiting for a solution with that hardware (this=20
> > hardware is already delivred AND used);
> > - We have important comittments and severe penalties ($$$) if we're=20
> > not able to deliver on time (due for March 15th);
> > - We've already looked at a hardware solution, which corresponds to=20
> > replace current units ($$$$$), so that is not really an option for us;
> >=20
> > So as a last resort, I'm wondering, where is the USB expert who could=20
> > help us solving our problem? Any suggestions?
>
> That would be me.

Great. What do you need to make it a priority?

>
> > If we are to get into debugging the USB driver, we would do it with=20
> > the current kernel used (V2.6.31). What are the better tools to get=20
> > into that? I guess a USB analyzer (hardware) would be the smart thing?=
=20
> > Any brand name to suggest?
>
> It really would be better to start by debugging the most recent kernel po=
ssible.  Once the problem has been solved there, it should be fairly straig=
htforward to port it back.

How much time do you think you'd spend solving that kind of issue? Few days=
? Few weeks, or few months? Could you commit on a certain number of hours? =
(We are trying to evaluate a possible date where we could start delivering =
products)

When you say "straightforward", again do you have an idea of the amount of =
time to do such work?

> > Any other ideas for a solution will be really appreciated.
>
> You should begin by using usbmon during a short test (one or two seconds =
ought to be enough).  See the instructions in the kernel source file Docume=
ntation/usb/usbmon.txt.
>

Thanks for your support,
Michael Tessier

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Alan Stern]

On Tue, 10 Feb 2015, Michael Tessier wrote:

> > > Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015) 
> > > on an i.MX51 plattform and the problem is still there. Unless an 
> > > important change occured in V3.19, it appears that the latest kernel 
> > > is not the solution for us. So we're still not able to use 4 codecs on 
> > > our i.MX plattform.
> > > 
> > > So just to make things clearer:
> > > - We have customers waiting for a solution with that hardware (this 
> > > hardware is already delivred AND used);
> > > - We have important comittments and severe penalties ($$$) if we're 
> > > not able to deliver on time (due for March 15th);
> > > - We've already looked at a hardware solution, which corresponds to 
> > > replace current units ($$$$$), so that is not really an option for us;
> > > 
> > > So as a last resort, I'm wondering, where is the USB expert who could 
> > > help us solving our problem? Any suggestions?
> >
> > That would be me.
> 
> Great. What do you need to make it a priority?

Let's put it this way: Fixing bugs in the ehci-hcd driver already is a
priority for me.  But it takes second place to other priorities, such
as my day job.

(And incidentally, finding and fixing bugs in kernels as old as 2.6.31
is _not_ a priority, since so many have already been found and fixed.  
That is one important reason for my suggestion that you do the
debugging with the most recent kernel version you can.)

> > > If we are to get into debugging the USB driver, we would do it with 
> > > the current kernel used (V2.6.31). What are the better tools to get 
> > > into that? I guess a USB analyzer (hardware) would be the smart thing? 
> > > Any brand name to suggest?
> >
> > It really would be better to start by debugging the most recent kernel possible.  Once the problem has been solved there, it should be fairly straightforward to port it back.
> 
> How much time do you think you'd spend solving that kind of issue?
> Few days? Few weeks, or few months?

No idea.  In the past, such things have taken a few days to a few 
weeks, depending on lots of factors -- when they are solvable at all.

>  Could you commit on a certain
> number of hours? (We are trying to evaluate a possible date where we
> could start delivering products)

No, I can't commit to anything specific.

> When you say "straightforward", again do you have an idea of the
> amount of time to do such work?

Again, it all depends.  For example, it might turn out that the 
hardware you are using contains a bug of a sort I have seen in the 
past.  In that case, programming a workaround wouldn't take more than a 
few hours, once I knew what was going on.

Alan Stern

Re: PROBLEM: USB isochronous urb leak on EHCI driver

[Fabio Estevam]

On Mon, Jan 5, 2015 at 1:12 PM, Michael Tessier
<michael.tessier@axiontech.ca> wrote:

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

We have support for mx51 on the latest kernel. All you need to do is
to describe your hardware on a device tree file. You can refer to
arch/arm/boot/dts/imx51-babbage.dts as an example.

Should be simple for you to make such test with the latest kernel.

RE: PROBLEM: USB isochronous urb leak on EHCI driver

[Michael Tessier]

DQo+ID4gSWYgc291bmQgaXMgb2sgd2hlbiB1c2luZyBvbmx5IDEgY29kZWMgYW5kIGJlY29tZXMg
Y2hvcHB5IHdoZW4gYWRkaW5nIA0KPiA+IGEgc2Vjb25kIGNvZGVjLCB0aGVuIGl0IG1lYW5zIHRo
YXQgdGhpcyBpc3N1ZSBpcyBzdGlsbCBpbiB0aGUgMy54IA0KPiA+IGtlcm5lbC4gVGhpcyBhbnN3
ZXIgd2lsbCB0ZWxsIG1lIGlmIGl0IGlzIHdvcnRoIHdvcmtpbmcgb24gdXNpbmcgYSBuZXdlciBr
ZXJuZWwgb3Igbm90Lg0KPiA+IEkgaGF2ZSB0byBzYXkgdGhhdCBJJ20gbm90IGEgbGludXggZXhw
ZXJ0LCBzbyBJIHNlZSB0aGUgbWlncmF0aW9uIHRvIGEgDQo+ID4gbmV3ZXIga2VybmVsIGFzIGEg
cXVpdGUgYmlnIGFtb3VudCBvZiB3b3JrLi4uDQo+DQo+IFdlIGhhdmUgc3VwcG9ydCBmb3IgbXg1
MSBvbiB0aGUgbGF0ZXN0IGtlcm5lbC4gQWxsIHlvdSBuZWVkIHRvIGRvIGlzIHRvIGRlc2NyaWJl
IHlvdXIgaGFyZHdhcmUgb24gYSBkZXZpY2UgdHJlZSBmaWxlLiBZb3UgY2FuIHJlZmVyIHRvIGFy
Y2gvYXJtL2Jvb3QvZHRzL2lteDUxLWJhYmJhZ2UuZHRzIGFzIGFuIGV4YW1wbGUuDQo+DQo+IFNo
b3VsZCBiZSBzaW1wbGUgZm9yIHlvdSB0byBtYWtlIHN1Y2ggdGVzdCB3aXRoIHRoZSBsYXRlc3Qg
a2VybmVsLg0KDQpJJ2xsIHRyeSB0byBkbyBzby4gTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgZXZl
biBpZiBpdCBoYXMgYmVlbiBjb3JyZWN0ZWQNCmluIHRoZSBsYXN0IGtlcm5lbCwgSSdtIG5vdCBm
cmVlIHRvIGp1c3QgdXNlIHRoZSBsYXN0IGtlcm5lbDsgb3VyIGN1c3RvbWVycw0KYWxyZWFkeSBo
YXZlIHVuaXRzIGluIHRoZWlyIGhhbmRzLCBhbmQgdGhleSBib3VnaHQgdXMgYSAiRm9ybSBGaXQg
JiBGdW5jdGlvbiINCnBsYXR0Zm9ybS4gV2UgaGF2ZSBhIGh1Z2UgYnVuY2ggb2YgZG9jdW1lbnRh
dGlvbiBjb21pbmcgd2l0aCBlYWNoIGRlbGl2ZXJhYmxlDQoocGFydCBvZiBhbiBJU08gcHJvY2Vz
cywgZm9sbG93aW5nIElFRUUgc29mdHdhcmUgc3RhbmRhcmRzKS4gU28gZm9yIHRoZQ0KY29tcGFu
eSwgbWlncmF0aW5nIHRvIHRoZSBsYXRlc3Qga2VybmVsIGlzIHRoZSBsYXN0IHJlc29ydCBiZWNh
dXNlIG9mIHRoZQ0KYW1vdW50IG9mIHdvcmsgaXQgd291bGQgcmVxdWlyZS4gVGhhbmtzIGZvciB0
aGUgaWRlYSwgSSdsbCBsZXQgeW91IGtub3cuDQoNCk1pY2hhZWwgVGVzc2llcg0K