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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Aug 2007 11:36:31 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Toralf Förster <toralf.foerster@....de>
Cc:	Pavel Machek <pavel@....cz>, ibm-acpi-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: suspend/hibernation regression between 2.6.19 and 2.6.20 w/
	Thinkpad T41

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/