Bug 624117 - recording fails when usb audio device is connected to EHCI controller (ehci_hcd)
recording fails when usb audio device is connected to EHCI controller (ehci_hcd)
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Don Zickus
Depends On:
  Show dependency treegraph
Reported: 2010-08-13 13:54 EDT by Dave Maley
Modified: 2011-02-16 10:28 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-16 10:28:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sysreport for system which reproduces problem (x3250 M3) (2.09 MB, application/x-bzip)
2010-08-13 13:54 EDT, Dave Maley
no flags Details
sysreport for system which does not reproduce problem (420.52 KB, application/x-bzip)
2010-08-13 13:56 EDT, Dave Maley
no flags Details
split transaction cleanups (4.68 KB, patch)
2010-09-20 15:32 EDT, Don Zickus
no flags Details | Diff

  None (edit)
Description Dave Maley 2010-08-13 13:54:57 EDT
Created attachment 438731 [details]
sysreport for system which reproduces problem (x3250 M3)

Description of problem:
Customer has C-Media CM108 USB headsets connected to a system w/ only EHCI controllers (IBM x3250 M3).  When attempting to access the headset the following error is flooding syslog:

  cannot submit datapipe for urb 0, err = -12

This problem does not occur when the headset is connected to their other platforms which have UHCI companion controllers.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. connect USB headset
2. `cat /dev/dsp`

Actual results:
no sound and syslog gets flooded w/ "cannot submit datapipe for urb 0, err = -12" error

Expected results:
sound played/heard

Additional info:
* details for the CM108 chip:
Comment 1 Dave Maley 2010-08-13 13:56:12 EDT
Created attachment 438732 [details]
sysreport for system which does not reproduce problem
Comment 2 Dave Maley 2010-08-13 14:28:47 EDT
The problem appears to stem from the lack of UHCI companion controllers in these x3250m3's, and it's not clear whether "full speed" USB 2.0 audio devices are expected to work w/ ehci_hcd. The Cmedia CM108 specs state it's a full speed USB device, and that's it's USB 2.0 compliant.

I've found mention in the ehci_hcd kernel docs indicating that it's not expected to work (http://www.mjmwired.net/kernel/Documentation/usb/ehci.txt).

From the 1st sentence of the doc it's clear that ehci_hcd is used to talk to "high speed" USB 2.0 devices. However it's not clear whether uhci_hcd (or ohci_hcd) is needed for "full speed" USB 2.0 devices or whether they're only needed for USB 1.1 devices.

But the thing that stood out in this doc is this statement:

"Full Speed Isochronous transfer support, through transaction translators, is not yet available.  Note that split transaction support for ISO transfers can't share much code with the code for high speed ISO transfers, since EHCI represents these with a different data structure.  So for now, most USB audio and video devices can't be connected to high speed buses."

..specifically that last sentence.  Note: the doc is dated 2002 so it may be horribly outdated.

some additional details/notes from the I-T:
- loading uhci_hcd does not help
- after removing ehci_hcd and loading uhci_hcd /dev/dsp does not exist
- response from eng-ops --> no x3250m3's available for general use
- customer is looking into testing rhel5 (or later) on the x3250m3
Comment 3 Dave Maley 2010-09-02 14:09:34 EDT
got access to a test setup:

- basic playback (via aplay) works under 4.8
- the error's only seen when reading from the device (cat /dev/dsp)
- errors flood console and syslog and render system usless, have to disconnect audio device to regain responsiveness
- rhel5 does not produce error
Comment 5 Dave Maley 2010-09-14 15:27:22 EDT
I rebuilt 2.6.9-89.0.29.ELsmp w/ CONFIG_USB_DEBUG enabled.  Nothing extra gets logged at the time of the errors.  There are some additional details in dmesg wrt the ehci controllers however nothing stands out to me (I'll attach the complete dmesg).
Comment 6 Dave Maley 2010-09-14 15:30:25 EDT
Created attachment 447310 [details]
dmesg (2.6.9-89.0.29.ELsmp + CONFIG_USB_DEBUG enabled)
Comment 7 Don Zickus 2010-09-14 18:01:35 EDT
Hi Dave,

I was poking around and noticed that 'err = -12' means -ENOMEM.  Looking at the error message displayed and places in the code that could print that out and have an error value of -ENOMEM, I came up with


Unfortunately, I will not be around the next couple of days, but just to see if I was on the right track you might be able to add code to the above function like so:

if (!qtd)
    printk("ehci_qtd_alloc: no memory!\n")

then we can try and take it from there.  Though I really don't have any clue why there would be no memory from the dma pool available.

Comment 8 Dave Maley 2010-09-15 12:41:59 EDT
Thanks Don for taking a look and the pointer.

Unfortunately the suggested printk didn't uncover anything.  I'm going to continue poking around the ehci code however if you have any further suggestions I'm happy to give them a spin.

Comment 9 Dave Maley 2010-09-15 12:48:58 EDT
I should also note (from comment 3):

> - errors flood console and syslog and render system usless, have to disconnect
> audio device to regain responsiveness

The error reproduces via arecord but doesn't flood the console/logs.  Instead it's recorded once to syslog and arecord throws the below error and exits:

ALSA lib pcm_hw.c:549:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe
arecord: xrun:1033: read/write error, state = PREPARED
Comment 10 Don Zickus 2010-09-20 15:32:20 EDT
Created attachment 448534 [details]
split transaction cleanups

I dug up a patch that went into 2.6.11 that specifically cleaned up and removed the code that was reporting the -ENOMEM in the kernel log.  I guess the original code was nervous about doing split transactions of input data and put a giant -ENOMEM if it detected it (just like in this case).

Using the arecord reproducer, the problem doesn't exist any more.  This might need a little more testing to make sure it works properly with everything else.

Comment 14 RHEL Product and Program Management 2010-09-21 10:28:59 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 17 Don Zickus 2010-10-06 14:13:12 EDT


Comment 18 Dave Maley 2010-10-06 14:20:34 EDT
Don - Apologies for the delayed response here.  The customr has tested the patched module and validated that it resolves the problem in their environment/application.

Comment 21 Vivek Goyal 2010-10-13 12:14:26 EDT
Committed in 89.42.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 26 Brenda Tian 2011-01-26 03:10:33 EST
Through code review, confirmed the patch included into
 kernel-2.6.9-97.EL, marked SanityOnly.
Comment 27 errata-xmlrpc 2011-02-16 10:28:45 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.