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): kernel-2.6.9-89.0.20.EL How reproducible: 100% Steps to Reproduce: 1. connect USB headset 2. `cat /dev/dsp` 3. 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: http://www.cmedia.com.tw/ProductsDetail.aspx?page=p&C1Serno=25&C2Serno=26&PSerno=7 http://www.qsl.net/om3cph/sb/CM108_DataSheet_v1.6.pdf
Created attachment 438732 [details] sysreport for system which does not reproduce problem
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
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
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).
Created attachment 447310 [details] dmesg (2.6.9-89.0.29.ELsmp + CONFIG_USB_DEBUG enabled)
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 drivers/usb/host/ehci-mem.c::ehci_qtd_alloc() 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. Cheers, Don
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. Cheers! ~Dave
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
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. Cheers, Don
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 release.
Dave, Ping? Cheers, Don
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. Cheers! ~Dave
Committed in 89.42.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Through code review, confirmed the patch included into kernel-2.6.9-97.EL, marked SanityOnly.
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. http://rhn.redhat.com/errata/RHSA-2011-0263.html