Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

From: Stephen Warren
Date: Tue Mar 19 2013 - 14:03:44 EST


On 03/18/2013 03:06 PM, Greg Kroah-Hartman wrote:
> 3.8-stable review patch. If anyone has any objections, please let me know.

This patch causes reboot/shutdown to fail on Tegra-based systems in 3.9-rc3.

I reported this at:

http://www.spinics.net/lists/linux-usb/msg82518.html

although there's been no discussion there yet, and I haven't had time to
investigate exactly what the problem is.

> ------------------
>
> From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
>
> commit 6402c796d3b4205d3d7296157956c5100a05d7d6 upstream.
>
> This patch (as1660) works around a hardware problem present in some
> (if not all) Intel EHCI controllers. After a QH has been unlinked
> from the async schedule and the corresponding IAA interrupt has
> occurred, the controller is not supposed access the QH and its qTDs.
> There certainly shouldn't be any more DMA writes to those structures.
> Nevertheless, Intel's controllers have been observed to perform a
> final writeback to the QH's overlay region and to the most recent qTD.
> For more information and a test program to determine whether this
> problem is present in a particular controller, see
>
> http://marc.info/?l=linux-usb&m=135492071812265&w=2
> http://marc.info/?l=linux-usb&m=136182570800963&w=2
>
> This patch works around the problem by always waiting for two IAA
> cycles when unlinking an async QH. The extra IAA delay gives the
> controller time to perform its final writeback.
>
> Surprisingly enough, the effects of this silicon bug have gone
> undetected until quite recently. More through luck than anything
> else, it hasn't caused any apparent problems. However, it does
> interact badly with the path that follows this one, so it needs to be
> addressed.
>
> This is the first part of a fix for the regression reported at:
>
> https://bugs.launchpad.net/bugs/1088733

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/