Mar 16, 2025, updated at 22:12:45 (UTC)

121

Resolving Standby Problems Caused by USB Devices on Fedora Linux 41

Tutorial RedHat, Fedora, CentOS

Table of contents

Introduction

Step 1: Identify ACPI Devices with Wake-up Capability

Step 2: List USB Devices

Step 3: Identify the Problematic Device by Plugging and Unplugging

Step 4: Fix Standby Issues with udev Rules on Fedora Linux 41

Step 5: Alternative - Systemd Service for the USB Controller

Conclusion

Introduction

Sometimes on Linux systems, certain USB devices can wake the computer from standby mode or prevent it from entering standby mode at all. In this tutorial, I'll show you how to identify problematic USB devices and disable their wake-up functionality. As an example, I'll use a Logitech Logi Bolt Receiver with a Logitech MX Mechanical keyboard - a combination that frequently causes standby problems.

P.S. The Logitech MX Mechanical Keyboard (Amazon affiliate link) is one of the best mechanical keyboards I know. All the Linux and Windows computers in the editorial and administration departments are equipped with it. Have a look at them.

Step 1: Identify ACPI Devices with Wake-up Capability

First, you need to find out which ACPI devices can wake your computer from sleep:

cat /proc/acpi/wakeup

Example output:

Device	S-state	  Status   Sysfs node
GPP0	  S4	*enabled   pci:0000:00:01.1
GPP1	  S4	*disabled
GPP3	  S4	*disabled
GPP4	  S4	*disabled
GPP5	  S4	*disabled
GPP6	  S4	*disabled
GPP7	  S4	*disabled
GPP8	  S4	*enabled   pci:0000:00:03.1
GPP9	  S4	*disabled
GPPA	  S4	*disabled
GPPB	  S4	*disabled
GPPC	  S4	*disabled
GPPD	  S4	*disabled
GPPE	  S4	*disabled
GPPF	  S4	*disabled
GP10	  S4	*disabled
GP11	  S4	*disabled
GP12	  S4	*enabled   pci:0000:00:07.1
GP13	  S4	*enabled   pci:0000:00:08.1
XHC0	  S4	*enabled   pci:0000:0b:00.3
GP30	  S4	*disabled
GP31	  S4	*disabled
PS2K	  S3	*disabled
PS2M	  S3	*disabled
GPP2	  S4	*enabled   pci:0000:00:01.3
PTXH	  S4	*enabled   pci:0000:02:00.0

This output shows:

Device: The ACPI device name (e.g., PTXH, XHC0)
S-state: The deepest sleep state from which the device can wake up
Status: enabled or disabled (indicates whether the device is activated as a wake-up source)
Sysfs node: The corresponding path in the sysfs filesystem

Step 2: List USB Devices

Next, list all connected USB devices:

lsusb

Example output:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 004: ID 25a7:fa0b Areson Technology Corp 2.4G Wireless Receiver
Bus 001 Device 009: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 1038:12f6 SteelSeries ApS Arctis Nova 4X
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Step 3: Identify the Problematic Device by Plugging and Unplugging

A practical method to find the problematic device is to systematically plug and unplug individual USB devices:

Remove all non-essential USB devices
Try to put the computer into standby mode
If standby works, reconnect one device at a time and test standby after each connection
Once standby stops working, you've found the problematic device

In this case, using this method identified the Logitech Bolt Receiver as the culprit. To find the specific device in the list:

lsusb | grep -i logitech

Output:

Bus 001 Device 003: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver

Note the Vendor ID (046d) and Product ID (c548), as you'll need these for the udev rules.

Step 4: Fix Standby Issues with udev Rules on Fedora Linux 41

On Fedora Linux 41, create udev rules specific to the Logitech Logi Bolt Receiver. Use the tee method to avoid permission issues:

echo 'ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled"' | sudo tee /etc/udev/rules.d/90-logibolt-disable-wakeup.rules > /dev/null  
echo 'ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/autosuspend}="0"' | sudo tee /etc/udev/rules.d/91-logibolt-power-management.rules > /dev/null  

After creating the rules, reload the udev rules:

sudo udevadm control --reload
sudo udevadm trigger

Verify udev Rules
To check if the udev rules have been applied, use these commands:

# Find the corresponding USB device path
for device in /sys/bus/usb/devices/*; do
  if grep -q "046d" "$device/idVendor" 2>/dev/null && grep -q "c548" "$device/idProduct" 2>/dev/null; then  
    echo "Logitech Bolt Receiver found at: $device"  
    
    # Check wake-up status
    if [ -f "$device/power/wakeup" ]; then  
      echo "Wake-up status: $(cat $device/power/wakeup)"  
    fi
    
    # Check autosuspend status
    if [ -f "$device/power/autosuspend" ]; then  
      echo "Autosuspend status: $(cat $device/power/autosuspend)"  
    fi
  fi
done

The wake-up status should show "disabled" and the autosuspend status should be "0".

Output:

Logitech Bolt Receiver found at: /sys/bus/usb/devices/1-5
Wake-up status: disabled
Autosuspend status: 0

Step 5: Alternative - Systemd Service for the USB Controller

If the udev rules aren't sufficient, you can create a systemd service (also using the tee method):

echo '[Unit]  
Description=Disable Logitech MX Mechanical Bolt Receiver wake-up
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo PTXH > /proc/acpi/wakeup"  
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target' | sudo tee /etc/systemd/system/disable-logibolt-wakeup.service > /dev/null  

Enable the service so it runs at system startup:

sudo systemctl enable disable-logibolt-wakeup.service

Verify Systemd Service
After a reboot, check if the systemd service ran successfully:

cat /proc/acpi/wakeup | grep PTXH

The output should show "disabled" for the corresponding USB controller:

PTXH	  S4	*disabled   pci:0000:02:00.0

You can also check the service status:

sudo systemctl status disable-logibolt-wakeup.service

Conclusion

With these methods, you can prevent the Logitech MX Mechanical keyboard with the Logi Bolt Receiver from waking your computer from standby mode on Fedora Linux 41. The udev rules are the preferred method as they target specific devices, while the systemd service method affects the entire USB controller.

The ultimate test is whether your computer now enters and remains in standby mode without unwanted wake-ups.

Important note: After implementing these solutions, you will no longer be able to wake your computer using the keyboard connected to the Logitech Bolt Receiver. You will need to use another device, such as your mouse or the power button (configured to trigger standby mode via Gnome Settings -> Power -> Power Button Behavior: Suspend), to wake your computer from standby.

Please also mark the comments that contributed to the solution of the article

Content-ID: 671384

Url: https://rootdb.com/tutorial/resolving-standby-problems-caused-by-usb-devices-on-fedora-linux-41-671384.html

Printed on: March 31, 2025 at 12:03 o'clock

Tutorial RedHat, Fedora, CentOS

Series: Fedora

Resolving Standby Problems Caused by USB Devices on Fedora Linux 41 Linux NetworkManager - Adding a search domain using nmcli or nmtui2