Re: [RFT] PCI changes related to wakeup (was: Re: ehci_hcd related S3 lockup on ASUS laptops, again)

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

 



On Tue, 29 May 2012, Rafael J. Wysocki wrote:

> On Tuesday, May 29, 2012, Alan Stern wrote:
> > On Sun, 27 May 2012, Rafael J. Wysocki wrote:
> > 
> > > So, do you think we should apply [1/4] and [2/4] and try to work around the
> > > BIOS bug from https://bugzilla.kernel.org/show_bug.cgi?id=43278 (I suppose
> > > we can do that by double checking if the target state returned by ACPI is
> > > in agreement with the capabilities returned by the PCI layer)?
> > 
> > Here's one possible approach.  It only solves part of the problem, but
> > it ought to help with Bugzilla 43278 (Dâniel's case).  I suggest that
> > we don't believe the output from _SxW if the PCI PM capability
> > indicates that PME is supported in a higher-numbered D state than _SxW
> > says.
> > 
> > On Dâniel's smachine, _SxW returns D2
> 
> No, it doesn't.  In fact, _SxW is not present for that device in his DSDT.

Oh -- I guess I got the machines mixed up.  Since _SxW isn't present
and _SxD is, we accept the value of _SxD as the only state in which
wakeup is supported.

ACPI apparently doesn't have any way to express: "The device is allowed 
to be in either D2 or D3 during S3 sleep, but it supports wakeup only 
in D3."  And trying to express the inexpressible, the BIOS ended up 
being buggy.

ACPI also apparently doesn't have any way to express: "The device is 
allowed be in D2 but not D3 during S3 sleep, even if wakeup is not 
enabled."

> > but the controller supports PME in D3; therefore we would use D3.
> 
> Yes, we can do that.  This goes along the lines of what I said in the bug
> entry.
> 
> > This still leaves the original problem.  It seems clear that ACPI
> > won't be sufficient to solve this -- at least, it won't help in the
> > case where the controller isn't enabled for wakeup.
> > 
> > Therefore we really do need a quirk, probably in ehci-hcd like the 
> > original patch.  If it is restricted to apply only in cases where the 
> > DMI information lists ASUSTeK as the manufacturer, perhaps that will be 
> > sufficient.  (For some reason, the manufacturer field in Dâniel's BIOS 
> > isn't initialized.)
> 
> Yeah.
> 
> I'll have a deeper look at this later today, I think.

It's easy enough to write such a check (or perhaps more reliably, check
for a product name matching "P8Z68-V").  More difficult is knowing
whether it's the right thing to do.  We don't know the extent of the
underlying problem.

Alan Stern

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux