On Mon, Jul 09, 2012 at 06:50:24PM +0200, Rafael J. Wysocki wrote: > On Monday, July 09, 2012, Alan Stern wrote: > > Quite a few ASUS computers experience a nasty problem, related to the > > EHCI controllers, when going into system suspend. It was observed > > that the problem didn't occur if the controllers were not put into the > > D3 power state before starting the suspend, and commit > > 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during > > suspend on ASUS computers) was created to do this. > > > > It turned out this approach messed up other computers that didn't have > > the problem -- it prevented USB wakeup from working. Consequently > > commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add > > NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it > > reverted the earlier commit and added a whitelist of known good board > > names. > > > > Now we know the actual cause of the problem. Thanks to AceLan Kao for > > tracking it down. > > > > According to him, an engineer at ASUS explained that some of their > > BIOSes contain a bug that was added in an attempt to work around a > > problem in early versions of Windows. When the computer goes into S3 > > suspend, the BIOS tries to verify that the EHCI controllers were first > > quiesced by the OS. Nothing's wrong with this, but the BIOS does it > > by checking that the PCI COMMAND registers contain 0 without checking > > the controllers' power state. If the register isn't 0, the BIOS > > assumes the controller needs to be quiesced and tries to do so. This > > involves making various MMIO accesses to the controller, which don't > > work very well if the controller is already in D3. The end result is > > a system hang or memory corruption. > > > > Since the value in the PCI COMMAND register doesn't matter once the > > controller has been suspended, and since the value will be restored > > anyway when the controller is resumed, we can work around the BIOS bug > > simply by setting the register to 0 during system suspend. This patch > > (as1590) does so and also reverts the second commit mentioned above, > > which is now unnecessary. > > > > In theory we could do this for every PCI device. However to avoid > > introducing new problems, the patch restricts itself to EHCI host > > controllers. > > > > Finally the affected systems can suspend with USB wakeup working > > properly. > > > > Signed-off-by: Alan Stern <st...@rowland.harvard.edu> > > Tested-by: Dâniel Fraga <frag...@gmail.com> > > Tested-by: Javier Marcet <jmar...@gmail.com> > > Tested-by: Andrey Rahmatullin <w...@wrar.name> > > Tested-by: Oleksij Rempel <bug-tr...@fisher-privat.net> > > Tested-by: Pavel Pisa <p...@cmp.felk.cvut.cz> > > CC: <sta...@vger.kernel.org> > > Acked-by: Rafael J. Wysocki <r...@sisk.pl>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> -- 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
