I have met a situation where USB was not working correctly on my system, and the fix was to build a kernel with CONFIG_USB_EHCI_TT_NEWSCHED enabled. So my hope is that you will: - either fix the default scheduler; - or make CONFIG_USB_EHCI_TT_NEWSCHED the default. ==================================================== Description of my problem with the default scheduler ==================================================== I have a USB mouse and a USB audio DAC. Both work fine separately on my system (linux 2.6.33, x86-64, distro: Arch Linux). The problem is when I try using both simultaneously. The first-plugged device will work fine, but not the second-plugged device. For example, if I plug the audio DAC first and the mouse second, then the audio DAC works and the mouse doesn't work. And conversely. If I then unplug the first-plugged device and plug the other one, then it works. No need to reboot. When I say that the second-plugged device doesn't work, here's what I mean: the USB device is detected by the system, but gets "reset" every 2 seconds and can't be actually used at all. Here are some log messages. lsusb output: $ lsusb | egrep -i mouse\|texas Bus 002 Device 009: ID 08bb:2704 Texas Instruments Japan Bus 002 Device 007: ID 046d:c526 Logitech, Inc. MX Revolution Cordless Mouse Here, "Texas Instruments Japan" is my audio DAC. So, at the level of lsusb, all is well. Now here's what dmesg says when I plug the second device: usb 2-1.1: reset full speed USB device using ehci_hcd and address 4 usb 2-1.1: reset full speed USB device using ehci_hcd and address 4 usb 2-1.1: reset full speed USB device using ehci_hcd and address 4 cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth cannot submit datapipe for urb 0, error -28: not enough bandwidth The second-plugged device then doesn't work at all. The problem only happens with this precise combination of USB devices (mouse and DAC). =========================== Description of the solution =========================== Compiled a vanilla kernel 2.6.33.1 with my current /proc/config.gz and only this option changed: CONFIG_USB_EHCI_TT_NEWSCHED set to Yes. This fixed the problem immediately. Note also that my distro, Arch linux, doesn't patch much (if at all) kernels. Thus it is very reasonable to assume that CONFIG_USB_EHCI_TT_NEWSCHED is what fixed this problem. ================= What I would like ================= I would like Linux's default USB scheduler to be clever enough that I don't have to compile custom kernels again in the future :) Thanks for listening.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 29 Mar 2010 13:48:38 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=15649 > > Summary: Default scheduler not working, make > CONFIG_USB_EHCI_TT_NEWSCHED the default? > Product: Drivers > Version: 2.5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: USB > AssignedTo: greg@kroah.com > ReportedBy: jacob.benoit.1@gmail.com > Regression: No > > > I have met a situation where USB was not working correctly on my system, and > the fix was to build a kernel with CONFIG_USB_EHCI_TT_NEWSCHED enabled. So my > hope is that you will: > - either fix the default scheduler; > - or make CONFIG_USB_EHCI_TT_NEWSCHED the default. > > ==================================================== > Description of my problem with the default scheduler > ==================================================== > > I have a USB mouse and a USB audio DAC. > > Both work fine separately on my system (linux 2.6.33, x86-64, distro: Arch > Linux). > > The problem is when I try using both simultaneously. The first-plugged device > will work fine, but not the second-plugged device. For example, if I plug the > audio DAC first and the mouse second, then the audio DAC works and the mouse > doesn't work. And conversely. > > If I then unplug the first-plugged device and plug the other one, then it > works. No need to reboot. > > When I say that the second-plugged device doesn't work, here's what I mean: > the > USB device is detected by the system, but gets "reset" every 2 seconds and > can't be actually used at all. > > Here are some log messages. > > lsusb output: > > $ lsusb | egrep -i mouse\|texas > Bus 002 Device 009: ID 08bb:2704 Texas Instruments Japan > Bus 002 Device 007: ID 046d:c526 Logitech, Inc. MX Revolution Cordless Mouse > > Here, "Texas Instruments Japan" is my audio DAC. So, at the level of lsusb, > all > is well. > > Now here's what dmesg says when I plug the second device: > > usb 2-1.1: reset full speed USB device using ehci_hcd and address 4 > usb 2-1.1: reset full speed USB device using ehci_hcd and address 4 > usb 2-1.1: reset full speed USB device using ehci_hcd and address 4 > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > cannot submit datapipe for urb 0, error -28: not enough bandwidth > > The second-plugged device then doesn't work at all. > > The problem only happens with this precise combination of USB devices (mouse > and DAC). > > =========================== > Description of the solution > =========================== > > Compiled a vanilla kernel 2.6.33.1 with my current /proc/config.gz and only > this option changed: CONFIG_USB_EHCI_TT_NEWSCHED set to Yes. > > This fixed the problem immediately. > > Note also that my distro, Arch linux, doesn't patch much (if at all) kernels. > Thus it is very reasonable to assume that CONFIG_USB_EHCI_TT_NEWSCHED is what > fixed this problem. > > ================= > What I would like > ================= > > I would like Linux's default USB scheduler to be clever enough that I don't > have to compile custom kernels again in the future :) > > Thanks for listening.
Greg, thanks to commit 37cd681c022a0a46ebcff025897a57457d3ca8cd (USB: EHCI: make CONFIG_USB_EHCI_TT_NEWSCHED default to Y), it looks like there's nothing more to be done with this bug report. It should be closed out.