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:	Wed, 26 Sep 2007 00:18:00 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Frans Pop <elendil@...net.nl>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Damien Wyart <damien.wyart@...e.fr>,
	Len Brown <len.brown@...el.com>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	linux-acpi@...r.kernel.org
Subject: Re: ACPI suspend/hibernate tests (was: ACPI power off regression in 2.6.23-rc8)

On Tuesday, 25 September 2007 23:44, Frans Pop wrote:
> On Tuesday 25 September 2007, Rafael J. Wysocki wrote:
> > On Tuesday, 25 September 2007 17:40, Linus Torvalds wrote:
> > > Len - why are you guys moving stuff into CONFIG_PM_SLEEP? I know you
> > > seem to think that absolutely *everybody* should always support suspend
> > > and hibernation, but the fact is, not everybody does. And it's a
> > > totally separate thing for normal ACPI CPU runstate support that people
> > > have used to manage a *running* CPU (and shutting it down).
> >
> > This was a mistake and fixes have already been posted:
> >
> > http://marc.info/?l=linux-acpi&m=119052970904643&w=4
> > http://marc.info/?l=linux-acpi&m=119073173625910&w=4
> 
> As this whole "separate suspend and hibernate" change seems to have been 
> trickier than expected, I have done some additional testing using 
> 2.6.23-rc8 plus both patches referred to above.
> 
> I compiled kernels (i386) for my laptop (Toshiba Satellite A40) with:
> A) PM + SUSPEND + HIBERNATION + ACPI
> B) PM + SUSPEND + ACPI
> C) PM + HIBERNATION + ACPI
> D) PM + ACPI
> E) PM + SUSPEND + HIBERNATION but _without_ ACPI
> F) without PM

Thanks a lot for testing this!
 
> In all cases CONFIG_APM was not set; all compiled without errors.
> 
> With all I have have booted, tried to suspend (close lid, which runs sleep 
> script, which does 'echo mem >/sys/power/state'), tried to hibernate ('echo 
> disk >/sys/power/state') and powered off (all from KDE sessions).
> 
> RESULTS
> 	boot	s2ram	s2disk	off
> A)	OK	OK	OK	OK
> B)	OK	OK	N/A	OK
> C)	OK	OK 1)	OK	OK
> D)	OK 2)	OK 1)	N/A	OK
> E)	OK 3)	N/A 4)	??? 5)	Only halted 6)
> F)	OK	N/A	N/A	Only halted 6)
> 
> Comments:
> 1) sleep script ran, but laptop stayed on
> 2) dmesg lists S0,S5 supported
>    /proc/acpi/{sleep,wakeup} do not exist (is that correct?)
> 3) /proc/acpi/{sleep,wakeup} do not exist; /sys/power/state only has 'mem'

Hm, this should be 'disk' ...

>    so SUSPEND seems missing even though compiled in

... but it so follows from this comment.  Can you clarify, please?

> 4) sleep script did not even run (as expected)
> 5) System did suspend, but power stayed on with on console:
>      Shutdown: hda \ Power down. \ Shutdown: hda \ hda: lost interrupt (2x)
>      \ psmouse.c: Failed to deactivate mouse on isa0060/serio1
>    System powered off manually and resumed correctly after that
> 6) System halted correctly, but did not power off automatically
> 
> The results for E and F are possibly correct as basically the config 
> (without ACPI) was broken for this laptop. In fact, I was somewhat 
> surprised how well it behaved without ACPI.
> 
> I suspect that whether a system powers off without ACPI or not can depend on 
> the system?
> 
> I have dmesg after boot and some other info available for all kernels if 
> anybody is interested. If any additional tests are wanted, please ask.

I think that your results reflect the code pretty well, ie. no big surprises.

On ACPI machines suspend doesn't actually work without ACPI and that's why
'mem' is missing from kernel/power/state with E).  Hibernation theoretically
works without ACPI, but the box cannot be powered off due to the lack of
support for that.

For the same reason, the system doesn't power off with E), F).

The errors from device drivers in the last phase of hibernation with E) may be
related to some confusion cause by the lack of ACPI methods expected to be
present.

Greetings,
Rafael
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ