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

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

[Rafael J. Wysocki]

On Saturday, May 26, 2012, Rafael J. Wysocki wrote:
> On Saturday, May 26, 2012, Steven Rostedt wrote:
> > On Fri, 2012-05-25 at 22:01 -0400, Alan Stern wrote:
> > > Steve and Andrey:
> > > 
> > > It turns out that the proposed solution for your problem causes a
> > > regression on other ASUS computers (see Bugzilla 43278).  Rafael's got a
> > > proposal for a replacement.
> > > 
> > > Can you try out the patch attached to comment #61 of Bugzilla 42728?  It
> > > may even allow USB wakeup to work for you (but I wouldn't count on it!).
> > > Thanks.
> > 
> > I added the patch against 3.4 and my laptop still suspends.
> > 
> > And no, wakeup still doesn't work.
> > 
> > Tested-by: Steven Rostedt <rostedt@goodmis.org>
> 
> Thanks!
> 
> Unfortunately, I have no idea what to do to make wakeup work on the
> affected machines.

Andrey, Stephen,

We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
so some more testing will be necessary, I'm afraid.

I will send a series of ACPI and PCI patches I have collected so far,
that I'd like you to test on top of kernel 3.4.0 with commit
151b61284776 reverted.

Please let me know if suspend/wakeup work for you with these patches applied.

Thanks,
Rafael

[RFT][PATCH 1/4] ACPI / PM: Make acpi_pm_device_sleep_state() follow the specification

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

The comparison between the system sleep state being entered
and the lowest system sleep state the given device may wake up
from in acpi_pm_device_sleep_state() is reversed, because the
specification (ACPI 5.0) says that for wakeup to work:

"The sleeping state being entered must be less than or equal to the
 power state declared in element 1 of the _PRW object."

In other words, the state returned by _PRW is the deepest
(lowest-power) system sleep state the device is capable of waking up
the system from.

Moreover, acpi_pm_device_sleep_state() also should check if the
wakeup capability is supported through ACPI, because in principle it
may be done via native PCIe PME, for example, in which case _SxW
should not be evaluated.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux/drivers/acpi/sleep.c
===================================================================
--- linux.orig/drivers/acpi/sleep.c
+++ linux/drivers/acpi/sleep.c
@@ -732,8 +732,8 @@ int acpi_pm_device_sleep_state(struct de
 	 * can wake the system.  _S0W may be valid, too.
 	 */
 	if (acpi_target_sleep_state == ACPI_STATE_S0 ||
-	    (device_may_wakeup(dev) &&
-	     adev->wakeup.sleep_state <= acpi_target_sleep_state)) {
+	    (device_may_wakeup(dev) && adev->wakeup.flags.valid &&
+	     adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
 		acpi_status status;
 
 		acpi_method[3] = 'W';

[RFT][PATCH 2/4] PCI / PM: Make platform choose target low-power states of more devices

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

It turns out that there are devices whose power states cannot be set
by ACPI (the _PRn and _PSn methods are not available for them), but
it still is necessary to use ACPI for setting up those devices to
wake up the system from sleep states.  Then, according to the ACPI
specification (ACPI 5.0 and earlier), if there are _SxD and/or _SxW
methods defined for those devices, the results returned by them
should be taken into consideration.  Moreover, some hardware vendors
seem to use this requirement to work around hardware and/or firmware
bugs, so it's better to follow it (which we don't do at the moment)
to avoid some nasty suspend/resume issues that are quite difficult to
debug.

This change is based on a patch from Oleksij Rempel.

References: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/pci.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

Index: linux/drivers/pci/pci.c
===================================================================
--- linux.orig/drivers/pci/pci.c
+++ linux/drivers/pci/pci.c
@@ -1691,10 +1691,16 @@ pci_power_t pci_target_state(struct pci_
 {
 	pci_power_t target_state = PCI_D3hot;
 
-	if (platform_pci_power_manageable(dev)) {
+	/*
+	 * It turns out that there are devices whose power states cannot be set
+	 * by the platform, although their wakeup capabilities depend on it.
+	 * The platform should be called to choose the target low-power states
+	 * of those devices too.
+	 */
+	if (platform_pci_power_manageable(dev)
+	    || (device_may_wakeup(&dev->dev) && platform_pci_can_wakeup(dev))) {
 		/*
-		 * Call the platform to choose the target state of the device
-		 * and enable wake-up from this state if supported.
+		 * Call the platform to choose the target state of the device.
 		 */
 		pci_power_t state = platform_pci_choose_state(dev);
 

[RFT][PATCH 3/4] ACPI / PM: Shorten variable name in acpi_pm_device_sleep_state()

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Save a couple of code lines by using a more concise name for the
variable representing the ACPI method to evaluate.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep.c |   14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

Index: linux/drivers/acpi/sleep.c
===================================================================
--- linux.orig/drivers/acpi/sleep.c
+++ linux/drivers/acpi/sleep.c
@@ -697,7 +697,7 @@ int acpi_pm_device_sleep_state(struct de
 {
 	acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
 	struct acpi_device *adev;
-	char acpi_method[] = "_SxD";
+	char method[] = "_SxD";
 	unsigned long long d_min, d_max;
 
 	if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
@@ -705,7 +705,7 @@ int acpi_pm_device_sleep_state(struct de
 		return -ENODEV;
 	}
 
-	acpi_method[2] = '0' + acpi_target_sleep_state;
+	method[2] = '0' + acpi_target_sleep_state;
 	/*
 	 * If the sleep state is S0, we will return D3, but if the device has
 	 * _S0W, we will use the value from _S0W
@@ -722,7 +722,7 @@ int acpi_pm_device_sleep_state(struct de
 	 * provided -- that's our fault recovery, we ignore retval.
 	 */
 	if (acpi_target_sleep_state > ACPI_STATE_S0)
-		acpi_evaluate_integer(handle, acpi_method, NULL, &d_min);
+		acpi_evaluate_integer(handle, method, NULL, &d_min);
 
 	/*
 	 * If _PRW says we can wake up the system from the target sleep state,
@@ -736,17 +736,15 @@ int acpi_pm_device_sleep_state(struct de
 	     adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
 		acpi_status status;
 
-		acpi_method[3] = 'W';
-		status = acpi_evaluate_integer(handle, acpi_method, NULL,
-						&d_max);
+		method[3] = 'W';
+		status = acpi_evaluate_integer(handle, method, NULL, &d_max);
 		if (ACPI_FAILURE(status)) {
 			if (acpi_target_sleep_state != ACPI_STATE_S0 ||
 			    status != AE_NOT_FOUND)
 				d_max = d_min;
 		} else if (d_max < d_min) {
 			/* Warn the user of the broken DSDT */
-			printk(KERN_WARNING "ACPI: Wrong value from %s\n",
-				acpi_method);
+			pr_warning("ACPI: Wrong value from %s\n", method);
 			/* Sanitize it */
 			d_min = d_max;
 		}

[RFT][PATCH 4/4] ACPI / PM: Fix interactions between _SxD and _SxW

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

The ACPI specification (ACPI 5.0 and earlier) tells us to use the
value returned by the _SxD method for the given device as the
lowest-power state the device can be put into before transitioning
the system into the given sleep state if (1) the device is supposed
to wake up the system and (2) the _SxW method is not present for it.
However, if both _SxD and _SxW are not present, we are free to use
D3cold as the lowest-power state to put the device into.

Unfortunately, acpi_pm_device_sleep_state() returns D0 as the
lowest-power state to put the device into if both _SxD and _SxW are
not present, which is incorrect.  Prevent this from happening by
making acpi_pm_device_sleep_state() check whether or not _SxD is
present while deciding what value to use as the lowest-power state
to put the device into.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/acpi/sleep.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

Index: linux/drivers/acpi/sleep.c
===================================================================
--- linux.orig/drivers/acpi/sleep.c
+++ linux/drivers/acpi/sleep.c
@@ -699,6 +699,8 @@ int acpi_pm_device_sleep_state(struct de
 	struct acpi_device *adev;
 	char method[] = "_SxD";
 	unsigned long long d_min, d_max;
+	acpi_status status;
+	bool sxd_present = false;
 
 	if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &adev))) {
 		printk(KERN_DEBUG "ACPI handle has no context!\n");
@@ -719,10 +721,13 @@ int acpi_pm_device_sleep_state(struct de
 	 * minimum D-state is D0 (ACPI 3.x).
 	 *
 	 * NOTE: We rely on acpi_evaluate_integer() not clobbering the integer
-	 * provided -- that's our fault recovery, we ignore retval.
+	 * provided in case of an error.
 	 */
-	if (acpi_target_sleep_state > ACPI_STATE_S0)
-		acpi_evaluate_integer(handle, method, NULL, &d_min);
+	if (acpi_target_sleep_state > ACPI_STATE_S0) {
+		status = acpi_evaluate_integer(handle, method, NULL, &d_min);
+		if (status != AE_NOT_FOUND)
+			sxd_present = true;
+	}
 
 	/*
 	 * If _PRW says we can wake up the system from the target sleep state,
@@ -734,13 +739,10 @@ int acpi_pm_device_sleep_state(struct de
 	if (acpi_target_sleep_state == ACPI_STATE_S0 ||
 	    (device_may_wakeup(dev) && adev->wakeup.flags.valid &&
 	     adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
-		acpi_status status;
-
 		method[3] = 'W';
 		status = acpi_evaluate_integer(handle, method, NULL, &d_max);
 		if (ACPI_FAILURE(status)) {
-			if (acpi_target_sleep_state != ACPI_STATE_S0 ||
-			    status != AE_NOT_FOUND)
+			if (sxd_present || status != AE_NOT_FOUND)
 				d_max = d_min;
 		} else if (d_max < d_min) {
 			/* Warn the user of the broken DSDT */

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

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 570 bytes --]

On Sat, May 26, 2012 at 11:16:29PM +0200, Rafael J. Wysocki wrote:
> Andrey, Stephen,
> 
> We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> so some more testing will be necessary, I'm afraid.
> 
> I will send a series of ACPI and PCI patches I have collected so far,
> that I'd like you to test on top of kernel 3.4.0 with commit
> 151b61284776 reverted.
> 
> Please let me know if suspend/wakeup work for you with these patches applied.
I get the usual freeze on suspending with these patches.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Rafael J. Wysocki]

On Saturday, May 26, 2012, Andrey Rahmatullin wrote:
> On Sat, May 26, 2012 at 11:16:29PM +0200, Rafael J. Wysocki wrote:
> > Andrey, Stephen,
> > 
> > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > so some more testing will be necessary, I'm afraid.
> > 
> > I will send a series of ACPI and PCI patches I have collected so far,
> > that I'd like you to test on top of kernel 3.4.0 with commit
> > 151b61284776 reverted.
> > 
> > Please let me know if suspend/wakeup work for you with these patches applied.
> I get the usual freeze on suspending with these patches.

I see.

Please try to unapply [4/4] and see if that helps.  If it doesn't,
please try to enable the problematic USB controller to wake up
(e.g. by writing "enabled" to its /sys/power/.../wakeup file before the
suspend) and see if that helps.

Thanks,
Rafael

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

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 697 bytes --]

On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > Andrey, Stephen,
> > > 
> > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > so some more testing will be necessary, I'm afraid.
> > > 
> > > I will send a series of ACPI and PCI patches I have collected so far,
> > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > 151b61284776 reverted.
> > > 
> > > Please let me know if suspend/wakeup work for you with these patches applied.
> > I get the usual freeze on suspending with these patches.
> 
> I see.
> 
> Please try to unapply [4/4] and see if that helps.
It helps.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Alan Stern]

On Sun, 27 May 2012, Andrey Rahmatullin wrote:

> On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > > Andrey, Stephen,
> > > > 
> > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > so some more testing will be necessary, I'm afraid.
> > > > 
> > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > 151b61284776 reverted.
> > > > 
> > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > I get the usual freeze on suspending with these patches.
> > 
> > I see.
> > 
> > Please try to unapply [4/4] and see if that helps.
> It helps.

Trying to follow the ACPI spec too closely may be a bad idea.  We 
should try to copy what Windows does (whatever that is!).

Alan Stern

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

[Rafael J. Wysocki]

On Sunday, May 27, 2012, Alan Stern wrote:
> On Sun, 27 May 2012, Andrey Rahmatullin wrote:
> 
> > On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > > > Andrey, Stephen,
> > > > > 
> > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > so some more testing will be necessary, I'm afraid.
> > > > > 
> > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > 151b61284776 reverted.
> > > > > 
> > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > I get the usual freeze on suspending with these patches.
> > > 
> > > I see.
> > > 
> > > Please try to unapply [4/4] and see if that helps.
> > It helps.
> 
> Trying to follow the ACPI spec too closely may be a bad idea.  We 
> should try to copy what Windows does (whatever that is!).

Well, that's why I made it a separate patch, among other things. :-)

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

Rafael

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

[Alan Stern]

On Sun, 27 May 2012, Andrey Rahmatullin wrote:

> On Sun, May 27, 2012 at 12:06:01AM +0200, Rafael J. Wysocki wrote:
> > > > Andrey, Stephen,
> > > > 
> > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > so some more testing will be necessary, I'm afraid.
> > > > 
> > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > 151b61284776 reverted.
> > > > 
> > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > I get the usual freeze on suspending with these patches.
> > 
> > I see.
> > 
> > Please try to unapply [4/4] and see if that helps.
> It helps.

Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
and see what happens if the EHCI controllers' power/wakeup sysfs
atributes are first set to "disabled"?

Alan Stern

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

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Sun, May 27, 2012 at 12:41:43PM -0400, Alan Stern wrote:
> > > > > Andrey, Stephen,
> > > > > 
> > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > so some more testing will be necessary, I'm afraid.
> > > > > 
> > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > 151b61284776 reverted.
> > > > > 
> > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > I get the usual freeze on suspending with these patches.
> > > 
> > > I see.
> > > 
> > > Please try to unapply [4/4] and see if that helps.
> > It helps.
> 
> Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> and see what happens if the EHCI controllers' power/wakeup sysfs
> atributes are first set to "disabled"?
It freezes.

-- 
WBR, wRAR

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rafael J. Wysocki]

On Sunday, May 27, 2012, Andrey Rahmatullin wrote:
> On Sun, May 27, 2012 at 12:41:43PM -0400, Alan Stern wrote:
> > > > > > Andrey, Stephen,
> > > > > > 
> > > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > > so some more testing will be necessary, I'm afraid.
> > > > > > 
> > > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > > 151b61284776 reverted.
> > > > > > 
> > > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > > I get the usual freeze on suspending with these patches.
> > > > 
> > > > I see.
> > > > 
> > > > Please try to unapply [4/4] and see if that helps.
> > > It helps.
> > 
> > Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> > and see what happens if the EHCI controllers' power/wakeup sysfs
> > atributes are first set to "disabled"?
> It freezes.

Well, that means trying to work around this through changing the algorithm
of selecting the target state of a device wasn't a good idea after all.

Still, we've found some bugs in the process, so it was worth the effort.

Please attach the output of dmidecode from your machine.
Steven, please do that too.

Thanks,
Rafael

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

[Andrey Rahmatullin]

[-- Attachment #1.1.1: Type: text/plain, Size: 1360 bytes --]

On Mon, May 28, 2012 at 10:13:01PM +0200, Rafael J. Wysocki wrote:
> > > > > > > Andrey, Stephen,
> > > > > > > 
> > > > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > > > so some more testing will be necessary, I'm afraid.
> > > > > > > 
> > > > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > > > 151b61284776 reverted.
> > > > > > > 
> > > > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > > > I get the usual freeze on suspending with these patches.
> > > > > 
> > > > > I see.
> > > > > 
> > > > > Please try to unapply [4/4] and see if that helps.
> > > > It helps.
> > > 
> > > Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> > > and see what happens if the EHCI controllers' power/wakeup sysfs
> > > atributes are first set to "disabled"?
> > It freezes.
> 
> Well, that means trying to work around this through changing the algorithm
> of selecting the target state of a device wasn't a good idea after all.
> 
> Still, we've found some bugs in the process, so it was worth the effort.
> 
> Please attach the output of dmidecode from your machine.
Attached.


-- 
WBR, wRAR

[-- Attachment #1.1.2: dmidecode-K53E.txt.gz --]
[-- Type: application/octet-stream, Size: 3902 bytes --]

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Alan Stern]

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 but the controller supports PME 
in D3; therefore we would use D3.

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

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafael J. Wysocki]

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.

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

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafael J. Wysocki]

On Tuesday, May 29, 2012, Andrey Rahmatullin wrote:
> On Mon, May 28, 2012 at 10:13:01PM +0200, Rafael J. Wysocki wrote:
> > > > > > > > Andrey, Stephen,
> > > > > > > > 
> > > > > > > > We still have problems with this patch in https://bugzilla.kernel.org/show_bug.cgi?id=43278
> > > > > > > > so some more testing will be necessary, I'm afraid.
> > > > > > > > 
> > > > > > > > I will send a series of ACPI and PCI patches I have collected so far,
> > > > > > > > that I'd like you to test on top of kernel 3.4.0 with commit
> > > > > > > > 151b61284776 reverted.
> > > > > > > > 
> > > > > > > > Please let me know if suspend/wakeup work for you with these patches applied.
> > > > > > > I get the usual freeze on suspending with these patches.
> > > > > > 
> > > > > > I see.
> > > > > > 
> > > > > > Please try to unapply [4/4] and see if that helps.
> > > > > It helps.
> > > > 
> > > > Andrey, can you try out Rafael's patches 1-3 (with 151b... reverted)  
> > > > and see what happens if the EHCI controllers' power/wakeup sysfs
> > > > atributes are first set to "disabled"?
> > > It freezes.
> > 
> > Well, that means trying to work around this through changing the algorithm
> > of selecting the target state of a device wasn't a good idea after all.
> > 
> > Still, we've found some bugs in the process, so it was worth the effort.
> > 
> > Please attach the output of dmidecode from your machine.
> Attached.

Cool, thanks!

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

[Alan Stern]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafael J. Wysocki]

On Tuesday, May 29, 2012, Alan Stern wrote:
> 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.

Precisely.

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

Yeah.

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

That's my understanding too.

> > > 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").

I think we should try to express it as a PCI quirk in quirks.c, though.

> More difficult is knowing whether it's the right thing to do.  We don't
> know the extent of the underlying problem.

Well, we can only learn that by experience, so we should address the know
cases and then try to find patterns, if they exist.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

On Mon, 2012-05-28 at 22:13 +0200, Rafael J. Wysocki wrote:

> Please attach the output of dmidecode from your machine.
> Steven, please do that too.

Attached.

-- Steve


[-- Attachment #2: dmi.gz --]
[-- Type: application/x-gzip, Size: 3391 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

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

[Alan Stern]

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

> > > > 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").
> 
> I think we should try to express it as a PCI quirk in quirks.c, though.

Here's my attempt.  Everybody, please try this patch with the
151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
enabled so we can check the controller's power state during suspend, 
and check that the "broken D3 during system sleep on ASUS" message 
shows up during booting.

Alan Stern



Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
 	if (target_state == PCI_POWER_ERROR)
 		return -EIO;
 
+	/* Some devices mustn't be in D3 during system sleep */
+	if (target_state == PCI_D3hot &&
+			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
+		return 0;
+
 	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
 
 	error = pci_set_power_state(dev, target_state);
Index: usb-3.4/drivers/pci/quirks.c
===================================================================
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
 
+/*
+ * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
+ * ASUS motherboards will cause memory corruption or a system crash
+ * if they are in D3 while the system is put into S3 sleep.
+ */
+static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
+{
+	const char *sys_info;
+	static const char good_Asus_board[] = "P8Z68-V";
+
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
+		return;
+	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+		return;
+	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
+	if (sys_info && memcmp(sys_info, good_Asus_board,
+			sizeof(good_Asus_board) - 1) == 0)
+		return;
+
+	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
+	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
+	device_set_wakeup_capable(&dev->dev, false);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
 			  struct pci_fixup *end)
 {
Index: usb-3.4/include/linux/pci.h
===================================================================
--- usb-3.4.orig/include/linux/pci.h
+++ usb-3.4/include/linux/pci.h
@@ -176,6 +176,8 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
 	/* Provide indication device is assigned by a Virtual Machine Manager */
 	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+	/* Device causes system crash if in D3 during S3 sleep */
+	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
 };
 
 enum pci_irq_reroute_variant {

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafael J. Wysocki]

On Thursday, May 31, 2012, Alan Stern wrote:
> On Tue, 29 May 2012, Rafael J. Wysocki wrote:
> 
> > > > > 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").
> > 
> > I think we should try to express it as a PCI quirk in quirks.c, though.
> 
> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.
> 
> Alan Stern
> 
> 
> 
> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
>  	if (target_state == PCI_POWER_ERROR)
>  		return -EIO;
>  
> +	/* Some devices mustn't be in D3 during system sleep */
> +	if (target_state == PCI_D3hot &&
> +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> +		return 0;
> +

Why do you want to skip the wakeup setting in that case?

>  	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
>  
>  	error = pci_set_power_state(dev, target_state);
> Index: usb-3.4/drivers/pci/quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/quirks.c
> +++ usb-3.4/drivers/pci/quirks.c
> @@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
>  
> +/*
> + * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
> + * ASUS motherboards will cause memory corruption or a system crash
> + * if they are in D3 while the system is put into S3 sleep.
> + */
> +static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
> +{
> +	const char *sys_info;
> +	static const char good_Asus_board[] = "P8Z68-V";
> +
> +	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
> +		return;
> +	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> +		return;
> +	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
> +	if (sys_info && memcmp(sys_info, good_Asus_board,
> +			sizeof(good_Asus_board) - 1) == 0)
> +		return;
> +
> +	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
> +	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
> +	device_set_wakeup_capable(&dev->dev, false);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> +
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>  			  struct pci_fixup *end)
>  {
> Index: usb-3.4/include/linux/pci.h
> ===================================================================
> --- usb-3.4.orig/include/linux/pci.h
> +++ usb-3.4/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
>  	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
>  	/* Provide indication device is assigned by a Virtual Machine Manager */
>  	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> +	/* Device causes system crash if in D3 during S3 sleep */
> +	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
>  };
>  
>  enum pci_irq_reroute_variant {

The quirks part looks good to me.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dâniel Fraga]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

On Thu, 31 May 2012 17:07:36 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.

	Hi Alan, I tested your patch. It wakes up fine through
keyboard, but it didn't write the "broken D3 during..." message. I
attached the dmesg output.

-- 
Linux 3.4.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

[-- Attachment #2: dmesg-alan.txt --]
[-- Type: application/octet-stream, Size: 9987 bytes --]

usb 2-1.6: unlink qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.13 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.93 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
usb 2-1.5: unlink qh32-0601/ffff880213868980 start 6 [1/2 us]
usb 2-1.5: unlink qh8-0601/ffff880215cda180 start 5 [1/2 us]
usb 2-1.2.1.1: usb suspend, wakeup 0
usb 2-1.3: usb suspend, wakeup 0
usb 2-1.6: usb suspend, wakeup 0
usb 2-1.1: usb suspend, wakeup 0
usb 2-1.5: usb suspend, wakeup 1
usb usb1: usb auto-resume
ehci_hcd 0000:00:1a.0: resume root hub
sd 4:0:0:0: [sda] Synchronizing SCSI cache
sd 4:0:0:0: [sda] Stopping disk
ACPI handle has no context!
hub 2-1.2.1:1.0: hub_suspend
usb 2-1.2.1: unlink qh256-0001/ffff880213868b00 start 3 [1/0 us]
usb 2-1.2.1: usb suspend, wakeup 0
hub 1-0:1.0: hub_resume
hub 1-0:1.0: port 1: status 0507 change 0000
usb 1-1: usb auto-resume
hub 2-1.2:1.0: hub_suspend
usb 2-1.2: unlink qh256-0001/ffff8802161b0e80 start 2 [1/0 us]
usb 2-1.2: usb suspend, wakeup 0
hub 2-1:1.0: hub_suspend
usb 2-1: unlink qh256-0001/ffff880216089900 start 1 [1/0 us]
usb 2-1: usb suspend, wakeup 0
hub 2-0:1.0: hub_suspend
usb usb2: bus suspend, wakeup 0
ehci_hcd 0000:00:1d.0: suspend root hub
ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
usb 1-1: finish resume
hub 1-1:1.0: hub_resume
ehci_hcd 0000:00:1a.0: reused qh ffff88021509ca00 schedule
usb 1-1: link qh256-0001/ffff88021509ca00 start 1 [1/0 us]
hub 1-1:1.0: hub_suspend
usb 1-1: unlink qh256-0001/ffff88021509ca00 start 1 [1/0 us]
usb 1-1: usb suspend, wakeup 0
hub 1-0:1.0: hub_suspend
usb usb1: bus suspend, wakeup 0
ehci_hcd 0000:00:1a.0: suspend root hub
e1000e 0000:00:19.0: wake-up capability enabled by ACPI
PM: suspend of devices complete after 215.730 msecs
PM: late suspend of devices complete after 0.058 msecs
ehci_hcd 0000:00:1d.0: wakeup: 1
ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1d.0: --> PCI D3hot
ehci_hcd 0000:00:1a.0: wakeup: 1
ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
ehci_hcd 0000:00:1a.0: --> PCI D3hot
PM: noirq suspend of devices complete after 21.999 msecs
ACPI: Preparing to enter system sleep state S3
PM: Saving platform NVS memory
Disabling non-boot CPUs ...
CPU 1 is now offline
CPU 2 is now offline
CPU 3 is now offline
CPU 4 is now offline
CPU 5 is now offline
CPU 6 is now offline
CPU 7 is now offline
Extended CMOS year: 2000
ACPI: Low-level resume complete
PM: Restoring platform NVS memory
Extended CMOS year: 2000
Enabling non-boot CPUs ...
Booting Node 0 Processor 1 APIC 0x2
CPU1 is up
Booting Node 0 Processor 2 APIC 0x4
CPU2 is up
Booting Node 0 Processor 3 APIC 0x6
CPU3 is up
Booting Node 0 Processor 4 APIC 0x1
CPU4 is up
Booting Node 0 Processor 5 APIC 0x3
CPU5 is up
Booting Node 0 Processor 6 APIC 0x5
CPU6 is up
Booting Node 0 Processor 7 APIC 0x7
CPU7 is up
ACPI: Waking up from system sleep state S3
ehci_hcd 0000:00:1a.0: wake-up capability disabled by ACPI
ehci_hcd 0000:00:1d.0: wake-up capability disabled by ACPI
PM: noirq resume of devices complete after 0.553 msecs
PM: early resume of devices complete after 0.024 msecs
i915 0000:00:02.0: setting latency timer to 64
e1000e 0000:00:19.0: wake-up capability disabled by ACPI
ehci_hcd 0000:00:1a.0: setting latency timer to 64
ehci_hcd 0000:00:1d.0: setting latency timer to 64
ahci 0000:00:1f.2: setting latency timer to 64
pci 0000:03:00.0: setting latency timer to 64
snd_hda_intel 0000:00:1b.0: irq 42 for MSI/MSI-X
e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
usb usb1: usb resume
ehci_hcd 0000:00:1a.0: resume root hub
usb usb2: usb resume
ehci_hcd 0000:00:1d.0: resume root hub
ehci_hcd 0000:00:1d.0: port 1 remote wakeup
hub 2-0:1.0: hub_resume
hub 1-0:1.0: hub_resume
hub 2-0:1.0: port 1: status 0507 change 0000
hub 1-0:1.0: port 1: status 0507 change 0000
usb 2-1: usb resume
usb 1-1: usb resume
[drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
usb 1-1: finish resume
usb 2-1: finish resume
hub 2-1:1.0: hub_resume
hub 1-1:1.0: hub_resume
hub 2-1:1.0: port 1: status 0507 change 0000
hub 2-1:1.0: port 2: status 0507 change 0000
hub 2-1:1.0: port 3: status 0307 change 0000
hub 2-1:1.0: port 5: status 0303 change 0004
hub 2-1:1.0: port 6: status 0307 change 0000
ehci_hcd 0000:00:1a.0: reused qh ffff88021509ca00 schedule
usb 1-1: link qh256-0001/ffff88021509ca00 start 1 [1/0 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880216089900 schedule
usb 2-1: link qh256-0001/ffff880216089900 start 1 [1/0 us]
usb 2-1.5: finish resume
usb 2-1.3: usb resume
usb 2-1.6: usb resume
usb 2-1.2: usb resume
usb 2-1.1: usb resume
ehci_hcd 0000:00:1d.0: reused qh ffff880215cda180 schedule
usb 2-1.5: link qh8-0601/ffff880215cda180 start 5 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880213868980 schedule
usb 2-1.5: link qh32-0601/ffff880213868980 start 6 [1/2 us]
usb 2-1.6: finish resume
usb 2-1.1: finish reset-resume
usb 2-1.2: finish resume
usb 2-1.3: finish resume
hub 2-1.2:1.0: hub_resume
hub 2-1.2:1.0: port 1: status 0507 change 0000
ehci_hcd 0000:00:1d.0: reused qh ffff8802161b0e80 schedule
usb 2-1.2: link qh256-0001/ffff8802161b0e80 start 2 [1/0 us]
usb 2-1.2.1: usb resume
hub 2-1:1.0: port 1 not reset yet, waiting 10ms
usb 2-1.2.1: finish resume
hub 2-1.2.1:1.0: hub_resume
hub 2-1.2.1:1.0: port 1: status 0507 change 0000
ehci_hcd 0000:00:1d.0: reused qh ffff880213868b00 schedule
usb 2-1.2.1: link qh256-0001/ffff880213868b00 start 3 [1/0 us]
usb 2-1.2.1.1: usb resume
usb 2-1.1: reset high-speed USB device number 3 using ehci_hcd
usb 2-1.2.1.1: finish resume
hub 2-1:1.0: port 1 not reset yet, waiting 10ms
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88021606b618), AE_NOT_FOUND (20120320/psparse-536)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88021606b618), AE_NOT_FOUND (20120320/psparse-536)
ata3.00: configured for UDMA/133
restoring control 00000000-0000-0000-0000-000000000001/1/2
restoring control 00000000-0000-0000-0000-000000000001/2/3
restoring control 00000000-0000-0000-0000-000000000001/3/4
uvcvideo: Failed to query (SET_CUR) UVC control 4 on unit 1: -32 (exp. 4).
uvcvideo 2-1.1:1.0: reset_resume error -5
snd-usb-audio 2-1.1:1.2: no reset_resume for driver snd-usb-audio?
snd-usb-audio 2-1.1:1.3: no reset_resume for driver snd-usb-audio?
snd-usb-audio 2-1.1:1.2: forced unbind
snd-usb-audio 2-1.1:1.3: forced unbind
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
DROP INPUT: IN=eth0 OUT= MAC=01:00:5e:00:00:01:d8:5d:4c:b9:dc:ce:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88021606b708), AE_NOT_FOUND (20120320/psparse-536)
ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20120320/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88021606b708), AE_NOT_FOUND (20120320/psparse-536)
ata5.00: configured for UDMA/133
sd 4:0:0:0: [sda] Starting disk
PM: resume of devices complete after 4539.833 msecs
snd-usb-audio 2-1.1:1.2: usb_probe_interface
snd-usb-audio 2-1.1:1.2: usb_probe_interface - got id
Restarting tasks ... 
hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 1-1:1.0: state 7 ports 6 chg 0000 evt 0000
hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 2-1:1.0: state 7 ports 8 chg 0020 evt 0000
hub 2-1:1.0: port 5, status 0303, change 0000, 1.5 Mb/s
hub 2-1.2:1.0: state 7 ports 2 chg 0000 evt 0000
hub 2-1.2.1:1.0: state 7 ports 4 chg 0000 evt 0000
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff8802148f9700 schedule
usb 2-1.6: link qh8-0601/ffff8802148f9700 start 0 [1/2 us]
done.
video LNXVIDEO:00: Restoring backlight state
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.6: unlink qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff8802148f9700 schedule
usb 2-1.6: link qh8-0601/ffff8802148f9700 start 0 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
hub 1-1:1.0: hub_suspend
usb 1-1: unlink qh256-0001/ffff88021509ca00 start 1 [1/0 us]
usb 1-1: usb auto-suspend, wakeup 1
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
hub 1-0:1.0: hub_suspend
usb usb1: bus auto-suspend, wakeup 1
ehci_hcd 0000:00:1a.0: suspend root hub
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]
ehci_hcd 0000:00:1d.0: reused qh ffff880212aefd00 schedule
usb 2-1.3: link qh8-0601/ffff880212aefd00 start 7 [1/2 us]
usb 2-1.3: unlink qh8-0601/ffff880212aefd00 start 7 [1/2 us]

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

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 400 bytes --]

On Thu, May 31, 2012 at 05:07:36PM -0400, Alan Stern wrote:
> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.
dmesg attached

-- 
WBR, wRAR

[-- Attachment #1.2: dmesg.gz --]
[-- Type: application/octet-stream, Size: 2417 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Alan Stern]

On Thu, 31 May 2012, Dâniel Fraga wrote:

> On Thu, 31 May 2012 17:07:36 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > Here's my attempt.  Everybody, please try this patch with the
> > 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> > enabled so we can check the controller's power state during suspend, 
> > and check that the "broken D3 during system sleep on ASUS" message 
> > shows up during booting.
> 
> 	Hi Alan, I tested your patch. It wakes up fine through
> keyboard, but it didn't write the "broken D3 during..." message. I
> attached the dmesg output.

That's good.  The message isn't supposed to appear on your system 
because your system works properly without any special treatment.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Stern]

On Thu, 31 May 2012, Rafael J. Wysocki wrote:

> > @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> >  	if (target_state == PCI_POWER_ERROR)
> >  		return -EIO;
> >  
> > +	/* Some devices mustn't be in D3 during system sleep */
> > +	if (target_state == PCI_D3hot &&
> > +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> > +		return 0;
> > +
> 
> Why do you want to skip the wakeup setting in that case?

Because that's what the 151b61284776 commit did.  Also, the quirk marks 
the controller as not wakeup-capable.

Still, it's worth testing.  Andrey and Steve, here's an updated patch 
which should leave wakeup enabled on your EHCI controllers.  If you 
don't have a USB keyboard handy for generating a wakeup signal, you 
can test the wakeup functionality by doing:

	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup

before suspending.  (In fact you need only one of those two lines, but
at the moment I forget which -- probably the usb2 one.)  Then while
the system is asleep, either plugging or unplugging a USB device
directly into the computer should cause it to wake up.

Alan Stern



Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1745,6 +1745,11 @@ int pci_prepare_to_sleep(struct pci_dev
 
 	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
 
+	/* Some devices mustn't be in D3 during system sleep */
+	if (target_state == PCI_D3hot &&
+			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
+		return 0;
+
 	error = pci_set_power_state(dev, target_state);
 
 	if (error)
Index: usb-3.4/drivers/pci/quirks.c
===================================================================
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2917,6 +2917,31 @@ static void __devinit disable_igfx_irq(s
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
 
+/*
+ * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
+ * ASUS motherboards will cause memory corruption or a system crash
+ * if they are in D3 while the system is put into S3 sleep.
+ */
+static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
+{
+	const char *sys_info;
+	static const char good_Asus_board[] = "P8Z68-V";
+
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
+		return;
+	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+		return;
+	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
+	if (sys_info && memcmp(sys_info, good_Asus_board,
+			sizeof(good_Asus_board) - 1) == 0)
+		return;
+
+	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
+	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
 			  struct pci_fixup *end)
 {
Index: usb-3.4/include/linux/pci.h
===================================================================
--- usb-3.4.orig/include/linux/pci.h
+++ usb-3.4/include/linux/pci.h
@@ -176,6 +176,8 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
 	/* Provide indication device is assigned by a Virtual Machine Manager */
 	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+	/* Device causes system crash if in D3 during S3 sleep */
+	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
 };
 
 enum pci_irq_reroute_variant {

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

[Steven Rostedt]

On Fri, 2012-06-01 at 11:13 -0400, Alan Stern wrote:
> On Thu, 31 May 2012, Rafael J. Wysocki wrote:
> 
> > > @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> > >  	if (target_state == PCI_POWER_ERROR)
> > >  		return -EIO;
> > >  
> > > +	/* Some devices mustn't be in D3 during system sleep */
> > > +	if (target_state == PCI_D3hot &&
> > > +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> > > +		return 0;
> > > +
> > 
> > Why do you want to skip the wakeup setting in that case?
> 
> Because that's what the 151b61284776 commit did.  Also, the quirk marks 
> the controller as not wakeup-capable.
> 
> Still, it's worth testing.  Andrey and Steve, here's an updated patch 
> which should leave wakeup enabled on your EHCI controllers.  If you 
> don't have a USB keyboard handy for generating a wakeup signal, you 
> can test the wakeup functionality by doing:
> 
> 	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
> 	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup
> 
> before suspending.  (In fact you need only one of those two lines, but
> at the moment I forget which -- probably the usb2 one.)  Then while
> the system is asleep, either plugging or unplugging a USB device
> directly into the computer should cause it to wake up.

I applied the patch, it suspends and resumes fine, but still no wakeup.

I even plugged in a USB keyboard, suspended, and tried to wake it up
with that. That did not work. I even enabled what you stated above, with
no effect (with keyboard or usb storage).

-- Steve

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

[Alan Stern]

On Fri, 1 Jun 2012, Steven Rostedt wrote:

> > > Why do you want to skip the wakeup setting in that case?
> > 
> > Because that's what the 151b61284776 commit did.  Also, the quirk marks 
> > the controller as not wakeup-capable.
> > 
> > Still, it's worth testing.  Andrey and Steve, here's an updated patch 
> > which should leave wakeup enabled on your EHCI controllers.  If you 
> > don't have a USB keyboard handy for generating a wakeup signal, you 
> > can test the wakeup functionality by doing:
> > 
> > 	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
> > 	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup
> > 
> > before suspending.  (In fact you need only one of those two lines, but
> > at the moment I forget which -- probably the usb2 one.)  Then while
> > the system is asleep, either plugging or unplugging a USB device
> > directly into the computer should cause it to wake up.
> 
> I applied the patch, it suspends and resumes fine, but still no wakeup.
> 
> I even plugged in a USB keyboard, suspended, and tried to wake it up
> with that. That did not work. I even enabled what you stated above, with
> no effect (with keyboard or usb storage).

This suggests that the original version of the patch is superior.  
There's not point in saying the controller is wakeup-capable and trying 
to enable wakeup if it's not going to work.

Alan Stern

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

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 1674 bytes --]

On Fri, Jun 01, 2012 at 11:50:44AM -0400, Steven Rostedt wrote:
> > > > @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
> > > >  	if (target_state == PCI_POWER_ERROR)
> > > >  		return -EIO;
> > > >  
> > > > +	/* Some devices mustn't be in D3 during system sleep */
> > > > +	if (target_state == PCI_D3hot &&
> > > > +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> > > > +		return 0;
> > > > +
> > > 
> > > Why do you want to skip the wakeup setting in that case?
> > 
> > Because that's what the 151b61284776 commit did.  Also, the quirk marks 
> > the controller as not wakeup-capable.
> > 
> > Still, it's worth testing.  Andrey and Steve, here's an updated patch 
> > which should leave wakeup enabled on your EHCI controllers.  If you 
> > don't have a USB keyboard handy for generating a wakeup signal, you 
> > can test the wakeup functionality by doing:
> > 
> > 	echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
> > 	echo enabled >/sys/bus/usb/devices/usb2/power/wakeup
> > 
> > before suspending.  (In fact you need only one of those two lines, but
> > at the moment I forget which -- probably the usb2 one.)  Then while
> > the system is asleep, either plugging or unplugging a USB device
> > directly into the computer should cause it to wake up.
> 
> I applied the patch, it suspends and resumes fine, but still no wakeup.
> 
> I even plugged in a USB keyboard, suspended, and tried to wake it up
> with that. That did not work. I even enabled what you stated above, with
> no effect (with keyboard or usb storage).
The same here, and the keyboard LEDs turn off on suspending.

-- 
WBR, wRAR

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Alan Stern]

On Fri, 1 Jun 2012, Andrey Rahmatullin wrote:

> > I applied the patch, it suspends and resumes fine, but still no wakeup.
> > 
> > I even plugged in a USB keyboard, suspended, and tried to wake it up
> > with that. That did not work. I even enabled what you stated above, with
> > no effect (with keyboard or usb storage).
> The same here, and the keyboard LEDs turn off on suspending.

The LEDs are expected to turn off during suspend; that's normal.  
Otherwise they would use up unnecessary electrical power.

Alan Stern

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

[Steven Rostedt]

On Fri, 2012-06-01 at 11:59 -0400, Alan Stern wrote:
>  
> > I even plugged in a USB keyboard, suspended, and tried to wake it up
> > with that. That did not work. I even enabled what you stated above, with
> > no effect (with keyboard or usb storage).
> 
> This suggests that the original version of the patch is superior.  
> There's not point in saying the controller is wakeup-capable and trying 
> to enable wakeup if it's not going to work.

I would point out that I have yet to get wakeup via usb to work with any
patch.

Maybe I missed a patch, which one is suppose to work?

-- Steve

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

[Alan Stern]

On Fri, 1 Jun 2012, Steven Rostedt wrote:

> On Fri, 2012-06-01 at 11:59 -0400, Alan Stern wrote:
> >  
> > > I even plugged in a USB keyboard, suspended, and tried to wake it up
> > > with that. That did not work. I even enabled what you stated above, with
> > > no effect (with keyboard or usb storage).
> > 
> > This suggests that the original version of the patch is superior.  
> > There's not point in saying the controller is wakeup-capable and trying 
> > to enable wakeup if it's not going to work.
> 
> I would point out that I have yet to get wakeup via usb to work with any
> patch.
> 
> Maybe I missed a patch, which one is suppose to work?

No, I think it's more likely that USB wakeup simply can't be made to
work on your computer.  Whatever caused the original suspend problem
also interferes with wakeup.

Alan Stern

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

[Steven Rostedt]

On Fri, 2012-06-01 at 13:17 -0400, Alan Stern wrote:
>  
> > Maybe I missed a patch, which one is suppose to work?
> 
> No, I think it's more likely that USB wakeup simply can't be made to
> work on your computer.  Whatever caused the original suspend problem
> also interferes with wakeup.

OK, that's what I thought, as it doesn't even work with Windows.

-- Steve

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

[Rafael J. Wysocki]

Hi Alan,

On Thursday, May 31, 2012, Alan Stern wrote:
> On Tue, 29 May 2012, Rafael J. Wysocki wrote:
> 
> > > > > 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").
> > 
> > I think we should try to express it as a PCI quirk in quirks.c, though.
> 
> Here's my attempt.  Everybody, please try this patch with the
> 151b61284776 commit removed.  Make sure that CONFIG_USB_DEBUG is
> enabled so we can check the controller's power state during suspend, 
> and check that the "broken D3 during system sleep on ASUS" message 
> shows up during booting.

It looks like this worked for everyone concerned, is that correct?

In that case, do you intend to send this patch for inclusion any time soon?
It would be good to have this particular issue taken care of.

Thanks,
Rafael


> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1743,6 +1743,11 @@ int pci_prepare_to_sleep(struct pci_dev
>  	if (target_state == PCI_POWER_ERROR)
>  		return -EIO;
>  
> +	/* Some devices mustn't be in D3 during system sleep */
> +	if (target_state == PCI_D3hot &&
> +			(dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
> +		return 0;
> +
>  	pci_enable_wake(dev, target_state, device_may_wakeup(&dev->dev));
>  
>  	error = pci_set_power_state(dev, target_state);
> Index: usb-3.4/drivers/pci/quirks.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/quirks.c
> +++ usb-3.4/drivers/pci/quirks.c
> @@ -2917,6 +2917,32 @@ static void __devinit disable_igfx_irq(s
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
>  
> +/*
> + * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
> + * ASUS motherboards will cause memory corruption or a system crash
> + * if they are in D3 while the system is put into S3 sleep.
> + */
> +static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
> +{
> +	const char *sys_info;
> +	static const char good_Asus_board[] = "P8Z68-V";
> +
> +	if (dev->dev_flags & PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
> +		return;
> +	if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> +		return;
> +	sys_info = dmi_get_system_info(DMI_BOARD_NAME);
> +	if (sys_info && memcmp(sys_info, good_Asus_board,
> +			sizeof(good_Asus_board) - 1) == 0)
> +		return;
> +
> +	dev_info(&dev->dev, "broken D3 during system sleep on ASUS\n");
> +	dev->dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
> +	device_set_wakeup_capable(&dev->dev, false);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
> +
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>  			  struct pci_fixup *end)
>  {
> Index: usb-3.4/include/linux/pci.h
> ===================================================================
> --- usb-3.4.orig/include/linux/pci.h
> +++ usb-3.4/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
>  	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
>  	/* Provide indication device is assigned by a Virtual Machine Manager */
>  	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> +	/* Device causes system crash if in D3 during S3 sleep */
> +	PCI_DEV_FLAGS_NO_D3_DURING_SLEEP = (__force pci_dev_flags_t) 8,
>  };
>  
>  enum pci_irq_reroute_variant {
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Stern]

On Wed, 13 Jun 2012, Rafael J. Wysocki wrote:

> Hi Alan,

> It looks like this worked for everyone concerned, is that correct?

Apparently.

> In that case, do you intend to send this patch for inclusion any time soon?
> It would be good to have this particular issue taken care of.

Thanks for reminding me.  I'll send it soon.

Alan Stern