Kernel 6.11, KDE - seltsames/falsches WLAN Verhalten

Started by ro_sid, 2024/10/06, 15:13:37

Previous topic - Next topic

ro_sid

Eine Beobachtung:
Seit Einführung des 6.11er (Siduction-)Kernels wird meine WLAN-Einstellung beim Einloggen in den KDE-Desktop nicht mehr (richtig) ausgeführt. Eingestellt habe ich den "Flug(zeug)"-Modus (bei explizit ausgeschaltetem WLAN). Wenn ich das jetzt (nach einem Boot) tue, sind die "Häkchen" immer noch so gesetzt (kein WLAN, Flugmodus), also weiterhin übernommen. Jedoch ist meine WLAN-LED eingeschaltet und alle WLANs in der Nähe werden angezeigt.
Ändern läßt sich das nur(!), indem ich den Flugmodus aus- und das WLAN einschalte, dann WLAN aus- und Flugmodus einschalte.
Nicht dramatisch, aber bemerkenswert. Ich vermute den Kernel als schuldigen Part, also daß er (immer) mit eingeschaltetem WLAN startet.

Penyelam

Ich hatte gestern W-Lan aus, weil ich den Läppi über Kabel verbunden hatte.
Heute Kabel ab, Läppi eingeschaltet, W-Lan war immer noch aus.

ro_sid

@Penyelam: Aha, danke. Dann ist mein erster Gedanke (Kernel schaltet WLAN immer an) falsch.
Ich werde mal ältere (6.10, 6.2) booten und sehen, was dort passiert.

ro_sid

Folgende Analyseergebnisse: Beide ältere Kernel zeigen das (Fehl-)Verhalten nicht! Nur der 6.11er.
Das WLAN wird (erst) bei der Anmeldung "eingeschaltet", nicht (schon) vorher. [Also auch nicht vom Kernel von vorneherein!]
Es hat also mit dem Kernel und dem (KDE(?)-)Login zu tun.

hendrikL

Was sagt denn "rfkill list" bzw urfkill dazu?

ro_sid

Quote from: hendrikL on 2024/10/07, 10:28:53
Was sagt denn "rfkill list" bzw urfkill dazu?
#rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

... und das, obwohl der Flugmodus eingestellt ist, womit Bluetooth und WLAN abgeschaltet sein müßten - und früher auch waren.

hendrikL

rfkill block 2, sollte das wlan abstellen, reboot und checken.
Dann sollte es funktionieren via gui (NM), aktivieren und deaktivieren des wlan und die entsprechende Einstellung auch einen reboot überstehen, theoretisch.

ro_sid

@hendrikL: Danke für den Vorschlag. Leider funktioniert er nur theoretisch :(.
Das Blocken hat zunächst den gewünschten Effekt, übersteht aber leider den Reboot nicht.
Interessanterweise funktioniert die Taskleiste des Desktops genauso. Der Zyklus "(Flugmodus aus, WLAN ein,) WLAN aus, Flugmodus ein" erzeugt denselben Zustand wie "rfkill block 2": Soft blocked: yes bei phy0.

hendrikL

seltsam, hier™ funktioniert es, auch mit dem 6.11 kernel!
mal systemctl status systemd-rfkill.service angeschaut? journalctl oder dmesg befragt?

ro_sid

Quote from: hendrikL on 2024/10/07, 22:59:13
seltsam, hier™ funktioniert es, auch mit dem 6.11 kernel!
mal systemctl status systemd-rfkill.service angeschaut? journalctl oder dmesg befragt?
Dem Service geht es hervorragend schlecht ("inactive (dead)"):)
# systemctl status systemd-rfkill
○ systemd-rfkill.service - Load/Save RF Kill Switch Status
     Loaded: loaded (/usr/lib/systemd/system/systemd-rfkill.service; static)
     Active: inactive (dead) since Tue 2024-10-08 02:46:48 CEST; 49s ago
   Duration: 5.004s
Invocation: 031b52afeb0541b3a2b0349cfec19cba
TriggeredBy: ● systemd-rfkill.socket
       Docs: man:systemd-rfkill.service(8)
    Process: 3789 ExecStart=/usr/lib/systemd/systemd-rfkill (code=exited, status=0/SUCCESS)
   Main PID: 3789 (code=exited, status=0/SUCCESS)
   Mem peak: 1.6M
        CPU: 8ms

Okt 08 02:46:43 tp-p72 systemd[1]: Starting systemd-rfkill.service - Load/Save RF Kill Switch Status...
Okt 08 02:46:43 tp-p72 systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
Okt 08 02:46:48 tp-p72 systemd[1]: systemd-rfkill.service: Deactivated successfully.

Man achte vor allem auf das "Deactivated successfully". Der "●" ist übrigens grün ;).
[im journalctl und dmesg sind mir keine Besonderheiten zu "iwlwifi" aufgefallen.]

Es scheint sich hier jedoch um eine Besonderheit meines Systems zu handeln, wenn auch jederzeit reproduzierbar vom Kernel abhängig. Daher sollten wir vielleicht die Entwicklung mit dem/n nächsten Kernel/n abwarten, solange es nicht noch jemand anderen betrifft.

PS: Die Ausgabe des systemd-rfkill.service sieht übrigens im "Erfolgsfall" (alter Kernel) genauso aus.

Erst einmal vielen Dank!

Edit: PS hinzugefügt.

der_bud

Hast Du zufällig das Tool/Paket tlp installiert?
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

ro_sid

Quote from: der_bud on 2024/10/09, 14:15:47
Hast Du zufällig das Tool/Paket tlp installiert?
Ich habe nachgesehen. Nein, ist (in Siduction) nicht installiert. Auch betreibe ich das Gerät fast ausschließlich am (Strom-)Netz. So auch in jedem hier aufgeführten Testfall.

ro_sid

Das Problem hat sich mit KDE/Plasma6 für mich erledigt.

Ich sprach zu früh, denn ich hatte nicht bemerkt, daß SDDM mich - abweichend von meinen Standard - in "Wayland" eingeloggt hat. Ein Umstand auf den mich erst ein Posting in diesem Forum in einer anderen Gruppe aufmerksam machte. Unter "Wayland" ist das Problem keins (mehr), jedoch (weiterhin) unter "X11".
Das Verhalten (unter X11) hängt ebenfalls weiterhin (auch) an der Kernel-Version. Der "6.10"er macht auch jetzt keine Probleme unter "X11".

Edit: Korrekturen hinzugefügt.