Bug 624117 - recording fails when usb audio device is connected to EHCI controller (ehci_hcd)
Summary: recording fails when usb audio device is connected to EHCI controller (ehci_hcd)
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.8
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Don Zickus
QA Contact: desktop-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-13 17:54 UTC by Dave Maley
Modified: 2018-10-27 13:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-16 15:28:45 UTC
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 17:54 UTC, Dave Maley
no flags Details
sysreport for system which does not reproduce problem (420.52 KB, application/x-bzip)
2010-08-13 17:56 UTC, Dave Maley
no flags Details
split transaction cleanups (4.68 KB, patch)
2010-09-20 19:32 UTC, Don Zickus
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0263 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 4.9 kernel security and bug fix update 2011-02-16 15:14:55 UTC

Description Dave Maley 2010-08-13 17:54:57 UTC
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 17:56:12 UTC
Created attachment 438732 [details]
sysreport for system which does not reproduce problem

Comment 2 Dave Maley 2010-08-13 18:28:47 UTC
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 18:09:34 UTC
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 19:27:22 UTC
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 19:30:25 UTC
Created attachment 447310 [details]
dmesg (2.6.9-89.0.29.ELsmp + CONFIG_USB_DEBUG enabled)

Comment 7 Don Zickus 2010-09-14 22:01:35 UTC
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 16:41:59 UTC
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 16:48:58 UTC
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 19:32:20 UTC
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 14:28:59 UTC
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 18:13:12 UTC



Comment 18 Dave Maley 2010-10-06 18:20:34 UTC
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 16:14:26 UTC
Committed in 89.42.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/

Comment 26 Brenda Tian 2011-01-26 08:10:33 UTC
Through code review, confirmed the patch included into
 kernel-2.6.9-97.EL, marked SanityOnly.

Comment 27 errata-xmlrpc 2011-02-16 15:28:45 UTC
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.