Suspensions loop when udev autosuspends at a given battery percentage.

Peter_Parch · 2025-06-30 11:50:14

Hi everyone!

I tried setting my laptop to auto-suspend at a certain battery percentage by following this wiki.

### What I did: ###

As suggested in the first note, I checked with

udevadm monitor --property

, while on battery, if any events were reported and I could see that no events are reported when the battery percentage drops (I waited for it to go from 30% to 25% but no messages).

However the value of

/sys/class/power_supply/BAT0/alarm

is different from 0 (it's 2986000) so I tried to see if the events are reported only when 'energy_now' reaches a lower level than 'alarm' and yes: raising the alarm level just above that of energy_now, after launching

udevadm monitor --property

, generates output.

At this point I calculated 5% of the value of 'energy_full' (energy_full is 37237000) = 1861850, I tried to change the value of 'alarm' from 2986000 to 1861850 but I only managed to set it to 1861000.

I then created the udev rule by copying it from the wiki

/etc/udev/rules.d/99-lowbat.rules

# Suspend the system when battery level drops to 5% or lower
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="[0-5]", RUN+="/usr/bin/systemctl hibernate"

but replacing

RUN+="/usr/bin/systemctl hibernate"

with

RUN+="/usr/bin/systemctl suspend -i"

.

Finally I just reloaded udev with

sudo udevadm control --reload

and when the battery reached 5% the system automatically suspended. The problem is that when I resumed it automatically suspended again in an infinite loop even though I immediately put the laptop on charge and waited a few minutes before resuming.

Unable to log in to the system, I had to force shutdown and log in with a live USB because even after the forced shutdown, when I tried to reboot the system, I couldn't log in due to the continuous suspensions. By logging in to the system with a live USB and deleting the udev rule I was able to log in normally. From the live USB I could also notice that the value of 'alarm' had returned to the default (2986000) and it seemed strange to me.

I don't understand where I went wrong and I hope someone can kindly help me understand.

Thanks in advance folks!

Last edited by Peter_Parch (2025-06-30 14:26:54)

unixman · 2025-07-02 22:29:55

So 'a few minutes' not enought to climb %6 then?
An alternative approach is dont use/rely on udev and write a basic script/cron which do same job.
with above problem accounted of course.

Peter_Parch · 2025-07-02 23:30:23

unixman wrote:

So 'a few minutes' not enought to climb %6 then?

No, he reached and surpassed it.
I initially resumed immediately after suspending but since the system immediately auto-suspended again, I assumed it was because the battery was still at 5% and waited a few minutes.
The system suspends just 1 or 2 seconds after the resume, so I could see the battery charge up to at least 10%, before I could, between one suspension and another, turn off. All this while charging, and when I turned it back on, still waiting a few minutes, the problem was still there.
I have a dual boot with Windows (but on two different internal ssd) and on Windows I noticed that before I tried logging into Arch again, the battery had reached 80% and yet the system continued to hang, preventing me from logging in.

An alternative approach is dont use/rely on udev and write a basic script/cron which do same job.
with above problem accounted of course.

Ok, thanks. Do you mean I might run into the same problem? Anyway I tried this solution just because I find it in the Arch Wiki and I would like to understand what I did wrong. If I can't figure it out I'll try the script/cron route even though I don't know how to do it.

unixman · 2025-07-03 01:41:18

Add/combine IF_NOT(ac_power_plugged) condition to your udev rule.
not that above is pseudocode.

I guess that udev or someone cache the current state to filesystem/nvmem(so permanent) before suspend,
then still use old cached state after resume?

A possible hack if possible is you order udev to write a cookie(file) before going to suspend.
cookie may be contains timespamps of suspend. Then order it that use that cookie after resume to avoid to making stupid things.

Last edited by unixman (2025-07-04 12:14:26)

seth · 2025-07-03 22:43:35

From the live USB I could also notice that the value of 'alarm' had returned to the default (2986000) and it seemed strange to me.

sysfs is transient, https://wiki.archlinux.org/title/System … rary_files - but since the default is ~8% that's not necessary anyway.

the wiki wrote:

If you have more than one battery or if you are using a battery powered peripheral device, the rule could be triggered unexpectedly by another battery discharging

Also

cat /sys/power/mem_sleep

and check the journal of the suspend-looping boot, maybe the udev rule stacked up a flurry of suspend invocations while the power was low and then replayed that every time your woke up.
You could test this w/ sth. harmless

RUN+="/usr/bin/bash -c 'date >> /tmp/wannasuspend'"

and then manually send the system to sleep and see whether there're any unexpected entries.

Peter_Parch · 2025-07-06 11:38:22

seth wrote:

sysfs is transient, https://wiki.archlinux.org/title/System … rary_files - but since the default is ~8% that's not necessary anyway.

ok, thanks.

This is the output of

cat /sys/power/mem_sleep

[s2idle]

You could test this w/ sth. harmless
RUN+="/usr/bin/bash -c 'date >> /tmp/wannasuspend'"

Trying this, when the battery drops below 5%, the date is correctly printed in the /tmp/wannasuspend file, but when I tried to suspend the system manually with 'systemctl suspend' I noticed that the laptop suspends for about a second and then resumes automatically. However, if the laptop is under charge and/or has exceeded 5%, manual suspension with 'systemctl suspend' works correctly.

seth · 2025-07-06 12:59:39

I noticed that the laptop suspends for about a second and then resumes automatically

Please post the system journal covering that event.

Peter_Parch · 2025-07-06 14:17:53

Right.

Here the output of

sudo journalctl -b

http://0x0.st/8GTL.txt

seth · 2025-07-06 14:26:35

sleep is neither inhibited nor failing, there's gonna be some wakeup trigger.

cat /proc/acpi/wakeup

lug 06 16:14:01 archpeter root[12418]: ACPI action undefined: PNP0C0A:00

looks relevant and the event occurs frequently (basically every second, starting 5s into the boot)
This is probably the charger…

Peter_Parch · 2025-07-06 15:47:02

cat /proc/acpi/wakeup

Device  S-state   Status   Sysfs node
GPP1      S4    *enabled   pci:0000:00:01.2
GPP2      S4    *disabled
GPP0      S4    *enabled   pci:0000:00:01.1
GPP5      S4    *enabled   pci:0000:00:02.1
GPP6      S4    *enabled   pci:0000:00:02.2
GPP7      S4    *enabled   pci:0000:00:02.3
GP11      S0    *disabled
SWUS      S4    *disabled
GP12      S0    *disabled
SWUS      S4    *disabled
XHC0      S3    *enabled   pci:0000:07:00.3
XHC1      S3    *enabled   pci:0000:07:00.4
XHC2      S3    *enabled   pci:0000:08:00.0
XHC3      S3    *enabled   pci:0000:08:00.3
XHC4      S3    *enabled   pci:0000:08:00.4
NHI0      S0    *disabled
NHI1      S0    *disabled

lug 06 16:14:01 archpeter root[12418]: ACPI action undefined: PNP0C0A:00

Could this be because I enabled the acpid.service service? I forgot to specify this in the first post. I enabled it so I could use acpi_listen to check if the system generated ACPI events. Would disabling the service still make the udev rule work?

seth · 2025-07-06 15:53:30

acpid logs the events, but it doesn't cause them.

lspci

but probably disable the GPP? devices.

echo GPP1 | sudo tee /proc/acpi/wakeup

will eg. toggle GPP1
XHC? are USB devices.

Peter_Parch · 2025-07-06 16:28:28

lspci

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Root Complex (rev 01)
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 17h-19h IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge (rev 01)
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge (rev 01)
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge (rev 01)
00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge (rev 01)
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge (rev 01)
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h Internal PCIe GPP Bridge (rev 10)
00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h Internal PCIe GPP Bridge (rev 10)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 71)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 7
01:00.0 VGA compatible controller: NVIDIA Corporation GA107M [GeForce RTX 3050 Ti Mobile] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GA107 High Definition Audio Controller (rev a1)
02:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN850X NVMe SSD (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 16)
04:00.0 Network controller: MEDIATEK Corp. MT7921 802.11ax PCI Express Wireless Network Adapter
05:00.0 SD Host controller: Genesys Logic, Inc GL9750 SD Host Controller (rev 01)
06:00.0 Non-Volatile memory controller: Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD (rev 01)
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] (rev c8)
07:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Radeon High Definition Audio Controller [Rembrandt/Strix]
07:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 19h PSP/CCP
07:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Rembrandt USB4 XHCI controller #3
07:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Rembrandt USB4 XHCI controller #4
07:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Audio Coprocessor (rev 60)
07:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller
08:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Rembrandt USB4 XHCI controller #8
08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Rembrandt USB4 XHCI controller #5
08:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Rembrandt USB4 XHCI controller #6

But why the manual suspension work correctly when under charge or even when the battery is over 5%?

Last edited by Peter_Parch (2025-07-06 16:30:35)

seth · 2025-07-06 16:45:12

But why the manual suspension work correctly when under charge or even when the battery is over 5%?

I tried to see if the events are reported only when 'energy_now' reaches a lower level than 'alarm' and yes: raising the alarm level just above that of energy_now, after launching

00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge
00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge

as non-speaking as it gets, you'll have to try whether and which of the devices is this trigger for PNP0C0A:00

Peter_Parch · 2025-07-06 16:52:45

as non-speaking as it gets, you'll have to try whether and which of the devices is this trigger for PNP0C0A:00

By disabling the GPP devices? One at a time or all together?

seth · 2025-07-06 20:35:00

You can just take them out completely and see whether that impacts the situation at all.

Peter_Parch · 2025-07-07 12:17:15

OK. I tried disabling all GPP devices, one by one, with:

 echo GPP1 | sudo tee /proc/acpi/wakeup

 echo GPP0 | sudo tee /proc/acpi/wakeup

 echo GPP5 | sudo tee /proc/acpi/wakeup

 echo GPP6 | sudo tee /proc/acpi/wakeup

 echo GPP7 | sudo tee /proc/acpi/wakeup

So the output of cat /proc/acpi/wakeup was:

Device  S-state   Status   Sysfs node
GPP1      S4    *disabled  pci:0000:00:01.2
GPP2      S4    *disabled
GPP0      S4    *disabled  pci:0000:00:01.1
GPP5      S4    *disabled  pci:0000:00:02.1
GPP6      S4    *disabled  pci:0000:00:02.2
GPP7      S4    *disabled  pci:0000:00:02.3
GP11      S0    *disabled
SWUS      S4    *disabled
GP12      S0    *disabled
SWUS      S4    *disabled
XHC0      S3    *enabled   pci:0000:07:00.3
XHC1      S3    *enabled   pci:0000:07:00.4
XHC2      S3    *enabled   pci:0000:08:00.0
XHC3      S3    *enabled   pci:0000:08:00.3
XHC4      S3    *enabled   pci:0000:08:00.4
NHI0      S0    *disabled
NHI1      S0    *disabled

When the battery dropped below 5% I manually suspended it with 'systemctl suspend -i' but the system still suspends for just a second and then it resumes automatically.
Again, once put under charge instead the manual suspension works correctly.
This is the journal: http://0x0.st/8G_I.txt
For the

ACPI action undefined: PNP0C0A:00

issue, I think it's the charger, but I have yet to try booting the system when fully charged and see a journal after some time of use (but before putting it back on charge of course).

seth · 2025-07-07 13:09:08

The wakeup might not be exposed to the OS, eg. I can configure my UEFI to wake on AC, but that's not reflected anywher in my wakeup table (neither charger nor battery device show up there)

Peter_Parch · 2025-07-09 10:53:45

The wakeup might not be exposed to the OS, eg. I can configure my UEFI to wake on AC, but that's not reflected anywher in my wakeup table (neither charger nor battery device show up there)

Ok. Thanks.

In the meantime I did this test:

Peter_Parch wrote:

I have yet to try booting the system when fully charged and see a journal after some time of use (but before putting it back on charge of course)

And yes, the ACPI action undefined: PNP0C0A:00 error is charger dependent. This is the journal of a system boot before putting it under charge: http://0x0.st/8Gke.txt
This is the journal of the same boot but executed after putting the laptop on charge: http://0x0.st/8GdZ.txt

Arch Linux

#1 2025-06-30 11:50:14

Suspensions loop when udev autosuspends at a given battery percentage.

#2 2025-07-02 22:29:55

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#3 2025-07-02 23:30:23

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#4 2025-07-03 01:41:18

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#5 2025-07-03 22:43:35

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#6 2025-07-06 11:38:22

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#7 2025-07-06 12:59:39

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#8 2025-07-06 14:17:53

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#9 2025-07-06 14:26:35

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#10 2025-07-06 15:47:02

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#11 2025-07-06 15:53:30

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#12 2025-07-06 16:28:28

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#13 2025-07-06 16:45:12

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#14 2025-07-06 16:52:45

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#15 2025-07-06 20:35:00

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#16 2025-07-07 12:17:15

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#17 2025-07-07 13:09:08

Re: Suspensions loop when udev autosuspends at a given battery percentage.

#18 2025-07-09 10:53:45

Re: Suspensions loop when udev autosuspends at a given battery percentage.

Board footer