------------------------------------------------------------------------
TL;DR:
- ECC scheint nicht zu gehen, obwohl die Komponenten ECC-fähig
sind. Kann das jemand mit einem Xeon oder ECC-fähigen Pentium auf
einem Fujitsu D3417(-B2) bestätigen oder widerlegen? Oder Tips
geben, wie ich die ECC-Funktionalität sicher nachweise? - Gibt es einen öffentlich zugänglichen Bugtracker von Fujitsu?
{ Edit 2017-08-03 18:50: Im BIOS-Handbuch[3] erwähnter Punkt
"Runtime Error Logging" existiert ebenfalls nicht }
Für einen Server habe ich folgende Komponenten zusammengefügt:
Board: Fujitsu D3417-B2
CPU: Intel Pentium G4560T (Kaby Lake, ECC-fähig)
RAM: 1 x Samsung 8 GB DDR4, unbuffered, ECC
Die CPU ist laut Intel ARK[1] ECC-fähig:
Unterstützung von ECC-Speicher: Ja
Ein Auslesen des ECCDIS-Bits[2] im CAPID0-Register bestätigt das:
Code: Select all
## Check for plausibility of register values
# setpci -s 00:00.0 0.w ## Offset 0: 2 Bytes Vendor ID. Default: 8086h
8086
# setpci -s 00:00.0 e4.l ## Offset E4h: Capabilities A (CAPID0). Default: 0h
60012061
## 60012061h = 1110 0000 0000 0001 0010 0000 0110 0001b
## ==> Bit 25 (ECCDIS) = 0 ==> ECC capable
Trotzdem also die CPU ECC-fähig ist, gibt es nicht den geringsten
Hinweis darauf, daß diese Speicherschutz-Möglichkeit erkannt und
genutzt wird. Im BIOS-Setup läßt sich diesbezüglich nichts
konfigurieren (Background Scrubbing, Chip Kill etc.); das Wort ECC
taucht nicht einmal auf. Edit: Laut BIOS-Manual müßte es
(normalerweise) zwischen "CPU Configuration" und "Drive Configuration"
den Punkt "Runtime Error Logging" geben, aber den gibt es nicht (in
der aktuellen BIOS-Version 1.8.0).
Leider funktionieren die entsprechenden Linux-EDAC-Kernelmodule für
Intel nur mit Xeons, und die Intel-Dokumentation zu dem Thema ist
... nennen wir es einmal "unübersichtlich".
Um also sicher herauszufinden, ob der Speicherschutz funktioniert,
habe ich kurzerhand Pins 1-3 (NC, VCC (mehrfach vorhanden), DQ4) eines
DIMM-Sockels mit einem dünnen Stück Plastikfolie elektrisch isoliert
(ESD-Maßnahmen selbstredend beachtet), das DIMM vorsichtig
hineingesteckt, den Sitz der Isolation geprüft und den Rechner
gestartet.
Erwartet habe ich:
- Der Rechner startet,
- der ECC-Mechanismus korrigiert den 1-Bit-Fehler,
- im Smbios-Event-Log (im BIOS-Setup unter "Event Logs" einsehbar) ist
mindestens 1 eindeutiger Eintrag zu diesem künstlich herbeigeführten
und automatisch korrigierbaren 1-Bit-Fehler zu finden, und - die Logfiles unter Linux werden mit MCE-Meldungen (Machine Check Exception)
überflutet.
Stattdessen:
- Bleibt der Bildschirm schwarz, und der Rechner gibt eine
kontinuierliche Folge von mittellangen Pieptönen von sich, und - nach dem Entfernen des Stücks Folie findet sich im Smbios-Event-Log
kein weiterer Eintrag.
Das sieht für mich erst einmal so aus, als sei der ECC-Support auf
diesem Board dysfunktional.
Mögliche Ursachen:
- BIOS-Fehler: ECC-Support wird nur bei Xeon-Familie genutzt, nicht
allgemein bei Prozessoren, die ECC-fähig sind. - Intels Angaben sind sowohl im WWW als auch im Silizium falsch, und
der Pentium G4560T beherrscht gar kein ECC. - Die CPU ist defekt.
- Das RAM ist defekt.
- Das Board ist defekt.
- Alles tut, wie es soll. Der Rechner muß erst mal bis zum BIOS
kommen, das den ECC-Support erst aktivieren muß, bevor ECC
funktioniert.
Kann jemand mit einem Xeon oder ECC-fähigen Pentium auf einem Fujitsu
D3417(-B2) meine Beobachtungen bestätigen oder gegenteilige
Beobachtungen oder weiterführende Details beitragen? Oder Tips geben,
was ich noch tun könnte, um sicher herauszufinden, ob ECC
funktioniert?
Und: Gibt es einen öffentlich zugänglichen Bugtracker von Fujitsu?
Grüße
peterlistig
[1] https://ark.intel.com/de/products/97465 ... e-2_90-GHz
[2] https://www.intel.com/content/www/us/en ... vol-2.html - chapter 3.39, page 97
[3] ftp://ftp.ts.fujitsu.com/pub/Mainboard- ... op_GER.pdf