Sleep resume - caveats and gotchas.

[Crivens]

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.

 

[Cath O'Deray]

Sleep, wake, privacy, security​

---

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

KDE bug <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 <link removed> (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 <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

 

[Cath O'Deray]

From <link removed> (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.

 

[Cath O'Deray]

NVIDIA​

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

— got a private thumbs-up from ashafer in <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.

 

[Phishfry]

the bug

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.

 

[Cath O'Deray]

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:

---

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

<link removed>

Thanks

 

[Cath O'Deray]

… 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).

 

[Cath O'Deray]

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).

 

[Crivens]

<nitpick> Doesn't FreeBSD run Xorg on vt9? </nitpick>

 

[Phishfry]

F9 is ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure

 

[smithi]

F9 is ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure

If only IBM had started with an F0 key ...

 

[Crivens]

If only IBM had started with an F0 key ...

Yep, they blew it. I stand corrected.

 

[blackbird9]

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.

 

[Cath O'Deray]

A bit old but look here

… I found this:

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.

 

[Cath O'Deray]

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.

 

[Cath O'Deray]

16th September:

… /boot/loader.conf:

hw.usb.usbhid.enable="1"
usbhid_load="YES"
uhid_load="NO"

…

17th:

… in /boot/loader.conf

hw.usb.usbhid.enable="1"
usbhid_load="YES"
hkbd_load="YES"

uhid can optionally be disabled from loader.conf:

uhid_load="NO"

…

After experimenting with the 16th September suggestion, I had a handful of consecutive sleep failures. For me:

• sleep failures are unusual
• so many consecutive failures was extraordinary.

After reverting the configuration: the next attempt to sleep failed.

Weird. All attempts had this in common:

• the attempt to sleep was very soon after automated log in to Plasma.

---

The next sleep, long after login and whilst the system was much busier, succeeded. I took a screenshot shortly before the success (2024-09-17 08:26:52):

% zgrep -e BOOT -e suspend /var/log/messages.0.bz2
Sep 16 19:06:35 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 16 19:15:54 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 16 19:23:05 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 16 19:35:14 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 16 19:45:04 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 17 08:27:46 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 17 09:15:47 mowa219-gjp4-zbook-freebsd acpi[56285]: suspend at 20240917 09:15:47
% grep -e BOOT -e suspend /var/log/messages
Sep 18 04:46:58 mowa219-gjp4-zbook-freebsd kernel: ---<<BOOT>>---
%

At a glance, I can't tally what's logged (above) with my recollection of things … maybe changes of boot environments (below) were a factor … I certainly did intentionally wait a long time before the successful sleep. More precisely: I waited for the poudriere build of rust to succeed, then waited for the related long run of rm to end.

Spoiler: environments

root@mowa219-gjp4-zbook-freebsd:~ # bectl list -c creation | tail -n 6
1500023-066-base          -      -          2.79G 2024-09-15 08:15
1500023-067-base          -      -          2.80G 2024-09-15 15:55
1500023-068-base          -      -          2.80G 2024-09-16 06:50
1500023-069-base          -      -          2.87G 2024-09-16 16:18
1500023-070-base-ports    -      -          2.80G 2024-09-17 10:54
1500023-071-base          NR     /          388G  2024-09-18 03:02
root@mowa219-gjp4-zbook-freebsd:~ # uname -mvKU
FreeBSD 15.0-CURRENT main-n272273-ee4506105171 GENERIC-NODEBUG amd64 1500023 1500023
root@mowa219-gjp4-zbook-freebsd:~ # tail -n 6 /home/grahamperrin/Documents/boot\ environments.txt
1500023-066-base                2024-09-15 08:15 main-n272228-afd096326aad
1500023-067-base                2024-09-15 15:55 main-n272240-4ccad5452058
1500023-068-base                2024-09-16 06:50 main-n272244-4b273a7fb9e6
1500023-069-base                2024-09-16 16:18 main-n272256-1c6bb4c5789c
1500023-070-base-ports          2024-09-17 10:54 main-n272271-666303f59808
1500023-071-base                2024-09-18 03:02 main-n272273-ee4506105171
root@mowa219-gjp4-zbook-freebsd:~ #

% pkg iinfo nvidia
linux-nvidia-libs-470-470.161.03
nvidia-driver-470-470.161.03_1
nvidia-settings-535.146.02_1
nvidia-xconfig-525.116.04
% sysrc kld_list
kld_list: fusefs filemon nvidia-modeset
%

---

For reference only. No support for CURRENT here.

 

[blackbird9]

"the attempt to sleep was very soon after automated log in to Plasma."

What happens if you disable that? I wonder if plasma is doing something. And/or, can you install another desktop, XFCE4 say, and see if that exhibits the same problems? Perhaps I've been lucky but I've never seen a failed sleep or failed resume on my X201 with recent releases (13.x, 14.x), using my setup with sddm, windowmaker, and xidle/slock as screenlock, it works every time here. Can you isolate the problem to plasma automated login? Automated login (as opposed to password login) sounds like something that might not be used very often...

From the kernel log, acpi is making the suspend request, but something lower down, presumably the device driver, is timing out. Another line of investigation is to look through the source for acpi and find where that timeout message is emitted, and try to identify why.

 

[Cath O'Deray]

Thanks, when these lines are seen:

… acpi0: suspend request timed out, forcing sleep now

– IIRC it does not necessarily mean that sleep fails.

Postscript

Timestamps can be slightly mind-bending. An example:

% grep -e suspend -e resume -e BOOT /var/log/messages | tail -n 5
Sep 20 09:06:37 mowa219-gjp4-zbook-freebsd kernel: ---<<BOOT>>---
Sep 20 16:34:56 mowa219-gjp4-zbook-freebsd kernel: acpi0: suspend request timed out, forcing sleep now
Sep 21 18:27:12 mowa219-gjp4-zbook-freebsd acpi[37646]: suspend at 20240921 18:27:12
Sep 21 18:27:17 mowa219-gjp4-zbook-freebsd acpi[37958]: resumed at 20240921 18:27:17
Sep 21 18:35:48 mowa219-gjp4-zbook-freebsd kernel: ---<<BOOT>>---
%

• I slept the computer on Friday afternoon (20th September)
• successful wake on Saturday evening
• Friday's afternoon's ACPI suspend was logged on Saturday evening (five seconds before the log of the resume).

---

No support for CURRENT here.

(I'll discuss elsewhere. The bigger pictures are off from this topic.)

 

[Cath O'Deray]

… submitted a bug report that describes an apparent problem in the USB support causing USB devices to be, in effect, umounted on waking from use of zzz. …

Yours may be a duplicate of 2012 bug 173722.

Fairly well known, but relatively poorly documented:

• FreeBSD use of USB does not yet allow things such as sleep and wake of the OS, if the OS (on UFS or ZFS) boots from and then runs from a USB drive

– anyone, please, correct me if I'm wrong.

From a 2013 blog post – Home Server with FreeBSD and ZFS – before FreeBSD began using OpenZFS:

1. …
2. The system wakes up but often fails to resume the USB hard disk.

… a deal breaker, since my entire root partition was on a USB drive, and it would hang whenever I tried to invoke system commands. …

I might have expected failure (hangs) always, not often, although 2013 was before my time.

FreeBSD-based NomadBSD is a 64-bit live system for USB flash drives. It's reported that Suspend and Resume using the Leave Menu works out of the box on a Dell Latitude E5570, however that was with the OS installed on a hard disk drive (presumably not on USB).

OS on USB aside​

ZFS

In 2020 on the freebsd-current list, whilst discussing suspend/resume versus OpenZFS on USB, the late HPS observed:

USB is not hanging.

It looks like a problem with USB resume, that no devices are recognized, until you re-plug them ...

Recommended subscriptions: issue 5242 and linked PR 11082.

I have a script at

/usr/local/sbin/suspend.sh

– called by customised /etc/rc.suspend, the script attempts to:

• export a named pool on a single HDD on USB
• take offline two removable cache devices on USB (Kingston DataTraveler 3.0, Verbatim STORE N GO).

USB in general for mass storage

Please don't quote me on this (I can't find my points of reference), IIRC:

• what's required for USB to work for storage, following wake from sleep, occurs too late in the FreeBSD wake routine

– or something like that …

 

[Cath O'Deray]

Not recent, but worth reading: the March/April 2018 FreeBSD Journal article by jhb@, Pain and Suffering on the Road to Resume.

---

From EuroBSDCon 2023 Trip Report – Mark Johnston:

"… Hiroki Sato’s talk on his patches to FreeBSD’s USB stack to enable the use of the USB debug capability. This is a hardware feature present in some USB controllers which lets one create a communication channel over USB. This effectively allows one to get a debugging console for any device with a compatible USB controller. This should be very handy for debugging issues related to suspend/resume of laptops, which otherwise lack an out-of-band channel that one could use for debugging. …"

 

[Cath O'Deray]

Around the end of July, I began finding symptoms of a possible regression.

Touch wood: no problem since I chose to make changes to loader.conf on 16th October. It's too soon to draw a conclusion – the changes made by me coincided with a routine upgrade, I have not yet found time to focus on those packages.

If a conclusion is reached, I'll write again. In the meantime: if anyone else has sensed a regression, please send a private message. Thanks.