Immidieate wakeup after sleep

IamNotHere · 2024-02-21 13:11:49

I have the following setup:

udev rule:

$ cat /etc/udev/rules.d/50-wake-on-device.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled", ATTR{driver/5-1/power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="disabled", ATTR{driver/5-1/power/wakeup}="disabled"

and a systemd service:

$ cat /etc/systemd/system/wakeup-events.service
[Unit]
Description=Disable wakeup events on startup

[Service]
Type=oneshot
ExecStart=/bin/bash -c "echo disabled | tee /sys/bus/usb/devices/*/power/wakeup"

[Install]
WantedBy=multi-user.target

But regardless of this, after i click suspend my PC wakes up instantly as soon as it finishes the "into sleep" routine.
Until recently the udev rule on its own was sufficient to fix this, but it stopped working after a while, i did not add or remove any hardware (including peripherals)

$ uname -a
Linux 6.7.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 17 Feb 2024 14:02:33 +0000 x86_64 GNU/Linux
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Graphics Platform: Wayland

Last edited by IamNotHere (2024-02-21 13:14:56)

seth · 2024-02-21 13:40:38

a) /proc/acpi/wakeup (maybe it's not a USB device)
b) Please post your complete system journal for a boot coverign a failed S3:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

for the current one

IamNotHere · 2024-02-21 15:21:28

seth wrote:

a) /proc/acpi/wakeup (maybe it's not a USB device)

I highly doubt it, since previously the udev rule worked, regardless, heres the readout:

$ cat /proc/acpi/wakeup | grep -i enabled
GPP7      S4    *enabled   pci:0000:00:02.1
UP00      S4    *enabled   pci:0000:04:00.0
DP00      S4    *enabled   pci:0000:05:00.0
DP20      S4    *enabled   pci:0000:05:04.0
DP28      S4    *enabled   pci:0000:05:05.0
DP30      S4    *enabled   pci:0000:05:06.0
DP38      S4    *enabled   pci:0000:05:07.0
DP40      S4    *enabled   pci:0000:05:08.0
UP00      S4    *enabled   pci:0000:0b:00.0
DP00      S4    *enabled   pci:0000:0c:00.0
DP20      S4    *enabled   pci:0000:0c:04.0
DP30      S4    *enabled   pci:0000:0c:06.0
DP38      S4    *enabled   pci:0000:0c:07.0
DP40      S4    *enabled   pci:0000:0c:08.0
DP60      S4    *enabled   pci:0000:0c:0c.0
XH00      S4    *enabled   pci:0000:12:00.0
DP68      S4    *enabled   pci:0000:0c:0d.0
DP60      S4    *enabled   pci:0000:05:0c.0
XH00      S4    *enabled   pci:0000:14:00.0
DP68      S4    *enabled   pci:0000:05:0d.0
GP17      S4    *enabled   pci:0000:00:08.1
XHC0      S4    *enabled   pci:0000:3a:00.3
XHC1      S4    *enabled   pci:0000:3a:00.4
XHC2      S4    *enabled   pci:0000:3b:00.0
GPP0      S4    *enabled   pci:0000:00:01.1
SWUS      S4    *enabled   pci:0000:01:00.0
SWDS      S4    *enabled   pci:0000:02:00.0

And i guess i failed to mention that, when it first wakes up, and i click sleep again, but without logging in, it sleeps properly somehow.

Also, manually executing:

# echo disabled | tee /sys/bus/usb/devices/*/power/wakeup

Makes it work as intended, on the first try, without this flakiness

seth · 2024-02-21 15:32:24

The service probably fires too early™ before some critical device has initiated.

ExecStartPre=/usr/bin/sleep 5

?

IamNotHere · 2024-02-22 09:31:44

seth wrote:

The service probably fires too early™ before some critical device has initiated.
ExecStartPre=/usr/bin/sleep 5
?

This appears to fix the issue.

However the whole systemd service fix is really janky...

The udev rule used to work up until recently, and nothing about my system has changed, can i somehow diagnose why the udev rule decided to stop working?

seth · 2024-02-22 09:57:19

The udev rule covers only two logitech devices and the systemd service might simply hit tooearly™ before the critical device shows up.
Does a sevice w/

udevadm trigger --type=subsystems --action=add --subsystem-match=usb --attr-match="idVendor=046d"

work as well?
(Assuming those are the only logitech devices, otherwise you'd also have to match idProduct for both)

nothing about my system has changed

systemd update?
But generally you might have just been lucky in a race condition and now the device appearance falls into the cracks during the udev start.
Check your system journal itr.

IamNotHere · 2024-02-23 14:37:25

seth wrote:

The udev rule covers only two logitech devices and the systemd service might simply hit tooearly™ before the critical device shows up.
Does a sevice w/
udevadm trigger --type=subsystems --action=add --subsystem-match=usb --attr-match="idVendor=046d"
work as well?
(Assuming those are the only logitech devices, otherwise you'd also have to match idProduct for both)

This didnt help, it still woke up instantly...

nothing about my system has changed
systemd update?
Check your system journal itr.

I meant nothing hardware-wise changed

seth · 2024-02-23 15:14:09

This didnt help, it still woke up instantly...

What exactly did you try?
The idea was to alter the service

$ cat /etc/systemd/system/wakeup-events.service
[Unit]
Description=Disable wakeup events on startup

[Service]
Type=oneshot
ExecStartPre=/usr/bin/sleep 5
ExecStart=udevadm trigger --type=subsystems --action=add --subsystem-match=usb --attr-match="idVendor=046d"

[Install]
WantedBy=multi-user.target

To see whether the udev rule is actually sufficient

IamNotHere · 2024-02-23 18:24:00

I executed the following command by hand as root and tried to sleep the PC:

# udevadm trigger --type=subsystems --action=add --subsystem-match=usb --attr-match="idVendor=046d"

seth · 2024-02-23 20:48:15

lsusb still shows driver/5-1/power/wakeup as the logtech device?
In that case this would suggest that one of the other devices in /sys/bus/usb/devices/*/power/wakeup is (also) waking the system.
b/c of "until recently" you could compare them to the LTS kernel (eg. whether a new device showed up)

IamNotHere · 2024-02-24 16:10:49

seth wrote:

lsusb still shows driver/5-1/power/wakeup as the logtech device?
In that case this would suggest that one of the other devices in /sys/bus/usb/devices/*/power/wakeup is (also) waking the system.
b/c of "until recently" you could compare them to the LTS kernel (eg. whether a new device showed up)

# lsusb -v | grep -i logitech
Bus 003 Device 003: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
  idVendor           0x046d Logitech, Inc.
  iManufacturer           1 Logitech
Bus 003 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
  idVendor           0x046d Logitech, Inc.
  iManufacturer           1 Logitech
Bus 009 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
  idVendor           0x046d Logitech, Inc.
  iManufacturer           1 Logitech

seth · 2024-02-24 22:52:11

cat /sys/bus/usb/devices/*/driver/5-1/idVendor

IamNotHere · 2024-02-25 11:34:08

$ sudo cat /sys/bus/usb/devices/*/driver/5-1/idVendor
cat: '/sys/bus/usb/devices/*/driver/5-1/idVendor': No such file or directory

Turns out it doesn't exist ¯\_(ツ)_/¯
But why would that change? And how can i update the udev rule to be agnostic to changed like this?

seth · 2024-02-25 14:11:57

UEFI update or HW reconfiguration?
https://wiki.archlinux.org/title/Udev#W … USB_device

You could instead run a script that searches for the proper device to deactivate.

IamNotHere · 2024-02-26 10:55:21

seth wrote:

UEFI update or HW reconfiguration?
https://wiki.archlinux.org/title/Udev#W … USB_device

You could instead run a script that searches for the proper device to deactivate.

But that would not work for any freshly plugged in device, can i somehow fix the udev rule?

seth · 2024-02-26 13:20:18

No, why?
You'd 'RUN+="/path/to/your/script"' and have that script check for the vendor/product ID (could be passed as parameters by udev)

IamNotHere · 2024-02-26 21:11:43

seth wrote:

No, why?
You'd 'RUN+="/path/to/your/script"' and have that script check for the vendor/product ID (could be passed as parameters by udev)

What do You mean exactly?

seth · 2024-02-26 21:20:48

Have you read https://wiki.archlinux.org/title/Udev ?
What exactly isn't clear about this?
You have the udev rule run a script that checks which /sys/bus/usb device has actually the relevant vendor & product IDs and then alters its power/wakeup state.

You can also just figure which it is right now (I assume this is a dongle and you maybe moved it to a different port?) and adjust your udev rule accordingly.

IamNotHere · 2024-02-27 15:11:29

Would a solution involving only udev, with this omitted work? If not, why? And can i make do with only udev?

ATTR{driver/5-1/power/wakeup}="disabled"

That's the only thing that changes, and I would like to avoid scripting for this particular issue

seth · 2024-02-27 15:31:07

You already have "ATTR{power/wakeup}="disabled"" and apparently that's insufficient, so: "no"

I would like to avoid scripting for this particular issue

I'll give you a head start…

#!/bin/bash
while read device; do
    device="$(dirname "$device")"
    read idProduct < "$device/idProduct"
    [ "$idProduct" = "$2" ] || continue
    echo "disabled" > "$device/power/wakeup"
done < <(grep -l $1 /sys/bus/usb/devices/*/driver/*/idVendor)

/usr/local/bin/disable_wakeup 046d c548

IamNotHere · 2024-02-27 15:44:14

seth wrote:

You already have "ATTR{power/wakeup}="disabled"" and apparently that's insufficient, so: "no"
I would like to avoid scripting for this particular issue
I'll give you a head start…
#!/bin/bash
while read device; do
    device="$(dirname "$device")"
    read idProduct < "$device/idProduct"
    [ "$idProduct" = "$2" ] || continue
    echo "disabled" > "$device/power/wakeup"
done < <(grep -l $1 /sys/bus/usb/devices/*/driver/*/idVendor)
/usr/local/bin/disable_wakeup 046d c548

This works, however if i re-plug one of the devices it stops working until i manually either execute this script or

 echo disabled | tee /sys/bus/usb/devices/*/power/wakeup

Which is why i wanted to stick purely to udev

seth · 2024-02-27 15:45:14

The idea is to run that script from the udev rule…

V1del · 2024-02-27 15:57:00

FWIW from my own curiosity you should be able to access the direct parent node with ATTRS, so for this case

ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled", ATTRS{power/wakeup}="disabled"

assuming its not further up the chain, at which point a script is probably simplest.

Arch Linux

#1 2024-02-21 13:11:49

Immidieate wakeup after sleep

#2 2024-02-21 13:40:38

Re: Immidieate wakeup after sleep

#3 2024-02-21 15:21:28

Re: Immidieate wakeup after sleep

#4 2024-02-21 15:32:24

Re: Immidieate wakeup after sleep

#5 2024-02-22 09:31:44

Re: Immidieate wakeup after sleep

#6 2024-02-22 09:57:19

Re: Immidieate wakeup after sleep

#7 2024-02-23 14:37:25

Re: Immidieate wakeup after sleep

#8 2024-02-23 15:14:09

Re: Immidieate wakeup after sleep

#9 2024-02-23 18:24:00

Re: Immidieate wakeup after sleep

#10 2024-02-23 20:48:15

Re: Immidieate wakeup after sleep

#11 2024-02-24 16:10:49

Re: Immidieate wakeup after sleep

#12 2024-02-24 22:52:11

Re: Immidieate wakeup after sleep

#13 2024-02-25 11:34:08

Re: Immidieate wakeup after sleep

#14 2024-02-25 14:11:57

Re: Immidieate wakeup after sleep

#15 2024-02-26 10:55:21

Re: Immidieate wakeup after sleep

#16 2024-02-26 13:20:18

Re: Immidieate wakeup after sleep

#17 2024-02-26 21:11:43

Re: Immidieate wakeup after sleep

#18 2024-02-26 21:20:48

Re: Immidieate wakeup after sleep

#19 2024-02-27 15:11:29

Re: Immidieate wakeup after sleep

#20 2024-02-27 15:31:07

Re: Immidieate wakeup after sleep

#21 2024-02-27 15:44:14

Re: Immidieate wakeup after sleep

#22 2024-02-27 15:45:14

Re: Immidieate wakeup after sleep

#23 2024-02-27 15:57:00

Re: Immidieate wakeup after sleep

Board footer