frank
Goto Top

Fedora Linux 41: Standby-Probleme durch USB-Geräte lösen


Manchmal kann es bei Linux-Systemen vorkommen, dass bestimmte USB-Geräte den Computer aus dem Standby-Modus wecken oder verhindern, dass der Computer überhaupt in den Standby wechselt. In diesem Tutorial zeige ich dir, wie du problematische USB-Geräte identifizierst und deren Aufweckfunktion deaktivierst. Als Beispiel verwende ich einen Logitech Logi Bolt Receiver mit einer Logitech MX Mechanical Tastatur - eine Kombination, die häufig Standby-Probleme verursacht.

P.S. Die Logitech MX Mechanical Tastatur (Amazon Partnerlink) ist übrigens eine der besten mechanischen Tastaturen, die ich kenne. Alle Linux- und Windows-Rechner in Redaktion und Administration sind damit ausgestattet. Schaut sie euch an.

back-to-topSchritt 1: Aufweckfähige ACPI-Geräte identifizieren


Zuerst musst du herausfinden, welche ACPI-Geräte deinen Computer aus dem Ruhezustand aufwecken können:
cat /proc/acpi/wakeup

Beispielausgabe:
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
PS2

Die Ausgabe zeigt folgende Informationen:

  • Device: Der ACPI-Gerätename (z.B. PTXH, XHC0)
  • S-state: Der tiefste Schlafzustand, aus dem das Gerät aufwecken kann
  • Status: enabled oder disabled (zeigt an, ob das Gerät als Aufweckquelle aktiviert ist)
  • Sysfs node: Der entsprechende Pfad im sysfs-Dateisystem

back-to-topSchritt 2: USB-Geräte auflisten


Als nächstes listest du alle angeschlossenen USB-Geräte auf:
lsusb

Beispielausgabe:
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

back-to-topSchritt 3: Problematisches Gerät durch Ein- und Ausstecken identifizieren


Eine praktische Methode, um das problematische Gerät zu finden, ist das systematische Ein- und Ausstecken einzelner USB-Geräte:

  1. Entferne alle nicht essentiellen USB-Geräte
  2. Versuche, den Computer in den Standby-Modus zu versetzen
  3. Wenn der Standby funktioniert, stecke ein Gerät nach dem anderen wieder ein und teste jeweils den Standby
  4. Sobald der Standby nicht mehr funktioniert, hast du das problematische Gerät gefunden

In diesem Fall wurde durch diese Methode der Logitech Bolt Receiver als Übeltäter identifiziert. Um das spezifische Gerät in der Liste zu finden:
lsusb | grep -i logitech

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

Notiere dir die Vendor-ID (046d) und die Produkt-ID (c548), da du diese für die udev-Regeln benötigst.

back-to-topSchritt 4: Standby-Problem mit udev-Regeln in Fedora Linux 41 beheben


Auf Fedora Linux 41 erstellst du udev-Regeln, die spezifisch für den Logitech Logi Bolt Receiver gelten. Verwende dazu die tee-Methode, um Berechtigungsprobleme zu vermeiden:

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  

Nach dem Erstellen der Regeln lädst du die udev-Regeln neu:
sudo udevadm control --reload
sudo udevadm trigger

udev-Regeln überprüfen

Um zu prüfen, ob die udev-Regeln angewendet wurden, kannst du folgende Befehle in der bash verwenden:
# Finde den entsprechenden USB-Gerätepfad
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 gefunden unter: $device"  
    
    # Prüfe den Wakeup-Status
    if [ -f "$device/power/wakeup" ]; then  
      echo "Wakeup-Status: $(cat $device/power/wakeup)"  
    fi
    
    # Prüfe den Autosuspend-Status
    if [ -f "$device/power/autosuspend" ]; then  
      echo "Autosuspend-Status: $(cat $device/power/autosuspend)"  
    fi
  fi
done

Der Wakeup-Status sollte "disabled" anzeigen und der Autosuspend-Status sollte "0" sein.

Ausgabe:
Logitech Bolt Receiver gefunden unter: /sys/bus/usb/devices/1-5
Wakeup-Status: disabled
Autosuspend-Status: 0

back-to-topSchritt 5: Alternative - Systemd-Service für den USB-Controller


Falls die udev-Regeln nicht ausreichen, kannst du einen systemd-Service erstellen (auch hier mit der tee-Methode):

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  

Aktiviere den Service, damit er beim Systemstart ausgeführt wird:
sudo systemctl enable disable-logibolt-wakeup.service

Systemd-Service überprüfen

Nach einem Neustart kannst du prüfen, ob der Systemd-Service erfolgreich ausgeführt wurde:
cat /proc/acpi/wakeup | grep PTXH

Die Ausgabe sollte "disabled" für den entsprechenden USB-Controller anzeigen.
Du kannst auch den Status des Services überprüfen:
sudo systemctl status disable-logibolt-wakeup.service

back-to-topFazit


Mit diesen Methoden kannst du auf Fedora Linux 41 verhindern, dass die Logitech MX Mechanical Tastatur mit dem Logi Bolt Receiver deinen Computer permanent aus dem Standby-Modus weckt. Die udev-Regeln sind die bevorzugte Methode, da sie gezielt auf bestimmte Geräte wirken, während die systemd-Service-Methode den gesamten USB-Controller betrifft.

Der ultimative Test ist jedoch, ob dein Computer jetzt problemlos in den Standby-Modus wechselt und dort bleibt, ohne ungewollt aufzuwachen.

Wichtiger Hinweis: Nach der Implementierung dieser Lösungen kannst du deinen Computer nicht mehr mit der Tastatur aufwecken, die am Logitech Bolt Receiver angeschlossen ist. Du musst ein anderes Gerät verwenden, wie zum Beispiel deine Maus oder den Einschaltknopf (konfiguriert für den Standby-Modus über die Gnome-Einstellungen -> Energie -> Auswirkungen des Einschaltknopfs: Bereitschaft), um deinen Computer aus dem Standby-Modus aufzuwecken.

Gruß
Frank

Content-ID: 671982

Url: https://administrator.de/tutorial/fedora-linux-41-standby-probleme-durch-usb-geraete-loesen-671982.html

Ausgedruckt am: 15.04.2025 um 10:04 Uhr

Spirit-of-Eli
Spirit-of-Eli 19.03.2025 aktualisiert um 08:31:25 Uhr
Goto Top
Moin Frank,

ich habe da dafür genau so eine Lösung suchen müssen als ich mich weiter auf Linux eingelassen habe.
Schon merkwürdig, dass dieses Problem noch nicht generell angegangen wurde.

In meiner Lösung wird der wakeup Befehl von sämtlichen USB Geräten unterdrückt. Seit dem kann ich das Notebook im Standby lassen.
Die integrierte Tastatur funktioniert allerdings.


Vorher ist das Notebook immer sofort aufwacht oder es hat maximal 30s gedauert.

Gruß
Spirit
Frank
Frank 19.03.2025 aktualisiert um 09:58:24 Uhr
Goto Top
Hi @Spirit-of-Eli,

Schon merkwürdig, dass dieses Problem noch nicht generell angegangen wurde.

Ich glaube nicht, dass das ein Linux-spezifisches Problem ist. Unter Windows habe ich oft das gleiche Ruhezustand Problem. Nur ist es dort noch schwieriger zu beheben.

In diesem Fall ist es der "Logitech MX Mechanical Bolt Receiver", also der USB-Dongle der Tastatur, der den Ruhezustand verhindert. Vom gleichen Hersteller gibt es z.B. auch die Tastatur Logitech MX Keys S (Amazon Partner Link). Der USB-Empfänger dieser Tastatur funktioniert unter Linux ohne Probleme. Was genau das Problem mit dem Mechanical Bolt USB Receiver ist, ob es an Fedora 41 liegt, ob Logitech hier einen Standard nicht einhält oder eine Funktion nicht unterstützt, weiß ich leider nicht.

Bei deinem Notebook kann es ein anderes USB-Gerät sein, das den Ruhezustand verhindert hat, es muss nicht immer eine Tastatur sein. Es kann auch ein USB-Drucker, eine USB-Festplatte oder eine USB-Maus sein. Natürlich könnte man auch einfach alle USB-Geräte unterdrücken, aber ich möchte schon, dass man z.B. mit der Maus den Rechner aus dem Ruhezustand holen kann.

Die integrierte Tastatur funktioniert allerdings.

Bei Notebooks ist die Tastatur nicht über USB angeschlossen, daher funktioniert sie auch, wenn man die "wakeup" Möglichkeiten der USB-Controller abschaltet.

face-smile

Gruß
Frank
Spirit-of-Eli
Spirit-of-Eli 19.03.2025 um 10:51:53 Uhr
Goto Top
Ich habe hier eine Dockingstation wo alles dran hängt.
Hier sind kabelgebundene Logitech Geräte im Einsatz.

Ich trage nachher mal alle Infos zusammen.

Mir wäre ein simpler Weg hilfreich, wie ich herausfinde welches Geräte für den Wake verantwortlich ist.
Frank
Frank 19.03.2025 aktualisiert um 11:07:41 Uhr
Goto Top
Hi,

führe wie oben beschrieben ein:
lsusb
aus und du bekommst alle USB Geräte angezeigt.

Gruß
Frank
Spirit-of-Eli
Spirit-of-Eli 19.03.2025 um 12:08:59 Uhr
Goto Top
Ich meine welches Geräte tatsächlich für aufwecken verantwortlich ist.
Frank
Frank 19.03.2025 aktualisiert um 13:38:12 Uhr
Goto Top
Naja, mit lsusb bekommst du ja eine Liste all deiner USB-Geräte, die du dann einfach mit ein- oder aus, alternativ mit rein- oder rausstecken abarbeiten kannst. Dabei immer testen, ob das Standby funktioniert oder nicht. Das ist der "einfache" Weg.

Es gibt natürlich auch die "aufwendige" Alternative, das per Terminal und Logfile zu erkennen:

Mit cat /proc/acpi/wakeup siehst du alle Geräte, die für den "wakeup" in Frage kommen. Dort wo "*enabled" im Status steht, das sind die Geräte, die in Frage kommen. Jedes Gerät oder Controller kannst du ein- oder ausschalten.

Beispiel:
cat /proc/acpi/wakeup

Meine Ausgabe:
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

Jetzt schaltest du in den Standby per Terminal:
systemctl suspend
(Oder mit der Maus auf "Bereitschaft" klicken)

Sollte der Rechner jetzt nicht in den Standby gehen, schaut man sich das Log dazu an:
journalctl -b | grep -i "resume\|wake"  

Bei mir stand da:
Mär 15 22:54:45 catalyst kernel: ACPI: PM: Low-level resume complete
Mär 15 22:54:45 catalyst kernel: xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
Mär 15 22:54:45 catalyst kernel: PM: resume devices took 1.567 seconds
Mär 15 22:54:45 catalyst NetworkManager[1624]: <info>  [1742075685.4419] manager: sleep: wake requested (sleeping: yes  enabled: yes)

Es war also der "xhci_hcd 0000:02:00.0" Controller, der den Standby verhindert. Hier ist "0000:02:00.0" die PCI-Adresse des Geräts, das den Fehler verursacht. In der Ausgabe von /proc/acpi/wakeup sucht man nach demselben PCI-Pfad und findet dann das Gerät dazu:
PTXH S4 *enabled pci:0000:02:00.0
PTXH ist einfach der ACPI-Name für diesen spezifischen Controller in deinem System.

Jetzt kannst du dieses Gerät manuell ausschalten und danach den Standby testen:
echo "PTXH" > /proc/acpi/wakeup  
systemctl suspend

Wenn der Standby jetzt funktioniert, hast du den Controller, der den Standby verhindert, schon mal gefunden.

Jetzt schauen wir uns den USB-Controller genauer an und identifizieren ihn anhand der PCI-Adresse (nur zur Info):
lspci -s 02:00.0 -v
02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 xHCI Compliant Host Controller (rev 01) (prog-if 30 [XHCI])
	Subsystem: ASMedia Technology Inc. Device 1142
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Memory at fcca0000 (64-bit, non-prefetchable) [size=32K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd

Jetzt suchen wir nach allen Geräten an diesem USB-Controller (den Code einfach so ins Terminal eingeben):
for dev in $(ls -d /sys/bus/usb/devices/usb*); do
  if [ -f $dev/authorized_default ]; then
    controller=$(readlink -f $dev/controller 2>/dev/null || echo unknown)
    if [[ "$controller" == *"0000:02:00.0"* ]]; then  
      bus_num=$(basename $dev | sed 's/usb//')  
      echo "Bus $bus_num ist mit dem Controller 0000:02:00.0 verbunden"  
      echo "Geräte an diesem Bus:"  
      lsusb | grep "Bus 00$bus_num"  
    fi
  fi
done

Meine Ausgabe:
Bus 1 ist mit dem Controller 0000:02:00.0 verbunden
Geräte an diesem Bus:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 003: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 001 Device 004: ID 25a7:fa0b Areson Technology Corp 2.4G Wireless Receiver
Bus 2 ist mit dem Controller 0000:02:00.0 verbunden
Geräte an diesem Bus:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Damit hat man nun die Liste der USB-Geräte, die an diesem USB-Controller hängen. Die zuverlässigste Methode wäre jetzt, jeweils ein Gerät physisch zu entfernen und zu testen, ob der Standby dann funktioniert.

Alternativ kannst du nun auch den USB-Autosuspend für die einzelnen Geräte deaktivieren. Dazu musst du aber noch den "devices" Pfad für das jeweilige Gerät finden. Dazu brauchst du nun die Geräte ID. ("046d" als Beispiel für den Bus 001 Device 003: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver aus der oberen Ausgabe). Die ID von "$vendor" = "" musst du im Script entsprechend anpassen:

for dev in /sys/bus/usb/devices/*; do
  if [ -f "$dev/idVendor" ]; then  
    vendor=$(cat "$dev/idVendor" 2>/dev/null)  
    if [ "$vendor" = "046d" ]; then  
      echo "Logitech-Gerät gefunden: $dev"  
      product=$(cat "$dev/idProduct" 2>/dev/null)  
      echo "Produkt-ID: $product"  
      if [ -f "$dev/power/wakeup" ]; then  
        wakeup=$(cat "$dev/power/wakeup" 2>/dev/null)  
        echo "Wake-up-Status: $wakeup"  
      fi
    fi
  fi
done

Als Ergebnis erscheint:
Logitech-Gerät gefunden: /sys/bus/usb/devices/1-5
Produkt-ID: c548
Wake-up-Status: disabled

Jetzt hast du den Pfad vom Logi Bolt Receiver -> /sys/bus/usb/devices/1-5 und kannst den Wake-Up Status ein- oder ausschalten:
# Um Wake-up zu deaktivieren (falls es enabled ist)
sudo sh -c 'echo disabled > /sys/bus/usb/devices/1-5/power/wakeup'  

# Oder um Wake-up zu aktivieren (falls es disabled ist)
sudo sh -c 'echo enabled > /sys/bus/usb/devices/1-5/power/wakeup'  

Den aktuellen Status bekommst du mit:
cat /sys/bus/usb/devices/1-5/power/wakeup

Um es permanent zu machen, brauchst du dann die oben genannte udev-Regel:
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  

Gefolgt von einem:
sudo udevadm control --reload
sudo udevadm trigger

Das ist aber deutlich aufwendiger, als die einzelnen USB-Geräte, die an dem USB-Controller hängen, ein- oder auszuschalten oder sie rein- oder rauszustecken. Aber machbar ist das natürlich face-wink

Viel Spaß beim Testen.

Gruß
Frank