Re: [ 51/68] PCI: EHCI: fix crash during suspend on ASUS computers
On Thu, Jul 12, 2012 at 04:02:25PM -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- Missing also the diff/"signoff area" on this one. > > From: Alan Stern > > commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream. > > 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. > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 51/68] PCI: EHCI: fix crash during suspend on ASUS computers
From: Greg KH 3.0-stable review patch. If anyone has any objections, please let me know. -- From: Alan Stern commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 51/68] PCI: EHCI: fix crash during suspend on ASUS computers
On Thu, Jul 12, 2012 at 04:02:25PM -0700, Greg Kroah-Hartman wrote: From: Greg KH gre...@linuxfoundation.org 3.0-stable review patch. If anyone has any objections, please let me know. -- Missing also the diff/signoff area on this one. From: Alan Stern st...@rowland.harvard.edu commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream. 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. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- []'s Herton -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 51/68] PCI: EHCI: fix crash during suspend on ASUS computers
From: Greg KH gre...@linuxfoundation.org 3.0-stable review patch. If anyone has any objections, please let me know. -- From: Alan Stern st...@rowland.harvard.edu commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream. 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
