Re: wie lese ich meine kerneldumps?

Update:
Die Sache entwickelt sich so langsam zu einem echten Ärgernis,
will meinen, ich kriege die Panics nicht recht weg und kann auch
die Ursache nicht finden. Das Fehlerbild wird immer bizarrer,
und scheint sich den üblichen Analyse-Strategien zu entziehen.

Ich wäre dankbar für ein paar Ideen, wie man die Geschichte
erklären könnte.

Alexander meinte:
On Fri, Oct 14, 2016 at 10:20:09AM +0200, Alexander Klein wrote:
> Aber abseits von allem Assembler: Was sagt denn der SMART-Status der
> Platte? Kann es sein, daÃ<9F> sie wirklich nur ein paar defekte Flash-Seiten
> hat und deswegen zwischendurch IO-Fehler wirft?

Das sind keine Probleme oder Fehlerraten, auf keinem der SATA drives.
Nur eine SCSI produziert, wie schon erwähnt, massig Soft-ECC.

Und Christian:
On Fri, Oct 14, 2016 at 20:39:15AM +0200, Christian Weisgerber wrote:
> > Von da an gabs dann immerhin einen automatischen Reboot - allerdings
> > keinen Dump, sondern die Meldung, dass die Platte, auf die gedumpt
> > werden soll (also das swap device auf der SSD, das mglw. schuld an der
> > Sache ist) I/O Error liefert. :(
>
> Damit scheint das Problem ja schon gefunden. Wenn das Laufwerk
> I/O-Fehler meldet, dann folgt spÃ#testens beim Zugriff auf Filesystem-
> strukturen die Panic. Es lohnt sich nicht, das weiter im Kernel zu
> verfolgen.

Ja, klingt logisch und wäre schön wenn es so einfach wäre...
Aber wie gesagt, da wird ein I/O-Fehler gemeldet, wenn gedumpt werden
soll, also *NACH* der Panic.
Inwieweit kann man eine haltbare Diagnose ableiten aus Fehlermeldungen,
die nach einer Panic getriggert werden? Also, wie definiert ist zu
dem Zeitpunkt der Zustand des Kernel überhaupt noch? Vor allem dann,
wenn man im Regelbetrieb keinerlei derartige Fehler sieht?

Ich hab schon zuerst in der Richtung gesucht, hatte aber gleich das
diffuse Gefühl, dass was anderes dahintersteckt - und das bestätigt
sich immer mehr.
Konkret: ich hab etwas gefunden, wie man (mit ziemlich hoher
Wahrscheinlichkeit, es sind dann jedenfalls keine mehr aufgetreten)
die Panics abstellen kann. Und zwar, indem man im SCSI-Controller
das TCQ für alle SCSI-Platten abschaltet!

Halten wir also fest: man baut ein SATA-SSD in den Rechner. Der
fängt daraufhin an, ~zweimal am Tag panics zu produzieren. Man wird
diese Panics nicht los (und ich hab zwischenzeitlich gut drei Viertel
der Hardware testweise ausgewechselt, ohne dass sich am Fehlerbild
was geändert hätte), ausser indem man für die SCSI-Platten das TCQ
ausschaltet. Ist das bizarr oder ist das bizarr?

-- 
Peter Much * Fichtenstr. 28 * 65527 Niedernhausen
home +49-6127-967111 * road +49-151-21416768 * office +49-170-9295685
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message