From: Greg KH <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"AceLan Kao" <acelan.kao@canonical.com>,
"Dâniel Fraga" <fragabr@gmail.com>,
"Javier Marcet" <jmarcet@gmail.com>,
"Andrey Rahmatullin" <wrar@wrar.name>,
"Oleksij Rempel" <bug-track@fisher-privat.net>,
"Pavel Pisa" <pisa@cmp.felk.cvut.cz>,
linux-pci@vger.kernel.org, "USB list" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] PCI: EHCI: fix crash during suspend on ASUS computers
Date: Mon, 9 Jul 2012 09:47:20 -0700 [thread overview]
Message-ID: <20120709164720.GA15994@kroah.com> (raw)
In-Reply-To: <201207091850.24550.rjw@sisk.pl>
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@rowland.harvard.edu>
> > Tested-by: Dâniel Fraga <fragabr@gmail.com>
> > Tested-by: Javier Marcet <jmarcet@gmail.com>
> > Tested-by: Andrey Rahmatullin <wrar@wrar.name>
> > Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
> > Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
> > CC: <stable@vger.kernel.org>
>
> Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
next prev parent reply other threads:[~2012-07-09 16:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 15:09 [PATCH] PCI: EHCI: fix crash during suspend on ASUS computers Alan Stern
2012-07-09 16:50 ` Rafael J. Wysocki
2012-07-09 16:47 ` Greg KH [this message]
2012-07-10 15:32 ` Bjorn Helgaas
2012-07-10 16:00 ` Greg KH
2012-07-10 16:11 ` Alan Stern
2012-07-10 16:17 ` Greg KH
2012-07-10 16:40 ` Bjorn Helgaas
2012-07-10 16:46 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120709164720.GA15994@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=acelan.kao@canonical.com \
--cc=bhelgaas@google.com \
--cc=bug-track@fisher-privat.net \
--cc=fragabr@gmail.com \
--cc=jmarcet@gmail.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pisa@cmp.felk.cvut.cz \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--cc=wrar@wrar.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox