Neue Erkenntnisse zu Speicherfehlern bei DRAM

[SPINA]

Container kann man übrigens reparieren, aber wiegesagt - sowas kommt in der Praxis eh nicht vor...

Wenn ich da an den Dienst zur automatischen Defragmentierung von Windows 7 denke, sehe ich schon Praxisrelevanz.

Auch wenn die Wahrscheinlichkeit eines Festplattenfehlers voraussichtlich deutlich höher ist.

 

[mibo]

Danke SPINA für die ECC/reg-Erklärung.

Mir fällt gerade ein, dass ich auf der Arbeit wahrscheinlich auch ECC-DDR2 in ein paar Rechnern habe. Da kann ich mir nen Riegel zum Testen leihen.

Zum Thema Wahrscheinlichkeit:
Ich hatte (wie gesagt) schon beschädigte Daten (Ursache unbekannt) und 35€ für nen 2GB ECC RAM wäre mir der Versuch Wert.
Defekter RAM is mir auch schon ein paar mal begegnet.

Mein Fileserver hat ein Raid1, um Festplattenausfälle zu entschärfen.

 

[User002]

Wenn ich da an den Dienst zur automatischen Defragmentierung von Windows 7 denke, sehe ich schon Praxisrelevanz.

Auch wenn die Wahrscheinlichkeit eines Festplattenfehlers voraussichtlich deutlich höher ist.

Stimmt, so eine Autodefragmentierungsfunktion könnte da kritisch sein. Bei zunehmend SSDs als Systemlaufwerk und großen Dateien im Archiv (Filme und Bilder, weitere gepackte Archive)) lohnt sich Defragmentierung zwar nicht (Bei der Datensicherung - kein Backup, sondern kopieren der Files auf andere HDs defragmentiert sich das von selbst, und geht wesentlich schneller wie das rumkopieren auf einer HD), aber zumindest in der Theorie hast du da recht. Grade bei so "minimal" instabilem Speicher, der nur sehr sporadisch Fehler verursacht..

Grüße!

 

[larsbo]

Stimmt nicht...die Paritätsprüfung erkennt einen 1Bit Fehler! ECC kann einen 1Bit Fehler beheben und einen 2Bit Fehler erkennen

He, he, nice try sagt der Amerikaner dazu.....

Ja, eine Paritätsprüfung könnte 1bit Fehler erkennen. Problem ist nur, dass non-ECC-Dimms kein Paritätsbit mit abspeichern. Parity-Module stammt noch aus der Zeit der 8bit-simms. Die hatten ggf. ein neuntes Bit mit drauf für die Parität. Wenn man heute bei 64bit Dimms einen zusätzlichen Chip mit draufhaut, dann liefert der gleich 8bit mit dazu, womit dann eben praktischerweise automatisch ECC möglich ist. Es gibt also nur entweder Module ohne jegliche Sicherung oder welche mit ECC. Reine Parität gibbet nicht mehr in PCs.

 

[KIDH]

He, he, nice try sagt der Amerikaner dazu.....

Ja, eine Paritätsprüfung könnte 1bit Fehler erkennen. Problem ist nur, dass non-ECC-Dimms kein Paritätsbit mit abspeichern. Parity-Module stammt noch aus der Zeit der 8bit-simms. Die hatten ggf. ein neuntes Bit mit drauf für die Parität. Wenn man heute bei 64bit Dimms einen zusätzlichen Chip mit draufhaut, dann liefert der gleich 8bit mit dazu, womit dann eben praktischerweise automatisch ECC möglich ist. Es gibt also nur entweder Module ohne jegliche Sicherung oder welche mit ECC. Reine Parität gibbet nicht mehr in PCs.

Verdammt...erwischt! Ich war echt der festen Überzeugung, daß heutzutage irgendwo ne Paritätsprüfung stattfindet.

1Bit-Fehler dürften ja mit Abstand die häufigsten sein...so bräuchte man nur die Daten verwerfen und gut ist.

 

[trick]

beim post zeigt mein asus-board, wenn ecc an ist.
linux meldet es bei aktuellen kernels ebenfalls:

[   10.439974] EDAC amd64_edac:  Ver: 3.2.0 Oct 15 2009
[   10.440247] EDAC amd64: ECC is enabled by BIOS, Proceeding with EDAC module initialization
[   10.440269] EDAC MC: F10h CPU detected
[   10.440320] EDAC MC0: Giving out device to 'amd64_edac' 'Family 10h': DEV 0000:00:18.2
[   10.440334] EDAC PCI0: Giving out device to module 'amd64_edac' controller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED)

sporadisch meldet linux mir im kernel log auch meldungen zu ecc-fehlern. da die fehler nicht reproduzierbar sind, konnte ich bislang durch testen einzelner module/modulkombinationen nicht rausfinden, welches modul nun die macke hat. wenn der fehler kommt, dann früh und solange der pc läuft, immer wieder mal. kommt in den ersten minuten keine meldung, kommen auch keine mehr.

ungewöhnlich, normalerweise kommt sowas entweder kurz nach dem booten oder gar nicht (2 fehler von einer ganzen reihe):

[452242.012915] EDAC amd64 MC0: BUS ERROR: 
[452242.012919]   time-out(no timeout) mem or i/o(mem access)
[452242.012922]   participating processor(local node originated (SRC))
[452242.012925]   memory transaction type(generic read) 
[452242.012927]   cache level(L3/generic) Error Found by: Normal Operation
[452242.012937] EDAC amd64 MC0: CE ERROR_ADDRESS= 0x1bfa6e0
[452242.012949] EDAC MC0: CE page 0x1bfa, offset 0x6e0, grain 0, syndrome 0x3d01, row 3, channel 0, label "": amd64_edac
[452242.012956] EDAC amd64 MC0: ExtErr=(0x8) F10-ECC/K8-Chipkill error
[452767.121311] EDAC amd64 MC0: BUS ERROR:
[452767.121315]   time-out(no timeout) mem or i/o(mem access)
[452767.121318]   participating processor(local node responded to request (RES))
[452767.121321]   memory transaction type(generic read)
[452767.121323]   cache level(L3/generic) Error Found by: Normal Operation
[452767.121334] EDAC amd64 MC0: CE ERROR_ADDRESS= 0x1bfa6e0
[452767.121345] EDAC MC0: CE page 0x1bfa, offset 0x6e0, grain 0, syndrome 0x3d01, row 3, channel 0, label "": amd64_edac
[452767.121352] EDAC MC0: CE - no information available: amd64_edacError Overflow set
[452767.121358] EDAC amd64 MC0: ExtErr=(0x8) F10-ECC/K8-Chipkill error

 

[ghostadmin]

Ein gekipptes Bit kann dafür sorgen, dass sich ein Bild nicht mehr öffnen lässt. Mit etwas Arbeit könnte man vielleicht das geänderte Bit finden - aber was ist z.B. mit einem verschlüsselten Container? Da sind dann alle enthaltenen Daten verloren.

Glaube ich kaum, ausser es erwischt den zentralen Schlüssel aber den kann man dann ja wiederherstellen falls man so schlau war, den vorher zu sichern. Mit einem Fehler in 12 JAhren kann ich leben.

 

[mibo]

Mal ne doofe Frage zu EDAC unter Linux.
Muss ich mir da echt nen neuen Kernel für bauen?
Ich wollte das gerade auf meinem Ubuntu-Fileserver benutzen und habe die edac-utils installiert, aber da ist kein Kernel-Modul dabei, was geladen wird
Oder wie aktiviere ich das?

Bitte um Hilfe
mibo

Edit:
uname -a
Linux xbmc 2.6.27-14-generic #1 SMP Tue Aug 18 16:25:45 UTC 2009 i686 GNU/Linux

 

[trick]

edac für amd cpus ist erst mit dem 2.6.31er kernel gekommen. um es zu nutzen musst du also nen neuen kernel installieren, z.b. den von karmic

 

[PuckPoltergeist]

edac für amd cpus ist erst mit dem 2.6.31er kernel gekommen. um es zu nutzen musst du also nen neuen kernel installieren, z.b. den von karmic

Sofern das $DISTRIBUTOR nicht zurück portiert hat.

 

[trick]

wenn amd64_edac_mod nicht zur verfügung steht, muss er so oder so nen neuen kernel installieren, egal ob den von karmic oder einen anderen mit entsprechendem backport.

 

[mibo]

Danke für die Infos, auch wenn es nicht das ist, was ich hören wollte
Mal sehen, ob ich heute Abend Zeit für ein Kernel-Update finde.

Memtest 2.10/2.11 von ner Boot-CD hat zwar ECC angezeigt, aber deaktiviertes Chipkill (obwohl im BIOS angeschaltet) und 428MHz Speichertakt gemeldet. Der Takt sollte auf standard-400MHz (DDR2-800) stehen.

 

[mibo]

Mein Ubuntu 8.10 Kernel 2.6.27 hat ein amd76x_edac.ko-Modul, welches ich auch laden kann.
edac-util --status
edac-util: EDAC drivers loaded. No memory controllers found

Leider funzt das nicht
Wie heißt das Modul, dass ich brauche?

Also müsste ich entweder einen aktuellen EDAC-Patch in den vorhandenen Kernel 2.6.27 oder einen kompletten Kernel 2.6.31 compilieren? Da warte ich vielleicht lieber auf Ubuntu 9.10. Das hat ja auch den Kernel 2.6.31.

 

[trick]

der genaue modulname steht oben (amd64_edac_mod)! das von dir getestete modul ist für den alten amd 760mp(x)-chipsatz für athlon mp cpus, die noch den k7 kern haben.
die final von karmic sollte eigentlich in diesen tagen erscheinen.

 

[mibo]

der genaue modulname steht oben (amd64_edac_mod)! das von dir getestete modul ist für den alten amd 760mp(x)-chipsatz für athlon mp cpus, die noch den k7 kern haben.
die final von karmic sollte eigentlich in diesen tagen erscheinen.

Danke für die Info. "amd64_edac_mod" sieht so anders aus, als die anderen EDAC-Module. Deshalb dachte ich, dass wäre nur der "ungefähre" Name.

Dann warte ich wohl auf 9.10.

 

[buette]

heheh datensicherung auf CD und DVD, na das kann ja was werden.
genau, die kisten laufen dann instabil.
wenn man hinterher versuchen will/muss die daten wieder zu retten oder container zu flicken,
muss man wissen was einem seine freizeit in monetärem nutzen wert ist.
da wird ecc interessant, zumal die preise nicht mehr so abartig sind.
2x 2GB 800er zu 70€ sind ok