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

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
>