Re: MSI-Board mit Pentium 4 (HT): Stillstand

Am Freitag, 27. Mai 2005 14:47 schrieb Oliver Fromme:
> Andreas Braml <a.strich.b(at)web.de> wrote:
> > Hier folgt gleich ein Problem, wie man es liebt: keine Ausgabe
> > in der Logdatei, keine Meldungen von wegen Page Fault/Kernel
> > Crash o.Ä. auf der ersten virtuellen Konsole, nichts! Es ist
> > zum Mäuse melken!
>
> Das ist üblicherweise ein Zeichen für ein Hardwareproblem,
> oder (selten) eine Unverträglichkeit zwischen Hardware und
> OS auf unterster Ebene.

Das hatte ich auch getippt. Seit ich FreeBSD im Einsatz habe (ca. 2
Jahre) und irgendwas lief mal nicht, war entweder ich Schuld oder
defekte Hardware (einmal RAM, einmal die Festplatte, Netzteil
durfte auch). Aber da ist dann immer der Kernel "ausgerastet"
und /var/log/messages platzte aus allen Nähten. Beim RAM gab es
immer Segfaults beim Kompilieren, also alles irgendwie bemerkbar.
Aber wieso bleibt die Maschine jetzt einfach stehen?

>
> War das System zum Zeitpunkt des Freeze idle, oder liefen
> irgendwelche nennenswerten Prozesse?

Eher idle, ein paar Instanzen nfsd, bind etc., aber kein buildworld
oder Apache oder so.

> Wie oft ist es schon
> passiert,

4-5 Mal insgesamt in den letzten 10 Tagen.

> und wie schnell nach dem Booten passiert es, d.h.
> wie hoch ist so die durchschnittliche Uptime?

Mal so mal so. Einmal läuft das System 6 Stunden, dann stop, dann
wieder 2 Tage, dann stop. Als er 2 Tage lief, baute er die Packages
für die Clients aus den Ports, also eher Hochlast, bei den 6 h
stand er mehr oder weniger nur rum.

> Hat es einen
> Einfluß, ob der Rechner idle oder unter Last ist -- mit an-
> deren Worten: Tritt der Freeze schneller auf, wenn der
> Rechner viel zu tun hat?

Nein, eher im Gegenteil, aber die Häufigkeit (1 Mal) reicht nicht
für eine aussagekräftige Statistik ;)

>
> Ohne Crash-dump oder sonstige Anhaltspunkte ist es natür-
> lich leider sehr schwer, das Problem einzukreisen.

Ja, ist mir klar. Deshalb habe ich mich auch fast gescheut, hier zu
posten. Aber das System hat scheinbar keine Zeit mehr, einen Fehler
zu werfen. Deshalb tippe ich auch eher auf ein Hardwareproblem,
aber welches?

>
> Verwendest Du einen GENERIC-Kernel?

Ja, nur die 486/586er-Unterstützung habe ich rausgenommen.

> Du könntest testweise
> mal alles aus dem Kernel rauswerfen, das Du nicht unbedingt
> benötigst, also einen Minimal-kernel bauen.

Hatte ich schon, selbes Verhalten.

>
> Du könntest testweise auch eine andere OS-Version einsetzen
> (6-current oder 4-stable, oder auch DragonFly BSD) und dann
> schauen, ob das Problem dort auch auftritt.

Hm, ist leider nicht so einfach. Der Server steht inzwischen "in
Produktion", die Testphase war leider, als er die 3 Tage durchlief,
die Rückfallmaschine, auf der die Dienste bisher liefen, ist
inzwischen umgenutzt. Hier herrscht notorische Rechnerknappheit,
deshalb ist das mit den alternativen Systemen nicht so einfach.
Wenn alles andere nichts bringt, bleibt aber wohl nichts anderes zu
tun :(

> Oder mal ein
> anderes, aber verwandtes OS ausprobieren (NetBSD, OpenBSD).

Ja, wäre gleichzeitig was für den geistigen Horizont ;)

>
> Falls Du Ersatzteile herumliegen hast, könntest Du auch mal
> testweise Prozessor, RAM oder das ganze Mainboard austau-
> schen, um zu sehen, ob das einen Einfluß auf das Problem
> hat.

Leider nicht. Die Hardware gehört auch nicht uns, sondern wurde nur
"bereitgestellt". Wir dürfen sie nutzen, aber nicht dran frickeln.

> > [...]
> > Ist jemandem schon einmal solches Verhalten begegnet? Ich
> > dachte, vielleicht ist das RAM schlecht, memtest86 laufen
> > gelassen: nichts, "leider" alles in Ordnung. Was kommt da noch
> > in Frage? Netzteil? Prozessor (alles was nach HT aussah, habe
> > ich im BIOS deaktiviert)?
>
> Im Prinzip ist alles mögliche denkbar. Es kann am RAM lie-
> gen,

Der memtest gab keinen Fehler, deshalb würde ich sagen, eher nicht.

> am Prozessor, am Chipsatz (North-/Southbridge) oder
> an sonstigen Komponenten. Auch z.B. ein hängender PCI-Ge-
> rät (z.B. ein Controller) kann das ganze System mit sich
> ziehen. Normale PC-Hardware ist leider nicht besonders
> robust oder fehlertolerant.

Ja, das ist vielleicht noch relevant: in der Kiste ist eine MAudio
Delta 66 PCI-Soundkarte eingebaut, über die ein mp3-Stream
persistent abgespielt wird (MPlayer mit dem OSS-Treiber von
4Front). Da die Ausgabe dann über Posttrennverstärker auf UKW
rausgeht, wäre es auch so wichtig, dass das System 24/7 uptime
hätte.
Kann es sein, dass der Treiber den Fehler verursacht? Aber ich kann
nicht ohne ihn zu laden testen, da dann der Stream abreißen würde.

>
> > Kombination FreeBSD/Hardware?
>
> Denkbar, aber meistens äußert sich sowas in anderen Sympto-
> men als einem »cold freeze«.
>
> > WinXP lief auf dem Rechner recht stabil, d.h. ohne totale
> > Lockups.
>
> Das muß nicht unbedingt etwas heißen, da unterschiedliche
> Betriebssysteme unterschiedliche »usage patterns« haben,
> d.h. daß sie die Komponenten der Hardware auf unterschied-
> liche Weise ausnutzen bzw. auslasten.

OK, wäre es vermessen, die Leute antreten zu lassen, von denen die
Hardware gestellt wurde, sie sollen mal alles durchchecken? Oder
kann man das auch selbst, mit irgendwelchen Tools? Ich bin leider
nicht der Hardware-Überguru, deshalb bin ich mit meinem Latein fast
am Ende.

Danke jedenfalls schonmal für die Denkanstöße,

Gruß
Andreas

-- 
Andreas Braml
a.strich.b(at)web.de
PGP-Key: 0xEB7B9BFB http://braml.org/andreas_braml.asc
Keyserver: random.sks.keyserver.penguin.de

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 27 May 2005 - 17:33:49 CEST