Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
On Sat, Jul 14, 2007 at 11:08:30AM +0200, martin f krafft wrote: also sprach Andrew Pimlott [EMAIL PROTECTED] [2007.07.13.2224 +0200]: One solution would be for hibernate to recognize the 0x20 exit status from s2ram -n. There could be an option USuspendRamUnsureOk yes that tells hibernate to proceed in this case, and not pass -f to s2ram. Just an idea, maybe you know a better way. Good idea. I've implemented this; does the following patch work for you? Not quite--the unsure check should be in EnsureUSuspendCapable, since -n mode is the only place where s2ram exits with a non-zero status for unsure systems. Here is an alternative, that I've quickly tested, but be warned that I don't do much shell scripting. Andrew --- ususpend.bak2007-07-16 21:09:42.0 -0700 +++ ususpend2007-07-16 23:03:21.0 -0700 @@ -6,6 +6,7 @@ AddConfigHelp USuspendMethod disk|ram|both Enables use of the uswsusp suspend method of newer kernels (= 2.6.17rc1) AddConfigHelp USuspendRamForce boolean Passes the -f flag to s2ram to force suspending even if the machine is not recognised +AddConfigHelp USuspendRamUnsureOk boolean Instructs s2ram to continue when it's unsure about the system type, thus not requiring -f to be passed AddConfigHelp USuspendRamVbeSave boolean Passes the -s flag to s2ram to save VBE state before suspending and restore after resume AddConfigHelp USuspendRamVbePost boolean Passes the -p flag to s2ram to VBE POST the graphics card after resume AddConfigHelp USuspendRamVbeMode boolean Passes the -m flag to s2ram to get VBE mode before suspend and set it after resume @@ -18,6 +19,7 @@ USUSPEND_DEVICE=/dev/snapshot USUSPEND_PROG=s2disk USUSPEND_RAM_FORCE=0 +USUSPEND_RAM_UNSUREOK=0 USUSPEND_RAM_VBESAVE=0 USUSPEND_RAM_VBEPOST=0 USUSPEND_RAM_VBEMODE=0 @@ -49,6 +51,9 @@ ususpendramforce) BoolIsOn $1 $2 USUSPEND_RAM_FORCE=1 || return 0 ;; + ususpendramunsureok) + BoolIsOn $1 $2 USUSPEND_RAM_UNSUREOK=1 || return 0 + ;; ususpendramvbesave) BoolIsOn $1 $2 USUSPEND_RAM_VBESAVE=1 || return 0 ;; @@ -110,10 +115,21 @@ vecho 0 $USUSPEND_PROG not installed. return 2 fi -if [ $USUSPEND_PROG = s2ram ] [ $USUSPEND_RAM_FORCE -eq 0 ] \ -! $USUSPEND_PROG -n /dev/null; then - vecho 0 $USUSPEND_PROG: unknown machine, see s2ram(8) and the USuspendRamForce option - return 2 +if [ $USUSPEND_PROG = s2ram ] [ $USUSPEND_RAM_FORCE -eq 0 ]; then + $USUSPEND_PROG -n /dev/null + ret=$? + case $ret/$USUSPEND_RAM_UNSUREOK in + 0/*) :;; + 32/1) :;; # unsure, but USuspendRamUnsureOk passed + 32/*) + vecho 0 $USUSPEND_PROG: unsure about your machine, see the USuspendRamUnsureOk option + return 2 + ;; + *) + vecho 0 $USUSPEND_PROG: unknown machine, see s2ram(8) and the USuspendRamForce option + return 2 + ;; + esac fi if ! test -f $USUSPEND_STATE_FILE ; then vecho 0 Your kernel does not have power management built in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
Please try the following patch against the original ususpend scriptlet (the one provided by the package): Index: scriptlets.d/ususpend === --- scriptlets.d/ususpend (revision 1133) +++ scriptlets.d/ususpend (working copy) @@ -6,6 +6,7 @@ AddConfigHelp USuspendMethod disk|ram|both Enables use of the uswsusp suspend method of newer kernels (= 2.6.17rc1) AddConfigHelp USuspendRamForce boolean Passes the -f flag to s2ram to force suspending even if the machine is not recognised +AddConfigHelp USuspendRamUnsureOk boolean Instructs s2ram to continue when it's unsure about the system type, thus not requiring -f to be passed AddConfigHelp USuspendRamVbeSave boolean Passes the -s flag to s2ram to save VBE state before suspending and restore after resume AddConfigHelp USuspendRamVbePost boolean Passes the -p flag to s2ram to VBE POST the graphics card after resume AddConfigHelp USuspendRamVbeMode boolean Passes the -m flag to s2ram to get VBE mode before suspend and set it after resume @@ -18,6 +19,7 @@ USUSPEND_DEVICE=/dev/snapshot USUSPEND_PROG=s2disk USUSPEND_RAM_FORCE=0 +USUSPEND_RAM_UNSUREOK=0 USUSPEND_RAM_VBESAVE=0 USUSPEND_RAM_VBEPOST=0 USUSPEND_RAM_VBEMODE=0 @@ -49,6 +51,9 @@ ususpendramforce) BoolIsOn $1 $2 USUSPEND_RAM_FORCE=1 || return 0 ;; + ususpendramunsureok) + BoolIsOn $1 $2 USUSPEND_RAM_UNSUREOK=1 || return 0 + ;; ususpendramvbesave) BoolIsOn $1 $2 USUSPEND_RAM_VBESAVE=1 || return 0 ;; @@ -110,10 +115,21 @@ vecho 0 $USUSPEND_PROG not installed. return 2 fi -if [ $USUSPEND_PROG = s2ram ] [ $USUSPEND_RAM_FORCE -eq 0 ] \ -! $USUSPEND_PROG -n /dev/null; then - vecho 0 $USUSPEND_PROG: unknown machine, see s2ram(8) and the USuspendRamForce option - return 2 +if [ $USUSPEND_PROG = s2ram ] [ $USUSPEND_RAM_FORCE -eq 0 ]; then + USUSPEND_PROG -n /dev/null + ret=$? + case $ret/$USUSPEND_RAM_UNSUREOK in + 0/*) :;; + 32/1) :;; # unsure, but USuspendRamUnsureOk passed + 32/*) + vecho 0 $USUSPEND_PROG: unsure about your machine, see the USuspendRamUnsureOk option + return 2 + ;; + *) + vecho 0 $USUSPEND_PROG: unknown machine, see s2ram(8) and the USuspendRamForce option + return 2 + ;; + esac fi if ! test -f $USUSPEND_STATE_FILE ; then vecho 0 Your kernel does not have power management built in. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
On Tue, Jul 17, 2007 at 12:13:25PM +0200, martin f krafft wrote: Please try the following patch against the original ususpend scriptlet (the one provided by the package): [snip] + USUSPEND_PROG -n /dev/null You left off a $ here. :-) Other than that, it works fine. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
tags 433028 pending fixed-upstream thanks also sprach Andrew Pimlott [EMAIL PROTECTED] [2007.07.17.1918 +0200]: You left off a $ here. :-) Other than that, it works fine. Great. Will be in the next upload. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
tags tags 433028 patch
thanks
also sprach Andrew Pimlott [EMAIL PROTECTED] [2007.07.13.2224 +0200]:
One solution would be for hibernate to recognize the 0x20 exit status
from s2ram -n. There could be an option USuspendRamUnsureOk yes
that tells hibernate to proceed in this case, and not pass -f to s2ram.
Just an idea, maybe you know a better way.
Good idea. I've implemented this; does the following patch work for
you?
Index: /home/madduck/debian/pkg/hibernate/upstream.trunk/scriptlets.d/ususpend
===
--- /home/madduck/debian/pkg/hibernate/upstream.trunk/scriptlets.d/ususpend
(revision 1133)
+++ /home/madduck/debian/pkg/hibernate/upstream.trunk/scriptlets.d/ususpend
(working copy)
@@ -6,6 +6,7 @@
AddConfigHelp USuspendMethod disk|ram|both Enables use of the uswsusp
suspend method of newer kernels (= 2.6.17rc1)
AddConfigHelp USuspendRamForce boolean Passes the -f flag to s2ram to
force suspending even if the machine is not recognised
+AddConfigHelp USuspendRamUnsureOk boolean Instructs s2ram to continue
when it's unsure about the system type, thus not requiring -f to be passed
AddConfigHelp USuspendRamVbeSave boolean Passes the -s flag to s2ram to
save VBE state before suspending and restore after resume
AddConfigHelp USuspendRamVbePost boolean Passes the -p flag to s2ram to
VBE POST the graphics card after resume
AddConfigHelp USuspendRamVbeMode boolean Passes the -m flag to s2ram to
get VBE mode before suspend and set it after resume
@@ -18,6 +19,7 @@
USUSPEND_DEVICE=/dev/snapshot
USUSPEND_PROG=s2disk
USUSPEND_RAM_FORCE=0
+USUSPEND_RAM_UNSUREOK=0
USUSPEND_RAM_VBESAVE=0
USUSPEND_RAM_VBEPOST=0
USUSPEND_RAM_VBEMODE=0
@@ -49,6 +51,9 @@
ususpendramforce)
BoolIsOn $1 $2 USUSPEND_RAM_FORCE=1 || return 0
;;
+ ususpendramunsureok)
+ BoolIsOn $1 $2 USUSPEND_RAM_UNSUREOK=1 || return 0
+ ;;
ususpendramvbesave)
BoolIsOn $1 $2 USUSPEND_RAM_VBESAVE=1 || return 0
;;
@@ -96,9 +101,16 @@
[ $USUSPEND_RAM_VBEMODE -eq 1 ] ARGS=$ARGS -m
[ $USUSPEND_RAM_ACPISLEEP -ne 0 ] ARGS=$ARGS -a
$USUSPEND_RAM_ACPISLEEP
fi
- vecho 1 $EXE: Running $USUSPEND_PROG_PATH $ARGS ${FORCE:+$FORCE }...
- $USUSPEND_PROG_PATH $ARGS 21 | vcat 2 \
- || vecho 0 $EXE: $USUSPEND_PROG_PATH failed.
+ vecho 1 $EXE: Running $USUSPEND_PROG_PATH $ARGS...
+ $USUSPEND_PROG_PATH $ARGS 21 | vcat 2
+ ret=$?
+ case $ret/$USUSPEND_RAM_UNSUREOK in
+ 0/*) :;;
+ 32/1) :;; # unsure, but USuspendRamUnsureOk passed
+ *)
+ vecho 0 $EXE: $USUSPEND_PROG_PATH failed (return code $ret).
+ ;;
+ esac
else
vecho 1 $EXE: Not actually suspending (--no-suspend given).
fi
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
Bug#433028: hibernate shouldn't need s2ram -f on UNSURE systems
Package: hibernate Version: 1.96~pre-svn.r1136-1 Severity: normal I am using hibernate with the ususpend-ram configuration. When I run s2ram -n, it comes back with ATTENTION: Your machine is in the whitelist but the entry has not been confirmed. and the program exits with status 0x20 (UNSURE in s2ram-x86.c). As a result, hibernate refuses to continue unless I set USuspendRamForce yes. The problem with this is, when you use s2ram -f, s2ram does not consult its whitelist at all, so it doesn't use the settings for my system. (Even though they're UNSURE, they're probably better than nothing.) One solution would be for hibernate to recognize the 0x20 exit status from s2ram -n. There could be an option USuspendRamUnsureOk yes that tells hibernate to proceed in this case, and not pass -f to s2ram. Just an idea, maybe you know a better way. Andrew -- Package-specific info: --- configuration == /etc/hibernate/common.conf == Verbosity 0 LogFile /var/log/hibernate.log LogVerbosity 1 Distribution debian SaveClock restore-only UnloadBlacklistedModules yes LoadModules auto SwitchToTextMode yes == /etc/hibernate/disk.conf == TryMethod ususpend-disk.conf TryMethod sysfs-disk.conf == /etc/hibernate/hibernate.conf == TryMethod suspend2.conf TryMethod disk.conf TryMethod ram.conf == /etc/hibernate/ram.conf == TryMethod ususpend-ram.conf TryMethod sysfs-ram.conf == /etc/hibernate/suspend2.conf == UseSuspend2 yes Reboot no EnableEscape yes DefaultConsoleLevel 1 Compressor lzf Encryptor none FullSpeedCPU yes Include common.conf == /etc/hibernate/sysfs-disk.conf == UseSysfsPowerState disk Include common.conf == /etc/hibernate/sysfs-ram.conf == UseSysfsPowerState mem Include common.conf == /etc/hibernate/ususpend-both.conf == USuspendMethod both Include common.conf == /etc/hibernate/ususpend-disk.conf == USuspendMethod disk Include common.conf == /etc/hibernate/ususpend-ram.conf == USuspendMethod ram Include common.conf --- /sys/power == /sys/power/disk == platform == /sys/power/image_size == 524288000 == /sys/power/resume == 0:0 == /sys/power/state == mem disk --- s2ram -n Machine unknown This machine can be identified by: sys_vendor = sys_product = sys_version = bios_version = --- log hibernate.log file not readable. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hibernate depends on: ii console-tools 1:0.2.3dbs-65 Linux console and font utilities Versions of packages hibernate recommends: ii dash 0.5.3-9 The Debian Almquist Shell ii hdparm 7.5-1 tune hard disk parameters for high ii uswsusp0.6~cvs20070618-1 tools to use userspace software su ii vbetool0.7-1.1 run real-mode video BIOS code to a -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
