[SOLVED] Suspensions loop when suspends with udev rules at low battery

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-08-13 22:52:39)

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

Peter_Parch · 2025-08-11 10:48:51

Hi folks! It's been a while. In the meantime, I've switched to Wayland + River, but I haven't found a solution yet.
The best I've managed to do so far is:
- Now all devices in /proc/acpi/wakeup are permanently disabled (I don't remember how I achieved this, sorry):
cat /proc/acpi/wakeup

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	*disabled  pci:0000:07:00.3
XHC1	 S3	*disabled  pci:0000:07:00.4
XHC2	 S3	*disabled  pci:0000:08:00.0
XHC3	 S3	*disabled  pci:0000:08:00.3
XHC4	 S3	*disabled  pci:0000:08:00.4
NHI0	 S0	*disabled
NHI1	 S0	*disabled

- the udev rule now runs a script, when the battery drops below 5%, to check if the battery is connected to the power supply and, only if not, runs 'systemct suspend -i':
/etc/udev/rules.d/99-lowbat.rules

SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="[0-5]", RUN+="/usr/local/bin/lowbat-udev.sh"

/usr/local/bin/lowbat-udev.sh

 #!/bin/sh
if [ "$(cat /sys/class/power_supply/ACAD/online)" -ne 0 ]; then
  exit 0
  fi

exec /usr/bin/systemctl suspend -i

This still starts a loop in which the system suspends itself, immediately resumes itself, suspends itself again, etc., but this loop now breaks as soon as the battery charging cable is plugged in.

This is the journal of a boot where the above happened: https://0x0.st/8F62.txt

Last edited by Peter_Parch (2025-08-11 10:51:43)

seth · 2025-08-11 13:40:47

ago 11 11:24:20 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:20 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:20 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:20 archpeter kernel: ACPI: button: The lid device is not compliant to SW_LID.
ago 11 11:24:22 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:22 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:24 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:24 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:24 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:26 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:26 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:26 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:28 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:28 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:28 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:31 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:31 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:31 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:33 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:33 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:35 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:35 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:35 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:38 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:38 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:38 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:41 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:41 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:41 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:43 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:43 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:43 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:45 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:45 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:47 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:47 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:49 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0
ago 11 11:24:49 archpeter kernel: ioremap error for 0x41e300000-0x41e301000, requested 0x2, got 0x0

Can you configure the UEFI/BIOS to not wake on lid events?

Peter_Parch · 2025-08-11 14:35:01

Thank you seth! How can I get this? Only by UEFI menu?

seth · 2025-08-11 14:37:34

Yes - the lid doesn't show up in the ACPI wakeup table, there's an error about it, I assume the notebook still wakes up when you open the lid… so I suspect that's the problem.
Unless there's a UEFI setting your best shot might be a UEFI update to hopefully fix that APCI entry.

Peter_Parch · 2025-08-13 19:04:55

Unfortunately, there's no option in the UEFI for this.
However, following this wiki, I found some devices with the wakeup 'enabled' setting in /sys/class/wakeup, but I'm not sure if disabling it for them is safe, as I don't understand what some of them are. The devices I found with wakeup 'enabled' are:
- /sys/class/wakeup/wakeup38/name: ACAD --> /sys/class/wakeup/wakeup38/device/device/firmware_node/path: \_SB_.ACAD (It should be the power device and I don't think it's good to disable wakeup);
- /sys/class/wakeup/wakeup39/name: PNP0C0C:00 --> /sys/class/wakeup/wakeup39/device/path: \_SB_.PWRB (power button?);
- /sys/class/wakeup/wakeup40/name: PNP0C0D:00 --> /sys/class/wakeup/wakeup40/device/path: \_SB_.LID_ (I try to disable wakeup for that but nothing changed)
- /sys/class/wakeup/wakeup41/name: PNP0C0A:00 --> /sys/class/wakeup/wakeup41/device/path: \_SB_.BAT0 (Ok this should be the battery and also don't think should be disabled)
- /sys/class/wakeup/wakeup47/name: serio0 --> /sys/class/wakeup/wakeup47/device/firmware_id: PNP: HPQ8001 PNP0303 (??)
- /sys/class/wakeup/wakeup48/name: 00:01 --> /sys/class/wakeup/wakeup48/device/firmware_node/path: \_SB_.PCI0.SBRG.RTC0 (??)
- /sys/class/wakeup/wakeup49/name: alarmtimer.0.auto --> /sys/class/wakeup/wakeup49/device/modalias: platform:alarmtimer (something related to battery alarm?)

And sorry but I have an off topic question: Is it normal for the mesa module not to load with Wayland? I noticed it wasn't loaded because I was trying every way to save battery life, as a full charge doesn't even last an hour, just with regular web browsing and writing my thesis with Only Office (I still lose more than 1% per minute even with nothing open). Trying to load it with modprobe gives the following output:

modprobe: FATAL: Module mesa not found in directory /lib/modules/6.15.9-zen1-1-zen

.
I had the problem of excessive power consumption with Xorg as well. I still can't say whether it's worsened or improved with Wayland.

Here a journal:
http://0x0.st/8Cgn.txt

seth · 2025-08-13 20:02:58

You can disable everything in /proc/acpi/wakeup - worst case scenario is that the system goes to sleep and now there's no wakeup trigger lest at all and you'll have to reboot.

------
"mesa" is not a kernel module, how did you arrive at that idea?
https://wiki.archlinux.org/title/OpenGL

I had the problem of excessive power consumption with Xorg as well. I still can't say whether it's worsened or improved with Wayland.

=> https://archlinux.org/packages/extra/x86_64/powertop/
Fwwi, the journal is full of spam from wpa_supplicant - you've a very low wifi signal, if you cannot get closer to the AP, try a 2.4GHz connection

Peter_Parch · 2025-08-13 22:48:07

seth wrote:

You can disable everything in /proc/acpi/wakeup - worst case scenario is that the system goes to sleep and now there's no wakeup trigger lest at all and you'll have to reboot.

I have already permanently set wakeup to 'disabled' for all devices in /proc/acpi/wakeup:

cat /proc/acpi/wakeup
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	*disabled  pci:0000:07:00.3
XHC1	 S3	*disabled  pci:0000:07:00.4
XHC2	 S3	*disabled  pci:0000:08:00.0
XHC3	 S3	*disabled  pci:0000:08:00.3
XHC4	 S3	*disabled  pci:0000:08:00.4
NHI0	 S0	*disabled
NHI1	 S0	*disabled

But some devices in /sys/class/wakeup/, the ones I reported in the previous comment, are still 'enabled'.

In any case, I found an acceptable solution for this: following the same wiki, I set the kernel parameter acpi.ec_no_wakeup=1 which prevents "wakeup triggers from embedded controller when the system is in suspend-to-idle" from being passed, if I understood correctly. This, in my case, means that the only possible way to wake the system from suspension is to press the power button, and that's acceptable to me.
So I'll mark this topic as solved.

seth wrote:

"mesa" is not a kernel module, how did you arrive at that idea?

Oh.. ok I don't know why, but anyway thank you so much!

seth wrote:

=> https://archlinux.org/packages/extra/x86_64/powertop/

Thank you! I've already installed it and applied all the suggestions, and more. I'm also using power-profile-daemon set to power-saving. I've also completely disabled the dedicated video card and wired network card, but so far nothing has managed to get the battery to last more than about 45 minutes.

seth wrote:

Fwwi, the journal is full of spam from wpa_supplicant - you've a very low wifi signal, if you cannot get closer to the AP, try a 2.4GHz connection

Thank you so much! Unfortunately, my connection is even slower with 2.4GHz. However, during that boot, I had trouble connecting to the Arch forum for at least half an hour. But that was only when connecting and browsing the Arch forum. That could be the reason.

Arch Linux

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

[SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

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

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#19 2025-08-11 10:48:51

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#20 2025-08-11 13:40:47

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#21 2025-08-11 14:35:01

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#22 2025-08-11 14:37:34

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#23 2025-08-13 19:04:55

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#24 2025-08-13 20:02:58

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

#25 2025-08-13 22:48:07

Re: [SOLVED] Suspensions loop when suspends with udev rules at low battery

Board footer