Difference between revisions of "Problems with ACPI suspend-to-ram"
Uberpenguin (Talk | contribs) (→Troubles on resume) |
(→Troubles on suspend: Adding 'switching to UP code' hang problem.) |
||
Line 5: | Line 5: | ||
;Broken sysfs interface:You may experience problems when using {{cmdroot|echo standby > /sys/power/state}} or {{cmdroot|echo mem > /sys/power/state}} (machine goes to sleep and wakes up immediately). This can be avoided by using {{cmdroot|echo -n 3 >/proc/acpi/sleep}} to get it to sleep. This can be also happen if hotplug daemon is still running. | ;Broken sysfs interface:You may experience problems when using {{cmdroot|echo standby > /sys/power/state}} or {{cmdroot|echo mem > /sys/power/state}} (machine goes to sleep and wakes up immediately). This can be avoided by using {{cmdroot|echo -n 3 >/proc/acpi/sleep}} to get it to sleep. This can be also happen if hotplug daemon is still running. | ||
+ | |||
+ | ;Hangs on {{cmdresult|switching to UP code}}:You may be using a [[How to make use of Dynamic Frequency Scaling|frequency scaling governor]] such as "conservative" or "ondemand", which sometimes have problems with suspending. Switching to a governor such as "powersave" or "performance" before suspending may solve this problem. | ||
;MySQL daemon running:If you're running MySQL, sleep may also not work, so stop MySQL first, then sleep. Remember to restart MySQL when you wakeup. | ;MySQL daemon running:If you're running MySQL, sleep may also not work, so stop MySQL first, then sleep. Remember to restart MySQL when you wakeup. |
Revision as of 03:47, 13 August 2006
The following glitches may or may not occur in relation to suspending to RAM:
Troubles on suspend
- Permissions
- If your suspend is failing, and a
# tail /var/log/acpid
shows "Permission denied" errors, be sure that your new ACPI event and action scripts have the appropriate permissions.
- Broken sysfs interface
- You may experience problems when using
# echo standby > /sys/power/state
or# echo mem > /sys/power/state
(machine goes to sleep and wakes up immediately). This can be avoided by using# echo -n 3 >/proc/acpi/sleep
to get it to sleep. This can be also happen if hotplug daemon is still running.
- Hangs on
switching to UP code
- You may be using a frequency scaling governor such as "conservative" or "ondemand", which sometimes have problems with suspending. Switching to a governor such as "powersave" or "performance" before suspending may solve this problem.
- MySQL daemon running
- If you're running MySQL, sleep may also not work, so stop MySQL first, then sleep. Remember to restart MySQL when you wakeup.
- LCD backlight remains on during sleep
- When your system is equiped with a Radeon Mobility graphic controller your LCD backlight may not turn off automatically. Use radeontool to switch off your backlight prior suspend in your sleep action script.
- High power drain during sleep
- Also, you might want to take note of the Problem with high power drain in ACPI sleep.
Troubles on resume
- Blank display on resume
- When resuming from a suspend-to-ram the display might remain black or might only show the pre-suspend output (the system is still rebootable via ctrlaltdel). See Problem with display remaining black after resume for solutions.
- Broken hardware support after resume
-
- The serial port of the port replicator might not work after resume.
- The parallel port might not work after resume. A possible fix is to unload and reload the parallel port drivers:
# rmmod lp parport_pc parport; modprobe lp
. - Problems with the CD-RW/DVD drive after wake up from ram have been experienced.
- There is a known Problem regarding battery info after suspend to RAM. A small patch exists for kernels 2.6.14/2.6.15.
- On X20 and X21 (and possibly other) models, the sleep LED is not reset properly on resume and will keep blinking. If you have the ibm-acpi kernel module loaded with the experimental=1 option, you can switch it off on resume by appending the following line to your suspend script:
echo 7 off > /proc/acpi/ibm/led
- Crash on resume
-
- When using older ATI proprietary drivers a crash on resume can be solved by using vbetool. See the example suspend script Problem with display remaining black after resume#Solution for ThinkPads with Intel I830 Chipset. This is no longer necessary with recent revisions of the ATI proprietary driver.
- A crash could also be caused by having apic support enabled in the kernel config. Try disabling it (in the "Processor type and features" section).
- On machines with Savage chipsets, the savagefb framebuffer driver might crash the machine on resume. Make sure it is disabled in your kernel config and use the standard vesafb driver instead.
- Sonoma chipset based laptops (R52, T43, T43p, X41, X41 Tablet) utilize the SATA layer for disk access and SATA does not have power-management support yet. Suspend to RAM crashes these machines on resume. See the relevant section on the Problems with SATA and Linux page.
- When system resumes it hangs right after restarting tasks. This may be fixed by passing ec_intr=0 on kernel cmdline.
- Shutdown on resume
- If your system immediately begins to shut down right after resume, make sure you don't have acpid running with the power button tied to shutdown. The system is simply sensing the power button event and shutting down. This issue has been reported as a bug against the kernel ACPI subsystem, refer to kernel.org bugzilla bug #6612.
- Immediate suspend on resume
- When running GNOME, sometimes gnome-power-manager will put the system back into suspend immediately after resuming. This is caused by a known bug in HAL that causes some ACPI events to be reported incorrectly after a suspend-to-ram. A simple workaround can be found here.
- Note that suspend being triggered by unrelated ACPI events such as disconnecting the AC adapter may also be fixed by the above method.