Bugzilla – Bug 228572
Supend to disk/ram does not work with Acer Aspire 1353
Last modified: 2007-06-05 11:20:44 UTC
When I select "Suspend to disk" in KPowersave applet, system switches to console and prints "Preparing hibernate..." and a few seconds later "resuming..." That means it does not suspend but resumes at once. With SUSE 10.1 "Suspend to disk" worked without problems. I use LVM for root, swap and home partitions. My home partition is encrypted. The LVM scheme is similar to the scheme which Yast offered at installation.
Created attachment 109731 [details] Output of /var/log/messages after suspend to disk
Created attachment 109733 [details] output of hwinfo
When clicking "Suspend to RAM" the behavior is similar to the behavior when trying to suspend to disk. System switches to console and prints "Preparing to suspend..." and a few seconds later "resuming..." That means it also doesn't suspend to RAM.
Uhuh, it was not neccessary to send me *whole* syslog, right? Suspend to RAM is not supported on your machine, there's a howto on opensuse telling you how to fix it. Dec 14 12:31:39 opensusez29 rcpowersaved: s2ram does not know your machine. See 's2ram -i' for details. (127) Dec 14 12:31:39 opensusez29 rcpowersaved: Use SUSPEND2RAM_FORCE=yes to override this detection. I do not see any attempt to suspend to disk in the log, perhaps powersave decides not to start suspend for some reason? powersave logs would be nice here. (Relevant part!)
Acer Aspire 1353LC, output of s2ram -i: This machine can be identified by: sys_vendor = "Acer,Inc." sys_product = "Aspire 1350" sys_version = "3A24" bios_version = "3A29" Suspend to RAM works with s2ram -f -p -m s2ram -f -p -s (after resume I get a message "Function not supported?") But only if I boot with init=/bin/bash!! If I try that in a running KDE session I get a black screen of death with dead keys!! In Kubuntu Edgy suspend to RAM or standby - I'm not sure which exactly - works with guidance-power-manager under KDE. Next thing I try is suspend to disk - seems it is disabled by default.
Ok, booting with vga=0 and s2ram -f -p -m works under an running KDE session. Output: #> s2ram -f -p -m Switching from vt7 to vt1 Calling get_mode Calling do_post Calling INT 0x15 (F000:F859) EAX is 0x5F00 Calling INT 0x15 (F000:F859) EAX is 0x5F02 Calling INT 0x15 (F000:F859) EAX is 0x5F01 Calling INT 0x15 (F000:F859) EAX is 0x5F02 Calling INT 0x15 (F000:F859) EAX is 0x5F02 Calling INT 0x15 (F000:F859) EAX is 0x5F0F Calling INT 0x15 (F000:F859) EAX is 0x5F02 Calling INT 0x15 (F000:F859) EAX is 0x5F18 Calling INT 0x1A (F000:FE6E) EAX is 0xB108 Calling set_vbe_mode switching back to vt7
you can check for the reason why the machine refused to suspend to disk in /var/log/pm-suspend.log. Please try to suspend to disk and after that fails, attach that file to the bug report. Thanks.
Created attachment 109953 [details] pm suspend log file
ok, suspend to disk is not yet supported on LVM/dm, so it refuses to suspend. For s2ram, i will add your machine to the whitelist. For now you can add your options to S2RAM_OPTS in /etc/pm/config.
I would wait with adding my machine to the whitelist because with these settings you have to add vga=0 to your boot parameters which is not a good solution in my point of view. I mean it works but I don't think that people - me included - like to see all boot messages running over if it's not needed. Do have an idea what could solve the problem with the framebuffer problem causing my notebook to hang when using vga=791 as boot parameter?
Your machine was probably designed to work with another OS - one that does not use VESA framebuffers. Maybe it is possible to fix the vesafb driver, but i'm not sure, and so adding the machine to the whitelist while mentioning that you need to pass "vga=0" is better than not offering suspend at all. BTW: you will only see the boot messages once, afterwards you will only suspend/resume anyway ;-)
Oops, this bug slipped past my attention. I have added the machine to the whitelist for future releases and will close the bug as fixed. The LVM / suspend-to-disk problem will probably have to wait some time for some time, sorry for that.