Instabiles System (Primär: Einfrieren unter X11 u. ä.)

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
Benutzeravatar
bifo
Beiträge: 335
Registriert: 10.07.2002 07:22:39
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Monschau

Instabiles System (Primär: Einfrieren unter X11 u. ä.)

Beitrag von bifo » 06.04.2004 11:32:21

Hallo zusammen,

tut mir Leid, daß der folgende Beitrag etwas länger ist. Ich habe versucht, mein Problem so erschöpfend, wie möglich zu beschreiben. Ich habe mir vor gut sechs Wochen einen neuen PC zugelegt, der mit ausnahme der Festplatte ausnahmslos aus neuen Komponenten besteht:
  • - Shuttle SG45 mit NForce2-Chipset und Sound On Board
    - ATI Radeon 9200 Excalibur
    - 1 GB RAM
    - 80 GB Western Digital IDE-Festplatte (Ext3-Filesysteme)
    - LG GSA-4081B, DVD-Brenner
Installiert ist Sarge mit wenigen Paketen aus Sid (XFree-Server, sowie der 2.6.4er Kernel). Zur Zeit ist das System höchst instabil. Meine Vermutung ist, daß dies nicht an den installierten Paketen liegt. Vielleicht könnt Ihr mir weiterhelfen. Zur Historie:

Ich habe die Festplatte aus meinem Altrechner einfach in das neue System eingebaut. Der 386er Standard-Kernel konnte das System hochfahren. Den Sound on Board habe ich mit Alsa ans Laufen bekommen. Für die Grafikkarte habe ich die DRI-Treiber verwenden können. Das ging auch bis vor etwa vier Wochen gut. Ich aktuallisiere täglich mein System per aptitude. Vor etwa vier Wochen fing es an, daß beim Öffnen von neuen Fenstern der Bildschirm "einfror" und keinerlei Tastatureingaben mehr möglich waren. Die gestarteten Programme liefen erkennbar weiter: gkrellm zeigte weiterhin laufende Anzeigen, die angezeigte Systemuhr lief ebenfalls weiter. Die Maus konnte auch weiterhin bewegt werden. Es half nur ein Reset. Analysen des XFree-Treibers brachten keinen Erfolg.

Aufgrund dieser Phänomene habe ich den XFree-Server 4.3 von Sid installiert und vom Kernel 2.4.25 auf 2.6.4 gewechselt. Ich hatte auch die DRI-XFree-Treiber deinstalliert. Leider alles ohne Erfolg. Einfrierende Bildschirme blieben an der Tagesordnung.

Mittlerweile weiten sich die Probleme aus, so daß ich mittlerweile vermute, daß entweder eine zentrale Library oder Hardwarekomponenten meines Systems defekt sind: fsck's beim Booten bleiben hängen, einfache Befehlsaufrufe in einem XTerm führen zum Stillstand des Systems. Anders als oben beschrieben, rührt sich dann garnichts mehr (die Systemuhr steht beispielsweise). Nun zu Dingen, die ich während der vergangenen Tage analysiert bzw. beobachtet habe. Ziel für mich ist, herauszufinden, wo ich der Ursache meiner Probleme auf die Spur kommen kann. Momentan habe ich keine Idee mehr, was mich bei der Ursachenfindung weiterbringen könnte...

Ein "dmesg" brachte folgende, aus meiner Sicht nicht normale, Meldungen zu Tage:

Code: Alles auswählen

[...]
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...  failed.
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ... works.
[...]
Das sieht für mich so aus, als ob der Kernel versucht, den Timer zu initialisieren. Beim dritten Versuch (ExtINT IRQ) hat der dann Erfolg. Was ist mit dem oben genannten MP-BIOS Bug? Muß ich da ein neues Bios installieren?

Code: Alles auswählen

[...]
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:radeon_unlock] *ERROR* Process 1266 using kernel context 0
[...]
Kann es sein, daß ich mit der Grafikkarte noch weiterhin Probleme habe?

Code: Alles auswählen

[...]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
[...]
Ist das ein Fehler, den ich mir mit XFree 4.3 eingehandelt habe? Und dann gab es da noch meinen inn2-Newsserver, der mir mehrmals meldete:

Code: Alles auswählen

innd: SERVER cant listen RCreader Address already in use
Was soll mir das sagen? Habe ich evtl. einen Adressenkonflikt?

Nun denn. Ich habe auch versucht, eventuellen Hardwareproblemen meines Systems auf die Schliche zu kommen. Ich habe schonmal erlebt, daß zwei RAM-Streifen nicht miteinander harmonierten. Deshalb kam ich auf die Idee "memtest all" mal auszuprobieren. Dabei gab es jede Menge Meldungen "Unable to malloc xyz bytes." und einen Segmentation fault.

Code: Alles auswählen

[...]
Unable to malloc 1815085056 bytes.
Unable to malloc 1810890752 bytes.
Unable to malloc 1806696448 bytes.
Unable to malloc 1802502144 bytes.
Unable to malloc 1798307840 bytes.
Allocated 1794113536 bytes...trying mlock...Segmentation fault
Diese Ausgabe hatte ich bei jedem Streifen im Einzelbetrieb als auch mit beiden. Inzwischen habe ich mir eine Boot-CD mit Memtest von http://www.memtest.org erstellt und damit den Speicher über sechs Stunden getestet. Nach dem 11. Durchlauf werden damit keinerlei Fehler angezeigt. Aus dem Grund komme ich eigentlich wieder auf Softwareprobleme zurück. Nach Recherchieren im Forum habe ich gefunden, daß das Chipset meines Boards wohl Probleme macht und diesen Hinweis in http://www.debianforum.de/forum/viewtopic.php?t=22447 gefunden:
hast Du evtl. ein Mainboard mit nforce2-Chipsatz?
Das hat bei mir nämlich genau solche Probleme produziert, bis ich das gesamte ACPI-Geraffel aus dem Kernel geworfen habe.
Ich habe den Tip, in meiner /etc/lilo.conf eine append-Zeite mit dem folgenden Inhalt zu setzen, mal probiert:

Code: Alles auswählen

append "noapic nolapic acpi=off"
Leider blieben meine Bemühungen ohne Erfolg. Hat hier jemand evtl. noch weitere Ideen. Ich habe bei meinen Recherchen im Forum gesehen, daß mehrere Artikel ähnliche Phänomene behandeln. Das spricht eigentlich dafür, daß man Hardwareprobleme oder andere diffuse Problemursachen ausschließen könnte... :?

Herzlichen Dank schonmal für Antworten. Es würde mich auch sehr freuen, wenn sich an dieser Stelle andere Mitglieder melden, die an ihrem System ein ähnliches Verhalten festgestellt haben...

Gruß
Uwe

mat74
Beiträge: 62
Registriert: 12.11.2003 12:41:29

Beitrag von mat74 » 06.04.2004 12:37:37

Ich hatte ähnliche Probleme, bis ich meinen DDR-Ram von 333MHz auf 266MHz runtergefahren habe, übers BIOS. Erklärt wurde mir das so, daß GNU/Linux halt aggressiver an den Speicher rangeht und ihn nutzt-im Gegensatz zu Windows, das lieber in den Swap schreibt. So kommt es, dass u.U. Einstellungen die unter Win. funzen unter GNU/Linux bocken. So war das...
Hoffe das hilft...
cya

Benutzeravatar
CereS
Beiträge: 167
Registriert: 08.11.2003 18:07:44
Wohnort: Ruhrpott

Beitrag von CereS » 06.04.2004 13:34:45

ich würde mat74 zustimmen, wenn die Probleme so massiv auftreten, wie Du beschreibst:
also auch bei nem fsck beim Start des Systems.

Hört sich eher nach Hardware an - vielleicht bietet Dein BIOS ja die Möglichkeiten sehr
konservative Werte einzustellen (failsave settings, oder so ähnlich)
Auch kannst Du mal schauen, ob direkt nach einem freeze die Temperaturen vielleicht zu hoch sind.

Evtl. andere Variante, hast Du DMA für die Festplatte aktiviert? Ich habe mir mal ein System
(damals ein Redhat) systematisch zerlegt indem ich sehr aggressive DMA einstellungen verwendet habe.

Gruß,
Chris
"Friede seiner Asche" wird geschüttelreimt zu
"Ade seiner Frische", was auf das gleiche hinauskommt.

Benutzeravatar
bifo
Beiträge: 335
Registriert: 10.07.2002 07:22:39
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Monschau

Beitrag von bifo » 06.04.2004 14:23:20

Ich denke, die Sache mit dem fsck ist eine Folge der Abstürze, weil die Filesysteme nicht ordentlich vom System abgemeldet werden. Einmal war es halt so heftig, daß ich die Partitionen über die Woody-Rescue-CD wieder aufräumen mußte... :?

Die beiden Tips werde ich Heute Abend mal zuhause ausprobieren...

Gruß
Uwe

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 06.04.2004 15:51:20

Schau 'mal, ob Du im BIOS die APIC noch deativieren kannst (Bei mir: "APIC Mode: disabled". Wenn das immer noch nicht hilft: Wirf 'mal einen Blick in die Ausgabe von "dmesg" und suche dort nach APIC. Je nach System wird die nämlich dennoch vom Kernel aktiviert. In diesem Fall musst Du den Kernel neukompilieren und die ganzen APIC Optionen deaktivieren.

Die fsck sind einfach Folge der Abstürze, korrekt.

Falls das radikale disablen der APIC nicht hilft, könnte memtest weiterhelfen...

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

Benutzeravatar
CereS
Beiträge: 167
Registriert: 08.11.2003 18:07:44
Wohnort: Ruhrpott

Beitrag von CereS » 07.04.2004 01:30:57

hatte das so interpretiert, dass fsck hängen bleibt im Sinne von *abstürzen*, und das hätte ich böse gefunden.

Gruß,
Chris
"Friede seiner Asche" wird geschüttelreimt zu
"Ade seiner Frische", was auf das gleiche hinauskommt.

Benutzeravatar
h-man
Beiträge: 745
Registriert: 05.02.2003 13:10:08
Wohnort: Berlin
Kontaktdaten:

Beitrag von h-man » 07.04.2004 02:11:32

hy,
stell das bios auf "mach alles gut" also alles schön gemächlich, nix exotisches.
dann boote den rechner mal mit knoppix. immer noch so unstabil?
falls nein -> bios wieder auf aggressive timings etc... wirds dann unstabil?
nervig, aber hilfreich ist es natürlich, immer nur EINEN parameter im bios zu
ändern :-)
hman
Nieder mit der Schwerkraft.

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 07.04.2004 02:20:13

hatte das so interpretiert, dass fsck hängen bleibt im Sinne von *abstürzen*, und das hätte ich böse gefunden.
Jo, das geht auch, aber da die NForce Abstürze durch erhöhte IRQ Last getriggert werden, und da beim fsck ja die Platte ordentlich rattert und daher IRQs en masse produziert, ist die Wahrscheinlichkeit, dass er dann direkt beim fsck wieder abstürzt schon einigermassen hoch... Ist aber alles das gleiche Problem...

Auf meiner Kiste konnte ich es mit der Netzwerkkarte problemlos triggern: einmal ein paar MB an den Server schicken, und schon war er tot... :-( noapic, nolapic, deaktivieren aller Kernel Optionen, die mit APIC zu tun haben (Das bedeutet auch SMP muss deaktiviert werden!!!) und deaktivieren im BIOS hat die Kiste dann zu 100% stabilisiert... Auf nforcershq hat mir ein Ami sogar 20$ per Post geschickt, weil ich die Lösung gefunden habe... Sein Rechner blieb vorher so ca. alle 3 Minuten hängen... ;-)

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

Benutzeravatar
bifo
Beiträge: 335
Registriert: 10.07.2002 07:22:39
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Monschau

Beitrag von bifo » 07.04.2004 14:31:05

Hallo zusammen,

ich wollte mal einen Zwischenstand meiner Evaluierungen geben...

Die APIC-Deaktivierung habe ich im Bios gefunden. Leider noch das gleiche Verhalten. Die Deaktivierung habe ich erstmal gelassen. Meldungen zu APIC kann ich in der Ausgabe von "dmesg" nicht finden. Ansonsten sind mir folgende Dinge aufgefallen:

Code: Alles auswählen

Kernel command line: BOOT_IMAGE=Linux ro root=301 hdc=ide-scsi noapic nolapic acpi=off
...
ACPI: Subsystem revision 20040220
ACPI: Interpreter disabled.
...
ACPI: ACPI tables contain no PCI IRQ routing entries
PCI: Invalid ACPI-PCI IRQ routing table
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router default [10de/01e0] at 0000:00:00.0
Was soll mir das sagen? Habe ich jetzt Pest gegen Cholera getauscht? Die Meldung mit der Invalid IRQ routing table gibt mir eigentlich zu denken. Und dann war da noch:

Code: Alles auswählen

ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: HL-DT-ST  Model: DVDRAM GSA-4081B  Rev: A100
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 5
Linux agpgart interface v0.100 (c) Dave Jones
sr0: scsi3-mmc drive: 32x/32x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Könnte das Verhalten auch daher kommen, daß ich meinen DVD-Brenner als SCSI-Komponente am System definiert habe? Das habe ich gemacht, weil xcdroast mir einen entsprechenden Hinweis gegeben hat...

Ich habe im Bios den FSB-Parameter von 166 MHz auf 133 MHz gesetzt. Nun wird der Prozessor als Athlon 1900+ erkannt und meine RAMs werden laut Bios-Meldung mit 266 MHz getaktet. Ich habe mein System danach allerdings noch nicht wieder so "unbekümmert" bedient, daß ich einen Absturz provoziere. An dem Test bin ich noch dran. :wink: (BTW: Kann die Ursache dort tatsächlich liegen? Immerhin handelt es sich um 400 MHz-Module, die nur mit 333 Hz getaktet wurden... :roll:)

Ansonsten habe ich die DMA-Einstellung für die Festplatte im Bios noch nicht gefunden. Alle Einstellungen, die Vorgabewerte einstellen, stehen auf "Optimal". Sowas wie "Failsave" gibt es als Auswahlmöglichkeit nicht.

Gruß
Uwe

Benutzeravatar
bifo
Beiträge: 335
Registriert: 10.07.2002 07:22:39
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Monschau

Beitrag von bifo » 11.04.2004 13:15:47

Hallo zusammen,

ich habe neue Informationen:

Inzwischen habe ich mir einen eigenen 2.6.3er Kernel ohne APIC-Optionen compiliert. Immerhin bin ich jetzt so weit gekommen, daß ich nach einem Einfrieren meines Desktops via Tastatur wieder auf die Textkonsole komme. Ich bin dann in der Lage, den gdm neu zu starten.

Ergebnis:
Der Login-Bildschirm erscheint wieder. So weit, so gut. Wenn ich mich dann anmelde, dann werden keinerlei Fenster geöffnet. Das ist doch schonmal was!

Kann mir jemand sagen, ob Gnome beim Start einen Output generieren kann? Wenn ja, wo?

Einen Hardwaredefekt würde ich mittlerweile ausschließen wollen: Nachdem ich memtest von memtest.org via Boot-CD mehrere Stunden laufen ließ habe ich auch mal Knoppix 3.3 gebootet und dort völlig unbekümmert Fenster öffnen können, während ich mit meiner Debian-Installation derzeit nach dem 10. bis 30. XTerm irgendwann ein Fenster ohne Rahmen erhalte und die Kiste steht... :cry:

Das einzige, was jetzt noch auf meiner Liste steht ist, den Parameter "SMP" im Bios zu suchen und zu deaktivieren...

Österliche Grüße
Uwe, der sich über Eure Hilfe sehr freut.

init 0
Beiträge: 673
Registriert: 21.10.2003 19:40:28

Beitrag von init 0 » 13.04.2004 23:45:33

Shuttle SG45 kann doch gar keinen SMP haben.
SMP bezeichnet die Mehrprozessorsysteme und du hast keines.

Benutzeravatar
bifo
Beiträge: 335
Registriert: 10.07.2002 07:22:39
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Monschau

Beitrag von bifo » 14.04.2004 21:03:45

Hallo zusammen,

herzlichen Dank für alle Antworten. Ich habe den subjektiven Eindruck, daß mein System, nachdem ich mir einen eigenen Kernel compiliert habe, stabiler wurde. Die Abstürze sind definitiv seltener geworden. Das kann allerdings auch an einigen neuen X- bzw. Gnome-Packages in Testing liegen, die letztens im Zuge der täglichen Aktuallisierung auf mein System übertragen wurden.

Nochmals vielen Dank für die Hilfe.

Gruß
Uwe

Antworten