[DE] [gelöst] poweroff doesn't work

[efilooser]

Arbeite seit 6 Jahren etwa erfolgreich mit siduction auf Lenovo T460s (dual neben Win X). DU gelingt, aber etwa seit 2021 etwa fährt das System nach suspend, hibernate und poweroff nicht sauber runter. irgendetwas bleibt noch an und saugt den Akku leer: es läßt sich nur durch langes Drücken der Powertaste beenden.

"systemctl poweroff" hatte ich ohne Erfolg probiert.

Abhilfe war Rückkehr zu Kernel 5.15.11-4: da geht alles...

Eine Neuinstallation XFCE mit Euren iso's oder mit bullseye aus den Debian-Quellen (ssd gewechselt) zeigt das gleiche Verhalten.

Wie kann ich erfolgreich mal wieder neu anfangen?

inxi -S: System:
  Host: ***** Kernel: 5.15.11-4-siduction-amd64 arch: x86_64 bits: 64
    Desktop: Xfce v: 4.16.1 Distro: siduction 18.3.0 Patience - xfce -
    (201805132203)


Edit: (hendrikL) habe das Ganze als gelöst gekennzeichnet.

[hendrikL]

Probiere mal 'systemctl isolate poweroff.target'

[samoht]

Kann ich nicht bestätigen!
Funktioniert wie gewohnt.

Code: [Select]

System:
  Host: tuxxy2-sid Kernel: 6.0.6-1-siduction-amd64 arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.26.0 Distro: siduction 21.1.1 C-Blues - kde -(202102190822)

[der_bud]

@efilooser, zeige doch auch bitte mal den Inhalt der Datei  /etc/systemd/logind.conf

[efilooser]

systemctl isolate poweroff... funktioniert nicht im gewünschten Sinn.

Habe mein Mikrofon stumm geschaltet: dabei leuchtet orange LED unter Taste F4. Nach dem Abschalten ist zwar der Bildschirm aus, die Taste leuchtet weiter und der Einschalter funktioniert nicht. Erst nach etwa 10sec Drücken wird ein reset durchgeführt: dann läßt sich die Maschine wieder einschalten (Neustart).

[efilooser]

/etc/systemd/login.conf siehe Anhang: hoffe, alles richtig gemacht zu haben.

[hendrikL]

Ist das Mikrofon im BIOS aktiviert? Wake on lan? was erzählt journalctl? das Microphone findet man unter Security I//O Port ....

[der_bud]

Zur logind.conf: nach meiner Erinnerung war die in Siduction wegen ähnlicher Probleme mal angepasst worden auf

Code: [Select]

KillUserProcesses=yes statt

Code: [Select]

#KillUserProcesses=noProbiers damit mal...

[efilooser]

Mikrofon funktioniert, läßt sich an- und aus- schalten (Fn-Tasten gehen auch).

"Wake on LAN" ist deaktiviert.

Ausgabe journalctl kurz vor dem Ende im Anhang.

Zu ändernde Zeile war in fehlerhafter Installation schon aktiv, sorry.

Beim Booten erscheinen für kurze Zeit folgende Zeilen:
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Read NO_PAID± Request device [00:12:4] fault addr 0xa
ffff000 [fault reason 0x02] Present bit in context entry is clear
tpm tmp0: Operation Timed out

Derzeitiger Zustand: keine Besserung.

systemctl reboot bringt den Rechner in einen Wartezustand. Es geht erst weiter, wenn die Powertaste länger gedrückt wird.

[Mister00X]

Hast du ein ähnliches Problem auch unter Windows?

Und  benutzt du irgendeine "exotische" Software? Ich hatte da mal einen Fall wo ein Programm im "uninterruptible sleep" feststeckte und sich das System dann erst nach 15 oder mehr Minuten heruntergefahren ist, selbst als der shutdown Vorgang eigentlich schon abgeschlossen war.

EDIT: Oh und wo wir schon dabei sind ich denke in deinem Fall könnte ein

Code: [Select]

inxi -Fxz etwas nützlicher sein als nur inxi -S

[efilooser]

Hallo,

Habe folgende System-Pakete, die gut auf der produktiven Platte funktionieren: linux-headers-5.15.11-4-siduction-amd64, linux-image-5.15.11-4-siduction-amd64, siduction-archive-keyring, siduction-scripts, udev-config-siduction

Sie kamen durch apt dist-upgrade oder apt full-upgrade im Verlauf der Zeit. Neuere linux-images und header gehen nicht: habe es daher bei o.g. kernel belassen: alles geht...

Besondere software außerhalb der repository oder Selbstgestricktes nutze ich nicht (willentlich).

Win... 10 (duale Installation) macht keine Zicken.

a) Habe aktuelles siduction-XFCE auf einer externen SSD installiert: fährt nicht sauber herunter. inxi -Fxz steht im Anhang.

b) Habe aktuelles debian-XFCE-inkl.non-free auf externer SSD installiert: fährt nicht sauber herunter.

c) arch-linux ohne Grafik fährt mit kernel 19.0.0 sauber herunter.

15min oder länger wollte ich nicht warten. - Der Fehler fiel vor 1-2 Jahren auf, als nach hibernate der Akku leer war und die Maschine neu anfing... Guter Indikator ist das stumm-geschaltete Mikro: die orangene LED in Taste F4 leuchtet weiter bei hängender Maschine.

Merkwürdig, wo doch die Maschinen mich unterstützen sollten...

[efilooser]

Hallo,

habe neue Festplatte mit aktuellem siduction-XFCE erstellt. Oben empfohlene Einstellungen sind aktiviert: keine Verbesserung, der Ausschaltzustand wird nicht erreicht.

Habe nun über apt Paket "linux-image-5.15.11-2-siduction-amd64" und die headers dazu nachgeladen, installiert und mit altem kernel neu gebootet: alles geht 

Zuvor genannte Meldungen zu DMAR sind verschwunden.

Meine Frage nun: wie komme ich ohne zu großen Zeitaufwand (!) an die schuldigen CONFIG-Variablen? Oder wie kann ich mir sonst helfen?

[hendrikL]

Auf die Gefahr hin, dass ich vollkommen daneben liege (dies ist jetzt einfach mal ein Schuss ins Blaue), probiere mal folgendes;

schreibe in die Kernel-Bootzeile  (beim Booten mit einem aktuellen Kernel)

Code: [Select]

intel_iommu=igfx_off
Vielleicht liegt dort das Problem, ansonsten hört es sich wie ein acpi Problem an.
Nebenbei bemerkt, ich arbeite mit einem TP 410 und habe keine Probleme mit poweroff.

[efilooser]

Hallo,

habe den Code an die kernel-Zeile angehängt und gebootet: gleiches Verhalten beim Ausschalten wie zuvor (nur hard reset möglich). Kann man die Variablen im laufenden System irgendwo abfragen (bei modinfo kam ich nicht weiter...)?

Komme mir schon reichlich blöd vor: Berater vor Ort hatten die Augen verdreht, es aber reproduzieren können.

Bis vor etwa einem Jahr war ja auch alles ok (bin auch sonst mit dem T460s immer noch zufrieden). Besonders ärgerlich ist es nach hibernate, wenn irgendwann der (gealterte) Akku leer ist...

Hatte vermutet, dass es eine verschleppte Einstellung sei - aber das sollte auf einer Neuinstallation auf SSD kein Thema sein.

Werde mal bei den acpi CONFIGs suchen...

Sonst noch eine Idee?

[hendrikL]

Kann man die Variablen im laufenden System irgendwo abfragen (bei modinfo kam ich nicht weiter...)?

Code: [Select]

cat /proc/cmdline
Mit Systeminformation zusammen:

Code: [Select]

inxi -Sa
Zu dem poweroff/hibernate Problem.
Da hilft wirklich nur dmesg und  journalctl durchforsten (nicht nur nach Fehlern, vielleicht ist es ja eine Variable), ebenso das BIOS (irgendeine Einstellung), als auch die systemd variablen kontrollieren.
Was mich wundert ist, dass dieses Problem mit einem 5.x Kernel nicht auftritt!