Suspend/Resume
One of the most often cited shortcomings for FreeBSD is for suspend and resume to actually work. Although most people want this feature on portable gear, there is some demand for it on the desktop as well.
This has several aspects:
- video drivers must successfully wake up and display video
- other drivers must successfully restart (notably networking and USB)
Unfortunately, commercial hardware is all over the map, and people tend to try suspend/resume once and then not investigate further if it fails. But perhaps we can make some headway on identifying common failure modes, using data instead of anecdotes.
a far more complete page for laptops is at https://laptop.bsdgroup.de/freebsd/index.html (FLCL). MarkLinimon was not aware that this page was still active before starting this one. Perhaps we should be using it for the dmesg reference instead?
How to test
We don't yet have the necessary infrastructure in place to make suspend to disk work on amd64. i386 lacks significant features, e.g., multiprocessor system support is missing, important machine-specific registers (MSRs) are not restored, and FPU state is lost. As such, the data collated here is focused on testing suspend to RAM (S3) on amd64.
To limit the number of variables involved when debugging problems, it is advised you test text mode suspend/resume before attempting it from a running X session.
suspend to RAM from text mode
- Boot into multiuser mode
- Ensure that no virtual terminals are running an X login manager and that X itself is not running
- Switch to vty 2 (ALT+F2)
- Login as root
- Run "acpiconf -s 3"
- Wait at least 30 seconds.
- If it succeeds, the screen should go black, the HDD wind down, the machine will turn off and the power LED should start slowly blinking on/off.
- If it fails
- The machine may:
- Do nothing and remain functional
- Turn the screen off but remain functional i.e. typing "find /" will grind the hard drive and the kernel still responds to network traffic
- Get into an unrecoverable tight loop after screen turns off but before machine powers down (normally the fans will crank all the way up if this happens)
- Hard reset
- You should try a bit of debugging:
- Try "sysctl debug.acpi.suspend_bounce=1" followed by "acpiconf -s 3". This tests SUSPEND/RESUME methods of all loaded device drivers. If it breaks, please file a PR about it. (Note: Verbose "dmesg", "devinfo -rv" and "pciconf -clv" output may be very helpful for the maintainers to resolve these issues. Once you are done, don't forget to turn it off, i. e., "sysctl debug.acpi.suspend_bounce=0".)
- Try "kldload vesa.ko" if screen does not turn on. (Note: Generally speaking, ATI/AMD GPUs can be easily reset with vesa.ko but it does not help some NVIDIA GPUs because their video BIOSes do not allow calling POST again to the best of my knowledge. For NVIDIA GPUs, you need a model-specific driver, i.e., ports/x11/nvidia-driver built with "WITH_ACPI_PM=yes". Setting "hw.acpi.reset_video" is no longer recommended.)
- Try "sysctl debug.acpi.resume_beep=1". When the BIOS finishes initialization and jumps to our resume code, it will make loud beep on system speaker for a while and stop. If it does not make noise while resuming, you know BIOS did not reach our resume code at all. On the other hand, if the noise does not stop, something has gone wrong while resuming a device driver or kernel panicked/hung. (Note: Some systems do not have capability to make noise on speaker. Press Ctrl+G on console to find out.)
Check if there is a relevant acpi_<manufacturer>.ko kernel module for your machine and if there is, make sure you test with the module unloaded first, then test again with it loaded.
- Check if S3 is listed in sysctl hw.acpi.supported_sleep_state
Try the ideas mentioned here DebuggingSuspendResume
- The machine may:
suspend to RAM from X
- TBD
resume from RAM
- Suspend must have succeeded i.e. the power LED should be slowly blinking on/off.
- Press the power button once, do not hold it down. The machine should wakeup, HDD should startup
- Wait 30 seconds.
- If the screen stays off:
- TBD
- If the screen comes back on:
- TBD
- If the screen stays off:
Field data
System |
Owner |
Willing to test? |
Test info |
|||||||
Suspend |
Resume |
uname -mpv |
kldstat | awk '{ if (index($5, ".ko")) print $5 }' |
pciconf -l | sed 's/[0-9]*@.*//' | sort -u |
Notes |
|||||
text mode |
X |
text mode |
X |
|||||||
Asus Eee 1005HA |
rpaulo |
yes |
yes |
TBD |
yes |
TBD |
FreeBSD 9/FreeBSD 10 |
acpi_video.ko acpi_asus.ko |
TBD |
You need kern.smp.disabled=1 and hw.acpi.reset_video=1 |
HP Z400 Workstation |
lstewart |
yes |
yes |
TBD |
no |
TBD |
FreeBSD 9.0-STABLE #1 r230474: Tue Jan 24 02:22:29 EST 2012 root@lstewart1:/usr/obj/usr/src/sys/S3TEST amd64 amd64 |
geom_raid.ko zfs.ko opensolaris.ko linprocfs.ko linux.ko |
ahci ehci hostb ioapic isab pcib uhci vgapci |
- S3TEST is GENERIC minus bge, sound and firewire related devices to minimise attached drivers for test. |
Toshiba Portege R600 Laptop |
lstewart |
yes |
yes |
yes |
yes |
yes |
FreeBSD 8.2-STABLE #8 r224238M: Thu Aug 11 09:54:34 EST 2011 root@lstewart-laptop:/usr/obj/usr/src/sys/GENERIC amd64 amd64 |
if_wpi.ko snd_hda.ko sound.ko ahci.ko atapicam.ko acpi_toshiba.ko cuse4bsd.ko linux_v4l2wrapper.ko linux.ko vboxdrv.ko sdhci.ko mmc.ko mmcsd.ko zfs.ko opensolaris.ko vboxnetflt.ko netgraph.ko ng_ether.ko vboxnetadp.ko wpifw.ko i915.ko drm.ko |
ahci ehci em hdac hostb isab pcib sdhci uhci vgapci wpi |
- Need sysctl hw.acpi.reset_video=1 |
Lenovo X1 Laptop |
osa |
yes |
- |
yes |
- |
yes |
FreeBSD 9.0-STABLE #7: Sun Jan 22 01:44:44 MSK 2012 root@x1:/usr/obj/usr/src/sys/X1 amd64 amd64 |
if_em.ko if_iwn.ko firmware.ko wlan.ko snd_hda.ko sound.ko usb.ko agp.ko acpi_video.ko cuse4bsd.ko iwn1000fw.ko wlan_amrr.ko acpi_ibm.ko vboxdrv.ko vboxnetflt.ko netgraph.ko ng_ether.ko vboxnetadp.ko wlan_wep.ko wlan_tkip.ko wlan_ccmp.ko ipfw.ko linux.ko sysvshm.ko sysvsem.ko sysvmsg.ko fuse.ko linux_adobe.ko i915.ko iicbb.ko iicbus.ko iic.ko drm.ko ng_socket.ko ng_mppc.ko rc4.ko ng_iface.ko ng_ppp.ko ng_tee.ko ng_pptpgre.ko ng_ksocket.ko ng_vjc.ko ehci.ko xhci.ko ums.ko uhid.ko |
ahci ehci em hdac hostb isab iwn none pcib vgapci xhci |
You need latest patch from Intel GPU page for X11 and suspend/resume support |
Lenovo X1 |
glebius |
yes |
- |
yes |
- |
yes |
FreeBSD head with Intel_GPU patches from kib@ |
|
|
|
Dell Latitude E5420 |
cperciva |
yes |
yes |
yes |
no |
no |
FreeBSD 9.0-RELEASE amd64 |
sdhci.ko mmc.ko mmcsd.ko linsysfs.ko linux.ko linprocfs.ko if_lagg.ko |
ahci bge ehci fwohci hdac hostb isab iwn none pcib sdhci vgapci |
Resume works sans video with reset_video=0, hangs with reset_video=1. Possibly related: Backlight control is nonfunctional (even without suspend/resume); battery charging causes interrupt storm on USB. |
Toshiba Z830 Laptop |
emaste |
yes |
yes |
TBD |
no |
TBD |
PC-BSD 9.0 |
|
|
Resume works but video does not come back, with reset_video=0 or reset_video=1 |
Asus G2K Laptop |
jkim |
yes |
yes |
yes |
yes |
yes |
FreeBSD 10.0-CURRENT #0 r233249M: amd64 |
vesa.ko ataahci.ko ata.ko cam.ko atapci.ko ataati.ko atasiliconimage.ko atajmicron.ko fdescfs.ko linprocfs.ko linux.ko linsysfs.ko firewire.ko sbp.ko lindev.ko if_ath.ko wlan.ko if_lagg.ko if_re.ko miibus.ko sound.ko snd_hda.ko usb.ko amdtemp.ko acpi_video.ko acpi_asus.ko cpuctl.ko cpufreq.ko dpms.ko udf.ko wlan_ccmp.ko wlan_tkip.ko wlan_wep.ko if_ath_pci.ko usb_quirk.ko ohci.ko ehci.ko amdsbwd.ko iic.ko iicbus.ko iicbb.ko iicsmb.ko smbus.ko intpm.ko smb.ko mmc.ko mmcsd.ko sdhci.ko cuse4bsd.ko if_bridge.ko bridgestp.ko ng_ubt.ko ng_hci.ko ng_bluetooth.ko netgraph.ko uhid.ko ng_l2cap.ko ng_btsocket.ko ng_socket.ko linux_adobe.ko logo_saver.ko wlan_xauth.ko |
atapci ath fwohci hdac hostb intsmb isab none pcib re sdhci vgapci |
I have two more desktops with ATI/AMD GPUs. They all work fine unless I load USB drivers cuse4bsd.ko (ports/multimedia/cuse4bsd-kmod 0.1.23). |
Related FreeBSD pages