Sleep resume - caveats and gotchas.

Crivens

Administrator
Staff member
Administrator
Moderator
Having had some trouble to get my hardware to correctly sleep/resume (and failing a lot at it) I would like this place to collect some strange things which may happen.

Model: Lenovo ThinkPad A485, Ryzen5, Vega gfx.
Symptom: crash during resume.
Reason: BIOS tamper protection triggers at EC reset and/or drive power down.
Solution: Disable tamper protection in BIOS.
Edit: it now hangs later instead of powering off.
 

Sleep, wake, privacy, security​



Technically fixed eight years ago, however there's potential to affect many present day users:

KDE bug 78871 <link removed>

From the opening comment:

If you right click the desktop and bring up a menu, kscreensaver will not start at all. …

… then put the computer to sleep, then wake it. Surprise! The screen is not locked.

In greater detail:

<link removed>

From bug 78871 comment 16 (2015):

… unfixable with X11, I consider this bug as fixed on Wayland.

To drive-by readers: please resist the urge to bash X11. There's more than enough bashing elsewhere. Thanks.



Fixed yesterday:

KDE bug 475506 <link removed>

I have not yet figured out whether something like this can bug FreeBSD.



To anyone who finds what might be a security issue: if it's not already fairly well-known to the public, please don't blurt it out here :)

Coordinated vulnerability disclosure - Wikipedia <link removed>

… (CVD, formerly known as responsible disclosure) …

Thanks ✅
 
Last edited:
From bug 78871 comment 16 (2015):

"… unfixable with X11, I consider this bug as fixed on Wayland."

Earlier today, in a FreeBSD room <link removed>:

Fun fact: my cats exposed an X11-related security issue that will never be fixed for many current users of FreeBSD.

Here's how I encountered the bug:
  • a keyboard simply touching the side of a trackball device, as if it was pressed by a finger.
Anyone who wakes the computer, after it's slept in this state (with a trackball or mouse or whatever) can:
  • find what you left on screen
  • continue using the computer as if they were you, for as long as they want, until they encounter something that requires a passphrase (known only to you).
Farewell, privacy.
 

Attachments

  • 1701235510978.png
    1701235510978.png
    563.6 KB · Views: 75
Last edited:

NVIDIA​

❝Resume does not yet work with Wayland with NVIDIA graphics hardware on FreeBSD.❞

— got a private thumbs-up from ashafer <removed>.

He and I were independently, coincidentally, looking at <link removed> for very different reasons.

We made the connection at <link removed>. His reason is Wayland.
 
Last edited:
I don't know that I would call it a bug. You can institute security measures if you prefer but if you walk away from keyboard in an unsecured env than you should log out. None of this is a bug but a feature.

Just like the console.
By default it doesn't logout after x-amount of time.
Is that a bug?
No. It's an easy setting.
 
I don't know that I would call it a bug.

For security software that is designed to lock at sleep time: silent failure to lock, when required, is a bug.

Not fixed for most users of security/plasma5-kscreenlocker (recognising that users of Wayland are in the minority).

Officially classified, upstream, as a major, high-priority bug. Screenshots from upstream, where things are fixed for users of Wayland:

1701609085117.png


1701608846346.png




Back to Wayland (for this topic to remain focused on sleep/wake (resume/suspend)):

<link removed>

Thanks
 
Last edited:
… an em(4) wired networking example. Sleep the computer at home, un-dock, dock it at work: wrong DHCP address. Basic stuff.

Note, I'm not seeking help (after years of frustration, I arrived at a workaround that's reliable enough). Just laying it on the table.

The workaround (verbose):

ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig wlan0 down && ifconfig em0 down && sleep 5 ; ls /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15 ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c 2 -4 freshports.org

May be /etc/rc.d/* scripts need suspend/resume sub-commands....

2023-05-23:

rc.suspend: execute rc-scripts with suspend keyword · freebsd/freebsd-src@2cf8ef5 <link removed>

Subsequently documented in acpiconf(8) and rcorder(8).
 
Last edited:
2014-03-18, svn revision 263321:

Reverted a few days later:

Revert r263321. · freebsd/freebsd-src@fe930c5 <link removed>

I was curious about with kern.vt.suspendswitch disabled (0) with NVIDIA graphics, x11/nvidia-driver-470. Result
  • blank screen after waking.
YMMV.

I waited a few minutes, then:
  1. switched away from ttyv8 to ttyv1
  2. switched back to ttyv8.
Success, no longer a blank screen.

Reverted kern.vt.suspendswitch to enabled (1).
 
Last edited:
<nitpick> Doesn't FreeBSD run Xorg on vt9? </nitpick>
 
For automatic screen locking after a timeout, I have the following line in my X11 window manger autostart file:-

# setup for xidle and slock
xidle -se -program "/usr/local/bin/slock" -timeout 300 &

After 300 secs of input device inactivity the screenlock program 'slock' is activated. If a random pigeon flies in the window and pecks at the keyboard (which happens quite often round here), the screen is locked. Of course you can choose a shorter inactivity timeout if you like.

With kern.vt.suspendswitch = 1, on resume xidle guarantees to start the screenlock before anything else is visible on the screen. However, performing a suspend-resume when kern.vt.suspendswitch=1 also breaks gpu hardware acceleration on resume, at least on intel integrated graphics using crocus DRI driver, which is a common setup. At least, that is what I have seen, in the limited testing I have done. On 14.0-RELEASE. Which is not ideal.

With kern.vt.suspendswitch = 0, suspending then resuming the system does not break gpu graphics acceleration, at least on my system, but with the caveat that whatever was on the screen at the time of the suspend will be momentarily visible for around 5 secs after the resume, before the screenlock is activated. So the random pigeon who just happened to peck the Fn key to resume the system will see what was on the screen at suspend time, for a short time. The pigeon doesn't actually have any access, he can't type a command, but he can see what was on the screen, for a few seconds. Then the screen lock overwrites the screen. Well; that's what happens on my box, anyway.

My solution for this, when running with kern.vt.suspendswitch=0 to prevent my gpu hardware accel from being clobbered after resuming from suspend, is to optionally switch to an empty X11 virtual desktop before suspending, depending upon what is on the screen. It's not really perfect.
 
A bit old but look here
https://www.reddit.com/r/freebsd/comments/2k6hq0/swap_virtual_machines/

… I found this:
https://freebsdfoundation.org/wp-content/uploads/2018/04/Pain-and-Suffering-on-the-Road-to-Resume.pdf

Linked from the 2018 article:

<link removed>

I think, none of the above place enough emphasis on the importance of appropriate graphics drivers.

From the current revision (129) of <link removed>:

If your use case is not covered by DRM or nvidia-driver, non-DRM – and if your computer uses UEFI – you may use the system console frame buffer (SCFB). See x11-drivers/xf86-video-scfb and GraphicsOld/SCFB.

Features that will not work with the system console frame buffer include:
  • sleep and wake (suspend and resume) of the computer.

Side note: the meaning of the first sentence was somewhat broken (sorry) by September 2023 removal of NVIDIA-related information.
 
Last edited:

Lenovo IdeaPad 5 14ALC050​

Not FreeBSD-friendly. Key points from discussion:
  • hw.acpi.supported_sleep_state: S4 S5
  • the latest BIOS – G5CN70WW, which corresponds to 2.16 – lacks a switch to enable S3.
 
Back
Top