[Gelöst] System friert sporadisch ein

[philonous]

Hallo,

hab mir kürzlich ein Lenovo T430 geholt und das mit einem frischen Debian 7.0 (Kernel 3.2.0-4-amd64) bestückt.
Leider friert das System sporadisch einfach ein. Ich weiß, ich weiß: Das ist keine Fehlermeldung ...

Einfrieren heißt: Es geht kein Strg-Alt-Backspace, kein Strg-Alt-F1, kein Alt-Druck-R. Maus und Tastatur sind tot.

Meine erster Ansatz war ein Blick in die Logfiles:

• /var/log/kern.log
  /var/log/daemon.log und
  /var/log/messages

Das einzige, was mir hier aufgefallen ist, war:

Code: Alles auswählen

Feb 11 21:43:20 panther kernel: [   20.319870] colord-sane[2887]: segfault at 8 ip 00007f70597d85cc sp 00007fffab9e2dc0 error 6 in libdbus-1.so.3.7.2[7f70597b0000+44000]
Feb 11 21:43:58 panther kernel: [   57.463656] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Feb 11 21:49:37 panther rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2148" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Feb 11 22:51:43 panther kernel: imklog 5.8.11, log source = /proc/kmsg started.

Aber aus meiner Laiensicht sind das zwar keine erfreulichen Nachrichten (segfault, HUPed ...), aber auch erstmal nichts, was den Freeze erklären würde ...

Daher die Frage: Welche Informationen könnten weiterhelfen, wo könnte ich weitersuchen?
(Hardware will ich fast ausschließen, zumindest am Alter der Hardware sollte es eigentlich nicht liegen. )

Mir ist außerdem aufgefallen, dass es mittlerweile öfter passiert ist, als ich mit UMLet (Java Tool für UML Diagramme) gearbeitet hab.
Möglicherweise kann man den Freeze dadurch reproduzieren, so ganz deterministisch verhält es sich aber noch nicht.

Könnte man in einer Konsole alle Ausgaben des Kernels "live" bekommen, sodass man noch die letzten Meldungen dort sehen kann, bevor das System "abraucht"?

Bin über jeden Hinweis dankbar!

Viele Grüße,
phil

[Cae]

Könnte man in einer Konsole alle Ausgaben des Kernels "live" bekommen, sodass man noch die letzten Meldungen dort sehen kann, bevor das System "abraucht"?

Code: Alles auswählen

# echo 9 >/proc/sysrq-trigger

wuerde praktisch alle Meldungen, die normalerweise nur im dmesg stehen, auch auf die Konsole schreiben. Dummerweise nicht in ein virtuelles Terminal, aber (mit Handarbeit) auf eine Serielle Schnittstelle. Setzt allerdings Zweithardware und Nullmodemkabel voraus.

Der Segfault im Log ist nicht *so* kritisch, aber ein Problem. Die "was HUPed"-Meldung besagt dagegen nur, dass er die Logfile zu- und wieder auf gemacht hat (zumindest laeuft's darauf hinaus, SIGHUP ist nur ein Signal, was der Prozess empfangen hat).

Gruss Cae

[novalix]

Hi,
Du könntest auch noch

Code: Alles auswählen

~/.xsession-errors

bzw.

Code: Alles auswählen

/var/log/Xorg.0.log

checken.

Ins Blaue, niels

[Huck Fin]

Erste Fehlersuche immer RAM.
Hier empfiehlt sich Memtest86
Zweite Fehlersuche immer CPU Temp.
Kann man teilweise im Bios überprüfen.
In den seltensten Fällen liegt es an der Software.

[pferdefreund]

schon mal probiert, die kiste bei freeze extern (telnet, ssh) anzusprechen ? - Eventuell kackt ja wirklich nur der x-server ab, wenn da intensiv mit Grafik gearbeitet wird. Ist Magic SYSRQ aktiviert ? Eventuell hilft auch ein neuerer Kernel. Ich hab hier einen Server mit Stable und trotzdem problemlos Kernel 3.7.2 im Einsatz (Original von Kernel.org). Dabei kann man auch gleich die zum booten notwendigen Treiber fest einkompilieren, (SCSI nicht vergessen) und die initrd entsorgen - ich hasse die... Ich tippe auf Grafikchip wird zu heiß oder Speicherfehler.

[philonous]

Danke für eure Antworten!

@Cae, pferdefreund: Zwar hab ich kein Nullmodemkabel, aber die Idee mit dem ssh-Server finde ich sehr gut.
Den werd ich jetzt mal installieren, einen zweiten Rechner zum Verbinden habe ich hier.

@Huck Fin: Memtest86+ ist schon auf CD gebrannt, werd ich demnächst mal komplett durchlaufen lassen. Aber wie gesagt: Ich glaub nicht so wirklich an einen Hardware-Fehler in diesem Fall, zumal sie komplett neu ist. (Ich weiß, das sagt nicht zwingend, dass es nicht an der Hardware liegt. Reduziert aber aus meiner Sicht die Wahrscheinlichkeit. )

@pferdefreund: Magic SYSRQ ist aktiviert. Extra deswegen einen Kernel zu kompilieren, ist zwar vermutlich der richtige Ansatz, ist mir aber gegenwärtig zu aufwändig. Als Student hatte ich dafür noch Zeit ...

@novalis: Danke für den Hinweis.

Möglicherweise ist es tatsächlich eine Sache mit dem X-Server. Vielleicht auch mit dem "Composite Manager"? Hab hier ein KDE mit aktivierten Desktop-Effekten laufen. Ich kann mich noch an Zeiten erinnern, wo in den System Settings so eine Art "Nutzung auf eigene Gefahr"-Hinweis stand. Der ist mittlerweile da zwar nicht mehr zu finden, aber ich kann mir durchaus vorstellen, dass das der Grund ist ...
Werde mal probieren, ob die Abstürze auch ohne Desktop-Effekte noch auftreten.

Ich halt euch auf dem Laufenden.

[philonous]

Update: Hab einen SSH-Server installiert und mich damit verbunden von einem anderen Rechner aus. Ergebnis: Nach "Freeze" ist auch der SSH-Server tot ...
Für mich heißt das: Liegt am Kernel oder an der Hardware.

Die Frage ist: Wie kann ich unter Debian Wheezy auch einen anderen (neueren) Kernel als 3.2.0-4-amd64 installieren?
Eine Alternative wäre wohl, die sid/unstable-Quellen in /etc/apt/sources.list freizuschalten und sich von da einen neueren Kernel zu holen ... – das fällt mir spontan ein.
(Mehr unstable als ein Freeze kanns ja nicht werden, hehe)

Welche Möglichkeiten seht ihr da?
Eigentlich war mein Plan schon, möglichst keinen "Misch-Masch" an Paketen zu haben, sondern (mit ursprünglichem Ziel: Stabilität) genau die aus dem Debian Wheezy Repository.

[novalix]

Welche Möglichkeiten seht ihr da?
Eigentlich war mein Plan schon, möglichst keinen "Misch-Masch" an Paketen zu haben, sondern (mit ursprünglichem Ziel: Stabilität) genau die aus dem Debian Wheezy Repository.

Pinning.
Du legst unter /etc/apt/preferences.d/ zwei Dateien an:
1. wheezy

Code: Alles auswählen

Package: *
Pin: release a=wheezy 
Pin-Priority: 900

2. unstable

Code: Alles auswählen

Package: *
Pin: release a=unstable 
Pin-Priority: 200

Danach fügst Du die Quellen für unstable zu Deiner sources.list zu und tust das, was ein Debianer tun muss.

Groetjes, niels

[philonous]

Memtest86+ ist über Nacht durchgelaufen. Ergebnis: Alles in bester Ordnung.
Ich hab jetzt mal die Desktop-Effekte ausgeschaltet und werd schauen, ob nochmals ein Freeze auftaucht.

@Niels: Hmm ok, dann werd ich tun, was ein Debianer tun muss. Allerdings zwei Fragen bzw. Anmerkungen dazu.

1. Mir scheint, als wäre bei testing und unstable die gleiche Kernel-Version im Einsatz: http://packages.debian.org/search?keywo ... ection=all
Interpretiere ich das richtig? Oder verstehe ich was falsch hier?

2. Angenommen, es liegt wirklich am Kernel. Für mich persönlich wäre es OK, wenn es mit dem Kernel aus unstable funktionieren würde. Insgesamt (d.h. für andere Nutzer oder das Projekt im Allgemeinen) wäre aber doch das beste, ich würde versuchen, rauszufinden, woran das liegt und/oder als Bug reporten (aus meiner derzeitigen Sicht ist es einer). Dazu – denk ich jedenfalls – sind die Informationen, die ich momentan habe, noch zu schwammig, vermutlich auch meine Expertise auf dem Gebiet zu gering ... Was könnt ich denn noch machen, um den Fehler weiter einzugrenzen? Gibt es eine Möglichkeit alle Systemaufrufe irgendwie mitzuloggen oder was ähnliches, also eine Art "verbose"-Mode des Kernels? Möglicherweise könnte man so bei einem Freeze sehen, was letztlich zum "Verhängnis" führte ...

Meinungen dazu?

[pferdefreund]

Wie wärs denn mit eigenem Kernel backen - vonr mir aus auch erst mal an dpkg vorbei
Ist eigentlich recht einfach - gibt ja genug Anleitungen dazu im Netz und dabei kann man durch fest einkompilieren Chipsatz, SCSI und Dateisystemtreiber des / Filesystems auch gleich die initrd entsorgen - ich hasse die nämlich..
Ich fahre schon montelang immer die neuesten Kernel auf Debian stable und noch nie Probleme - auch nicht mit wlan, sound usw - alles wie gewünscht.
Übrigens - die Kernel-config einfach aus /proc/config.gz und make oldconfig erstellt und dann das obengenannte angepasst.

[philonous]

Ja, die Idee ist an sich nicht schlecht. Nur momentan bin ich tatsächlich einfach nicht bereit, die Zeit dafür zu investieren. Dafür hab ich aktuell zu wenig
(Auch wenn der Vorschlag mit dem Übernehmen der Kernel-config aus /proc/config.gz und make oldconfig erstmal gut und nach weniger Aufwand klingt!)

Meine zwischenzeitlichen Recherchen haben aber erstmal folgendes aufgebracht:
Es scheint, als gäbe es in den Kernel-Versionen vor 3.5 Probleme mit Hardware, die auch bei mir verbaut ist.
"By searching the internet I came to the conclusion that it is a problem with the Linux Kernel and the Ivy Bridge GPU as mentioned here (see "Stability fixes for hard hangs on Ivy Bridge platform"): http://intellinuxgraphics.org/2012.02.html"

Quellen:

• viewtopic.php?f=26&p=917806
• http://forums.debian.net/viewtopic.php?f=10&t=85533
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692500

Das werd ich mir jetzt nochmal genauer anschauen, anschließend wohl den Weg über apt-pinning, wie von Niels beschrieben, gehen und nur den Kernel aus experimental ziehen ...

[philonous]

So, bin jetzt wie folgt vorgegangen.

Habe zwei Dateien unter /etc/apt/preferences.d angelegt (wie von Niels beschrieben, nur mit experimental statt unstable).

Anschließend folgende Zeile in /etc/apt/sources.list ergänzt:

Code: Alles auswählen

deb http://ftp.de.debian.org/debian/ experimental main

Und schließlich und endlich noch das ausgeführt:

Code: Alles auswählen

apt-get install linux-image-3.7-trunk-amd64

Der Rechner läuft jetzt mit 3.7-trunk-amd64 aus experimental. Bisher noch kein Absturz, aber die Kiste ist erst sechs Minuten am Laufen, wie mir uptime gerade mitgeteilt hat ...
Wenn das die komplette nächste Woche so weiter läuft, dann setz ich den Thread auf fixed. Drückt mir die Daumen!

[clue]

Oh Mann, willkommen in meiner Welt. Ich hab leider auch das Problem, dass meine Kiste gerne mal einfriert wenn ich n Film schaue und nebenbei surfe. Besonders gerne, wenn ich die CPU stark belaste. Temperatur ist ok.

Ich weiß nicht, welche Hardware Du hast, aber bei mir werkelt noch ne uralte radeon9600XT vor sich her.

Sie lief vor Squeeze völlig stabil. Doch mit Squeeze wurde Kernel 2.6.32 eingeführt welches das verbuggte KMS eingeführt hat.
Ich krieg mein System nur halbwegs stabil (also mit recht seltenen Abstürzen) wenn ich dem Kernel gleich den folgenden Parameter beim Start mitgebe:

Code: Alles auswählen

radeon.modeset=0

Leider hilft das bei dem Kernel 3.2 nicht mehr. Die Kiste friert andauernd ein. Also ists definitiv ein BUG, aber leider interessiert das NIEMANDEN. Und das, obwohl Linus Torvalds explizit drum gebeten hat, die neuen Kernel Versionen auch auf älterer Hardware zu testen.

Bei mir sind übrigens die Symptome beim Einfrieren wie folgt: Caps Lock geht nicht, Sysrq Befehle dito, ssh auch nicht. Logs sind leer, weil ja nichts geschrieben wird.

Darum kann ich auch keinen vernünftigen bug report schreiben (obwohl ich mein Problem schon seit 2.6.32 berichtet habe und auch bei 3.2). Aber wie gesagt: Leider interessiert es NIEMANDEN.

Fairerweise muss ich auch noch folgendes sagen: Die Kiste friert auch bei 3D-Spielen unter Windows ein (höchst! selten). Wahrscheinlich hat sie schon irgendwo ne Macke. Aber durch die gewaltige Verschlechterung der Situation bei Wechsel auf Kernel 3.2 ist für mich klar, dass es dort auf jeden Fall nen fetten BUG geben muss. Mal sehen, vielleicht wechsle ich zurück auf den Lenny-Kernel

[r4pt0r]

Selbes Problem habe ich auch - unter squeeze war es scheinbar direkt mit den nvidia-treibern und glx verknüpft, mit wheezy taucht es jetzt immer auf. Beim ersten Kaltstart friert das system nach ~5min einfach ein. Keine logeinträge, keine sonstigen spuren...
"Überlebt" das System die ersten 10 Minuten ist alles absolut stabil wie immer - auch längeres Spielen, Grafikbearbeitung, Videoschnitt etc pp bringt das System nicht ins kippen, der Rechner kann dann auch tagelang durchlaufen ohne Probleme (ausser für die Stromrechnung). Nach dem nächsten Kaltstart wieder 1x freeze -> reset -> alles OK...

STR/STD funktioniert dank verbugter nvidia-Treiber nicht (Bildschirm wird beim aufwecken nicht mehr eingeschaltet), ebenso wie seit ewigkeiten mit nvidia nicht mehr auf die tty-Konsolen gewechselt werden kann...