suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Toralf Förster]

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

It is a small - but IMHO nagging - regression between these 2 kernel versions.

To make a "software suspend" at this notebook ("suspend to RAM") you have
to press <Fn>+ <F4>. Pressing the <Fn>-Key after that wakes up the notenbook.

If you hibernated the system ("suspend to disc"), you have to press the power
button to wake up the notebook.

But now there is an issue if you want to wake up this notebook, after it was
suspended with <Fn>+<F4> again. It is now not possible to wake it up with <Fn>,
instead you have to press the power button as you would have it to do after a
hibernation.

This issue occures in the current 2.6.21 kernel too.
(all tested at a stable Gentoo system - also with git-kernel-versions).

-- 
MfG/Sincerely

Toralf Förster

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

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Henrique de Moraes Holschuh]

On Sun, 05 Aug 2007, Toralf Förster wrote:
> It is a small - but IMHO nagging - regression between these 2 kernel versions.
> 
> To make a "software suspend" at this notebook ("suspend to RAM") you have
> to press <Fn>+ <F4>. Pressing the <Fn>-Key after that wakes up the notenbook.
> 
> If you hibernated the system ("suspend to disc"), you have to press the power
> button to wake up the notebook.
> 
> But now there is an issue if you want to wake up this notebook, after it was
> suspended with <Fn>+<F4> again. It is now not possible to wake it up with <Fn>,
> instead you have to press the power button as you would have it to do after a
> hibernation.
> 
> This issue occures in the current 2.6.21 kernel too.
> (all tested at a stable Gentoo system - also with git-kernel-versions).

I am at a loss of how thinkpad-acpi could in any way cause, or change, the
firmware wake-up notification behaviour.

That said, my T43 with 2.6.21 and latest-of-the-latest thinkpad-acpi wakes
up from S3 just fine by pressing the "Fn" key and holding it down for ~2s.
I didn't know it did that :-)  I always use the power button.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Pavel Machek]

Hi!

> It is a small - but IMHO nagging - regression between these 2 kernel versions.
> 
> To make a "software suspend" at this notebook ("suspend to RAM") you have
> to press <Fn>+ <F4>. Pressing the <Fn>-Key after that wakes up the notenbook.
> 

> If you hibernated the system ("suspend to disc"), you have to press the power
> button to wake up the notebook.

Yes, I seen similar reports. Does it happen in all shutdown mode and
2.6.22? Does it happen   in platform mode in 2.6.19?


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Toralf Förster]

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

Am Montag, 6. August 2007 00:29 schrieb Pavel Machek:
> Yes, I seen similar reports. Does it happen in all shutdown mode and
> 2.6.22? Does it happen   in platform mode in 2.6.19?

I can reproduce this behaviour by doing the following with kernel 2.6.20 :

1. <Fn>+<F4>   - the systems sleeps within RAM
2. <Fn>             - the systems wakes up
3. <Fn>+<F12> - the systems hibernates to disk
4. <power>       - systems wakes up
5. <Fn>+<F4>   - the systems sleeps within RAM

Now pressing <Fn> doesn't wake up the system, I have to press the power button
for that instead.

BTW I tried to test the latest git-sources -rc2 but the <Fn> keys do not work
anymore with the thinkpad-acpi feature (neither as module nor if compiled into).

-- 
MfG/Sincerely

Toralf Förster

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

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Henrique de Moraes Holschuh]

On Mon, 06 Aug 2007, Toralf Förster wrote:
> Am Montag, 6. August 2007 00:29 schrieb Pavel Machek:
> > Yes, I seen similar reports. Does it happen in all shutdown mode and
> > 2.6.22? Does it happen   in platform mode in 2.6.19?
> 
> I can reproduce this behaviour by doing the following with kernel 2.6.20 :
> 
> 1. <Fn>+<F4>   - the systems sleeps within RAM
> 2. <Fn>             - the systems wakes up
> 3. <Fn>+<F12> - the systems hibernates to disk
> 4. <power>       - systems wakes up
> 5. <Fn>+<F4>   - the systems sleeps within RAM
> 
> Now pressing <Fn> doesn't wake up the system, I have to press the power button
> for that instead.

The resume path for suspend to disk is very different (for the firmware, at
least) than the resume path from sleep-to-RAM.  One of them goes through a
system shutdown and cold boot (S5) or whatever-boot (S4 - who knows if it is
the same as a cold boot in a given thinkpad model? It doesn't have to be!).

The firmware *knows* when you press Fn+F4/FN+F12, and recalls that. That's
why you can't get multiple hot key presses from pressing Fn+F4 or FN+F12
until you actually do an ACPI wake-up.

While you are just doing S3, all that state is preserved without fuss. But
S5 does not preserve anything, and S4 is anyone's guess.  Numerous thinkpad
BIOS fixes in the past were releated to such problems, so if you are not
using the latest BIOS for your model, your first duty is to upgrade it and
try again.

IMHO, probably some ACPI state is being lost by the BIOS because of the
sleep-to-disk.  I don't know how sleep-to-disk plays with the ACPI NV areas,
and ACPI data areas from the BIOS, so I can't help much there.

And, mind you, I am *not* sure one is supposed to be able to wake up
thinkpads using Fn.  It might be in fact a bug that we can do it.  One has
to at the very least verify whether it happens in Windows as well.

However, the following events *are* to wake a thinkpad up from S3:
	1. ACPI wake devices
	2. Dock or bay eject buttons/lever being actuated
	3. Brief press on power button

You can check if (2) is still working. If both Fn and (2) stop working, we
can be sure we have a bug in Linux.  (2) is useful because it is reported
inside the ACPI firmware mostly through the same codepaths.

> BTW I tried to test the latest git-sources -rc2 but the <Fn> keys do not work
> anymore with the thinkpad-acpi feature (neither as module nor if compiled into).

Don't enable the input layer by default in thinkpad-acpi Kconfig.  A patch
to change that to default to N has already been sent to Len Brown, but it
has not been merged yet.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Rafael J. Wysocki]

On Monday, 6 August 2007 16:36, Henrique de Moraes Holschuh wrote:
> On Mon, 06 Aug 2007, Toralf Förster wrote:
> > Am Montag, 6. August 2007 00:29 schrieb Pavel Machek:
> > > Yes, I seen similar reports. Does it happen in all shutdown mode and
> > > 2.6.22? Does it happen   in platform mode in 2.6.19?
> > 
> > I can reproduce this behaviour by doing the following with kernel 2.6.20 :
> > 
> > 1. <Fn>+<F4>   - the systems sleeps within RAM
> > 2. <Fn>             - the systems wakes up
> > 3. <Fn>+<F12> - the systems hibernates to disk
> > 4. <power>       - systems wakes up
> > 5. <Fn>+<F4>   - the systems sleeps within RAM
> > 
> > Now pressing <Fn> doesn't wake up the system, I have to press the power button
> > for that instead.
> 
> The resume path for suspend to disk is very different (for the firmware, at
> least) than the resume path from sleep-to-RAM.  One of them goes through a
> system shutdown and cold boot (S5) or whatever-boot (S4 - who knows if it is
> the same as a cold boot in a given thinkpad model? It doesn't have to be!).
> 
> The firmware *knows* when you press Fn+F4/FN+F12, and recalls that. That's
> why you can't get multiple hot key presses from pressing Fn+F4 or FN+F12
> until you actually do an ACPI wake-up.
> 
> While you are just doing S3, all that state is preserved without fuss. But
> S5 does not preserve anything, and S4 is anyone's guess.  Numerous thinkpad
> BIOS fixes in the past were releated to such problems, so if you are not
> using the latest BIOS for your model, your first duty is to upgrade it and
> try again.
> 
> IMHO, probably some ACPI state is being lost by the BIOS because of the
> sleep-to-disk.  I don't know how sleep-to-disk plays with the ACPI NV areas,
> and ACPI data areas from the BIOS, so I can't help much there.

We have the problem that ACPI is already initialized by the boot kernel before
the hibernation image is loaded, so there's a chance that the saved state
information will be lost.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Henrique de Moraes Holschuh]

On Mon, 06 Aug 2007, Rafael J. Wysocki wrote:
> On Monday, 6 August 2007 16:36, Henrique de Moraes Holschuh wrote:
> > On Mon, 06 Aug 2007, Toralf Förster wrote:
> > > Am Montag, 6. August 2007 00:29 schrieb Pavel Machek:
> > > > Yes, I seen similar reports. Does it happen in all shutdown mode and
> > > > 2.6.22? Does it happen   in platform mode in 2.6.19?
> > > 
> > > I can reproduce this behaviour by doing the following with kernel 2.6.20 :
> > > 
> > > 1. <Fn>+<F4>   - the systems sleeps within RAM
> > > 2. <Fn>             - the systems wakes up
> > > 3. <Fn>+<F12> - the systems hibernates to disk
> > > 4. <power>       - systems wakes up
> > > 5. <Fn>+<F4>   - the systems sleeps within RAM
> > > 
> > > Now pressing <Fn> doesn't wake up the system, I have to press the power button
> > > for that instead.
> > 
> > The resume path for suspend to disk is very different (for the firmware, at
> > least) than the resume path from sleep-to-RAM.  One of them goes through a
> > system shutdown and cold boot (S5) or whatever-boot (S4 - who knows if it is
> > the same as a cold boot in a given thinkpad model? It doesn't have to be!).
> > 
> > The firmware *knows* when you press Fn+F4/FN+F12, and recalls that. That's
> > why you can't get multiple hot key presses from pressing Fn+F4 or FN+F12
> > until you actually do an ACPI wake-up.
> > 
> > While you are just doing S3, all that state is preserved without fuss. But
> > S5 does not preserve anything, and S4 is anyone's guess.  Numerous thinkpad
> > BIOS fixes in the past were releated to such problems, so if you are not
> > using the latest BIOS for your model, your first duty is to upgrade it and
> > try again.
> > 
> > IMHO, probably some ACPI state is being lost by the BIOS because of the
> > sleep-to-disk.  I don't know how sleep-to-disk plays with the ACPI NV areas,
> > and ACPI data areas from the BIOS, so I can't help much there.
> 
> We have the problem that ACPI is already initialized by the boot kernel before
> the hibernation image is loaded, so there's a chance that the saved state
> information will be lost.

Yeah.  Big bad design issue right there.  And not one that is even remotely
easy to "fix", AFAIK.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Toralf Förster]

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

Am Montag, 6. August 2007 16:36 schrieb Henrique de Moraes Holschuh:
> On Mon, 06 Aug 2007, Toralf Förster wrote:
> > Am Montag, 6. August 2007 00:29 schrieb Pavel Machek:
> > > Yes, I seen similar reports. Does it happen in all shutdown mode and
> > > 2.6.22? Does it happen   in platform mode in 2.6.19?
> > 
> > I can reproduce this behaviour by doing the following with kernel 2.6.20 :
> > 
> > 1. <Fn>+<F4>   - the systems sleeps within RAM
> > 2. <Fn>             - the systems wakes up
> > 3. <Fn>+<F12> - the systems hibernates to disk
> > 4. <power>       - systems wakes up
> > 5. <Fn>+<F4>   - the systems sleeps within RAM
> > 
> > Now pressing <Fn> doesn't wake up the system, I have to press the power button
> > for that instead.
> 
> The resume path for suspend to disk is very different (for the firmware, at
> least) than the resume path from sleep-to-RAM.  One of them goes through a
> system shutdown and cold boot (S5) or whatever-boot (S4 - who knows if it is
> the same as a cold boot in a given thinkpad model? It doesn't have to be!).
> 
> The firmware *knows* when you press Fn+F4/FN+F12, and recalls that. That's
> why you can't get multiple hot key presses from pressing Fn+F4 or FN+F12
> until you actually do an ACPI wake-up.
> 
> While you are just doing S3, all that state is preserved without fuss. But
> S5 does not preserve anything, and S4 is anyone's guess.  Numerous thinkpad
> BIOS fixes in the past were releated to such problems, so if you are not
> using the latest BIOS for your model, your first duty is to upgrade it and
> try again.
> 
> IMHO, probably some ACPI state is being lost by the BIOS because of the
> sleep-to-disk.  I don't know how sleep-to-disk plays with the ACPI NV areas,
> and ACPI data areas from the BIOS, so I can't help much there.
> 
> And, mind you, I am *not* sure one is supposed to be able to wake up
> thinkpads using Fn.  It might be in fact a bug that we can do it.  One has
> to at the very least verify whether it happens in Windows as well.
> 
> However, the following events *are* to wake a thinkpad up from S3:
> 	1. ACPI wake devices
> 	2. Dock or bay eject buttons/lever being actuated
> 	3. Brief press on power button
> 
> You can check if (2) is still working. If both Fn and (2) stop working, we
> can be sure we have a bug in Linux.  (2) is useful because it is reported
> inside the ACPI firmware mostly through the same codepaths.
> 
> > BTW I tried to test the latest git-sources -rc2 but the <Fn> keys do not work
> > anymore with the thinkpad-acpi feature (neither as module nor if compiled into).
> 
> Don't enable the input layer by default in thinkpad-acpi Kconfig.  A patch
> to change that to default to N has already been sent to Len Brown, but it
> has not been merged yet.
> 

Because I
(1) use the latest BIOS and
(2) I'm able to wake up a suspended system via <Fn> under Windows XP (yes, dual
    boot system I need it at work) regardless whether I previously hibernated
    the system (under Windows XP) or not

I bisected this regression (rather of a feature than a bug, or ?) between
the 2 tags v2.6.19 and v2.6.20 (~2400 commits, I read a good book in the
meanwhile) and found :

last good commit : 7e244322cd4ea361ef9ee623b3fcb4d9f4ff841c
first bad commit: cfee47f99bc14a6d7c6b0be2284db2cef310a815

I double checked these 2 commits - here's the first commit after which <Fn>
doesn't wake up my system from suspend state after it was (at least one time
before) hibernated:

commit cfee47f99bc14a6d7c6b0be2284db2cef310a815
Merge: 7e24432... 9185cfa...
Author: Len Brown <len.brown@intel.com>
Date:   Sat Dec 16 01:01:18 2006 -0500

    Pull bugfix into test branch

    Conflicts:

        kernel/power/disk.c


-- 
MfG/Sincerely

Toralf Förster

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

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Henrique de Moraes Holschuh]

On Mon, 06 Aug 2007, Toralf Förster wrote:
> Because I
> (1) use the latest BIOS and
> (2) I'm able to wake up a suspended system via <Fn> under Windows XP (yes, dual
>     boot system I need it at work) regardless whether I previously hibernated
>     the system (under Windows XP) or not
> 
> I bisected this regression (rather of a feature than a bug, or ?) between
> the 2 tags v2.6.19 and v2.6.20 (~2400 commits, I read a good book in the
> meanwhile) and found :
> 
> last good commit : 7e244322cd4ea361ef9ee623b3fcb4d9f4ff841c
> first bad commit: cfee47f99bc14a6d7c6b0be2284db2cef310a815
> 
> I double checked these 2 commits - here's the first commit after which <Fn>
> doesn't wake up my system from suspend state after it was (at least one time
> before) hibernated:
> 
> commit cfee47f99bc14a6d7c6b0be2284db2cef310a815
> Merge: 7e24432... 9185cfa...
> Author: Len Brown <len.brown@intel.com>
> Date:   Sat Dec 16 01:01:18 2006 -0500
> 
>     Pull bugfix into test branch
> 
>     Conflicts:
> 
>         kernel/power/disk.c

There is a *very* interesting patch that was merged by the above commit (git
log 9185cfa ^7e24432 shows them):

9185cfa92507d07ac787bc73d06c42222eec7239 ACPI: S4: Use "platform" rather
than "shutdown" mode by default

So, please configure the kernel/s2ram/whatever you use to suspend-to-disk to
use "shutdown" as the default mode for suspend-to-disk, and check if that
doesn't solve things.

You might want to also try platform mode, but with commit
9185cfa92507d07ac787bc73d06c42222eec7239 reverted, since it does change
slightly the platform suspend code path (not in any way I think it should
matter, but hey, since I am not sure, I might as well say it).

This might not be the *root* of the problem even if it fixes your
regression, S4 *is* supposed to be the right way to suspend-to-disk, even on
some weird thinkpads.  Is there any way to find out what S-mode Windows use
to suspend-to-disk?  

Anyway, root-cause or not, it will be a damn good hint of what is really
wrong if switching to S5 for sleep-to-disk fixes the issue (if it is not
broken firmware).  And one can always document this in thinkwiki.org and
some other places, and add all thinkpads with your BIOS type (blacklist all
thinkpads with BIOS 1RET*) to a blacklist in s2ram/whatever.

Note that this should affect a HUGE number of thinkpads, at the very least
all of ThinkPad R50/p, R51 (1829, 1830, 1831, 1836), T40/p, T41/p, and T42/p
(all have BIOS 1RET*), which should cover a massive chunk of the thinkpads
currently running Linux.  Apparently, it is not very common for Linux
thinkpad users to wake it up using something other than the lid switch and
power button :-)

BTW, BIOS 1R was updated about one month ago, to 1RETDRWW (3.23).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Toralf Förster]

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

Am Dienstag, 7. August 2007 02:21 schrieb Henrique de Moraes Holschuh:
> On Mon, 06 Aug 2007, Toralf Förster wrote:
> > Because I
> > (1) use the latest BIOS and
> > (2) I'm able to wake up a suspended system via <Fn> under Windows XP (yes, dual
> >     boot system I need it at work) regardless whether I previously hibernated
> >     the system (under Windows XP) or not
> > 
> > I bisected this regression (rather of a feature than a bug, or ?) between
> > the 2 tags v2.6.19 and v2.6.20 (~2400 commits, I read a good book in the
> > meanwhile) and found :
> > 
> > last good commit : 7e244322cd4ea361ef9ee623b3fcb4d9f4ff841c
> > first bad commit: cfee47f99bc14a6d7c6b0be2284db2cef310a815
> > 
> > I double checked these 2 commits - here's the first commit after which <Fn>
> > doesn't wake up my system from suspend state after it was (at least one time
> > before) hibernated:
> > 
> > commit cfee47f99bc14a6d7c6b0be2284db2cef310a815
> > Merge: 7e24432... 9185cfa...
> > Author: Len Brown <len.brown@intel.com>
> > Date:   Sat Dec 16 01:01:18 2006 -0500
> > 
> >     Pull bugfix into test branch
> > 
> >     Conflicts:
> > 
> >         kernel/power/disk.c
> 
> There is a *very* interesting patch that was merged by the above commit (git
> log 9185cfa ^7e24432 shows them):
> 
> 9185cfa92507d07ac787bc73d06c42222eec7239 ACPI: S4: Use "platform" rather
> than "shutdown" mode by default
> 
> So, please configure the kernel/s2ram/whatever you use to suspend-to-disk to
> use "shutdown" as the default mode for suspend-to-disk, and check if that
> doesn't solve things.
> 
> You might want to also try platform mode, but with commit
> 9185cfa92507d07ac787bc73d06c42222eec7239 reverted, since it does change
> slightly the platform suspend code path (not in any way I think it should
> matter, but hey, since I am not sure, I might as well say it).
> 
> This might not be the *root* of the problem even if it fixes your
> regression, S4 *is* supposed to be the right way to suspend-to-disk, even on
> some weird thinkpads.  Is there any way to find out what S-mode Windows use
> to suspend-to-disk?  
> 
> Anyway, root-cause or not, it will be a damn good hint of what is really
> wrong if switching to S5 for sleep-to-disk fixes the issue (if it is not
> broken firmware).  And one can always document this in thinkwiki.org and
> some other places, and add all thinkpads with your BIOS type (blacklist all
> thinkpads with BIOS 1RET*) to a blacklist in s2ram/whatever.
> 
> Note that this should affect a HUGE number of thinkpads, at the very least
> all of ThinkPad R50/p, R51 (1829, 1830, 1831, 1836), T40/p, T41/p, and T42/p
> (all have BIOS 1RET*), which should cover a massive chunk of the thinkpads
> currently running Linux.  Apparently, it is not very common for Linux
> thinkpad users to wake it up using something other than the lid switch and
> power button :-)
> 
> BTW, BIOS 1R was updated about one month ago, to 1RETDRWW (3.23).
> 

I went to the first bad commit and applied the following patch manually:

diff --git a/kernel/power/main.c b/kernel/power/main.c
index ff3a618..500eb87 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -29,7 +29,7 @@
 DEFINE_MUTEX(pm_mutex);

 struct pm_ops *pm_ops;
-suspend_disk_method_t pm_disk_mode = PM_DISK_PLATFORM;
+suspend_disk_method_t pm_disk_mode = PM_DISK_SHUTDOWN;

 /**
  *     pm_set_ops - Set the global power method table.


After that the regression was solved - I was able to wake a suspended system
with <Fn> althought it was hibernated (and waked up) before.

I use the latest installed BIOS (currently 3.23/3.04) from the ThinkWiki.

Hope this helps you to track down the root cause :-)

> So, please configure the kernel/s2ram/whatever you use to suspend-to-disk to
> use "shutdown" as the default mode for suspend-to-disk, and check if that
> doesn't solve things.
I use "echo -n mem > /sys/power/state" resp.and "echo -n disk > /sys/power/state"
within the script /etc/acpi/default.sh.

-- 
MfG/Sincerely

Toralf Förster

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

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Rafael J. Wysocki]

On Tuesday, 7 August 2007 15:21, Toralf Förster wrote:
> Am Dienstag, 7. August 2007 02:21 schrieb Henrique de Moraes Holschuh:
> > On Mon, 06 Aug 2007, Toralf Förster wrote:
> > > Because I
> > > (1) use the latest BIOS and
> > > (2) I'm able to wake up a suspended system via <Fn> under Windows XP (yes, dual
> > >     boot system I need it at work) regardless whether I previously hibernated
> > >     the system (under Windows XP) or not
> > > 
> > > I bisected this regression (rather of a feature than a bug, or ?) between
> > > the 2 tags v2.6.19 and v2.6.20 (~2400 commits, I read a good book in the
> > > meanwhile) and found :
> > > 
> > > last good commit : 7e244322cd4ea361ef9ee623b3fcb4d9f4ff841c
> > > first bad commit: cfee47f99bc14a6d7c6b0be2284db2cef310a815
> > > 
> > > I double checked these 2 commits - here's the first commit after which <Fn>
> > > doesn't wake up my system from suspend state after it was (at least one time
> > > before) hibernated:
> > > 
> > > commit cfee47f99bc14a6d7c6b0be2284db2cef310a815
> > > Merge: 7e24432... 9185cfa...
> > > Author: Len Brown <len.brown@intel.com>
> > > Date:   Sat Dec 16 01:01:18 2006 -0500
> > > 
> > >     Pull bugfix into test branch
> > > 
> > >     Conflicts:
> > > 
> > >         kernel/power/disk.c
> > 
> > There is a *very* interesting patch that was merged by the above commit (git
> > log 9185cfa ^7e24432 shows them):
> > 
> > 9185cfa92507d07ac787bc73d06c42222eec7239 ACPI: S4: Use "platform" rather
> > than "shutdown" mode by default
> > 
> > So, please configure the kernel/s2ram/whatever you use to suspend-to-disk to
> > use "shutdown" as the default mode for suspend-to-disk, and check if that
> > doesn't solve things.
> > 
> > You might want to also try platform mode, but with commit
> > 9185cfa92507d07ac787bc73d06c42222eec7239 reverted, since it does change
> > slightly the platform suspend code path (not in any way I think it should
> > matter, but hey, since I am not sure, I might as well say it).
> > 
> > This might not be the *root* of the problem even if it fixes your
> > regression, S4 *is* supposed to be the right way to suspend-to-disk, even on
> > some weird thinkpads.  Is there any way to find out what S-mode Windows use
> > to suspend-to-disk?  
> > 
> > Anyway, root-cause or not, it will be a damn good hint of what is really
> > wrong if switching to S5 for sleep-to-disk fixes the issue (if it is not
> > broken firmware).  And one can always document this in thinkwiki.org and
> > some other places, and add all thinkpads with your BIOS type (blacklist all
> > thinkpads with BIOS 1RET*) to a blacklist in s2ram/whatever.
> > 
> > Note that this should affect a HUGE number of thinkpads, at the very least
> > all of ThinkPad R50/p, R51 (1829, 1830, 1831, 1836), T40/p, T41/p, and T42/p
> > (all have BIOS 1RET*), which should cover a massive chunk of the thinkpads
> > currently running Linux.  Apparently, it is not very common for Linux
> > thinkpad users to wake it up using something other than the lid switch and
> > power button :-)
> > 
> > BTW, BIOS 1R was updated about one month ago, to 1RETDRWW (3.23).
> > 
> 
> I went to the first bad commit and applied the following patch manually:
> 
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index ff3a618..500eb87 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -29,7 +29,7 @@
>  DEFINE_MUTEX(pm_mutex);
> 
>  struct pm_ops *pm_ops;
> -suspend_disk_method_t pm_disk_mode = PM_DISK_PLATFORM;
> +suspend_disk_method_t pm_disk_mode = PM_DISK_SHUTDOWN;
> 
>  /**
>   *     pm_set_ops - Set the global power method table.
> 
> 
> After that the regression was solved - I was able to wake a suspended system
> with <Fn> althought it was hibernated (and waked up) before.

Actually, you don't need the patch above, just do
"echo shutdown > /sys/power/disk" before the hibernation (or use
"shutdown method = shutdown" configuration option if you use s2disk).

BTW, can you please try this patch before you do that:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/19-ACPI-Enable-GPEs-before-_WAK-is-called.patch

> I use the latest installed BIOS (currently 3.23/3.04) from the ThinkWiki.
> 
> Hope this helps you to track down the root cause :-)

Not really ...

> > So, please configure the kernel/s2ram/whatever you use to suspend-to-disk to
> > use "shutdown" as the default mode for suspend-to-disk, and check if that
> > doesn't solve things.
> I use "echo -n mem > /sys/power/state" resp.and "echo -n disk > /sys/power/state"
> within the script /etc/acpi/default.sh.

So place "echo shutdown > /sys/power/disk" before that into your script.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Toralf Förster]

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

Am Dienstag, 7. August 2007 17:38 schrieb Rafael J. Wysocki:

> Actually, you don't need the patch above, just do
> "echo shutdown > /sys/power/disk" before the hibernation (or use
> BTW, can you please try this patch before you do that:
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/19-ACPI-Enable-GPEs-before-_WAK-is-called.patch

This patch applied at commit cfee47f doesn't solve the regression.

> 
> So place "echo shutdown > /sys/power/disk" before that into your script.
yep, that works for me.

-- 
MfG/Sincerely

Toralf Förster

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

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Henrique de Moraes Holschuh]

On Wed, 08 Aug 2007, Toralf Förster wrote:
> Am Dienstag, 7. August 2007 17:38 schrieb Rafael J. Wysocki:
> > Actually, you don't need the patch above, just do
> > "echo shutdown > /sys/power/disk" before the hibernation (or use
> > BTW, can you please try this patch before you do that:
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/19-ACPI-Enable-GPEs-before-_WAK-is-called.patch
> 
> This patch applied at commit cfee47f doesn't solve the regression.
> 
> > 
> > So place "echo shutdown > /sys/power/disk" before that into your script.
> yep, that works for me.

FYI, some other thinkpad models break badly if you use shutdown instead of
platform.  Sound goes away on wake, etc.

I am still very suspicious that the way we do wake-from-suspend-to-disk is
to blame... I wish we loaded the kernel just once, maybe from the boot
loader.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Rafael J. Wysocki]

On Wednesday, 8 August 2007 14:04, Henrique de Moraes Holschuh wrote:
> On Wed, 08 Aug 2007, Toralf Förster wrote:
> > Am Dienstag, 7. August 2007 17:38 schrieb Rafael J. Wysocki:
> > > Actually, you don't need the patch above, just do
> > > "echo shutdown > /sys/power/disk" before the hibernation (or use
> > > BTW, can you please try this patch before you do that:
> > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/19-ACPI-Enable-GPEs-before-_WAK-is-called.patch
> > 
> > This patch applied at commit cfee47f doesn't solve the regression.
> > 
> > > 
> > > So place "echo shutdown > /sys/power/disk" before that into your script.
> > yep, that works for me.
> 
> FYI, some other thinkpad models break badly if you use shutdown instead of
> platform.  Sound goes away on wake, etc.
> 
> I am still very suspicious that the way we do wake-from-suspend-to-disk is
> to blame... 

Yes, that's one possible reason.

We also don't enter S4 in the right way, AFAICS, but the infrastructure
allowing us to change that is only in -mm.  Anyway, here's the patch to fix
that (it's on top of some other patches, but the link to them is given in the
message): http://lkml.org/lkml/2007/8/7/316

> I wish we loaded the kernel just once, maybe from the boot loader.

Well, that's not so easy.  That will work for the bare image, but if we want it
to be compressed and/or encrypted, then the boot loader will need to
contain all of the necessary code.

I may be doable by using a special boot kernel with ACPI disabled and only
as many drivers as required to load the image, but that will make it more
difficult to set up and to recover from errors.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Henrique de Moraes Holschuh]

On Wed, 08 Aug 2007, Rafael J. Wysocki wrote:
> > I wish we loaded the kernel just once, maybe from the boot loader.
> 
> Well, that's not so easy.  That will work for the bare image, but if we want it
> to be compressed and/or encrypted, then the boot loader will need to
> contain all of the necessary code.

Doing things right always have an associated cost, or we'd be doing it right
since day one...

> I may be doable by using a special boot kernel with ACPI disabled and only
> as many drivers as required to load the image, but that will make it more
> difficult to set up and to recover from errors.

Better than the walking bomb we have now.  When waking from suspend-to-disk,
we should not overwrite ANY non-kernel data which has ties to external
systems (the hardware, the firmware).  Instead, we should re-init everything
(re-init hardware to make sure we know in which state it is, re-init
ourselves, to make sure we match the firmware and hardware state), as if we
were booting a cold system in the first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] suspend/hibernation regression between 2.6.19 and 2.6.20 w/ Thinkpad T41

[Rafael J. Wysocki]

On Wednesday, 8 August 2007 16:48, Henrique de Moraes Holschuh wrote:
> On Wed, 08 Aug 2007, Rafael J. Wysocki wrote:
> > > I wish we loaded the kernel just once, maybe from the boot loader.
> > 
> > Well, that's not so easy.  That will work for the bare image, but if we want it
> > to be compressed and/or encrypted, then the boot loader will need to
> > contain all of the necessary code.
> 
> Doing things right always have an associated cost, or we'd be doing it right
> since day one...
> 
> > I may be doable by using a special boot kernel with ACPI disabled and only
> > as many drivers as required to load the image, but that will make it more
> > difficult to set up and to recover from errors.
> 
> Better than the walking bomb we have now.  When waking from suspend-to-disk,
> we should not overwrite ANY non-kernel data which has ties to external
> systems (the hardware, the firmware).  Instead, we should re-init everything
> (re-init hardware to make sure we know in which state it is, re-init
> ourselves, to make sure we match the firmware and hardware state), as if we
> were booting a cold system in the first place.

Yes, we've already had an agreement about that on linux-pm, now the problem is
to implement it and not to break things in the process ...


-- 
"Premature optimization is the root of all evil." - Donald Knuth