Current head gives this when I plug a 'Mass Storage Device' into a 2.0 hub: [ 842.760400] hub 1-0:1.0: unable to enumerate USB device on port 3 [ 843.080058] usb 1-3: new high-speed USB device number 48 using ehci-pci [ 858.230072] usb 1-3: device descriptor read/64, error -110 [ 873.490070] usb 1-3: device descriptor read/64, error -110 Reverting the following commit makes it work again: commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 Author: Alan Stern <stern@rowland.harvard.edu> Date: Fri Jan 25 16:52:45 2013 -0500 USB: EHCI: remove ASS/PSS polling timeout This patch (as1647) attempts to work around a problem that seems to affect some nVidia EHCI controllers. They sometimes take a very long time to turn off their async or periodic schedules. I don't know if this is a result of other problems, but in any case it seems wise not to depend on schedule enables or disables taking effect in any specific length of time. The patch removes the existing 20-ms timeout for enabling and disabling the schedules. The driver will now continue to poll the schedule state at 1-ms intervals until the controller finally decides to obey the most recent command issued by the driver. Just in case this hides a problem, a debugging message will be logged if the controller takes longer than 20 polls. I don't know if this will actually fix anything, but it can't hurt. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c index 20dbdcb..f904071 100644 --- a/drivers/usb/host/ehci-timer.c +++ b/drivers/usb/host/ehci-timer.c @@ -113,14 +113,15 @@ static void ehci_poll_ASS(struct ehci_hcd *ehci) if (want != actual) { - /* Poll again later, but give up after about 20 ms */ - if (ehci->ASS_poll_count++ < 20) { - ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true); - return; - } - ehci_dbg(ehci, "Waited too long for the async schedule status (%x/%x), giving up\n", - want, actual); + /* Poll again later */ + ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true); + ++ehci->ASS_poll_count; + return; } + + if (ehci->PSS_poll_count > 20) + ehci_dbg(ehci, "PSS poll count reached %d\n", + ehci->PSS_poll_count); ehci->PSS_poll_count = 0; /* The status is up-to-date; restart or stop the schedule as needed */ Please note, that I'm using the 'irqpoll' cmdline to improve system stability.
On Sun, Feb 17, 2013 at 06:10:16PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > Summary: [regression][v3.8rc5->v3.8rc6] Ehci-pci fails with > error -110 on read/64 Please send this to linux-usb@vger.kernel.org
*** Bug 54011 has been marked as a duplicate of this bug. ***
I'm experiencing this bug also. kernel 3.7.9-201.fc18.i686 I got the problem on the motherboard USB. 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86) But not on a PCI card 00:0b.0 USB controller: NEC Corporation USB (rev 43) 00:0b.1 USB controller: NEC Corporation USB (rev 43) 00:0b.2 USB controller: NEC Corporation USB 2.0 (rev 04) bug present from 3.7.8
Just booted with 3.7.6-201.fc18.i686 USB is operating correctly
Hi there, If you have been bitten by this. This bug has already been solved to our knowledge. Patch will go mainline soon. My initial thread based on this bug: http://marc.info/?t=136112672200003&r=1&w=2 Authors (Alan Stern) response along with another victim (Paul Hartman): http://marc.info/?t=136130069700008&r=1&w=2 Conclusion it was VIA specific and will be fixed in v3.9-rc2: http://marc.info/?l=linux-usb&m=136154564922840&w=2 Suggest you try the patch here to confirm/fix: http://marc.info/?l=linux-usb&m=136147575231225&w=2