ECC (Error Correcting Code) ist eine Schlüsseltechnologie, um in einem Rechnersystem Daten zu schützen und Fehler zu erkennen. Dabei kann Standard-ECC-Memory, wie es heute in vielen Systemen verbaut wird, Einzelbitfehler erkennen und beheben. Doppelbitfehler werden zwar ebenfalls erkannt, können aber nicht ausgeglichen werden.
Das Umkippen eines einzelnen Bits in einem Byte kann dramatische Folgen haben. Wenn beispielsweise in einem Byte mit dem Wert 156 (10011100) das zweite Bit kippen würde (11011100), ergäbe sich ein Wert von 220. ECC kann diesen Fall entdecken und berichtigen, sodass der Anwender nichts davon merkt. Würden allerdings zwei Bits ihren Wert ändern, würde das zwar bemerkt, das Ergebnis wäre dann aber eine Machine Check Exception, die in einen Systemabsturz mündet.
Solche umkippenden Bits werden von elektrischen oder magnetischen Störungen verursacht. Einem Wikipedia-Artikel [1] und einer Studie über Einzelbitfehler im RAM [2] zufolge, gehen die meisten kippenden Bits auf das Konto der kosmischen Hintergrundstrahlung (hauptsächlich Neutronen). Die zwischen 2007 und 2009 ermittelten Fehlerraten schwanken zwischen 1010 und 1017 Fehler pro Bitstunde (Unterschied: sieben Größenordnungen!). Der niedrigere Wert entspricht einem Fehler pro Gigabit pro Stunde. Der höhere Wert ungefähr einem Fehler pro Gigabit in 1000 Jahren.
Eine Studie von Google (siehe Kasten "Korrigierbare Fehler" ) deutet darauf hin, dass Fehler im realen Leben viel häufiger sind. Diese Fehlerraten zu beobachten ist wichtig, denn sie sind ein genereller Indikator für Speicherfehler.
Korrigierbare Fehler
Google hat einmal reale Speicherfehler untersucht [3] . Sie fanden heraus, dass ein Drittel der beteiligten Rechner und mehr als acht Prozent der DIMMs während eines Jahres korrigierbare Speicherfehler aufwiesen. Das entsprach einer Beobachtung von Google, derzufolge es zu 25 000 bis 75 000 korrigierbaren Fehlern pro einer Milliarde Gerätestunden pro Megabit kommt (oder 250 bis 750 Fehlern pro Gigabit pro Jahr). Das ist viel mehr als die zuvor als hoch angenommene Fehlerrate von einem Fehler pro Gigabit pro Jahr.
Die Studie erbrachte noch weitere interessante Ergebnisse:
Der Autor dieses Beitrags arbeitete vor Jahren an einem Projekt namens Bluesmoke mit, das ein Kernel-Modul schaffen wollte, das Hardware-Fehler erkennen und melden sollte. Dabei ging es nicht allein um Speicherfehler, sondern um alle möglichen Fehler im Cache, beim DMA, bei der Temperaturregelung, auf dem Bus und so weiter. Der offizielle Name des Projekts war EDAC (Error Detection And Correction, siehe [5] ).
Viele Jahre lang schrieben Enwickler EDAC-Module für die verschiedensten Chipsätze. Das geschah zunächst außerhalb des Kernels, aber seit Kernel 2.6.16 ist EDAC dort integriert. Seit 2.6.18 erscheint EDAC auch im Sys-Filesystem unter
»/sys/devices/system/edac
«
.
Eine der besten Informationsquellen über EDAC ist das EDAC-Wiki [6] . Die Seite beschreibt den Einstieg und listet andere Ressourcen über EDAC (FAQs, Mailing-Listen und so weiter) auf. Hier soll es vor allem darum gehen, welche nützlichen Informtionen EDAC liefern kann. Für die Beispiele kommt ein Dell PowerEdge R720 zum Einsatz, der über zwei Prozessoren und 128 GByte Hauptspeicher verfügt. Während der Tests lief er unter CentOS 6.2.
Zunächst muss man sich vergewissern, dass die EDAC-Module geladen sind:
login2$ lsmod | grep edac sb_edac 18104 0 edac_core 53053 1 sb_edac
Sind die Module geladen, kann man als Nächstes das Verzeichnis
»/sys/devices/edac
«
untersuchen:
login2$ ls -s /sys/devices/system/edac insgesamt 0 0 mc
Wenn hier nur das device
»mc
«
auftaucht, überwacht EDAC nur den Memory-Controller. Schaut man tiefer in die Verzeichnisstruktur
login2$ ls -s /sys/devices/system/edac/mc insgesamt 0 0 mc0 0 mc1
kommen die beiden Komponenten
»mc0
«
und
»mc1
«
zum Vorschein.
Listing 1
zeigt, was man sieht, wenn man in das Verzeichnis
»mc0
«
schaut.
Listing 1
Memory-Controller
login2$ ls -s /sys/devices/system/edac/mc/mc0 total 0 0 ce_count 0 csrow1 0 csrow4 0 csrow7 0 reset_counters 0 size_mb 0 ce_noinfo_count 0 csrow2 0 csrow5 0 device 0 sdram_scrub_rate 0 ue_count 0 csrow0 0 csrow3 0 csrow6 0 mc_name 0 seconds_since_reset 0 ue_noinfo_count
Die beiden Memory-Controller dieses Systems verwalten eine Reihe von DIMMs, die in Zeilen (Chip Select,
»csrow
«
) und einer Kanaltabelle (
»chx
«
) organisiert sind (mehr Details dazu in der EDAC-Dokumenttion
[7]
). Wie
Listing 2
zeigt, kann es mehrere Csrows und mehrere Channels geben. Ihre Anzahl hängt vom Motherboard und der Art der Speicher-Controller und DIMMs ab.
Listing 2
Csrows und Channels
Für dieses Beispiel hat jeder Memory-Controller acht Csrows und eine Kanaltabelle. Eine Vorstellung vom Layout vermittelt Listing 3 .
Listing 3
Memory-Controller-Layout
login2$ more /sys/devices/system/edac/mc/mc0/csrow0/ch0_dimm_label CPU_SrcID#0_Channel#0_DIMM#0 login2$ more /sys/devices/system/edac/mc/mc0/csrow1/ch0_dimm_label CPU_SrcID#0_Channel#0_DIMM#1 login2$ more /sys/devices/system/edac/mc/mc0/csrow2/ch0_dimm_label CPU_SrcID#0_Channel#1_DIMM#0 login2$ more /sys/devices/system/edac/mc/mc0/csrow3/ch0_dimm_label CPU_SrcID#0_Channel#1_DIMM#1 login2$ more /sys/devices/system/edac/mc/mc0/csrow4/ch0_dimm_label CPU_SrcID#0_Channel#2_DIMM#0 login2$ more /sys/devices/system/edac/mc/mc0/csrow5/ch0_dimm_label CPU_SrcID#0_Channel#2_DIMM#1 login2$ more /sys/devices/system/edac/mc/mc0/csrow6/ch0_dimm_label CPU_SrcID#0_Channel#3_DIMM#0 login2$ more /sys/devices/system/edac/mc/mc0/csrow7/ch0_dimm_label CPU_SrcID#0_Channel#3_DIMM#1
Im Beispiel verfügt jeder Kanal (0 und 1) über vier Speicherkanäle (0 bis 3) und zwei DIMMs pro Kanal (0 und 1). In jedem
»csrow
«
-Unterverzeichnis finden sich dann eine Reihe weiterer Control- und Attribut-Files mit folgender Bedeutung:
Einige Attribut-Files in
»/sys/devices/system/edac/mc/mc0
«
können sehr nützlich sein. Sie beziehen sich auf den gesamten Controller:
Die Werte des Beispielsystems zeigt Listings 4 und 5 . Der letzte Reset liegt demnach 27 759 752 Sekunden oder ungefähr 321 Tage zurück. Der Speicher-Controller verwaltet 64 GByte und es gab weder korrigierbare noch nicht korrigierbare Fehler.
Listing 4
mc0/csrow0
login2$ ls -s /sys/devices/system/edac/mc/mc0/csrow0 total 0 0 ce_count 0 ch0_dimm_label 0 edac_mode 0 size_mb 0 ch0_ce_count 0 dev_type 0 mem_type 0 ue_count
Listing 5
Werte des Beispielsytems
login2$ more /sys/devices/system/edac/mc/mc0/ce_count 0 login2$ more /sys/devices/system/edac/mc/mc0/ce_noinfo_count 0 login2$ more /sys/devices/system/edac/mc/mc0/mc_name Sandy Bridge Socket#0 login2$ more /sys/devices/system/edac/mc/mc0/reset_counters /sys/devices/system/edac/mc/mc0/reset_counters: Permission denied login2$ more /sys/devices/system/edac/mc/mc0/sdram_scrub_rate login2$ more /sys/devices/system/edac/mc/mc0/seconds_since_reset 27759752 login2$ more /sys/devices/system/edac/mc/mc0/size_mb 65536 login2$ more /sys/devices/system/edac/mc/mc0/ue_count 0 login2$ more /sys/devices/system/edac/mc/mc0/ue_noinfo_count 0