Re: [regression][v3.8rc5->v3.8rc6] ehci-pci fails with error -110 on read/[64,all]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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 <stern@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx>
>     Tested-by: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
>     CC: <stable@xxxxxxxxxxxxxxx>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>
> 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

Would like to add that while searching the mailing lists I stumbled on this:

http://marc.info/?l=linux-usb&m=136045531311402&w=4

It's an entirely seperate USB issue in this cycle. The person is doing
git bisect to find the regression. I did another approach as
recompiling the full kernel on a 1,25GHz isn't even remotely funny
anymore.

On top of HEAD I started reverting groups of USB EHCI patches one by
one. I'm just mentioning it since I'm not sure if this procedure is
accepted here.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux