opensuse 10.3: System Lockup/ kompletter Freeze

lynx

lynx

0
Hallo Habos!

Seit ein paar Wochen hängt sich mein opensuse 10.3 komplett auf. Es ist auffällig, dass immer, wenn er den Bildschirmschoner einschalten will, der Bildschirm schwarz wird und das System auf nichts mehr reagiert: weder auf Maus, weder auf Tastatur. Man muss einen harten Reboot machen und dann läuft es wieder, aber nur, bis er wieder den Bildschirmschoner einschaltet.

Ich würde gerne rausfinden, woran das es liegt. Ich habe die Vermutung, dass es an meiner Grafikkarte, an der "ati X700 Mobility" liegt. Der neueste Treiber ist installiert, brachte aber keine Besserung.

Die Temperaturen sind laut Kima auch okay: ca. 54C für die cpu und nur 37C für die Festplatte.

Vielen Dank für Eure Hilfe im Vorraus!

Viele Grüsse,
lynx
 
an der graphikkarte sollte es nicht liegen, ich habe selbst eine Radeon X700 (zwar keine Mobility, aber der Chipsatz sollte bei beiden ein R300 sein) und bildschirmschoner laufen bei mir ohne probleme. wenn die maschine einfriert, kannst du sie noch von anderen computern aus z.b. per ssh erreichen? wenn ja, dann starte mal den xscreensaver mit
Code: 
$ killall xscreensaver
$ xscreensaver &
$ xscreensaver-command -lock
und logg dich auf deinem rechner per ssh ein, sobald der bildschirm einfriert. wenn du das getan hast, kannst du mit
Code: 
$ killall -KILL xscreensaver
den bildschirmschoner beenden und dir seine ausgabe in der konsole, in der du ihn gestartet hast, ansehen. evtl. produziert das einige erhellende fehlermeldungen.
 
@farhaven: Diese Möglichkeit per SSH gibt es bei mir leider nicht, habe nur dieses Laptop. Zudem geht wirklich nix mehr, also glaube ich nicht, dass das funktioniert hätte.

Weitere Ideen?

Viele Grüsse,
lynx
 
Schau nach dem Reboot einfach mal in die Logs. Achte aber dabei darauf, dass du dir auch die alten Logs (also anstatt der Xorg.0.log die Xorg.1.log) von dem Zeitraum vor dem Reboot anschaust. Da sollte sich dann bestimmt ein Hinweis in Form von Warnungen oder Fehlern auf das Freeze finden lassen.

Ich würde aber in erster Linie auf ein ACPI-Problem tippen. Einfach mal schauen, ob das Problem noch auftritt, wenn du dem Kernel beim Booten als Parameter ein 'acpi=off' übergibst. Das ist zwar für Laptops nicht gerade günstig, sollte aber helfen diese Fehlerursache auszuschliessen oder halt einzugrenzen.
 
@bitmuncher: Nun, das mit den Logs ist riesig. Der "ältere" (xorg.1.log)ist übrigens vom 24. März, also glaube ich nicht, dass der was bringt.
Der andere, xorg.0.log, ist von heute.

Nach was suche ich denn genau? Gibt es Zeichen, nach denen ich suchen kann!? So finde ich das nie raus. :(

Viele Grüsse,
lynx
 
Du suchst in erster Linie erstmal in den Logs nach dem Zeitpunkt des letzten Crashs und nach Warnungen oder Fehlern innerhalb dieses Zeitraums.
 
Es wäre gut, wenn du das "XOrg.0.log" mal hier an einen deiner Beiträge anhängen könntest, damit wir einen Blick darauf werfen können (damit wir wissen, über welche Konfiguration wir sprechen).

Meine Vermutung wäre hier, dass XScreensaver einen GL beschleunigten Screensaver verwenden möchte, das aber (wahrscheinlich dank fglrx) zu zumindest einem X Absturz führt. Gut wäre allerdings wirklich zu wissen, ob die Machine "hard-locked" (also Reset-bedürftig) oder einfach nur das X abgestürzt ist. Den Wechsel auf eine andere Konsole oder das Beenden von X via "Strg-Alt-Backspace" hast du schonmal probiert, oder? Du könntest auch erstmal einen ping auf die Maschine ausprobieren (bei einem Freund; du hast ja nur den Laptop).
 
fglrx sollte eigentlich nicht das problem sein, wie gesagt, ich hab den selbe graphikchipsatz und bei mir laufen opengl anwenungen und bildschirmschoner problemlos.

was ich mir noch vorstellen könnte, wäre, dass aus irgendeinem grund die 3d beschleunigung nicht geht und 3d bildschirmschoner dann ne menge cpu leistung verbraten, was erstmal "abgestürzt" aussieht.
 
@thread: Also ich lasse meine Maschine gerade ohne Bildschirmschoner laufen, das sieht ganz gut aus, keine Abstürze bisher.

Wenn der Rechner hängt, wie oben beschrieben, dann geht nix mehr: also hard-locked. Keine Möglichkeiten mehr über Tastatur oder Maus oder andere Knöpfe am Laptop irgendwas zu machen.

Ich habe die xorg.0.log vom 27.05. und die xorg.1.log vom 24. März hier angehängt. Schaut euch ruhig mal diese Dateien an, blicke da eh nicht durch...

Vielen Dank und viele Grüsse,
lynx
 
Code: 
(EE) fglrx(0): === [swlDalHelperSetControllerConfigForRemap] === CWDDC ControllerSetConfig failed: 6 - 0

Es scheint sich hierbei um einen Bug im fglrx-Treiber zu handeln. Tritt das Problem auch auf, wenn du den Vesa-Treiber verwendest oder den OpenSource-ATI-Treiber? Evtl. auch einfach mal eine ältere Version des fglrx-Treibers nutzen. Bei denen soll dieses Problem wohl nicht auftauchen.
 
@bitmuncher: Na toll, also lag es tatsächlich an der Grafikkarte oder wie!? Und ich war schon froh, dass die neueren fglrx-Treiber von ATI so "reibungslos" funktionieren.

Oh Mann, immer dieses Theater mit ATI. Der Laptop wird jetzt im August drei Jahre alt und die Probleme mit ATI sind immer noch da. Nur, dass es immer neue Probleme gibt. Ich hab echt nen Hass. X(

Sonst noch irgendwas gefunden?

Das Experiment mit den älteren Treibern probiere ich mal am Wochenende aus.

Danke schonmal!

Viele Grüsse,
lynx
 
Weiteres habe ich nicht gefunden, aber diese Fehlermeldung tritt definitiv in Verbindung mit einem Freeze des X-Servers auf. Wenn du auf Hardware-3D verzichten kannst, nimm einfach die Vesa-Treiber. Die machen selten Probleme. Ansonsten auch mal schauen ob dein Chipsatz von den OpenSource-Treibern unterstützt wird. Die liefern zwar kein sonderlich gutes Hardware-3D, entlasten aber die CPU besser als der Vesa-Treiber.
 
@bitmuncher: Das mit VESA und den open-source-Treibern ist schön und gut, aber mein Linux-System konkurrenzfähig halten die leider nicht. So kann ich weder "prahlen", dass Shooter XY auch auf meinem Linux-System läuft, noch Programme wie "Google Earth" nutzen.

Einfach nur traurig.
 
Tja, Augen auf beim Hardware-Kauf. Meine Onboard-Intel läuft besser als unter Windows und das mit OpenSource-Treibern. :D
 
Wenn der Rechner hängt, wie oben beschrieben, dann geht nix mehr: also hard-locked. Keine Möglichkeiten mehr über Tastatur oder Maus oder andere Knöpfe am Laptop irgendwas zu machen.
Zum Vergrößern anklicken....

Einen hard-reset sollte man dennoch besser vermeiden, sowas macht die Hardware auf Dauer mies gelaunt. Abhilfe: eine Kerneloption namens ?Magic SysRq?, unter SuSE sehr einfach über YaST zu aktivieren: "System" ? "Systemeinstellungen", im tab "Kernel-Einstellungen" den Haken bei "SysRq-Tasten aktivieren" setzen.

Eine sinnvolle Tastenabfolge wäre z.B. |R|S|E|I|U|B| (Nach jeder Taste ein paar Sekunden warten)

Raising Skinny Elephants Is Utterly Boring

...das aber nur mal so nebenbei.
 
@gropiuskalle: Ja, gerne würde ich das anwenden, was du da beschreibst, aber ich hatte vorhin wieder nen Lockup (hatte mal wieder MIT Bildschirmschoner probiert) und selbst das geht nicht!

Bin also wohl hoffnungslos verloren und ein Sklave von den Launen des ATI-Linux-Treibers. Bescheuert, echt, denn vor einigen Monaten war alles gut so.

Grüsse,
lynx
 
Hast Du die Einstellungen via YaST vorgenommen wie von mir beschrieben? Per default ist diese Kerneloption deaktiviert (und bislang hatte ich noch keinen Fall, wo nicht zumindest das abschließende 'B' einen sauberen Reset bewerkstelligt hat, wäre schon sehr ungewöhnlich)
 
kann magic sysrq eigentlich per software aktiviert werden, wenn im kernel die unterstützung dazu nicht einkompiliert ist?
 
Das wäre etwas widersinnig, oder? Mit dieser Funktion soll ja der Kernel angesprochen werden, wenn "alles drumherum" nicht mehr ansprechbar ist (also auch eine solche Software).

Schau mal, ob es bei Dir eine Datei namens /proc/sys/kernel/sysrq gibt und setze den Wert darin auf 1; meines Wissens nach wird Magic SysRq von so ziemlich allen Kerneln unterstützt.
 
genau das meine ich, ist das proc interface überhaupt verfügbar, wenn magic sysrq bei der kernelkonfiguration deaktiviert wurde?
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben