On Mon, Jul 9, 2012 at 10:47 AM, Greg KH <[email protected]> wrote:
> 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 <[email protected]>
>> > Tested-by: Dâniel Fraga <[email protected]>
>> > Tested-by: Javier Marcet <[email protected]>
>> > Tested-by: Andrey Rahmatullin <[email protected]>
>> > Tested-by: Oleksij Rempel <[email protected]>
>> > Tested-by: Pavel Pisa <[email protected]>
>> > CC: <[email protected]>
>>
>> Acked-by: Rafael J. Wysocki <[email protected]>
>
> Acked-by: Greg Kroah-Hartman <[email protected]>
I'm fine with this patch. I was going to add these:
Based-on-patch-by: AceLan Kao <[email protected]>
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
I don't have the previous iteration (c2fb8a3fa25513d) in my "next"
branch. I think it went through you, Greg. Do you want to handle
this one as well?
I *could* do it, but it looks like a messy merge -- I think I'd have
to rebase almost everything in my "next" branch -- so I'd rather not.
Of course, I do have some D3-related updates in pci_prepare_to_sleep()
which will conflict with this, too, so I guess it will be a bit of
work for somebody either way.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
