Asus P1-AH2 won't suspend (regression)
Hi,
I'm unable to get an asus P1-AH2 system to suspend (to ram). The issue occurs at suspend time: the system displays "Suspending console(s)" but does not turn off the screen and system fans.
I used to have suspend/resume working fine on this system using a 2.6.20.x kernel. Yes, I know this is a huge range... suspend has been broken on this sytem since at least 2.6.22.x
I tried running 2.6.24-rc6 with verbose PM debugging and suspend/resume event tracing. Still no luck, the last message I see is still "Suspending console(s)". The information from event tracing seems to be:
Magic number: 8:471:282
hash matches device tty19
I'm not sure if that's any help. Is there any way to help figure out the problem besides a git bisect ? would extra event traces during/after the suspend console stage help ???
This is with an x86_64 kernel. .config file can be found at
http://lespinasse.org/config-2.6.24-rc6 if that's any help.
Thanks,
Signature · 1 line
Michel Lespinasse
Quoted 16 lines · Michel Lespinasse
Hi,
I'm unable to get an asus P1-AH2 system to suspend (to ram). The issue occurs at suspend time: the system displays "Suspending console(s)" but does not turn off the screen and system fans.
I used to have suspend/resume working fine on this system using a 2.6.20.x kernel. Yes, I know this is a huge range... suspend has been broken on this sytem since at least 2.6.22.x
I tried running 2.6.24-rc6 with verbose PM debugging and suspend/resume event tracing. Still no luck, the last message I see is still "Suspending console(s)". The information from event tracing seems to be:
Magic number: 8:471:282
hash matches device tty19
Quoted 6 lines
I'm not sure if that's any help. Is there any way to help figure out the problem besides a git bisect ? would extra event traces during/after the suspend console stage help ???
This is with an
x86_64kernel. .config file can be found at
http://lespinasse.org/config-2.6.24-rc6 if that's any help.
Please try the patch series from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/
on top of 2.6.24-rc6 (patches 28-34 are relevant in particular) and see if that helps.
Thanks,
Rafael
Quoted 4 lines · Rafael J. Wysocki
Please try the patch series from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/
on top of 2.6.24-rc6 (patches 28-34 are relevant in particular) and see if that helps.
No luck. The system still does not suspend after applying the patch set. Still stuck at the same place, "Suspending console(s)"...
Quoted 8 lines · On Saturday 05 January 2008 07:20:22 Michel Lespinasse wrote:
Quoted 4 lines · Rafael J. Wysocki
Please try the patch series from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/
on top of 2.6.24-rc6 (patches 28-34 are relevant in particular) and see if that helps.No luck. The system still does not suspend after applying the patch set. Still stuck at the same place, "Suspending console(s)"...
Can you try applying this patch on top of Rafael's patch series:
http://files.strangeworlds.co.uk/acpi-force-1.0-suspend-behaviour
-Carlos
Signature · 3 lines
E-Mail: [email protected] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D
Quoted 7 lines · Carlos Corbacho
Quoted 2 lines · On Saturday 05 January 2008 07:20:22 Michel Lespinasse wrote:
No luck. The system still does not suspend after applying the patch set. Still stuck at the same place, "Suspending console(s)"...
Can you try applying this patch on top of Rafael's patch series:
http://files.strangeworlds.co.uk/acpi-force-1.0-suspend-behaviour
Nice !
The patch did not work as you sent it, but doing the same in acpi_pm_open() (i.e. forcing it to execute the revision<3 code) worked.
I'm now doing a happy dance :)
So what now, do you need some kind of signature for the system ? (I realize that would probably be some kind of DMI string, but I'm not sure where/how to obtain it)
Signature · 1 line
Michel Lespinasse
Quoted 11 lines · Michel Lespinasse
Quoted 7 lines · Carlos Corbacho
Quoted 2 lines · On Saturday 05 January 2008 07:20:22 Michel Lespinasse wrote:
No luck. The system still does not suspend after applying the patch set. Still stuck at the same place, "Suspending console(s)"...
Can you try applying this patch on top of Rafael's patch series:
http://files.strangeworlds.co.uk/acpi-force-1.0-suspend-behaviour
Nice !
Quoted 7 lines
The patch did not work as you sent it, but doing the same in
acpi_pm_open()(i.e. forcing it to execute the revision<3 code) worked.
I'm now doing a happy dance :)So what now, do you need some kind of signature for the system ? (I realize that would probably be some kind of DMI string, but I'm not sure where/how to obtain it)
Well, I think I'd rather want to introduce a boot parameter for that. Stay tuned.
Greetings,
Rafael
Quoted 11 lines · Rafael J. Wysocki
Quoted 7 lines · Michel Lespinasse
The patch did not work as you sent it, but doing the same in
acpi_pm_open()(i.e. forcing it to execute the revision<3 code) worked.
I'm now doing a happy dance :)So what now, do you need some kind of signature for the system ? (I realize that would probably be some kind of DMI string, but I'm not sure where/how to obtain it)
Well, I think I'd rather want to introduce a boot parameter for that. Stay tuned.
Surely this implies that the only behaviour tested (and, so, presumably the only behaviour implemented in Windows) is the 1.0-style flow? If so, we should just default to that regardless of what the spec says.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 10 lines · Matthew Garrett
Quoted 9 lines · Rafael J. Wysocki
Quoted 7 lines · Michel Lespinasse
The patch did not work as you sent it, but doing the same in
acpi_pm_open()(i.e. forcing it to execute the revision<3 code) worked.
I'm now doing a happy dance :)So what now, do you need some kind of signature for the system ? (I realize that would probably be some kind of DMI string, but I'm not sure where/how to obtain it)
Quoted 6 lines
Quoted 2 lines
Well, I think I'd rather want to introduce a boot parameter for that. Stay tuned.
Surely this implies that the only behaviour tested (and, so, presumably the only behaviour implemented in Windows) is the 1.0-style flow? If so, we should just default to that regardless of what the spec says.
Yes, but we have quite a lot of systems working with the current code, so I'd like to give them a chance to use the post-1.0 ordering (just in case).
Thanks,
Rafael
Quoted 2 lines · Rafael J. Wysocki
Yes, but we have quite a lot of systems working with the current code, so I'd like to give them a chance to use the post-1.0 ordering (just in case).
If the vast majority of systems have never been vendor-tested with the alternative ordering, then I don't see what it buys us. We've a demonstrable case here of it causing a regression.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 4 lines · Matthew Garrett
Quoted 2 lines · Rafael J. Wysocki
Yes, but we have quite a lot of systems working with the current code, so I'd like to give them a chance to use the post-1.0 ordering (just in case).
Just to clarify: I'm going to change the default to the pre-2.0 ordering and add a boot option for switching the post-1.0 ordering.
Quoted 2 lines
If the vast majority of systems have never been vendor-tested with the alternative ordering, then I don't see what it buys us.
1. Possibility to test the alternative ordering without hacking and recompiling the kernel.
2. Compatibility with future systems that will use the new odering.
Quoted 1 line
We've a demonstrable case here of it causing a regression.
Correct, but if the default is changed, I don't see a problem with leaving an option to do that.
Thanks,
Rafael
Quoted 8 lines · Rafael J. Wysocki
Quoted 4 lines · Matthew Garrett
Quoted 2 lines · Rafael J. Wysocki
Yes, but we have quite a lot of systems working with the current code, so I'd like to give them a chance to use the post-1.0 ordering (just in case).
Just to clarify: I'm going to change the default to the pre-2.0 ordering and add a boot option for switching the post-1.0 ordering.
Ah, sorry. That makes sense.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · Matthew Garrett
Quoted 2 lines · Rafael J. Wysocki
Yes, but we have quite a lot of systems working with the current code, so I'd like to give them a chance to use the post-1.0 ordering (just in case).
If the vast majority of systems have never been vendor-tested with the alternative ordering, then I don't see what it buys us. We've a demonstrable case here of it causing a regression.
I think having a runtime (or config) option will be great. As to what the default should be, I don't have a strong opinion but I must caution that a lot of people have reported issues with suspend/resume on this hardware, including some that mention running windows, so I'm worried about making a decision based only on this hardware - it looks like it's not been tested much on windows either :/
As an example of many other people complaining about suspend I can cite:
http://www.newegg.com/Product/ProductReview.aspx?Item=N82E16856110057
Signature · 1 line
Michel Lespinasse