Re: [PATCH] PCI: EHCI: fix crash during suspend on ASUS computers

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

 



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 <stern@xxxxxxxxxxxxxxxxxxx>
> > Tested-by: Dâniel Fraga <fragabr@xxxxxxxxx>
> > Tested-by: Javier Marcet <jmarcet@xxxxxxxxx>
> > Tested-by: Andrey Rahmatullin <wrar@xxxxxxxxx>
> > Tested-by: Oleksij Rempel <bug-track@xxxxxxxxxxxxxxxxx>
> > Tested-by: Pavel Pisa <pisa@xxxxxxxxxxxxxxxx>
> > CC: <stable@xxxxxxxxxxxxxxx>
> 
> Acked-by: Rafael J. Wysocki <rjw@xxxxxxx>


Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

--
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