ACPI(4) on CURRENT now appears to be completely broken: the system cannot be suspended, shut down, or rebooted, and ACPI-based power management is unavailable. Trying to suspend, shut down, or reboot the system leads to a panic; zzz(8) no longer works: # zzz Error: no ACPI or APM suspend support found. Reverting these commits helps to restore power management: Revert "sys/power: Generic sleep types" This reverts commit c43473dc9b8349103f78107300457ca35e437882. Revert "acpi: Use sleep types defined in sys/power.h" This reverts commit ce5e22b28ef6caff3ffd228ac188114b08c0da02. Revert "sys/power: Sleep type reporting by PM backends" This reverts commit e779891327b1d9b9ab10ba482e59f498790505a7. Revert "acpi: Fix build when `ACPI_DEBUG_OUTPUT` defined" This reverts commit 4894f5ba394306a75dbed9ed4377ab0eae75aede.
Notate the following commits, and thus Cc: olce: c43473dc9b8349103f78107300457ca35e437882 obiwac ce5e22b28ef6caff3ffd228ac188114b08c0da02 obiwac e779891327b1d9b9ab10ba482e59f498790505a7 obiwac 4894f5ba394306a75dbed9ed4377ab0eae75aede olce Also, since no patch is under discussion, needs-qa is premature.
(In reply to Marek Zarychta from comment #0) Confirmed.
One of my machines managed to capture a kernel panic from a poweroff(8). __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57 57 __asm("movq %%gs:%c1,%0" : "=r" (td) (kgdb) #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:57 td = <optimized out> #1 doadump (textdump=textdump@entry=1) at /opt/src/git-src/sys/kern/kern_shutdown.c:399 error = 0 coredump = <optimized out> #2 0xffffffff8070d320 in kern_reboot (howto=260) at /opt/src/git-src/sys/kern/kern_shutdown.c:519 once = 1 __pc = 0x0 #3 0xffffffff8070d857 in vpanic (fmt=0xffffffff80b8e00c "%s", ap=ap@entry=0xfffffe008a636960) at /opt/src/git-src/sys/kern/kern_shutdown.c:974 buf = "page fault", '\000' <repeats 245 times> __pc = 0x0 __pc = 0x0 __pc = 0x0 other_cpus = {__bits = {14, 0 <repeats 15 times>}} td = 0xfffff80006607000 bootopt = <unavailable> newpanic = <optimized out> #4 0xffffffff8070d683 in panic (fmt=<unavailable>) at /opt/src/git-src/sys/kern/kern_shutdown.c:887 ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0xfffffe008a636990, reg_save_area = 0xfffffe008a636930}} #5 0xffffffff80aeb4bc in trap_fatal (frame=<optimized out>, eva=<optimized out>) at /opt/src/git-src/sys/amd64/amd64/trap.c:969 type = <optimized out> handled = <optimized out> #6 0xffffffff80aeb4bc in trap_pfault (frame=0xfffffe008a636a00, usermode=false, signo=<optimized out>, ucode=<optimized out>) __pc = 0x0 __pc = 0x0 __pc = 0x0 td = <optimized out> p = <optimized out> eva = 136 map = <optimized out> ftype = <optimized out> rv = <optimized out> #7 <signal handler called> No locals. #8 device_get_softc (dev=dev@entry=0x0) at /opt/src/git-src/sys/kern/subr_bus.c:2141 No locals. #9 0xffffffff80429385 in acpi_wake_sleep_prep (handle=0xfffff80007706e00, stype=POWER_STYPE_POWEROFF) at /opt/src/git-src/sys/dev/acpica/acpi.c:3689 prw = {gpe_handle = 0x0, gpe_bit = 27, lowest_wake = 3, power_res = {{ Type = 0, Integer = {Type = 0, Value = 0}, String = {Type = 0, Length = 0, Pointer = 0x0}, Buffer = {Type = 0, Length = 0, Pointer = 0x0}, Package = {Type = 0, Count = 0, Elements = 0x0}, Reference = {Type = 0, ActualType = 0, Handle = 0x0}, Processor = {Type = 0, ProcId = 0, PblkAddress = 0, PblkLength = 87678488}, PowerResource = { Type = 0, SystemLevel = 0, ResourceOrder = 0}}, {Type = 369, Integer = {Type = 369, Value = 8}, String = {Type = 369, Length = 0, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Buffer = {Type = 369, Length = 0, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Buffer = {Type = 369, Length = 0, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Package = {Type = 369, Count = 0, Elements = 0x8}, Reference = { Type = 369, ActualType = 0, Handle = 0x8}, Processor = { Type = 369, ProcId = 0, PblkAddress = 8, PblkLength = 0}, PowerResource = {Type = 369, SystemLevel = 0, ResourceOrder = 8}}, {Type = 2159484735, Integer = { Type = 2159484735, Value = 0}, String = {Type = 2159484735, Length = 4294967295, Pointer = 0x0}, Buffer = { Type = 2159484735, Length = 4294967295, Pointer = 0x0}, Package = {Type = 2159484735, Count = 4294967295, Elements = 0x0}, Reference = {Type = 2159484735, ActualType = 4294967295, Handle = 0x0}, Processor = { Type = 2159484735, ProcId = 4294967295, PblkAddress = 0, PblkLength = 87678488}, PowerResource = {Type = 2159484735, SystemLevel = 4294967295, ResourceOrder = 0}}, {Type = 458, Integer = {Type = 458, Value = 8}, String = {Type = 458, Length = 0, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Buffer = {Type = 458, Length = 0, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Package = {Type = 458, Count = 0, Elements = 0x8}, Reference = { Type = 458, ActualType = 0, Handle = 0x8}, Processor = { Type = 458, ProcId = 0, PblkAddress = 8, PblkLength = 0}, PowerResource = {Type = 458, SystemLevel = 0, ResourceOrder = 8}}, {Type = 2159484735, Integer = { Type = 2159484735, Value = 18446741877008067488}, String = { Type = 2159484735, Length = 4294967295, Pointer = 0xfffffe008a636ba0 "\300kc\212"}, Buffer = { Type = 2159484735, Length = 4294967295, Pointer = 0xfffffe008a636ba0 "\300kc\212"}, Package = { Type = 2159484735, Count = 4294967295, Elements = 0xfffffe008a636ba0}, Reference = { Type = 2159484735, ActualType = 4294967295, Handle = 0xfffffe008a636ba0}, Processor = {Type = 2159484735, ProcId = 4294967295, PblkAddress = 18446741877008067488, PblkLength = 2154715683}, PowerResource = {Type = 2159484735, SystemLevel = 4294967295, ResourceOrder = 2321771424}}, { Type = 87678488, Integer = {Type = 87678488, Value = 18446735277723512832}, String = {Type = 87678488, Length = 4294965248, Pointer = 0xfffff80006607000 "\300\321G\204\377\377\377\377\020 "}, Buffer = {Type = 87678488, Length = 4294965248, Pointer = 0xfffff80006607000 "\300\321G\204\377\377\377\377\020 "}, Package = {Type = 87678488, Count = 4294965248, Elements = 0xfffff80006607000}, Reference = {Type = 87678488, ActualType = 4294965248, Handle = 0xfffff80006607000}, Processor = {Type = 87678488, ProcId = 4294965248, PblkAddress = 18446735277723512832, PblkLength = 87678464}, PowerResource = {Type = 87678488, SystemLevel = 4294965248, ResourceOrder = 106983424}}, {Type = 663, Integer = { Type = 663, Value = 18446735277704207896}, String = { Type = 663, Length = 0, Pointer = 0xfffff8000539de18 ""}, Buffer = {Type = 663, Length = 0, Pointer = 0xfffff8000539de18 ""}, Package = {Type = 663, Count = 0, Elements = 0xfffff8000539de18}, Reference = { Type = 663, ActualType = 0, Handle = 0xfffff8000539de18}, Processor = {Type = 663, ProcId = 0, PblkAddress = 18446735277704207896, PblkLength = 2165581152}, PowerResource = {Type = 663, SystemLevel = 0, ResourceOrder = 87678488}}, {Type = 87678464, Integer = { Type = 87678464, Value = 8}, String = {Type = 87678464, Length = 4294965248, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Buffer = {Type = 87678464, Length = 4294965248, Pointer = 0x8 <error: Cannot access memory at address 0x8>}, Package = {Type = 87678464, Count = 4294965248, Elements = 0x8}, Reference = {Type = 87678464, ActualType = 4294965248, Handle = 0x8}, Processor = {Type = 87678464, ProcId = 4294965248, PblkAddress = 8, PblkLength = 2321771456}, PowerResource = {Type = 87678464, SystemLevel = 4294965248, ResourceOrder = 8}}}, power_res_count = 0} dev = 0x0 sc = <optimized out> sstate = <optimized out> #10 acpi_wake_prep (handle=0xfffff80007706e00, level=<optimized out>, context=<optimized out>, status=<optimized out>) at /opt/src/git-src/sys/dev/acpica/acpi.c:3764 stype = POWER_STYPE_POWEROFF #11 0xffffffff803756db in AcpiNsWalkNamespace (Type=Type@entry=6, StartNode=<optimized out>, StartNode@entry=0xfffff800050b3880, MaxDepth=MaxDepth@entry=100, Flags=Flags@entry=1, DescendingCallback=DescendingCallback@entry=0xffffffff80429320 <acpi_wake_prep>, AscendingCallback=AscendingCallbac k@entry=0x0, Context=0xfffffe008a636ce4, ReturnValue=0x0) at /opt/src/git-src/sys/contrib/dev/acpica/components/namespace/nswalk.c:484 NodePreviouslyVisited = 0 '\000' ParentNode = 0xfffff800050b14c0 ChildNode = 0xfffff80007706e00 ChildType = 6 Level = 2 Status = 0 MutexStatus = <optimized out> #12 0xffffffff80375c45 in AcpiWalkNamespace (Type=Type@entry=6, StartObject=0xfffff800050b3880, MaxDepth=MaxDepth@entry=100, DescendingCallback=0xffffffff80429320 <acpi_wake_prep>, AscendingCallback=AscendingCallback@entry=0x0, Context=Context@entry=0xfffffe008a636ce4, ReturnValue=<optimized out>) at /opt/src/git-src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:809 Status = 0 #13 0xffffffff80426384 in acpi_wake_prep_walk (stype=POWER_STYPE_POWEROFF) at /opt/src/git-src/sys/dev/acpica/acpi.c:3777 sb_handle = 0xfffff800050b3880 #14 acpi_shutdown (dev=0xfffff80007716e00) at /opt/src/git-src/sys/dev/acpica/acpi.c:878 No locals. #15 0xffffffff8074c706 in DEVICE_SHUTDOWN (dev=0xfffff80007716e00) at ./device_if.h:262 rc = <optimized out> _m = <optimized out> _cep = <optimized out> _ce = <optimized out> _desc = <optimized out> #16 device_shutdown (dev=0xfffff80007716e00) at /opt/src/git-src/sys/kern/subr_bus.c:2753 No locals. #17 bus_generic_shutdown (dev=<optimized out>) at /opt/src/git-src/sys/kern/subr_bus.c:3563 child = <optimized out> #18 0xffffffff8074c706 in DEVICE_SHUTDOWN (dev=0xfffff800051b8200) at ./device_if.h:262 rc = <optimized out> _m = <optimized out> _cep = <optimized out> _ce = <optimized out> #16 device_shutdown (dev=0xfffff80007716e00) at /opt/src/git-src/sys/kern/subr_bus.c:2753 No locals. #17 bus_generic_shutdown (dev=<optimized out>) at /opt/src/git-src/sys/kern/subr_bus.c:3563 child = <optimized out> #18 0xffffffff8074c706 in DEVICE_SHUTDOWN (dev=0xfffff800051b8200) at ./device_if.h:262 rc = <optimized out> _m = <optimized out> _cep = <optimized out> _ce = <optimized out> _desc = <optimized out> #19 device_shutdown (dev=0xfffff800051b8200) at /opt/src/git-src/sys/kern/subr_bus.c:2753 No locals. #20 bus_generic_shutdown (dev=<optimized out>) at /opt/src/git-src/sys/kern/subr_bus.c:3563 child = <optimized out> #21 0xffffffff80750d06 in DEVICE_SHUTDOWN (dev=0xfffff800051b8500) at ./device_if.h:262 rc = <optimized out> _m = <optimized out> _cep = <optimized out> _ce = <optimized out> _desc = <optimized out> #22 device_shutdown (dev=0xfffff800051b8500) at /opt/src/git-src/sys/kern/subr_bus.c:2753 No locals. #23 root_bus_module_handler (mod=<optimized out>, what=<optimized out>, arg=<optimized out>) at /opt/src/git-src/sys/kern/subr_bus.c:5211 No locals. #24 0xffffffff806e534b in module_shutdown (arg1=<optimized out>, arg2=<optimized out>) at /opt/src/git-src/sys/kern/kern_module.c:101 mod = 0xfffff800051d3b00 #25 0xffffffff8070d3d3 in kern_reboot (howto=16392) at /opt/src/git-src/sys/kern/kern_shutdown.c:527 _ep = <optimized out> _t = 0xfffff800050e9f40 _el = 0xfffff800050e4600 once = 1 __pc = 0x0 #26 0xffffffff8070cd9c in sys_reboot (td=0xfffff80006607000, uap=0xfffff80006607428) at /opt/src/git-src/sys/kern/kern_shutdown.c:308 error = 5 #27 0xffffffff80aebe69 in syscallenter (td=0xfffff80006607000) at /opt/src/git-src/sys/amd64/amd64/../../kern/subr_syscall.c:193 se = 0xffffffff81054310 <sysent+1760> p = 0xfffffe0081002010 sa = 0xfffff80006607418 error = <optimized out> sy_thr_static = true traced = <optimized out> _audit_entered = <optimized out> #28 amd64_syscall (td=0xfffff80006607000, traced=0) at /opt/src/git-src/sys/amd64/amd64/trap.c:1208 ksi = {ksi_link = {tqe_next = 0xfffffe008a636f30, tqe_prev = 0xffffffff80aeae4d <trap+2173>}, ksi_info = { si_signo = -1973195040, si_errno = -512, si_code = -2139594896, si_pid = -1, si_uid = 25088, si_status = -2047, si_addr = 0x800000000000, si_value = {sival_int = -860430388, sival_ptr = 0x326493c1ccb6dfcc, sigval_int = -860430388, sigval_ptr = 0x326493c1ccb6dfcc}, _reason = {_fault = { _trapno = 3}, _timer = {_timerid = 3, _overrun = 0}, _mesgq = { _mqd = 3}, _poll = {_band = 3}, _capsicum = {_syscall = 3}, __spare__ = {__spare1__ = 3, __spare2__ = {106984784, -2048, -1973194752, -512, -2126868952, -1, 106983424}}}}, ksi_flags = -2130704888, ksi_sigq = 0x7} #29 <signal handler called> No locals. #30 0x000000000028bb1a in ?? ()
The "Error: no ACPI or APM suspend support found." message comes from the fact that zzz makes use of the hw.acpi.suspend_state sysctl, which I removed in D52043 instead of simply deprecating (as I should have). zzz should in general be rewritten and some more generic power management interface should be written so we don't have to do things the way it does. Thinking of/working on a solution in the meantime to add hw.acpi.suspend_state back in a nice way. As for your panic cy@, this is a different issue. I'm supposed to be getting the ACPI softc but I'm getting the softc of the device we're calling acpi_wake_sleep_prep on. Working on fix for this - glad someone ran into this early because I'm not able to reproduce this on my machines :)
(In reply to Aymeric Wibo from comment #4) What about the other part of our issue? In my cases my two laptops don't power off. FreeBSD shuts down but the power still remains on and it will remain on until I pull the power chord. Why is this?
I believe I responded to this in the 3rd paragraph of my comment. lmk if I missed something.
(In reply to Aymeric Wibo from comment #4) > hw.acpi.suspend_state sysctl, which I removed in D52043 instead of simply deprecating (as I should have) It's not late to restore it and mark deprecated.
(In reply to Andriy Gapon from comment #7) Restoring a deprecation notice won't resolve the inability to power off nor the poweroff panic. This series of commits needs to be fixed or reverted!
cy@, again, the poweroff panic is a separate issue.
Semi-temporary fix for the panic issue in https://reviews.freebsd.org/D52598. Ideally we'd get the ACPI softc so we can use sc->acpi_standby_sx, but in the meantime this probably won't cause any issues in the real world. I'll get to cleaning this up soon though.
And fix for the original issue raised: https://reviews.freebsd.org/D52600
Created attachment 263898 [details] panicking.ACPI.txt (In reply to Aymeric Wibo from comment #11) After applying the apparent fix from the D52600, I see slight progress: zzz(8) is not ignored, but leads to a panic, as shutdown, reboot and halt -p do. I am attaching the backtrace from the nice panic that occurred after the "halt -p" command was issued (with D52600) applied. This is quite unfortunate, as it affects one of the few desktop computers that handled ACPI suspend correctly and could reliably resume without issues. My old HP ProLiant DL360 G7 still powers off fine after these changes, so the scope of damage seems to be limited.
(In reply to Cy Schubert from comment #8) >Restoring a deprecation notice won't resolve the inability to power off nor the poweroff panic. This series of commits needs to be fixed or reverted! I fully agree that reverting is an appropriate and constructive option when a change introduces unintended regressions. This is a normal and healthy part of the development process, and it is something even the most experienced developers encounter. Reverting in such cases helps maintain stability and provides space to revisit the issue with a clearer path forward.
Applying both D52598 and D52600 fixes the issue for me.
> I fully agree that reverting is an appropriate and constructive option when a change introduces unintended regressions. This is a normal and healthy part of the development process, and it is something even the most experienced developers encounter. Reverting in such cases helps maintain stability and provides space to revisit the issue with a clearer path forward. Of course, and maybe I should've reverted earlier, but this sounds like a very straightforward issue (talking about the panic here) with a straightforward fix (D52598). > Applying both D52598 and D52600 fixes the issue for me. Glad things are working for you!
(In reply to Aymeric Wibo from comment #15) Perhaps I responded too early. The panic is fixed, suspend works, but the PC wakes immediately from this state, so suspend is still broken, even with the above fixes.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=506b36c4fdde0b402cc730b41a9d9d20130e1bca commit 506b36c4fdde0b402cc730b41a9d9d20130e1bca Author: Aymeric Wibo <obiwac@FreeBSD.org> AuthorDate: 2025-09-18 09:45:36 +0000 Commit: Aymeric Wibo <obiwac@FreeBSD.org> CommitDate: 2025-09-18 09:49:31 +0000 Revert "acpi: Use sleep types defined in sys/power.h" This reverts commit ce5e22b28ef6caff3ffd228ac188114b08c0da02. PR: 289634 sys/dev/acpica/acpi.c | 368 +++++++++++++++++----------------------------- sys/dev/acpica/acpi_lid.c | 4 +- sys/dev/acpica/acpivar.h | 15 +- sys/x86/acpica/acpi_apm.c | 25 ++-- 4 files changed, 158 insertions(+), 254 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=87e2b532ec9e9504ac743931ffae528679a1f4c0 commit 87e2b532ec9e9504ac743931ffae528679a1f4c0 Author: Aymeric Wibo <obiwac@FreeBSD.org> AuthorDate: 2025-09-18 09:45:27 +0000 Commit: Aymeric Wibo <obiwac@FreeBSD.org> CommitDate: 2025-09-18 09:49:17 +0000 Revert "sys/power: Sleep type reporting by PM backends" This reverts commit e779891327b1d9b9ab10ba482e59f498790505a7. PR: 289634 sys/dev/acpica/acpi.c | 6 ++---- sys/kern/subr_power.c | 46 +++++----------------------------------------- sys/sys/power.h | 3 +-- 3 files changed, 8 insertions(+), 47 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=25cddb1dfec6cfd874961ed08dcc9c76ec533df1 commit 25cddb1dfec6cfd874961ed08dcc9c76ec533df1 Author: Aymeric Wibo <obiwac@FreeBSD.org> AuthorDate: 2025-09-18 09:45:12 +0000 Commit: Aymeric Wibo <obiwac@FreeBSD.org> CommitDate: 2025-09-18 09:48:55 +0000 Revert "acpi: Fix build when `ACPI_DEBUG_OUTPUT` defined" This reverts commit 4894f5ba394306a75dbed9ed4377ab0eae75aede. PR: 289634 sys/dev/acpica/acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
> Perhaps I responded too early. The panic is fixed, suspend works, but the PC wakes immediately from this state, so suspend is still broken, even with the above fixes. Okay, considering this I have just reverted the changes. Can you send me your dmesg (before and after testing with the revert)?
Created attachment 263905 [details] dmesg, kldstat, dmidecode output I am attaching dmesg, kldstat and dmidecode output, before revert, with both D52598 and D52600 applied.
Thanks for sending this so promptly! I think I know what's going on - can you send me sysctl kern.power and hw.acpi pre-revert?
(In reply to Aymeric Wibo from comment #22) # sysctl kern.power kern.power.hibernate: hibernate kern.power.suspend: s2mem kern.power.standby: NONE kern.power.supported_stype: awake s2mem hibernate poweroff # sysctl hw.acpi hw.acpi.thermal.tz1._TSP: 10 hw.acpi.thermal.tz1._TC2: 5 hw.acpi.thermal.tz1._TC1: 1 hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._CRT: 105,1C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CR3: -1 hw.acpi.thermal.tz1._PSV: 108,1C hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.temperature: 29,9C hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._ACx: 80,1C 55,1C 0,1C 0,1C 0,1C -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._CRT: 105,1C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CR3: -1 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.temperature: 27,9C hw.acpi.thermal.user_override: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.min_runtime: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cppc_notify: 1 hw.acpi.reset_video: 0 hw.acpi.override_isa_irq_polarity: 1 hw.acpi.handle_reboot: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.verbose: 0 hw.acpi.s4bios: 0 hw.acpi.sleep_delay: 1 hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.sleep_button_state: s2mem hw.acpi.power_button_state: poweroff hw.acpi.supported_sleep_state: S3 S4 S5
Okay so my presumption was incorrect. Need to look into this a little deeper, will do this evening :)
So, at this point I'm fairly certain AcpiEnterSleepStatePrep is getting passed the right state for your system to sleep (ACPI_STATE_S3, which should also be what that function was getting before my changes), but it is failing with my changes for some reason (which it shouldn't because I'm in theory not touching that code). As a sanity check, can you compile the pre-revert changes with ACPI_DEBUG_OUTPUT set so I can see what is being passed to acpi_EnterSleepState? If you could also check which one of the returns AcpiEnterSleepStatePrep is hitting (APCICA code, sys/contrib/dev/acpica/components/hardware/hwxfsleep.c, by sprinkling some printf's there e.g.) that would help me a lot too. Thanks!
(In reply to Aymeric Wibo from comment #24) >So, at this point I'm fairly certain AcpiEnterSleepStatePrep is getting passed the right >state for your system to sleep (ACPI_STATE_S3, which should also be what that function >was getting before my changes), but it is failing with my changes for some reason (which >it shouldn't because I'm in theory not touching that code). The OS was entering sleep, at least partially, but was waking up promptly. >As a sanity check, can you compile the pre-revert changes with ACPI_DEBUG_OUTPUT set so I >can see what is being passed to acpi_EnterSleepState? >If you could also check which one of the returns AcpiEnterSleepStatePrep is hitting >(APCICA code, sys/contrib/dev/acpica/components/hardware/hwxfsleep.c, by sprinkling some >printf's there e.g.) that would help me a lot too. OK, I will do, but it will take some time. I need to read more about how to do it first. Thank you for fixing the issue!
Hi Marek! Did you have time to try this out?
(In reply to Aymeric Wibo from comment #27) No, I didn't look into this. Perhaps I will have more time on the weekend and will be able to test it. Will adding "WITH_ACPI_DEBUG_OUTPUT=yes" to src.conf be sufficient? If you want me to apply any extra patches to increase verbosity please let me know.
I think I have fixed the issue so compiling with ACPI_DEBUG_OUTPUT won't be necessary anymore. When you have time can you apply these patches and see if S3 is working again for you? - https://reviews.freebsd.org/D52705 - https://reviews.freebsd.org/D52600
(In reply to Aymeric Wibo from comment #29) fgit@slippy$ git apply /tmp/D52600.diff error: patch failed: sys/dev/acpica/acpi.c:189 error: sys/dev/acpica/acpi.c: patch does not apply fgit@slippy$
D52600 rebased.
(In reply to Aymeric Wibo from comment #31) It still fails to apply. fgit@slippy$ git apply /tmp/D52600.diff error: patch failed: sys/dev/acpica/acpi.c:195 error: sys/dev/acpica/acpi.c: patch does not apply fgit@slippy$ patch -C -p1 < /tmp/D52600.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c |--- a/sys/dev/acpica/acpi.c |+++ b/sys/dev/acpica/acpi.c -------------------------- Patching file sys/dev/acpica/acpi.c using Plan A... Hunk #1 failed at 195. Hunk #2 failed at 617. Hunk #3 succeeded at 1244 with fuzz 2 (offset -3114 lines). 2 out of 3 hunks failed while patching sys/dev/acpica/acpi.c Hmm... Ignoring the trailing garbage. done fgit@slippy$
Just tried applying D52705 and D52600 on main and they apply fine. Are you sure you applied D52705 first?
(In reply to Aymeric Wibo from comment #33) The patches do work. They're good to go.
(In reply to Aymeric Wibo from comment #29) It's hard to test anything on CURRENT now. There are multiple regressions. I spotted at least two, one with devd(8) and another with flapping USB. Anyway, I was able to apply D52705 and then D52600, just after commit 506b36c4fdde0b402cc730b41a9d9d20130e1bca (Revert "acpi: Use sleep types defined in sys/power.h"). It builds fine, and suspend (S3) seems to work fine as far as I was able to test. Unfortunately, devd(8) was broken before 506b36c4fdde0b402cc730b41a9d9d20130e1bca so my tests were only from CLI, but driver for graphics was loaded. The command "acpiconf -s3" makes OS to enter sleep state, though zzz(8) does not, it's complaining that "NONE" method is not supported, but only S3 and couple others S# are. So D52705 is fine, but D52600 needs more care. Thanks for giving the opportunity to test them. Since CURRENT is totally broken, testing was limited. Let's hope that someone will put reasonable old 16.0-CURRENT (in first days after 15 -> 16 transition it was OK) in poudriere and packages will be built. When they show up in official repo, more people will be able to run and evaluate this branch. Now, without packages, CURRENT resembles that one from early 2000's. FWIW: the USB was broken after 506b36c4fdde0b402cc730b41a9d9d20130e1bca but devd(8) before.
Hmm, can you send me the same sysctls as before? (kern. and hw.acpi.)
(In reply to Aymeric Wibo from comment #36) I am now on 56e01d0d7e0f7c2129c05467ca99d5f5538f52bc + D52705 and D52600 and it looks like below: #zzz Requested suspend state NONE is not supported. Supported states: S3 S4 S5 # sysctl kern.power kern.power.hibernate: hibernate kern.power.suspend: s2idle kern.power.standby: standby # sysctl hw.acpi hw.acpi.thermal.tz1._TSP: 10 hw.acpi.thermal.tz1._TC2: 5 hw.acpi.thermal.tz1._TC1: 1 hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._CRT: 105,1C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CR3: -1 hw.acpi.thermal.tz1._PSV: 108,1C hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.temperature: 29,9C hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._ACx: 80,1C 55,1C 0,1C 0,1C 0,1C -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._CRT: 105,1C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CR3: -1 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.temperature: 27,9C hw.acpi.thermal.user_override: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.min_runtime: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cppc_notify: 1 hw.acpi.reset_video: 0 hw.acpi.override_isa_irq_polarity: 1 hw.acpi.handle_reboot: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.verbose: 0 hw.acpi.s4bios: 0 hw.acpi.sleep_delay: 1 hw.acpi.standby_state: NONE hw.acpi.suspend_state: NONE hw.acpi.lid_switch_state: NONE hw.acpi.sleep_button_state: s2mem hw.acpi.power_button_state: poweroff hw.acpi.supported_sleep_state: S3 S4 S5 FWIW, problems with the USB mouse have gone; CURRENT seems to be usable now.
Ah right its defaulting to s2idle (see kern.power.suspend). If you set this to s2mem it should work again. I guess we should default to s2mem is ACPI S3 is available, I'll change this.
On PM backends with both s2idle and s2mem supported, I've made it select s2mem in https://reviews.freebsd.org/D52727. Normally on machines which support S0ix you'd prefer s2idle even if s2mem is also available, but we'd need a way to hint subr_power.c which sleep type is preferred. So I'll default this to s2mem for the time being to not break working S3 on older laptops.
(In reply to Marek Zarychta from comment #37) So if you apply D52705 + D52600 + D52727 then everything should work entirely as before.
(In reply to Aymeric Wibo from comment #40) Yes, it does. On the most recent CURRENT with D52705 + D52600 + D52727 applied suspend/resume, including zzz(8) works fine on my PC. As we approach the final solution, I have given it a try on my laptop... and everything seems to work! There is another mild regression introduced earlier, when this laptop enters sleep state after zzz(8), then it's able to wake up fine, when it goes to sleep after lid close, the screen seems to be frozen after waking up, and X11 has to be restarted, but this regression was introduced earlier than the discussed above changes to ACPI. Please proceed with D52705 + D52600 + D52727 Aymeric, and good luck with further improvements!
Created attachment 264090 [details] dmesg and sysctl output from laptop Perhaps it could be useful for further improvements.
It came out that the issue with freezing after closing the lid was XFCE-related. Let's hope that these three reviews mentioned above will pave the path for new enhancements, but no regression. Thank you, good luck! Dear audience of the bug report, thank you for your patience and support. This PR is already solved and closed. If anyone wishes to raise this topic again, please open a new one or send me email.
Tested on my UEFI and non-UEFI machines. All work.
This should be in-progress now.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9e1e29bd5ec61bba1bb3366ff4c069b0c8f75954 commit 9e1e29bd5ec61bba1bb3366ff4c069b0c8f75954 Author: Aymeric Wibo <obiwac@FreeBSD.org> AuthorDate: 2025-09-26 15:49:28 +0000 Commit: Aymeric Wibo <obiwac@FreeBSD.org> CommitDate: 2025-09-26 16:03:05 +0000 acpi: Add back `hw.acpi.suspend_state` sysctl When writing an ACPI S-state to it it will set kern.power.suspend to the appropriate sleep type, and when reading from it it will return the corresponding ACPI S-state to the sleep type in kern.power.suspend. This is deprecated and kern.power.suspend should be used directly instead, but add this back because zzz(1) makes use of this and we can't easily rewrite it just now. PR: 289634 Reviewed by: cy, markj Approved by: cy, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52600 Event: EuroBSDcon 2025 Devsummit sys/dev/acpica/acpi.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
Thanks for the reviews Cy - I've pushed the changes, lmk if anything breaks again!
Double FIXED! First round was the fix by reverts: 25cddb1dfec6cfd874961ed08dcc9c76ec533df1, 87e2b532ec9e9504ac743931ffae528679a1f4c0, 506b36c4fdde0b402cc730b41a9d9d20130e1bca, and in the second round, everything that was reverted was improved by new commits: 97d152698f4831db5a94d55c15233330c188feda, 9e1e29bd5ec61bba1bb3366ff4c069b0c8f75954 5632b0d4628d768c125594a3edee21fb23940067.