Gelegntliche Abstürze - Brauche Hilfe bei der Fehlersuche

[chr.gogolin]

Hallo!

Seit ca. zwei Wochen habe ich Probleme mit plötzlichen Abstürzen unter Debian Lenny auf meinem Samsung X20.

Leider kann ich die Situation, welche zum Absturz führt nicht reproduzieren und eine systematische Suche wird dadurch erschwert, dass die Abstürze (Gott sei Dank) recht selten sind. Ich habe einige Fakten zusammentragen können, bin aber noch nicht dahinter gekommen, was das Problem verursacht.

Tritt der Absturz auf, so werden auf dem Bildschirm in ca. halbsekündigen Wechsel zwei Pixelmuster dargestellt. Der Großteil des Bildschirms wird schwarz bis dunkelgrau und darüber ist ein helleres Muster mit einer Rasterungen in der Größe der Buchstaben auf den tty's zu sehen. Soweit ich das beurteilen kann ist die Auflösung zu diesem Zeitpunkt 640x480. Das ganze lässt sich sehr schwer beschreiben (und eine genaue Beschreibung ist warscheinlich auch wenig hilfreich) aber es sieht ein bsichen wie ein Matrix-Code in Graustufen aus.
Das Notebook reagiert dann auf keinerlei Befehle mehr und kann auch nicht gepignt werden.
Direkt nach dem Absturz leuchtet die Festplatten LED, sie erlischt aber nach einiger Zeit und die Festplatte hört auf zu laufen.

Nach einem Kaltstart beschwert sich der Rechner das die Dateisysteme nicht ordentlich ausgehäng wurden. Andere Nebenwirkungen sind bisher noch nicht aufgetreten.

Obwohl die Abstürze recht selten auftreten und sich nicht reproduzieren lassen ist doch eine gewisse Systematik erkennbar. Ich konnte den Absturz bisher ausschließlich in folgenden Situationen beobachten:

1) Beim Verlassen des Windowmanagers (Ich benutze ION3) direkt bevor eigentlich gdm wieder zu sehen sein müsste.

2) Beim Wechsel in den Suspend-to-Ram oder den Suspend-to-Disk Modus (Ich benutze das hibernate-Paket und uswsusp) und zwar sowohl wenn der Wechsel aus der Graphischen Oberfläche erfolgt, als auch wenn ich s2ram/s2disk aus dem Singel user mode ohne laufenden XServer aufrufe.

In den standard Log-Files (Xorg.log acpi debug dmesg hibernate kern messages ...) kann ich nichts verdächtiges entdecken, wobei ich auch nicht weiß nach was ich suchen soll...

Ich hatte bereits Abstürze mit den Kerneln 2.6.18 und 2.6.21 sowie 2.6.22 (letzteren aus sid). Andere hebe ich noch nicht getestet, denke aber das das auch nicht viel bringen wird.

Hat jemand eine Idee welcher Teil des Systems überhaut zu dem oben beschriebenen Verhalten führen kann, oder hat jemand eine gute Idee wie ich dem Problem auf die Schliche kommen könnte?

Auch für eine Hilfestellung wäre ich sehr dankbar!!!

[mragucci]

Moin,

läuft das Laptop heiß? Das wäre mal der erste Anhaltspunkt, eventuell CPU oder GraKa zu warm geworden. Zweiter Anlaufpunkt wäre der Ram-Speicher...

[chr.gogolin]

Danke schon mal für die ersten Anregungen!

An der Temperatur liegt es definitiv nicht. Die CPU wird nicht heißer als 35 °C und die Luft die aus dem Lüftungsschlitz unterhalb der RAM-Bänke kommt ist höchstens lau warm.

Ich werde heute Abend mal memtest86+ durchlaufen lassen um einen Fehler im Ram auszuschießen.

[Livingston]

Das Ganze kommt mir sehr bekannt vor, auch wenn ich dieses Phänomen auf einem älteren Desktop hatte: Deine Beschreibung des Abschuss-Bildschirms passt genau.
Die Probleme fingen bei mir mit der Einrichtung eines Framebuffers an. Sowohl Grafikkarte als auch Hauptspeicher sind etwas dünn besetzt (16MB Grafik, 128MB Hauptspeicher).
Gelöst habe ich das Ganze mit entsprechenden Bootoptionen in lilo/grub, indem ich speichersparende Einstellungen auswählte (Nachteil: Nicht die volle Grafikauflösung - ist für meine Ansprüche auf dem Rechner aber auch nicht nötig.)

[chr.gogolin]

Ich habe gestern memtest86+ laufen lassen und nach 23 Durchläufen wurde kein einziger Fehler gefunden. Der RAM scheint in Ordnung zu sein.

An einem zu kleinen Hauptspeicher wird es wohl auch eher nicht liegen. 1GB sollte doch ausreichen, dass ist ja schließlich kein Vista, dass ich da laufen habe ..

Die Grafikkarte ist eine intel integrated graphics Karte mit shared Memory.

Code: Alles auswählen

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

Müsste man aus den Situationen in denen das Problem auftritt nicht auf die Quelle schließen können?
Welche Prozesse laufen denn sowohl beim verlassen des Windowmanagers als auch beim ausführen von s2ram/s2disk aus der Kommandozeile ab?

[chr.gogolin]

Ich habe gerade eine Möglichkeit gefunden den Absturz zu reproduzieren!!!

1) Notebook ohne Akku starten.
2) In anmelden gdm und warten bis der Windowmanager geladen ist.
3) Akku einstecken.
4) Stromkabel abziehen.
5) Windowmanager beenden.
=> Absturz

Interessant ist auch, dass wenn man sich zwischen dem einstecken des Akkus und dem Abziehen des Stromkabels einmal abmeldet und wieder anmeldet nicht unbedingt ein Absturz auftritt.

Ich habe dieses Verhalten jetzt jeweils 4 mal mit meinen beiden Akkus reproduzieren können und konnte mich gleichzeitig mich vor dem einstecken des Akkus jedesmal viele male ohne Absturz an und ab melden

Da der Fehler ja scheinbar irgendetwas mit dem Akku zu tun hat hier mal die Ausgabe aus /var/log/acpi in den nopaste geschoben, auch wenn die für mich unverdächtig aussieht.

abziehen des Akkus:http://nopaste.debianforum.de/6441
einstecken des Akkus: http://nopaste.debianforum.de/6440

[edit]
Der Absturz selbst erzeugt keine Meldungen in /var/log/acpi.
[/edit]

[chr.gogolin]

ich habe um sicher zu gehen auch noch alle Partitionen der Festplatte mit 'e2fsck -c -C 0 /dev/...' gecheckt und alles scheint zu funktionieren. Ich denke, dass man einen Hardwarefehler nahezu ausschließen kann.

Wenn noch irgendjemand eine Idee hat wäre ich sehr dankbar!

[Livingston]

Da Du das Problem schon ganz gut eingekreist hast, wäre es wohl nützlich, einen neuen Thread aufzumachen, damit man auch sieht, worum es sich handelt.

[chr.gogolin]

Einen neune Thread werde ich wohl morgen/übermorgen aufmachen, wenn ich dazu Zeit finde, danke für den Tipp.

Das wird sich auch deshalb lohnen, ich jetzt das Problem wirklich sehr gut eingegrenzt habe. Gestern habe ich mal eine Image der Debian-root-Partition herausgekramt und ganz frech das (leider schon recht alte) /etc/ Verzeichnis anstelle meines momentanen in das System kopiert.

Seit dem hatte ich keinen einzigen Absturz mehr und auch mit der oben beschriebenen Methode konnte ich keinen Absturz herbei führen. Ich bin mir aber noch nicht ganz sicher ob das nicht vielleicht nur Zufall war und möchte deshalb das Verhalten des Systems noch ein zwei Tage beobachten.

Ärgerlich ist, dass ich wegen der Seltenheit der Abstürze den Fehler erst bemerkt hatte nachdem ich das aktuelle Backup des /etc/ Verzeichnisses (mache ich mit rsync) bereits überschreiben hatte, was die suche nach der den Fehler auslösenden Änderung erschweren wird.

Ich habe mit diff mal eine Liste der Änderungen erstellt und mit nopaste hoch geladen [1]. Wäre toll wenn man jemand eine flüchtigen Blick auf die 2 1/2 Seiten werfen könnte, vielleicht fällt ja jemandem was verdächtiges auf und erspart mir so eine langwierige Suche. Ich grade mitten in den Vordiplomprüfungen und kann daher jede Minute für die Vorbereitung gebrauchen, bin aber gleichzeitig auf mein Notebook angewiesen.

Vielen dank an alle die sich Gedanken zu dem Problem gemacht haben!

[1] http://nopaste.debianforum.de/6462

p.s. 'diff -r /dir1 /dir2' müsste doch alle Änderungen in den Verzeichnisbäumen auflisten, oder?

[edit]Falsche und missverständliche Ausgabe im nopaste berichtigt[/edit]