Schwer reproduzierbare Fehler bei memtest86+ nach Hardwaretausch

[Wakarahen]

Letzten Donnerstag habe ich neue PC-Komponenten[1] erhalten und auch zusammengebaut. In der folgenden Nacht lies ich dann einen routinemäßigen Speichertest mit memtest86+ 4.20 laufen, welcher zu meiner unangenehmen Überraschung im vierten Test beim sechsten Durchgang einen einzigen Bitfehler anzeigte.

Im Folgenden erwies es sich aber als unglaublich schwer, den Fehler verlässlich zu reproduzieren. Zum Beispiel ergab ein weiterer Testlauf mit 12 Durchgängen keinerlei Fehler. Auch ein Test mit MPrime, der Linux-Version von Prime95, zeigte nichts an. Hierbei wurde das UEFI zwischenzeitlich auf die BETA-Version F6e aus dem Tweaktown-Forum geupdated.

Erst in der Nacht von Sonntag auf Montag ergab ein weiterer Memtest, dieses Mal eingeschränkt auf den vierten Test und ein paar hundert Megabyte um den beim ersten Mal identifizierten Speicherbereich, einen weiteren Fehler. Ein daran angeschlossener längerer Durchlauf, bei dem ich, wenn ich mich richtig erinnere, das XMP-Profil des Speichers aktivierte, ergab ein paar mehr Fehler, bei denen ich mir leider die Details nicht notierte. Nachdem der Rechner dann eine Weile ausgeschaltet war und nach dem Einschalten wieder ein Test gestartet wurde, ergab sich wieder keinerlei Fehler.

Darauf tauschte ich den Speicher dieses Rechners mit dem eines anderen[2] und lies auf beiden Rechnern Speichertests laufen. Dies ergab jedoch auch bei längeren Durchläufen keinerlei Befund auf beiden Rechnern.

Nachdem ich die Speicher dann wieder zurücktauschte, erhielt ich erneut einen Bitfehler beim ersten Rechner. Dieses Mal beim 20. Durchgang, wobei die Durchgänge wieder auf den vierten Test eingeschränkt wurden. Vorher wurde auch noch über einen längeren Zeitraum die Intel-Version des Linpack-Benchmarks, welcher den Unterbau für die grafische Oberfläche LinX unter Windows bietet, fehlerfrei durchlaufen.

Danach aktivierte ich erneut das XMP-Profil im UEFI und startete einen weiteren Speichertest, welcher jetzt beim 45. Durchgang des vierten Testes immer noch fehlerfrei ist.

Das UEFI war, wenn ich das XMP-Profil nicht aktiviert hatte, was die Speicher- und Spannungseinstellungen betrifft, immer auf den "Optimized Defaults".

Ich bin nun etwas verzweifelt und weiß nicht wirklich, wie ich weiter vorgehen soll, da mir auch nicht ganz klar ist, was genau defekt ist. Auch das systematische Ausschließen erscheint mir sehr schwierig, da der Fehler nur so selten und schwierig zur reproduzieren ist und ich somit dann nie wissen kann, ob das Problem isoliert wurde, oder der Fehler sich nur einmal mehr nicht gezeigt hat.

Das einzig erkennbare Muster ist, dass, wenn ein Fehler angezeigt wird, immer das gleiche Bit kippt. Die betroffenen Adressen sind leicht verschieden, was mit dem Interleaving zusammenhängen mag. Auch das Testmuster ist nicht immer identisch, wobei das betroffene Bit natürlich immer den gleichen Zustand vor und nach dem Kippen hat.

Ich habe mehr Tests gemacht, als aufgelistet wurden, zum Teil auch mit ein paar Experimenten bezüglich der Einstellungen im UEFI, welche aber alle ohne Befund blieben. Auch eine Manipulation des memtest-Quellcodes, sodass nur das als defekt erkannte Muster, bzw. der Teil davon, der das Problem hervorrief, vewendet wurde, erwies sich nicht als hilfreich.

Ich möchte für die sehr lange Ausführung um Verzeihung bitten und mich für jede Hilfe im Voraus bedanken.


[1]
Neu gekauft:
Mainboard: Gigabyte GA-Z87X-D3H
Prozessor: Intel i7-4770K
Kühler: Thermalright Macho
Speicher: 16GB Crucial Ballistix Sport DDR3-1600 DIMM CL9 Dual Kit

Von altem Rechner übernommen:
Grafikkarte: Asus GTX660-DC2O-2GD5
Netzteil: be quiet! Straight Power E9-CM 580W
+Gehäuse und Laufwerke

[2]
Mainboard: Gigabyte GA-H77-D3H
Prozessor: Intel Xeon E3-1230V2
Kühler: Alpenföhn Sella
Speicher: 2*8GB Corsair Vengeance Low Profile DDR3-1600 DIMM CL9 Dual Kit (davon wurde nur ein Kit zum Test in den ersten Rechner verbaut)
Netzteil: Irgendein be quiet! Straight Power

 

[hwk]

Du kannst in der Speicherkompatibilitätsliste für dein Board mal nachschauen ob dein RAM da drin aufgelistet ist.
http://download.gigabyte.eu/FileList/Memory/mb_memory_ga-z87x-d3h.pdf

 

[JackOnell]

Solange du doch keine Probleme im täglichen Gebrauch hast, brauchst du dir weniger nen Kopf darüber zu machen vor allem wenn der fehler nicht reproduzierbar ist.

Evtl hebst du die Spannung des RAM mal etwas an

 

[Wakarahen]

@hwk:
Ist er nicht. Eigentlich ging ich aber davon aus, dass das kein großes Problem darstellen sollte, zumal die ja ohnehin nur einen Bruchteil der verfügbaren Speichermodule testen.

@JackOnell:
Auch wenn ich die Parameter für die gezielte Provokation des Fehlers nicht kenne, so ist er doch mehr als einmal aufgetreten; dies deutet, soweit ich das beurteilen kann, schon auf ein zugrundeliegendes Problem hin. Außerdem vertragen sich zufällige, wenn auch unter Umständen seltene, Bitflips nicht mit meiner Vorstellung von einem verlässlichen Rechner, da diese durchaus zu Datenkorruption führen können. Zumal die Komponenten ja "nagelneu" sind und dementsprechend auch fehlerfrei funktionieren sollten.

 

[SubLeo]

Wenn der "Fehler" sich in Prime95 reproduzieren lässt, flashe dein Bios auf Version "F6e" (Beta).

Mit kleinen "Anlaufschwierigkeiten" ist bei neuen Produkten immer zu rechnen.

 

[Wakarahen]

Wenn der "Fehler" sich in Prime95 reproduzieren lässt, flashe dein Bios auf Version "F6e" (Beta).

Mit kleinen "Anlaufschwierigkeiten" ist bei neuen Produkten immer zu rechnen.

Leider kann ich den Fehler nicht mit Prime95 reproduzieren. Und auch das UEFI ist bereits auf Version F6e.

Mit "nagelneu" meinte ich auch weniger das kürzliche Erscheinen der Haswell-Mikroarchitektur, als vielmehr die Tatsache, dass die Komponenten erst letzten Donnerstag geliefert wurden.

Ich würde nur gerne herausfinden, ob etwas, und wenn ja, was (RAM/Mainboard/CPU) defekt ist, damit ich das entsprechende Teil schnellstmöglich umtauschen kann. Solange ich aber keine Möglichkeit habe, den Fehler verlässlich zu reproduzieren, ist es einfach schwierig, genau zu sagen, welche Einstellung helfen oder welche Komponente defekt sein könnte.

 

[JackOnell]

@hwk:
Ist er nicht. Eigentlich ging ich aber davon aus, dass das kein großes Problem darstellen sollte, zumal die ja ohnehin nur einen Bruchteil der verfügbaren Speichermodule testen.

@JackOnell:
Auch wenn ich die Parameter für die gezielte Provokation des Fehlers nicht kenne, so ist er doch mehr als einmal aufgetreten; dies deutet, soweit ich das beurteilen kann, schon auf ein zugrundeliegendes Problem hin. Außerdem vertragen sich zufällige, wenn auch unter Umständen seltene, Bitflips nicht mit meiner Vorstellung von einem verlässlichen Rechner, da diese durchaus zu Datenkorruption führen können. Zumal die Komponenten ja "nagelneu" sind und dementsprechend auch fehlerfrei funktionieren sollten.

Dann reklamier den RAM

 

[Wakarahen]

Dann reklamier den RAM

Obwohl ich mir das auch schon überlegt habe, ist es doch überhaupt nicht sicher, dass der RAM die Ursache ist. Ich habe einfach kein gutes Gefühl bei der Benutzung des Rechners, wenn da etwas im Argen liegt, das ich nicht genau identifizieren kann.

Inzwischen habe ich auch die Riegel in die beiden anderen Slots des Mainboards verlegt, konnte den Fehler aber bis jetzt nicht beobachten. Da ich jedoch den Auslöser nicht kenne, bedeutet dies natürlich nichts. Es könnte genauso gut einfach noch dauern oder etwas Bestimmtem bedürfen, bis der Speichertest wieder anschlägt.

Ich mache jetzt seit fast zwei Wochen kaum anderes, als diesem Problem nachzujagen. So langsam bin ich dann am Ende mit meinem Latein und meinen Kräften.

 

[bugmenot3]

Ist dir langweilig?

 

[Wakarahen]

Ist dir langweilig?

Nein, mir ist nicht langweilig. Ich hätte durchaus lieber einen fehlerfreien Rechner zur Verfügung, bei dem kein Bedarf zum Hardwaredebugging besteht.

Nach weiteren Tests gibt es inzwischen auch neue Ergebnisse. Wenn ich die Riegel einzeln im DDR3_1-Slot teste, dann werfen sie beide Fehler, welche man den Bildern im Anhang entnehmen kann. An der Anzahl der Durchläufe beim zweiten Riegel sieht man auch, wie lange das bisweilen dauert. Denjenigen, der mehr und schneller Fehler anzeigte, habe ich auch im DDR3_3-Slot getestet, wo er, zumindest für die Dauer des Testes, keine Probleme anzeigte.

Interessanterweise ergab auch ein längerer Testlauf mit zwei der Corsair-Riegel aus dem anderen Rechner, welche in Slot 1 und Slot 2 gesteckt wurden, keinen Befund.
Auch ein einzelnes Testen der Crucial-Riegel im anderen Rechner führte zu keinen Fehlern.

Ergibt das für jemanden einen Sinn, oder gibt es etwas, was ich noch nicht bedacht habe? Ich habe nämlich wirklich keinerlei Idee, was der Grund für diese Probleme sein könnte.

Anmerkung zu den Bildern: Die Timings des Speichers stimmen natürlich nicht. Memtest86+ 4.20 hat nur noch keine Unterstützung für Haswell, was die Erkennung betrifft. Auf die Tests hat dies aber keine Auswirkung.

 

[JackOnell]

Dann schick den Ram in RMA irgendwo musst du ja Anfangen und wenn du mit anderen Riegeln keine Fehler Produzierst
ist das der beste ansatz

 

[Wakarahen]

Dann schick den Ram in RMA irgendwo musst du ja Anfangen und wenn du mit anderen Riegeln keine Fehler Produzierst
ist das der beste ansatz

Meine starke Hoffnung ist natürlich, dass Du recht hast und ein Tausch des Speichers das Problem behebt. Im Vergleich zu den anderen Komponenten, die an den Fehlern beteiligt sein könnten, wäre dies die einfachste und am wenigsten problematische Möglichkeit.

Der Grund, warum ich so lange zögere ist, weil ich zu verstehen versuche, wie es sein kann, dass ebendieser RAM in einem anderen Slot meines Rechners und in einem anderen Rechner keine Fehler anzeigt. Aber vielleicht kann man das einfach nicht begreifen, weil es an irgendwelchen irrwitzigen Race Conditions liegt, und eine Reklamation des Speichers -- sofern sie ihn mir nicht einfach wieder ungetauscht zurücksenden -- löst das Problem wirklich.

 

[JackOnell]

Meine starke Hoffnung ist natürlich, dass Du recht hast und ein Tausch des Speichers das Problem behebt. Im Vergleich zu den anderen Komponenten, die an den Fehlern beteiligt sein könnten, wäre dies die einfachste und am wenigsten problematische Möglichkeit.

Der Grund, warum ich so lange zögere ist, weil ich zu verstehen versuche, wie es sein kann, dass ebendieser RAM in einem anderen Slot meines Rechners und in einem anderen Rechner keine Fehler anzeigt. Aber vielleicht kann man das einfach nicht begreifen, weil es an irgendwelchen irrwitzigen Race Conditions liegt, und eine Reklamation des Speichers -- sofern sie ihn mir nicht einfach wieder ungetauscht zurücksenden -- löst das Problem wirklich.

In dem Bereich wird man nie allea verstehen können mit Sicherheit nicht.....

Aber wenn du einen fehlerfreien Rechner haben möchtest musst du wo anfangen und hier gibt ea den verständlichen Entschluss.
Also rma

 

[Wakarahen]

In dem Bereich wird man nie allea verstehen können mit Sicherheit nicht.....

Aber wenn du einen fehlerfreien Rechner haben möchtest musst du wo anfangen und hier gibt ea den verständlichen Entschluss.
Also rma

Da ich gerne so viel wie möglich verstehen möchte, ist das natürlich schade.

Aber natürlich hast Du recht und ich muss irgendwo beginnen. Also wird es wohl die Reklamation des Speichers.

Danke für Deine Geduld.

 

[ThomasGoe69]

Und, wie ist der aktuelle Stand?

 

[Wakarahen]

Der Besitzer des Xeon-Rechners hat mir den Crucial-Speicher abgenommen, da die Fehler dort ja nicht reproduzierbar waren.
Dafür habe ich mir die G.Skill Ares F3-1600C9D-16GAR gekauft; diese produzieren glücklicherweise, zumindest nach aktuellen Stand, keine Fehler. Das einzig erwähnenswerte wäre vielleicht, dass im SPD 1333MHz einprogrammiert sind, obwohl die Herstellerseite von 1600MHz SPD-Geschwindigkeit spricht. Das lässt sich aber natürlich mit XMP oder manueller Konfiguration leicht beheben, obwohl es mich dennoch ein wenig wundert.

Letztendlich bleibt der wahre Grund leider unbekannt. Wenn ich spekulieren müsste, dann würde ich auf eine Inkompatibilität oder, da die Fehler ja nicht in allen Slots auftraten, auf eine empfindliche Reaktion auf die unterschiedlichen Signalleitungslängen tippen.

 

[Stefan Payne]

Obwohl ich mir das auch schon überlegt habe, ist es doch überhaupt nicht sicher, dass der RAM die Ursache ist.

Doch, ist es.

Wenn Memtest86 Fehler anzeigt, dann ist der Ram hin. PUNKT.
Also nicht irgendwie rumreden sondern den RAM reklamieren.

 

[Wakarahen]

Doch, ist es.

Wenn Memtest86 Fehler anzeigt, dann ist der Ram hin. PUNKT.
Also nicht irgendwie rumreden sondern den RAM reklamieren.

Das lässt sich, meiner Meinung nach, so pauschal nicht sagen.

Memtest86+ schreibt Muster in den Speicher, liest sie und vergleicht. Hierbei sind mehrere Komponenten beteiligt, die auch alle zu Fehlern führen können. Dazu fallen mir spontan die CPU, insbesondere die Caches und der integrierte Speichercontroller, sowie die Signalleitungen auf dem Mainboard ein. Des Weiteren würde ich vermuten, dass auch ein Netzteil, das keine sauberen Spannungen liefert, zu interessanten Phänomenen führen kann.
Außerdem ist es möglich, dass ein falsch eingestelltes oder fehlerbehaftetes UEFI zu Fehlern führt, da die Einstellungen für die Fehlererkennungsmethode von memtest86+ ja transparent sind. Wenn das UEFI zum Beispiel zu straffe Subtimings vergibt oder manuell vorgenommene Einstellungen nicht umsetzt, dann führt dies zu Fehlern, die aber nicht in den Riegeln direkt begründet liegen.

Dass dennoch die mit Abstand wahrscheinlichste Ursache der Speicher ist, seien es nun falsche Einstellungen oder defekte Riegel, stelle ich gar nicht infrage. Ich wollte nur aufzeigen, dass ein Fehler in memtest86+ nicht ausschließlich defekten RAM impliziert.