This e-mail is a follow-up as requested in this bug[1]. I will repost
everything so far in this e-mail. Please CC me as I'm not subscribed
to your list.
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 <st...@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 <st...@rowland.harvard.edu>
Tested-by: Piergiorgio Sartor <piergiorgio.sar...@nexgo.de>
CC: <sta...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@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. What I forgot to mention in the bug was the chipset:
00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82)
(prog-if 20 [EHCI])
Subsystem: Micro-Star International Co., Ltd. KT4AV motherboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 32 bytes
Interrupt: pin D routed to IRQ 21
Region 0: Memory at dffeff00 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci-pci
Yes, it's 10 years old, and no I'm not scrooge. We are waiting a while
for computer prices to plummet mkay?
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=54031
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
