"acpi0: suspend request timed out, forcing sleep now" when going S3

Hello Adrian and others.

It took me another sleepless night to finally solved this issue. The 
problem was lurking neither in kernel, nor in devd. It was hiding in 
/etc/rc.suspend script (called by devd) in MY particular system. So, 
luckily, there's no such bug in FreeBSD. Excuse me my ignorance and 
sorry for troubling you guys.

This is how I shot myself in the foot. Some three years ago I had been 
debugging suspend/resume issues on my Lenovo laptop, during that process 
I intentionally commented out call to "acpiconf -k 0" in /etc/rc.suspend 
as it was not quite clear to me what it does (man page is a bit vague on 
this case). Now I know that this is exactly the way user-space notifies 
ACPICA to continue finalizing suspend! I've totally forgotten about 
modification I made, my system even lived through a number of upgrades 
inheriting this broken script. Recently, when I started digging in into 
the problem, I discovered that opening /dev/devctl makes ACPICA to wait 
for 10 secs to get notification from user-space, I erroneously presumed 
that this notification should come from devd preferably by closing fd 
and releasing the device, and so I wrongly tested my other machines 
using simple "cat /dev/devctl" instead of running full devd. Took me 
quite some time to figure out that my theory and understanding of the 
process were completely wrong. :-)

Now, I'm trying to get why my AMD based machines tend to not resume from 
S3 if AMDGPU driver is NOT loaded. But that's another story.

---
Regards,
Ruslan

On 2026-07-06 10:30, Adrian Chadd wrote:
> Hi! i'd start by filing a bug at https://bugs.freebsd.org/ .
> 
> As for debugging, you've provided a pretty good reproduction case, so
> hopefully someone with some devctl / acpi clue will step in and take a
> look.
> I don't know what the behavioural difference is in suspend with /
> without devctl being opened but i know which developers to ask!
> 
> 
> -a
> 
> On Sun, 5 Jul 2026 at 14:08, Ruslan Zalata <rz@fabmicro.ru> wrote:
>> 
>> Hello All!
>> 
>> I'm trying to nail down the following problem which bugs me starting
>> 13.x release (since 13.3 if memory serves me). The issue is the
>> following:
>> 
>> On many (not all) AMD Ryzen 5 based laptops and mini-PCs with S3
>> (suspend to memory) state, sending system to S3 takes 10 extra 
>> seconds,
>> after which "acpi0: suspend request timed out, forcing sleep now"
>> appears in dmesg and system proceeds with suspending procedure. This 
>> 10
>> secs delay is very annoying, because it makes me wait before I can 
>> close
>> laptop's lid after Power button press. If I do not wait and close lid
>> right away, the system in most cases will not recover.
>> 
>> I traced it down to /dev/devctl device, which, if opened (usually by
>> devd), makes acpica behave strangely. If I release /dev/devctl just by
>> "killall devd" or boot into single-user mode, no acpi0 timeout takes
>> place. It appears, the issue is not in devd itself, but somewhere deep
>> in implementation of /dev/devctl device driver or even deeper. To 
>> prove
>> that, one can do the following:
>> 
>> 1. Boot into single-user mode
>> 
>> 2. Type these commands:
>> 
>> sysctl hw.acpi.verbose=1 # <-- to enable APCI debug output
>> 
>> /bin/tcsh -c "cat /dev/devctl & && acpiconf -s 3" # <-- open 
>> /dev/devctl
>> and send system to S3
>> 
>> The above message "acpi0: timed out" will appear after 10 second 
>> delay.
>> 
>> If you send it "acpiconf -s 3" without opening the /dev/devctl device
>> first, system goes suspend immediately, as expected.
>> 
>> This issue happens 100% on all releases since 13.x (including 
>> -current)
>> on two of my machines:
>> 
>>   - Laptop Lenovo IdeaPad Gaming 3, ACPI Oem ID : "LENOVO", Oem Table 
>> ID
>> : "CB-01   "
>>   - mini-PC Tecno model ML01, ACPI Oem ID : "ALASKA", Oem Table ID : 
>> "A M
>> I "
>> 
>> I ask FreeBSD desktop users to please check if this issue happens on
>> their machines too and let me know.
>> 
>> Any ideas on how to trace down this problem will be highly 
>> appreciated.
>> Thank you!
>> 
>> --
>> Regards,
>> Ruslan
>>