RAM-Fehler je nach Netzteil, Spannungen aber OK und keine Abstürze bei maximaler Last

[JBG]

Hallo,

seit einiger Zeit ärgert mich ein seltsames RAM-Problem, besonders, da Tests teilweise einen halben Tag dauern, um zu prüfen, ob alles OK ist. Ich war mir nicht sicher, ob das Thema hierhin oder in das Arbeitsspeicher- bzw. Netzteil-Unterforum gehört, wenn es hier stören sollte, bitte entsprechend verschieben.

Fehlerbild: Memtest 86+ 5.01 und MemTest 86 Pro 6.20 zeigen RAM-Fehler bei den intensiveren Tests, also meistens ab dem zweiten Durchgang.

Komponenten:

CPU: 4790K (Standardtakt, "Auto" im UEFI)
RAM: 4 x 8 GiB GeIL EVO Corsa DDR3-1866, spezifiziert für CL9-10-9-28 (XMP-Profil) bei 1,50 V
Mainboard: ASRock Fatal1ty Z97 Professional, UEFI 2.30 (neueste Version)
Netzteil: Seasonic 760 W SS-760XP2 (Kaufdatum 05/2013)
Grafikkarte: ASUS R9290X-4GD5 (290X, Standardtakt), PCIe-Slot 2, PCIe 3.0 x8 (CPU-Lanes) (Slot 1 kommt vom Z97-Chipsatz)
Netzwerkkarte: Intel Server Adapter I350-T2 V2, PCIe-Slot 4, PCIe 2.0 x4 (CPU-Lanes)
SATA-Controller: Digitus DS-30104-1, PCIe-Slot 6, PCIe 2.0 x2 (CPU-Lanes)

Für die Testzwecke sind gerade keine Festplatten verbunden.

Wie ich auf den Fehler gekommen bin:

Etwa einmal pro Monat lasse ich ohne Anlass Memtest zur Kontrolle über Nacht laufen, was etwa fünf bis sechs Durchläufen entspricht. Das Mainboard habe ich im Dezember verbaut, unmittelbar nach dem Einbau lief es fehlerfrei, beim Januar-Check tauchten die Memtest-Fehler auf.

Bisherige Versuche zum Eingrenzen der Fehlerursache:

1) RAM-Module einzeln und alle zusammen mit gleicher CPU auf einem Z97-Mainboard eines anderen Herstellers geprüft - Fehlerfrei, auch bei 1866 MHz/1,500 V
2) RAM-Spannungen im UEFI schrittweise bis 1,600 V erhöht - weiterhin Fehler
3) Kontakte auf den RAM-Modulen mit Isopropylalkohol gereinigt - weiterhin Fehler
4) CPU-Sockel-Pins auf Beschädigungen hin inspiziert - keine zu erkennen
5) Auf der CPU die Kontakte mit Isopropylalkohol gereinigt - weiterhin Fehler
6) UEFI neu geflasht - weiterhin Fehler
7) Alle PCIe-Karten entfernt - weiterhin Fehler
8) RAM auf 1600 MHz mit den 1866er Timings laufen lassen - keine Fehler

Nun hätte ich auf ein defektes Mainboard getippt (Leitungen zwischen Sockel und RAM-Steckplätzen), aber:

Tausche ich das Seasonic 760 W SS-760XP2 zum Testen gegen ein Enermax 1200 W Platimax EPM1200EWT, läuft Memtest mit unveränderten UEFI-Einstellungen fehlerfrei durch (bis sieben Durchgänge getestet), also auch bei 1866 MHz und 1,500 V.

Dabei sind die Spannungen des Seasonic-Netzteils sehr gut (gemessen an Molex-Steckern während Memtest lief, 12,02 V und 5,001 V mit Fluke 117), bei der 3,3er komme ich leider nicht ran, laut der UEFI-Anzeige, die sogar bei den 12 und 5 V-Leitungen die gleichen Angaben wie das Multimeter macht, ist mit 3,34 V ebenfalls alles OK. Die Spannungen des Enermax-Netzteils sind ähnlich, einzig die 12 V-Leitung ist mit 12,13 V etwas höher.

Während Memtest zieht das System etwa 100-120 W aus der Steckdose, je nach Test, beide Netzteile langweilen sich also eigentlich.

Unter Windows kann ich auf Maximallast mit Prime95 (AVX2) und Furmark gehen, es kommt zu keinen Abstürzen.

Hat jemand eine Idee, was man tun könnte? Eine RMA bei Seasonic obwohl die Messwerte in Ordnung scheinen?

Das hier beschriebene Muster ist mir auch erst aufgefallen, nachdem ich das System mehrfach zerlegt habe.

Grüße,
JBG

 

[RedSlusher]

Solange das System stabil ist würde ich aufhören krampfhaft nach einem Fehler zu suchen. Hast schon genügend Zeit versenkt.

Falls du aber weiter machen willst: Vielleicht knickt das Netzteil irgendwann kurz ein?

 

[Candy_Cloud]

Entweder das Netzteil verträgt die Last-Spikes von CPU und GPU Turbo nicht so gut, weil die kurz zeit Kapazitäten auf 12V zu gering sind oder es kann auch sein das der RAM VRM aus irgend einem Grund (evtl. zu geringe 12V Spannung) den RAM nicht auf Spannung halten kann.

 

[JBG]

@RedSlusher:

Bei RAM-Fehlern verstehe ich wenig Spaß, da diese zu beschädigten Daten führen können, ohne dass man es unmittelbar mitbekommt. Im Alltag lasse ich das System auch mit 1600 MHz RAM-Takt laufen und prüfe lediglich mit 1866 MHz. Da hier jedoch zunächst alles fehlerfrei lief, also keine allgemeine Hardware-Inkompatibiltät vorliegt und erst nun Fehler kommen, scheint irgendwo der Wurm drin zu sein, den ich finden möchte, bevor es zu Ausfällen kommt, die wirklich etwas ausmachen.

@Candy_Cloud:

Das Netzteil ist beim Auftreten der Fehler ein paar Stunden in Betrieb bei etwa der gleichen Last, die GPU idled bei Memtest ja und das System verbraucht hauptsächlich so viel, da die Energiesparfunktionen der GPU nicht aktiv sind. Kann man hierzu noch etwas in den UEFI-Spannungseinstellungen ausprobieren, was den Verdacht eventuell erhärtet?

 

[Galaxy9000]

@Im Alltag lasse ich das System auch mit 1600 MHz RAM-Takt laufen und prüfe lediglich mit 1866 MHz.

Also hast Du doch Dein Problem schon gelöst: Im Standardtakt wie vorgegeben, alles OK. Mit Übertaktung dann nicht mehr. Ergo: RAM ist okay, aber mit Deinen OC Versuchen nicht -> Fazit2: Lass es einfach und freu Dich, dass Deine HW mit den Standardeinstellungen und vorgegeben XMP Profil problemlos läuft. Das hat auch nichts mit dem NT zu tun.

 

[JBG]

@Galaxy9000:

Das XMP-Profil des RAM ist mit 1866 MHz und 1,500 V hinterlegt (also dessen Standardeinstellung), bei der er auch stabil läuft, nur eben mit einem anderen Netzteil. Dazu lief er auch schon fehlerfrei mit diesen Einstellungen bei der ersten intensiven Prüfung unmittelbar nach dem Zusammenbau des Systems.

 

[Holt]

8) RAM auf 1600 MHz mit den 1866er Timings laufen lassen - keine Fehler

Dann ist das Problem doch gelöst, die RAM Chip vertragen offenbar die 1866er Timings nicht mehr, denn auch Chips altern und gerade am Anfang ändern sich daher ihre Eigenschaften schon mal minimal. Diese waren offenbar nur im Neuzustand in der Lage mit dieser Frequnz zu laufen und sind es nun offenbar nicht mehr. Genau deshalb machen Profis auch zuerst einen Burn-In Test bevor neue HW in den Produktionsbetrieb geht.

 

[JBG]

Das würde ich voll unterschreiben, wenn die Module nicht reproduzierbar mit einem anderen Netzteil "sofort" wieder fehlerfrei sieben vollständige Durchgänge laufen, ohne, dass irgend etwas im UEFI verändert wurde.

Die Module sind übrigens von 2012 und wie gesagt (fast) monatlich geprüft, also nicht nagelneu letzten Monat gekauft und plötzlich wollen sie nicht mehr.

Was wäre denn ein für Amateure nachstellbarer Burn-In-Test für RAM-Module? Mein bisheriges Vorgehen war eben bei jeder UEFI-Änderung Memtest über Nacht laufen lassen und anschließend das System erst verwenden.

 

[Holt]

Wenn sie von 2012 sind, dann wäre so eine Änderung in dem Alter zwar etwas ungewöhnlich, ist aber trotzdem nicht auszuschließen. Laufen die denn mit einem anderen Netzteil nun 7 Durchgänge fehlerfrei? Das Netzteil kann leidet natürlich auch unter Alterung und der Prozess geht auch ständig weiter. Es gibt da bzgl. RAM von google eine ältere Studie:

Across the entire fleet, 8.2% of
all DIMMs are affected by correctable errors and an average
DIMM experiences nearly 4000 correctable errors per year.
...
In summary, our results indicate that age severely affects
correctable error rates: one should expect an increasing in-
cidence of errors as DIMMs get older, but only up to a cer-
tain point, when the incidence becomes almost constant (few
DIMMs start to have correctable errors at very old ages).
The age when errors first start to increase and the steepness
of the increase vary per platform, manufacturer and DRAM
technology, but is generally in the 10–18 month range.

Also im Alter von 10 bis 18 Monaten traten oft erst zunehmend Fehler auf (vermutlich fehlt da ein "or", dann würde es erstmals oder zunehmend bedeuten, was mehr Sinn ergibt, zumal im Satz davor ja vom seltenen erstmaligen Auftreten von Fehlern im hohen Alter die Rede ist) selten traten Fehler erstmal bei noch älteren RAMs auf. Daher ist es eben auch durchaus sinnvoll den RAM Test nicht nur am Anfang einmal zu machen, sondern auch mal zu wiederholen, spätestens wenn sich denn mal Probleme zeigen. Wobei der Zeitraum sich auf Dauerbetrieb bezieht, also auf 7300 bis 13140 Betriebsstunden, wobei bei Heimanwendern auch mal 3 bis 6 Jahre dauert so viele Betriebsstunden zu erreichen.

 

[JBG]

Ja, sieben fehlerfreie Durchgänge mit dem anderen Netzteil. Leider war das der erste Test mit dem anderen Netzteil, als ich die Hypothese noch nicht aufgestellt hatte, später habe ich angefangen, Fotos für ein Prüfprotokoll zu machen, vgl. Anhang mit kürzeren Tests (bislang treten - wenn sie kommen - die Fehler meistens im zweiten, spätestens im dritten Durchgang auf, daher habe ich da beim fünften abgebrochen, Foto mit Fehlern zeigt das Seasonic-Netzteil, ohne das Enermax-Netzteil mit unveränderten UEFI-Einstellungen)



Habe heute Nachmittag alle Steckkontakte des Seasonic-Netzteils gereinigt und manuell die BCLK auf 100.0 gesetzt (bei Auto wird auf 99 gerundet), bin gespannt, ob sich etwas ändert, ein neuer Test läuft gerade, leider erst im ersten Durchgang.

An den messbaren Spannungen hat sich absolut nichts verändert, aber vielleicht brachte es was.

 

[Holt]

Also immer wieder andere Error-Bits zu haben und dann noch so viele ist in der Tat für normale RAM Fehler sehr untypisch und deutet auf andere Probleme als die RAMs hin. Ungewöhnlich ist da schon eher, dass es bei 1600 keine und bei 1866 dann auf einmal doch Probleme auftreten, klar belasten höhere Frequenzen das Netzteil mehr, aber so hoch ist die Belastung während Memtest86 nun auch nicht, wenn es dabei z.B. zu einer erhöhten Restwelligkeit kommt, was für alterndes Kondensatoren in Netzteilen typisch ist, dann müsste der Rechner bei wirklich hoher Belastung wie Prime oder Furmark oder beiden zusammen, ja dauernd abstürzen.

Gut das die Ursache nun gefunden ist und es zeigt auch mal wieder wie wichtig es ist regelmäßig mal das RAM zu testen und das Fehler dort, nicht immer nur auf das Konto defekter RAM Riegel gehen.

 

[JBG]

Beim gestern angefangenen Test sind bereits fünf Durchgänge fehlerfrei (Seasonic-NT, 1866 MHz/1,500 V), ich werde es noch eine Weile laufenlassen.

Sollte es fehlerfrei bleiben, werde ich noch eine Gegenprobe machen und die BCLK wieder auf "Auto"(99) stellen und schauen, ob die Fehler wieder kommen. Das scheint ja dann eher ein UEFI-Bug zu sein, wenn es bei minimalster Untertaktung zu RAM-Fehlern kommt, oder?

Falls es das nicht war, scheint das Reinigen der Netzteilstecker etwas gebracht zu haben, wobei ich das schon sehr seltsam fände, das NT war stets verbaut, die Kontakte lagen also nie länger frei, so dass sie verdreckt hätten werden können.

Ergänzung (28. Januar 2016)

[...] Habe heute Nachmittag alle Steckkontakte des Seasonic-Netzteils gereinigt und manuell die BCLK auf 100.0 gesetzt (bei Auto wird auf 99 gerundet), bin gespannt, ob sich etwas ändert, ein neuer Test läuft gerade, [...]

Eine der beiden Aktionen scheint die Lösung gewesen zu sein, nun läuft es wieder bei 1866 MHz/1,500 V mit dem Seasonic-Netzteil:

 

[Holt]

Am BCLK der Haswell sollte man tunlichst nicht rumfummeln! Wenn Du Untertakten willst, senk die Multi, aber dann braucht man eigentlich nicht den 4790K zu kaufen, wenn man im Grunde weniger Leistung möchte.

 

[JBG]

Da hast Du etwas missverstanden: Ich *möchte* nichts untertakten. Mir ist lediglich beim x-maligen Memtest-Anstarren aufgefallen, dass Memtest den BCLK-Wert stets mit 99 angab, an was ich keinen zweiten Gedanken verschwendet hätte, würden nicht diese eigenartigen Probleme auftauchen (vgl. erstes Memtest-Foto). Im UEFI stand, während es die Probleme mit dem Seasonic-NT gab, BCLK auf "Auto", in der Beschreibung daneben heißt es auch "Default: 100.0". Aber irgendwas scheint da krumm zu runden.

Nun habe ich gestern bzw. genauer gesagt vorgestern den BCLK-Wert von "Auto" manuell auf "100.0" gesetzt - eigentlch sollte das ja das Gleiche sein, allerdings erkennt nun Memtest auch runde 100 bei der BCLK-Anzeige. Und das lief nun wie im letzten Foto dokumentiert knapp 22 h fehlerfrei durch.

Wäre es eventuell eine Überlegung wert, alle "Auto"-Einstellungen manuell auf die *ordentlichen* Standardwerte festzulegen?

 

[JBG]

Leider zu früh gefreut:



Ich mache noch eine letzte Gegenprobe mit dem zweiten Netzteil, bei dem die Fehler bislang nie kamen, sollte es weiterhin so sein, werde ich eine RMA bei Seasonic anstoßen.

 

[Holt]

Und wieder Fehler mit vielen Fehlerbits und über alle Bits hinweg und jedes mal mit anderen Bits und in aufeinanderfolgenden Adressen. Gerade so als wenn die RAM Inhalte in einem ganzen Bereich zufällig oder überschrieben worden wären. Könnte es eine andere HW sein, die sich da mal RAM nimmt und es wieder freigibt, so dass Memtest86 es nicht merkt? Ist die iGPU aktiv? Oder gibt es andere Karten im Rechner? Vielleicht hat auch einfach die Spannungsversorgung eines Controller oder eben einer anderen Karte ein Problem, so dass die sich dann neu initialisert und diese Fehler verursacht, dann würde es ganz gut auch mit dem Netzteil zusammenpassen.

Nimm mal die testweise die
Netzwerkkarte: Intel Server Adapter I350-T2 V2, PCIe-Slot 4, PCIe 2.0 x4 (CPU-Lanes)
und dann auch mal die
SATA-Controller: Digitus DS-30104-1, PCIe-Slot 6, PCIe 2.0 x2 (CPU-Lanes)
raus, also teste mal nur mit der einen und mal nur mit der anderen und dann mal ohne die beiden. Ich hatte mit der Digitus auch gewissen Probleme als ich da ein RAID 0 mit zwei SSD dran realisiert hatte und dies mit h2testw getestet habe, hatte ich die Testdaten nach einiger Zeit noch mal geprüft und dabei in einem Bereich Fehler. Dazu schien mir der Rechner instabiler zu laufen und auch die 950 Pro wurde zuweilen beim Booten nicht zu erkannt. Ich habe sie jedenfalls wieder rausgeworfen und seidher weniger Probleme.

 

[JBG]

Hmmm,

hatte ja im ersten Beitrag bereits geschrieben:

[...] 7) Alle PCIe-Karten entfernt - weiterhin Fehler [...]

Aber mit der iGPU bringst Du mich auf eine Idee; im UEFI ist die Option "iGPU Multi-Monitor" auf "Disabled", laut Handbuch sollte also die integrierte Grafik deaktiviert sein und kein RAM (für diese) abgezweigt werden.

IGPU Multi-Monitor
Select disable to disable the integrated graphics when an external graphics card is installed. Select enable to keep the integrated graphics enabled at all times.

Weshalb ich es erwähne: Meine mich zu erinnern, dass die Intel Grafik im Geräte-Manager aufgeführt wurde, als ich nach irgendwelchen Unregelmäßigkeiten gesucht hatte (also obwohl eigentlich deaktiviert).

Checke ich bei nächster Gelegenheit, möchte den gerade laufenden Langzeittest mit dem bislang fehlerfreien Enermax-Netzteil nicht unterbrechen.

Die einzige Eigenheit der Digitus-Karte, die mir bislang auffiel, war, dass sie unter Windows (8.1) mit dem Standard-Microsofttreiber manchmal bei Hot-Plugging neue Laufwerke nicht erkennt, nach einem Neustart tauchen sie schließlich alle auf. Unter Linux funktioniert dagegen das Hot-Plugging ganz normal.

Werde mal suchen, ob es noch aktuelle FWs für den Marvell-Chip gibt. Schei***, dass dieser Chip die einzige eigentlich brauchbare Lösung für ein paar mehr SATA-Laufwerke ist, ohne gleich in die Stufe der großen HBAs abzudriften.

 

[Holt]

Ja der Marvell 9230 ist eigentlich auch toll und bietet gerade für den Preis wirklich viel, sogar TRIM für SSDs im RAID 0, email Benachrichtigungen bei Problemen, SSD Caching für HDDs aber so ganz problemfrei ist er nicht und mit der Unterstützung, gerade auch FW Updates kann man das vergessen, zumal bei Digitus, die die Teile irgerndwo eingekauft haben und dem Marvell nicht einmal einen Kühler spendieren, wie ihn teils Karten mit dem kleineren 9215 haben.

 

[HITCHER_I]

Stelle auf DDR3-1600 ein, und CR=2T, schneller ist nicht zulässig lt. Spezifikation für 4 Module, daher instabil.
Außerdem ist mir bei 4 Modulen noch ein Problem aufgetreten, nämlich dass die inneren beiden überhitzt sind, und deshalb nach kurzer Aufwärmzeit instabil wurden, selbst bei DDR3-1600, da der CPU-Lüfter sie nicht mit angeblasen hat. Ein Zusatzlüfter über den RAM-Modulen war die Lösung.

 

[JBG]

Bei sporadischen Bit-Fehlern durch Überhitzung wäre es aber doch sehr eigenartig, das die Fehler in aufeinander folgenden Speicheradressen kommen (dazu immer in 32er Stufen), oder?

Beim letzten Test sind die Fehler nun auch zum ersten Mal beim zweiten Netzteil aufgetreten, nach dem ähnlichen Muster:



Bleibt also noch defektes Mainboard vs. UEFI, da mit gleicher CPU und RAM-Riegel alles fehlerfrei in einem anderen Mainboard läuft.

Habe die iGPU-Geschichte verfolgt, hier liegt schon einmal ein Bug im UEFI vor: Im Alltag nutze ich die iGPU parallel zur dGPU, ihre Speicherzuweisung ist der kleinste mögliche Wert (32 MB). Für die RAM-Tests ist die UEFI-Funktion "iGPU Multi-Monitor" auf "Disabled", was eigentlich die iGPU deaktivieren sollte und so so viel RAM wie möglich für die Tests zur Verfügung steht - tut es aber nicht, die iGPU ist weiterhin aktiv, so lange die Speicherzuweisung nicht auf "Auto" steht.

Eventuell führt dieser Bug zu abnormen Verhalten bei der Zuweisung von RAM, was Memtest dann mitbekommt. Nun lasse ich es gerade mit *wirklich* deaktivierter iGPU laufen.