Linux TLP: rfkill für WWAN/Quectel deaktivieren

[Lufo]

Hallo Forum,
ich breche mir an folgendem Problem einen ab: Die Quectel em05-g funktioniert zwar einwandfrei unter Linux, aber immer nur bis das Gerät einmal in den suspend geht. Danach wird die Karte als neues Modem erkannt und es ist keine Verbindung mehr möglich.
Das Problem mit Quectel und Suspend/Standby scheint irgendwie bekannt zu sein. Ich wollte daher zunächst USB autosuspend deaktiveren. Das habe ich zunächst über udev rules und andere Sachen probiert, hat das Problem aber nicht gelöst.
Ich bin nun von "tuned" auf tlp/tlp-rdw gewechselt und nun zu der Erkenntnis gekommen, dass das Problem wohl nicht nur mit USB autosuspend zu tun hat, sondern auch mit rfkill, welches alle Wireless Komponenten zum suspend ausschaltet. Leider konnte ich hierfür noch keine Lösung finden. Ziel wäre dass die Karte weder stromlos noch sonst wie deaktiviert wird sondern einfach an bleibt.
Meine TLP-Konfiguration sieht aktuell so aus (USB_EXCLUDE_WWAN wahrscheinlich redundant):

USB_AUTOSUSPEND=0
USB_EXCLUDE_WWAN=0
WWAN_DISABLE=n

Gemäß Anleitung habe ich auch rfkill "gemasked".

journalctl -b | grep -i wwan

sagt unter anderem:

rfkill1: found WWAN radio killswitch (at /sys/devices/platform/thinkpad_acpi/rfkill/rfkill1) (platform driver thinkpad_acpi)

Hat noch jemand eine Idee, oder fische ich im ganz falschen Teich?

 

[Christina]

Hat noch jemand eine Idee

Einen Tipp habe ich so spontan leider nicht, aber ich muss mein Quectel RM520N-GL 5G Sub6 auch noch unter openSUSE zum Laufen bringen.
Vielleicht können wir uns dann gegenseitig weiterhelfen.

Gemäß Anleitung habe ich auch rfkill "gemasked".

Wo steht diese Anleitung (Link)?

Lg, Christina

Edit: Nur der Vollständigkeit halber: Das Quectel RM520N-GL 5G Sub6 läuft unter openSUSE Slowroll „out-of-the-box“.

 

[Lufo]

Wo steht diese Anleitung (Link)?

Punkt Installation in der TLP-Dokumentation: https://linrunner.de/tlp/installation/index.html

 

[zwieblum]

Schau mal da:

USB Autosuspend Feature Disconnects Active Devices

USB Power Management and USB Autosuspend can sometimes suspend AM01. Here we will discuss how to disable USB Power Management for AM01.

kb.atomminer.com

Oder im Kernel:

Power Management for USB — The Linux Kernel documentation

www.kernel.org

Coclusio: "usbcore.autosuspend=-1" zu den Kernelparameteren hinzufügen sollte was bewirken.

 

[linrunner]

USB_AUTOSUSPEND=0
USB_EXCLUDE_WWAN=0 #
WWAN_DISABLE=n

USB_EXCLUDE_WWAN ist redundant und funktioniert zudem nicht mit allen WWAN Karten.
Die Einstellung WWAN_DISABLE gibt es leider nicht in TLP .

Ob Autosuspend für die Karte aus ist, siehst Du mit tlp-stat -u, da steht dann in der Zeile der Karte control = on. Einige Treiber aktivieren auch von sich aus den Autosuspend. Da hilft dann USB_AUTOSUSPEND=0 nicht weiter, da das bewirkt, dass TLP gar nichts am Autosuspend verändert. In dem Fall musst Du die Karte in USB_DENYLIST="vvvv:dddd" eintragen oder den radikalen Ansatz von @zwieblum nehmen.

Gemäß Anleitung habe ich auch rfkill "gemasked".

Du willst sagen, Du hast systemd-rfkill.service maskiert. Der Service läuft aber nur bei Systemstart und -shutdown, bei Suspend/Resume wird er nicht aufgerufen. Steht in der Manpage (und ist auch so).

rfkill schaltet nur den HF-Transmitter von Bluetooth/WLAN/WWAN Karten aus und ein, nicht jedoch die ganze Karte. Ist also eine Schnittstelle um Wünsche aus Richtung des Users zu erfüllen.

Um zu sehen ob rfkill die Karte doch anfasst, kannst Du einfach die Ausgabe von rfkill list oder tlp-stat -r vor und nach dem Suspend anschauen bzw. vergleichen.

Soweit ich s2idle verstanden habe, geht der Kernel beim Suspend seine gesamte Treiberkette durch und jeder Treiber deaktiviert das Device für das er zuständig ist.

Ich halte dein Symptom für ein Problem des zuständigen Kerneltreibers. Du solltest herausfinden, welcher das ist (bei WWAN meist mehrere). Dann könntest Du probieren nach dem Resume den/die Treibermodule zu entladen und erneut zu laden.

 

[Lufo]

Richtig, der Fehler liegt klar im Treiber selbst. Das Gerät sollte auch nach Suspend ordnungsgemäß funktionieren.
Das Neu-Laden der Module (cdc_mbim, option) hat den selben Effekt wie der Suspend selbst, nämlich dass die Karte eine neue Modem-Nummer kriegt und keine Verbindung mehr hergestellt werden kann.
Muss ich das Notebook wohl weiterhin jedes Mal neustarten, wenn ich es unterwegs brauche.
Trotzdem Danke für den Input.

 

[linrunner]

Kernelprobleme lassen sich manchmal durch eine andere Kernelversion beheben. Schon probiert?

EDITH sagt: diverse Fundstellen weisen auch auf (angeblich) behobene Probleme mit modemmanager bzw. FCC Unlock hin,
z.B. https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1998111

EDITH2: einen älteren Forumsthread gibts auch:
https://thinkpad-forum.de/threads/wwan-linux-mit-den-2023-modellen.237003/

 

[Christina]

Die Quectel em05-g funktioniert zwar einwandfrei unter Linux, aber immer nur bis das Gerät einmal in den suspend geht. Danach wird die Karte als neues Modem erkannt und es ist keine Verbindung mehr möglich.

Hi, ich bin zwar noch fertig mit der Einrichtung, kann aber den Fehler bestätigen:
Das Quectel RM520N-GL 5G Sub6 ist nach einem Suspend to RAM aus Gnome 48 komplett verschwunden – bis zu einem Reboot.
Aktuell läuft hier Tumbleweed-Slowroll:

$ uname -a
Linux slowroll 6.15.7-1-default #1 SMP PREEMPT_DYNAMIC Fri Jul 18 08:58:35 UTC 2025 (3e63d43) x86_64 x86_64 x86_64 GNU/Linux

 

[Crisser67]

Aktuell läuft hier Tumbleweed-Slowroll

Ok, ist zwar OT, aber trotzdem.: Bist damit zufrieden, irgendwelche Nachteile ggü. anderen KDE- Distris ?

 

[Christina]

O.K. Das ist jetzt schon sehr off-topic.
Aber kurz gesagt, ist openSUSE schon mindestens die letzten 10 Jahre eher eine Distribution für KDE-Anhänger.
Ich verwende neben Gnome sehr gerne noch XFCE, aber XFCE unterstützt Wayland aktuell nur experimentell, das ich für scharf abgebildetes „fractional scaling“ beim 14-Zoll-WUXGA-Display zwingend brauche.
Unter openSUSE Leap 15.6 (Gnome 45.3) habe ich Wayland trotz Kernel- und Mesa-Update nicht zum Laufen bekommen (X11 fallback).
Unter Leap 16.0 Beta (Stand: Release Candidate) friert mein P14s Gen 6 (AMD) nach der Installation mit dem Neustart sofort ein. Zudem ärgert mich die Bevormundung mit dem btrfs-Dateisystem sehr! Mit Leap 16.0 findet ein sehr großer Umbruch statt. Vielleicht muss ich dann openSUSE den Rücken kehren. Dann wird's aber wieder eine RPM-basierende Distribution.

openSUSE Tumbleweed war mir immer schon zu heftig mit seinen abertausenden Updates, u.U. manchmal mehrmals pro Woche.
Tumbleweed-Slowroll ist immer noch experimentell, das merkt man etwas. Aber die Hardware des P14s Gen 6 (AMD) läuft auf Anhieb.
Bloß das Quectel RM520N-GL 5G Sub6 lässt leider noch nicht verbinden. Da mache ich die nächsten Tage ein neues Thema auf.
Edit: Das Quectel RM520N-GL 5G Sub6 läuft unter openSUSE Slowroll mit Gnome 48 „out-of-the-box“.