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.
Probiere mal 'systemctl isolate poweroff.target'
Kann ich nicht bestätigen!
Funktioniert wie gewohnt.
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)
@efilooser, zeige doch auch bitte mal den Inhalt der Datei /etc/systemd/logind.conf
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).
/etc/systemd/login.conf siehe Anhang: hoffe, alles richtig gemacht zu haben.
Ist das Mikrofon im BIOS aktiviert? Wake on lan? was erzählt journalctl? das Microphone findet man unter Security I//O Port ....
Zur logind.conf: nach meiner Erinnerung war die in Siduction wegen ähnlicher Probleme mal angepasst worden auf KillUserProcesses=yes statt #KillUserProcesses=noProbiers damit mal...
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.
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
inxi -Fxz etwas nützlicher sein als nur inxi -S
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...
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?
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)
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.
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?
ZitatKann man die Variablen im laufenden System irgendwo abfragen (bei modinfo kam ich nicht weiter...)?
cat /proc/cmdline Mit Systeminformation zusammen:
inxi -SaZu 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!
Versuche es mal damit, im Bios bei "TPM" von Version 2.0 nach 1.2 umzustellen, dann speichern und rebooten.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990868
Ich bin von Eurer Leistung absolut beeindruckt:
TPM nach TPM1.2 im BIOS umgestellt und alles geht !!!
Kann mir keinen Reim darauf machen, aber ganz vielen Dank !!!
Hoffe, dass zukünftig "gelöst" im Betreff erscheint
ZitatHoffe, dass zukünftig "gelöst" im Betreff erscheint
Das mußt du schon selbst machen.
Bearbeite deinen 1.Beitrag in der Betreffzeile mit einem vorangestellten [gelöst]. ;)
Zitat von: efilooser in 2022/11/02, 08:27:49
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.
Bin den Angaben gefolgt: TPM im BIOS auf TPM1.2 und alles geht.
intel_iommu=... oder acpi=off hilft nicht.
Würde gerne dazu lernen:
1) was hätte ich für die Selbsthilfe studieren müssen?
2) mit welchen Stichworten hätte ich den Tipp von BananaBoat in den Suchmaschinen gefunden?
Einfügen gelöst in das Subject gelingt mir nicht: meine erste Mitteilung hat keinen button "modify"...
Zitat von: efilooser in 2022/12/17, 11:25:06
Zitat von: efilooser in 2022/11/02, 08:27:49Einfügen gelöst in das Subject gelingt mir nicht: meine erste Mitteilung hat keinen button "modify"...
Auch wenn hendrikL inzwischen den Job erledigt hat: Wenn du angemeldet bist, dann findest du bei allen Beiträgen in der rechten oberen Ecke den Button für ein Zitat. Bei den eigenen Beiträgen ist rechts neben dem ,,Zitat"-Button noch einer zum ,,
Ändern" deines Beitrages. In der deutschen Version steht da natürlich nicht modify drauf.
Ein schönes Advents-Wochenende
edlin
Zitat von: edlin in 2022/12/17, 13:38:59...Bei den eigenen Beiträgen ist rechts neben dem ,,Zitat"-Button noch einer zum ,,Ändern" deines Beitrages...
Da gibts aber ein Ablaufdatum ab wann ältere Beiträge nicht mehr änderbar sind. Ich kann einen Beitrag von mir von Anfang November auch nicht mehr editieren, einen von vor einer Woche schon. Für den Threadinhalt ist das auch sinnvoll, um nicht nach Monaten noch den Sinn zu entstellen, für den Titel entfällt damit leider die Möglichkeit ohne Admineingriff alte Themen auf gelöst zu setzen.
Stimmt, daran hatte ich nicht mehr gedacht; mir war auch nicht präsent, dass das Ausgangsposting schon so ,,alt" ist. Die Zeit vergeht halt schneller als man denkt.
Müssen wir halt Probleme schneller lösen. Dann passiert das nicht mehr. ;D
Schönen Restadvent noch,
edlin