Gelegntliche Abstürze beim Herunterfahren/Neustraten

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Gelegntliche Abstürze beim Herunterfahren/Neustraten

Beitrag von chr.gogolin » 14.09.2007 15:55:20

Hallo,

ich muss leider noch ein mal das von mir bereits in [1] beschriebene Problem aufwärmen.

Da das Problem nach wie vor das selbe ist hier nochmals kurz die Fehlerbeschreibung:


Seit ca. 6 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). Wenn ich versucht habe mich Abzumelden dann ungefähr zu der Zeit, zu der gdm wieder zu sehen sein müsste und wenn ich versuchte herunter zu fahren dann ungefähr zu dem Zeitpunkt, zu dem die Shutdown-Meldungen auf der Konsole angezeigt werden sollten.

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.

Der Fehler ist noch nie bei anderen Gelegenheiten aufgetreten.


Ich melde mich erneut, da ich noch einen neuen Hinweis habe an was es liegen könnte:

In "/var/log/acpi" steht nach einem Absturz wärend des Übergangs in den Suspend-Mode immer etwas in der Art:

Code: Alles auswählen

[Fri Sep 14 14:57:42 2007] received event "button/sleep SLPB 00000080 00000001"
[Fri Sep 14 14:57:42 2007] notifying client 3497[105:107]
[Fri Sep 14 14:57:42 2007] notifying client 3570[0:0]
[Fri Sep 14 14:57:42 2007] executing action "/etc/acpi/sleep.sh"
[Fri Sep 14 14:57:42 2007] BEGIN HANDLER MESSAGES
Saving the system clock..
There is already a pid file /var/run/dhclient.eth2.pid with pid 19689
removed stale PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth2/00:12:f0:2b:a4:e6
Sending on   LPF/eth2/00:12:f0:2b:a4:e6
Sending on   Socket/fallback
DHCPRELEASE on eth2 to 192.168.178.1 port 67
There is already a pid file /var/run/dhclient.eth1.pid with pid 19768
removed stale PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth1/00:00:f0:78:f0:34
Sending on   LPF/eth1/00:00:f0:78:f0:34
Sending on   Socket/fallback
[Fri Sep 14 15:18:36 2007] starting up
Und nach einem geglückten Suspend:

Code: Alles auswählen


[Fri Sep 14 13:26:14 2007] received event "button/sleep SLPB 00000080 00000001"
[Fri Sep 14 13:26:14 2007] notifying client 3497[105:107]
[Fri Sep 14 13:26:14 2007] notifying client 3570[0:0]
[Fri Sep 14 13:26:14 2007] executing action "/etc/acpi/sleep.sh"
[Fri Sep 14 13:26:14 2007] BEGIN HANDLER MESSAGES
Saving the system clock..
There is already a pid file /var/run/dhclient.eth2.pid with pid 17354
removed stale PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth2/00:12:f0:2b:a4:e6
Sending on   LPF/eth2/00:12:f0:2b:a4:e6
Sending on   Socket/fallback
DHCPRELEASE on eth2 to 192.168.178.1 port 67
There is already a pid file /var/run/dhclient.eth1.pid with pid 17440
removed stale PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth1/00:00:f0:78:f0:34
Sending on   LPF/eth1/00:00:f0:78:f0:34
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.0.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
Shutting down ALSA...done.
resum.sh started...
Wie man sieht scheint der Absturz immer nach "Sending on Socket/fallback" auf eth1 statt zu finden.

eth1 ist mein Lan-interface und ist so gut wie nie in Verwendung. Ob auch Abstürze auftreten wenn ein Lan-Kabel eingesteckt ist weiß ich nicht.

Die von mir unter [1] beschriebene Möglichkeit den Fehler zu reproduzieren funktioniert nicht mehr. Ich weiß aber leider nicht seit wann das der Fall ist.

Die von mir unter [2] vorgeschlagenen Problemauslöser haben die Absturzhäufigkeit nur verringert und mich dadurch zunächst getäuscht, das Problem aber offensichtlich nicht verursacht.

Bitte nehmt euch noch mal meiner an, es ist so nerv tötend mit einem sonst wunderbar funktionierenden System immer wieder diese Abstürze zu haben... :-(


[1] http://www.debianforum.de/forum/viewtop ... highlight=
[2] http://www.debianforum.de/forum/viewtop ... highlight=

Geier0815
Beiträge: 361
Registriert: 07.04.2005 16:51:01

Beitrag von Geier0815 » 14.09.2007 19:02:06

Bei dem Verhalten was Du beschreibst, tippe ich auf acpi das vom Bios nicht richtig unterstützt wird. Eine Lösung kann ich dir allerdings nicht anbieten.
Wenn Windows die Lösung ist...
kann ich dann bitte das Problem zurück haben?

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 15.09.2007 10:32:22

Mhhh, halte ich für wenig wahrscheinlich, da ich mein Notebook schon seit ca. 1 1/2 Jahren mit Linux (erst Ubuntu dann Debian) betreibe und nie Probleme hatte.
Außerdem tritt der Absturz manchmal auch beim Ausloggen auf, wenn also einfach nur vom Windowmanager zu gdm gewechselt werden müsste.

Wird in so einem Fall überhaupt irgendwas mit acpi aktiv?

Benutzeravatar
steos
Beiträge: 326
Registriert: 16.10.2004 13:27:34
Wohnort: Wien

Beitrag von steos » 15.09.2007 16:52:56

Könnte es sein, daß deine Netzwerkkarten ein Prob haben? Wie ich sehe hast du gleichzeitig zwei Verbindungen aktiv, was IMHO nicht empfehlenswert ist. Ich hatte wie unter [1] beschrieben mit ndiswrapper zahlreiche Abstürze beim Neustart.

Nur so ne' Idee...

[1] http://www.debianforum.de/forum/viewtop ... 088a0d40d3

Benutzeravatar
armin
Beiträge: 2682
Registriert: 17.03.2005 11:49:14

Re: Gelegntliche Abstürze beim Herunterfahren/Neustraten

Beitrag von armin » 15.09.2007 17:36:12

chr.gogolin hat geschrieben:Seit ca. 6 Wochen habe ich Probleme mit plötzlichen Abstürzen unter Debian Lenny auf meinem Samsung X20.
Tja, ich habe leider keine Lösung für das Problem, kann es jedoch bestätigen.
Habe vor ein paar Wochen Lenny auf das X20 Meiner Freunding gepackt und beim Runterfahren kommt es desöfteren zu genannten Artefakten. Ascii-Art ist ja schön und gut, aber hier leider nicht ;)
Habe bisher noch keine Anhaltspunkte gefunden, was das Problem sein könnte. Google schwieg auch.
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 15.09.2007 21:34:23

Ah! Endlich jemand mit dem selben Problem! Das Macht Hoffnung!
Google schwieg auch.
Ja, ich weiß auch nicht wirklich nach was ich googeln soll um ehrlich zu sein, der Fehler lässt sich so blöde beschreiben.

Hast du mal in die /var/log/acpi geworfen? Endet bei deiner Freundin das Log auch so abrupt beim selben Eintrag?

Ich habe jetzt mal in der "/etc/network/interfaces" den "auto eth1" Eintrag auskommentiert. Wenn die Abstürze trotzdem weiter gehen, dann ist wenigsten sicher, dass ein anderer, gleichzeitig mit dem dhcpclient laufender Prozess das Problem verursacht und wenn sie dadurch aufhören, dann um so besser!

Außerdem könnten wir ja mal die installierten Pakete vergleichen, es kann ja nur an einem liegen, dass wir beide haben. Auch wenn es wahrscheinlich sehr viele Übereinstimmungen gibt kann man so vielleicht doch irgendwas ausschließen. Eine Liste der bei mir installierten Pakete gibt es unter [1].

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

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 17.09.2007 23:08:26

Das Auskommentieren der "auto" Option hat nichts gebracht. Die Abstürze treten weiterhin auf.


Außerdem habe noch einen Hinweis:

Ich habe heute das Pakte "laptop-mode-tools" wieder installiert, welches ich vor ca. 10 Tagen entfernt hatte.
Schon damals hatte ich den Eindruck, dass dadurch die Häufigkeit der Abstürze abgenommen hatte. Dieser Verdacht hat sich nun ziemlich deutlich bestätigt. In den Vergangenen 4 Tagen hatte ich ganze 2 Abstürze bei 22 logout/suspend/hibernate-Versuchen. Heute hatte ich nach der Installation der "laptop-mode-tools" 8 Abstürze bei 15 logout/suspend/hibernate-Versuchen (!).

Daraus ziehe ich den Schluss das eines der Programme die auch von den "laptop-mode-tools" verwendet werden den Fehler verursacht.

Ein heißer Kandidat scheint mir "hdparm" zu sein, da es sowohl von den "laptop-mode-tools" als auch vom "hibernate"-Paket verwendet wird, außerdem hatte ich das früher schon mal unter Verdacht...

Die Frage ist jetzt:

Wie finde ich am einfachsten Raus ob "hdparm" schuld ist?

Deinstallieren des Pakets scheint mir wenig verlockend da es, gesagt, Abhängigkeiten zum Paket "acpi-support" und "hibernate" gibt, welche ich ja brauche um den Fehler zu erzeugen.

Kann ich die Datei "/sbin/hdparm" einfach auf nichtausführbar setzen oder umbenennen ohne mein System zu ruinieren?

Benutzeravatar
armin
Beiträge: 2682
Registriert: 17.03.2005 11:49:14

Beitrag von armin » 18.09.2007 01:02:56

Ich muss bei Gelgenheit mal schauen, was da los ist.
Die meiste Zeit habe ich das Notebook aber nicht da, vor allem wenn es Probleme gibt ;)
Was nutzt du eigentlich für Suspend to Ram? Bei einem kurzen Test bekam ich außer dem Schachbrett nicht viel zu sehen beim Aufwachen (oder war der Bildschirm sogar komplett schwarz?).

Ich würde ja eigentlich auf ein Kernelproblem tippen, was das ganze auslöst. Du sagtest es fing vor ein paar Wochen an - war vorher alles ok?
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 18.09.2007 13:45:33

Das aufwachen aus dem s2ram funktioniert mit einem Kernel >= 2.6.21 nicht mehr. Ich konnte das Problem aber durch neu kompilieren des Kernels lösen siehe dazu meinen "Selbstgespräch-Thread" [1].

Beim Aufwachen wurde der Bildschirm damals komplett schwarz.

Ich glaube nicht, dass es an einer Kernel Option liegt, da der Fehler mit allen bei mir vorhandenen Kernen auftritt. Getestet habe ich die Versionen 2.6.18 (mehrere verschiedenen Versionen), 2.6.21(auch selbstkompilierte) und 2.6.22 (aus Sid).

Vorher lief alles wunderbar. Ich nutze Debian Lenny seit dem 24. Juli diesen Jahres und das Problem besteht erst seit ca. 6 Wochen.


[1] http://www.debianforum.de/forum/viewtop ... highlight=

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 18.09.2007 15:24:36

Um "hdparm" auf den Zahn zu fühlen habe ich jetzt mal die "/sbin/hdparm in "/sbin/hdparm.db" umbenannt und dann anstelle der "/sbin/hdparm" das folgende Skript kopiert.

Code: Alles auswählen

#!/bin/sh

program="/sbin/hdparm.db"
name="hdparm"

echo -e "`date`\t$program $*" >> /home/cgogolin/tmp/${name}.log

bash -c "${program} $*"

exitstatus=$?

echo -e "exitstatus: $exitstatus\n" >> /home/cgogolin//tmp/${name}.log

exit $exitstatus 
Das mir jetzt alle aufrufe von "hdparm" protokolliert.

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 19.09.2007 20:53:26

hdparm hat ein Alibi - der Test mit dem Skript zeigt das hdparm immer ordentlich funktioniert und mit den Abstürzen somit nichts zu tun hat.

Ich habe dann das gleiche mit "/sbin/dhclient3" gemacht. Das Ergebniss ist sehr merkwürdig...

Hier der Auszug aus "/var/log/acpid" zum Zeitpunkt des Absturzes:

Code: Alles auswählen

...
[/[Wed Sep 19 20:13:17 2007] received event "button/sleep SLPB 00000080 00000001"
[Wed Sep 19 20:13:17 2007] notifying client 3486[105:107]
[Wed Sep 19 20:13:17 2007] notifying client 3571[0:0]
[Wed Sep 19 20:13:17 2007] executing action "/etc/acpi/sleep.sh"
[Wed Sep 19 20:13:17 2007] BEGIN HANDLER MESSAGES
Saving the system clock..
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
There is already a pid file /var/run/dhclient.eth2.pid with pid 28448
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth2/00:12:f0:2b:a4:e6
Sending on   LPF/eth2/00:12:f0:2b:a4:e6
Sending on   Socket/fallback
[Wed Sep 19 20:29:54 2007] starting up
...
Der Absturz ist also scheinbar nach 20:13 und vor 20:29 aufgetreten.

Der Auszug aus dem mit dem oben geposteten Skript erstellten Log,

Code: Alles auswählen

Wed Sep 19 19:38:07 CEST 2007   dhclient3 -r -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0

Wed Sep 19 19:38:24 CEST 2007   dhclient3 -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0

Wed Sep 19 19:49:59 CEST 2007   dhclient3 -r -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0

Wed Sep 19 19:50:12 CEST 2007   dhclient3 -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0

Wed Sep 19 20:29:55 CEST 2007   dhclient3 -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0

Wed Sep 19 20:35:07 CEST 2007   dhclient3 -r -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0

Wed Sep 19 20:35:08 CEST 2007   dhclient3 -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
exitstatus: 0
enthält aber keinen Aufruf von "/sbin/dhclient3" im fraglichen Zeitraum und es fehlt zwischen dem Eintrag von 19:50:12 und dem von 20:29:55 scheinbar ein Eintrag mit der -r Option.

Zu dieser Option sagt "man dhclient3":
The client normally doesn’t release the current lease as it is not required by the DHCP protocol. Some cable ISPs require
their clients to notify the server if they wish to release an assigned IP address. The -r flag explicitly releases the
current lease, and once the lease has been released, the client exits.
Kann sich da jemand einen Reim drauf machen?

Für ein bischen Unterstützung wäre ich wirklich sehr Dankbar! Ich gebe mir alle Mühe so viele Informationen wie möglich zusammen zu tragen um dem Problem auf die Schliche zu kommen. Ich will endlich wieder ein funktionierendes System... :cry:
Zuletzt geändert von chr.gogolin am 19.09.2007 23:03:25, insgesamt 1-mal geändert.

Benutzeravatar
armin
Beiträge: 2682
Registriert: 17.03.2005 11:49:14

Beitrag von armin » 19.09.2007 21:19:48

Habe leider keine Neuigkeiten auf dem Gebiet. Ich tippe aber immer noch auf einen Kernel-Bug - es darf einfach nicht passieren, dass noch nicht mal Sysrq+r irgendetwas bewirkt.
Zum Suspend-Problem habe ich aber einen passenden Bug gefunden: http://bugzilla.kernel.org/show_bug.cgi?id=8640
Eventuell magst du doert hinzufügen das du das gleiche Problem hast und eventuell einen neuen Bug für das Hängenbleiben beim Suspend aufmachen.
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 21.09.2007 00:01:02

An dhclient3 scheint es auch nicht zu liegen. Ich habe das Skript noch mal modifiziert

Code: Alles auswählen

#!/bin/sh
program="/sbin/dhclient3.db"
name="dhclient3"

echo -e "`date`\t$name $*" >> /home/cgogolin/tmp/${name}.log
sync

sleep 1

$program $*

exitstatus=$?
echo -e "exitstatus: $exitstatus\n" >> /home/cgogolin/tmp/${name}.log
sync

exit $exitstatus 
Und wärend des letzten Absturzes sah man deutlich, dass dhcleint mit exit status 0 beendet wurde.

Ich habe jetzt mal einen Bugreort ausgefüllt [1]. Ich habe mich dabei auf das meiner Meinung nach wesentliche und als gesichert geltende beschränkt um niemanden auf einen falsche Fährte zu locken.

Wenn es unter den Lesern diese Threads noch anmerkungen gibt, wass an Infos für die Entwickler noch hilfreich sein könnte oder falls ihr der meinung seid, dass ich mich unklar ausgedrückt habe (Englisch ist schließlich nicht meine Muttersprache) dann sagt einfach bescheid.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443375

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 22.09.2007 15:35:04

Ich werde nicht aufgeben, bis ich diesen Fehler gefunden habe!

Ich habe wieder einmal etwas neues herausgefunden.

Diesmal habe ich die "/etc/acpi/prepare.sh" modifiziert und eine ganze menge "echo"s und "sync"s eingebaut.

Code: Alles auswählen

#!/bin/sh

echo "`date` prepare.sh started" >> /home/cgogolin/tmp/crash.log
sync

# sync harddrives befor anything else is done
sync

for SCRIPT in /etc/acpi/suspend.d/*.sh; do
    echo "`date`  starting script $SCRIPT" >> /home/cgogolin/tmp/crash.log
    sync

    . $SCRIPT
done

echo "`date` prepare.sh done" >> /home/cgogolin/tmp/crash.log
sync
damit habe ich beim letzten Absturz folgendes Log aufgezeichnet:

Code: Alles auswählen

...
Sat Sep 22 12:20:31 CEST 2007 prepare.sh started
Sat Sep 22 12:20:31 CEST 2007  starting script /etc/acpi/suspend.d/05-acpi-lock.sh
Sat Sep 22 12:20:31 CEST 2007  starting script /etc/acpi/suspend.d/10-thinkpad-standby-led.sh
Sat Sep 22 12:20:31 CEST 2007  starting script /etc/acpi/suspend.d/30-proc-sysfs-save-state.sh
Sat Sep 22 12:20:31 CEST 2007  starting script /etc/acpi/suspend.d/50-irda-stop.sh
Sat Sep 22 12:20:31 CEST 2007  starting script /etc/acpi/suspend.d/50-time.sh
Sat Sep 22 12:20:34 CEST 2007  starting script /etc/acpi/suspend.d/50-tosh-save-brightness.sh
Sat Sep 22 12:20:34 CEST 2007  starting script /etc/acpi/suspend.d/55-down-interfaces.sh
Sat Sep 22 12:20:36 CEST 2007  starting script /etc/acpi/suspend.d/60-generate-modules-list.sh
Sat Sep 22 12:20:36 CEST 2007  starting script /etc/acpi/suspend.d/65-services-stop.sh
Sat Sep 22 12:20:36 CEST 2007  starting script /etc/acpi/suspend.d/70-modules-unload.sh
Sat Sep 22 12:20:36 CEST 2007  starting script /etc/acpi/suspend.d/75-console-switch.sh
Der Absturz tritt also auf, während das script "75-console-switch.sh" läuft.

Solltes dieses Script wirklich den Fehler verursachen und nicht ein anderer parallel laufender Vorgang so ist der Fehler fast gefunden. Das fragliche Skript ist nämlich ausgesprochen kurz:

Code: Alles auswählen

$ cat 75-console-switch.sh 
#!/bin/sh

# And remember which console we're on
CONSOLE=`fgconsole`

# Change away from X, otherwise it'll blow up when we POST the video interface
chvt 12
Das Programm "chvt" hat scheinbar auch früher schon mal Probleme bereitet [1] und es passt auch daher, da es sicher beim wechsel in den suspend und hibernate Modus ausgeführt wird und ich könnte mir gut vorstellen, das es auch beim ausloggen aus dem Windowmanager genutzt wird.

Ich habe jetzt die letzte Zeile mal durch

Code: Alles auswählen

strace -t -o /home/cgogolin/tmp/chvt.trace chvt 12
sync
ersetzt, in der Hoffnung, dass "strace" es trotz des Absturzes noch schafft den trace auf die Platte zu retten.

Kann jemand hier bestätigen, dass "chvt" beim ausloggen aufgerufen wird?

@ Trigger: Teste doch bitte mal durch einen Eintrag der art

Code: Alles auswählen

...
for SCRIPT in /etc/acpi/suspend.d/*.sh; do
    echo "`date`  starting script $SCRIPT" >> /home/cgogolin/tmp/crash.log   <---- Diese beiden Zeilen 
    sync                                                                     <---- hinzufügen und Pfad anpassen

    . $SCRIPT
done
...
in der /etc/acpi/prepare.sh ob das x20 deiner Freundin an der selben stelle hängen bleibt.

Es muss einfach möglich sein dahinter zu kommen was schief läuft!

[1] http://www.uwsg.indiana.edu/hypermail/l ... /2150.html

Benutzeravatar
armin
Beiträge: 2682
Registriert: 17.03.2005 11:49:14

Beitrag von armin » 22.09.2007 15:39:28

Ok, werde das bei Gelegenheit testen.
Eine einfache Variante auszuschließen, dass der Terminalwechsel scheitert ist übrigens einfach auf ein Terminal zu wechseln, X zu beenden, den chvt Eintrag auszukkommentieren und dann schauen was passiert.
Theoretisch sollte der Rechner dann nicht mehr hängen bleiben. Der Terminalwechsel ist ja nicht mehr nötig.
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 22.09.2007 16:47:18

Da hatte ich auch schon dran gedacht aber der Absturz tritt halt nur manchmal auf und das sehr unregelmäßig. Manchmal habe ich 10+ suspend/resum Zyklen hin bekommen ohne das etwas passiert ist und manchmal stürzt er 4+ mal in direkter Folge ab. Man müsste das also _sehr_ oft wiederholen bevor man sicher gehen kann.

Aber zur Not werde ich auch dass testen.

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 22.09.2007 21:39:26

Und noch eine gute Neuigkeit!

Es scheint wirklich an "chvt" zu liegen!

Ich habe mit diesem kleinen Skript

Code: Alles auswählen

#!/bin/sh

i=0
while [ $i -le 20 ]
do
    strace -t -o /home/cgogolin/tmp/chvt.trace chvt 12
    sleep 3
    strace -t -o /home/cgogolin/tmp/chvt.trace chvt 7
    sleep 3
    i=`expr $i + 1`
done
den Absturz herbeiführen können. Das tracen hat jedoch leider nie funktioniert, da das System scheinbar zu schnell abschmiert.

Interessanter weise ist des Absturz entweder immer gleich beim ersten mal passiert oder alle 20 versuche sind durchgelaufen.

@ Trigger: Bitte Teste das auch. Wenn es bei dir auch den Fehler hervorruft, dann können wir endlich einen vernünftigen Bugreport erstellen.

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 25.09.2007 19:22:09

Hallo Trigger, bis du schon dazu gekommen "!chvt" auf den Zahn zu fühlen?

Auch wenn ich inzwischen _sehr_ sicher bin das es chvt ist wären deine Ergebnisse für mich Interessant.


Ich habe inzwischen die "chvt" Version aus dem dem Paket "kbd" bei mir Installiert und alle möglichen Kombinationen von alten Paketen getestet, die mit "chvt" in Zusammenhang stehen außerdem habe ich "chvt" aus den Quellen neu kompiliert.

Leider ohne Erfolg, mit allen Konfigurationen hatte ich einen Crash.

Da das Programm leider immer das Ganze System mit ins Grab reißt komme ich mit tracen oder einem Debugger auch nicht weiter.

Ich habe jetzt "chvt" noch mal aus dem Quellen neu kompiliert und den Quellcode mit einer ganzen Reihe von "fprintf()"s und "flush()"s verziert. Außerdem lasse ich nach jedem "flush()" 1/2 Sekunde Warten und die dadurch erzeugte Ausgabe auf eine zusätzliche Partition, die mit der Option "sync" gemountet, ist schreiben und hoffe so die Code-Zeile zu identifizieren die den Absturz hervorruft.

Leider (oder Gott sei Dank ?!) hatte ich heute noch keinen einzigen Absturz!

chr.gogolin
Beiträge: 441
Registriert: 12.10.2005 23:09:28
Lizenz eigener Beiträge: MIT Lizenz
Kontaktdaten:

Beitrag von chr.gogolin » 26.09.2007 09:17:28

Ich habe das Problem auf einen bestimmte Codezeile festnageln könne.

Da der Fehler jetzt schon sehr stark eingegrenz ist habe ich einen neuen Thread auf gemacht.


----> http://www.debianforum.de/forum/viewtop ... 080#563080

Antworten