Das könnte ein Adressierungsproblem sein, dann würden Daten von anderen Adressen ausgelesen und daher sind die Daten auch so verschieden. Das könnte am Board oder am Sockel der CPU liegen, wenn dann zuweilen ein Adresspin einfach keinen Kontakt hat. Das könnte angehen und wäre auch eine mögliche Ursache. Die Fehler treten ja auch bei den Tests mit zufälligen Daten auf, also wenn in den unterschiedlichen Adressen auch unterschiedliche Daten stehen, wenn überall die gleichen Daten geschrieben werden, fallen solche Fehladressierunge natürlich gar nicht auf.
RAM-Fehler je nach Netzteil, Spannungen aber OK und keine Abstürze bei maximaler Last
- Ersteller JBG
- Erstellt am
Es wäre ja fast zu schön, wenn die definitive Ursache rauskäme.
Den Sockel hatte ich wie gesagt bereits geprüft, eigentlich nichts zu sehen und der Kühler hat auch ein Montagesystem, bei dem die Radmuttern von Hand bis zum Ende angezogen werden, man also nichts zu fest anpressen können sollte.
Was mir gerade aufgefallen ist: Die Memtest-Fehler von Beitrag #10 und #20 sind identisch:
Anhang anzeigen 539458 Anhang anzeigen 540309
Kann man daraus etwas für oder gegen die Sockelthese ableiten?
Werde kommende Woche noch versuchen, vier andere RAM-Module für Gegentests zu besorgen.
Den Sockel hatte ich wie gesagt bereits geprüft, eigentlich nichts zu sehen und der Kühler hat auch ein Montagesystem, bei dem die Radmuttern von Hand bis zum Ende angezogen werden, man also nichts zu fest anpressen können sollte.
Was mir gerade aufgefallen ist: Die Memtest-Fehler von Beitrag #10 und #20 sind identisch:
Anhang anzeigen 539458 Anhang anzeigen 540309
Kann man daraus etwas für oder gegen die Sockelthese ableiten?
Werde kommende Woche noch versuchen, vier andere RAM-Module für Gegentests zu besorgen.
Zuletzt bearbeitet:
Wenn die zufälligen Daten beim Test gar nicht wirklich zufällig sind, könnte das die These verstärken, dass des ein Adressierrfehler ist und da wäre es dann sehr wahrscheinlich, dass es immer das gleiche Adressbit betrifft. Ob der nun im CPU Sockel, auf dem Boards, dem RAM Slot oder doch dem RAM Riegel liegt, lässt sich darauf aber wohl leider nicht ableiten.
Zwischenstand (lasse gerade das erste Mal Memtest mit tatsächlich deaktivierter iGPU laufen):
Also bislang die längste fehlerfreie Zeit, werde ihn laufen lassen, bis ich die Tage die vier anderen RAM-Module besorgt habe.
Wären denn nun noch Sockelunregelmäßigkeiten realistisch?
Dass gerade jetzt keine Fehler auftreten, nachdem die verbuggten UEFI-iGPU-Optionen gefunden sind - ob das ein Zufall ist?
Was mir noch aufgefallen ist: Die Memtest-Durchgänge dauern nun etwas länger, obwohl eigentlich nur etwa 32 MB mehr zu testen sind; zuvor dauerte der erste kurze Durchgang ca. 1 h, danach je 3 h, nun deutlich länger (alle UEFI-CPU-/RAM-Einstellungen identisch und Memtest läuft immer im forcierten Multi-Core-Modus).
Hatte bisher eher gedacht, dass eine aktive iGPU eher verhindert, dass Memtest eventuell vorhandene physische Fehler findet, da es nicht den RAM mittesten kann, den sich die iGPU reserviert hat.
Also bislang die längste fehlerfreie Zeit, werde ihn laufen lassen, bis ich die Tage die vier anderen RAM-Module besorgt habe.
Wären denn nun noch Sockelunregelmäßigkeiten realistisch?
Dass gerade jetzt keine Fehler auftreten, nachdem die verbuggten UEFI-iGPU-Optionen gefunden sind - ob das ein Zufall ist?
Was mir noch aufgefallen ist: Die Memtest-Durchgänge dauern nun etwas länger, obwohl eigentlich nur etwa 32 MB mehr zu testen sind; zuvor dauerte der erste kurze Durchgang ca. 1 h, danach je 3 h, nun deutlich länger (alle UEFI-CPU-/RAM-Einstellungen identisch und Memtest läuft immer im forcierten Multi-Core-Modus).
Hatte bisher eher gedacht, dass eine aktive iGPU eher verhindert, dass Memtest eventuell vorhandene physische Fehler findet, da es nicht den RAM mittesten kann, den sich die iGPU reserviert hat.
Zuletzt bearbeitet:
Ob es an der iGPU oder an einer Fehladressierung liegt ist schwer zu sagen wenn man nicht weiß ob die Zufallsdaten wirklich zufällig sind oder nur pseudozufällig. Sind es echte Zufallsdaten, so dürften sie sich nicht bei verschiedenen Testläufen wiederholen und dann spricht es eher für die iGPU, aber wieso die RAM belegt welches Memtest86 dann noch sehen und testen kann, verstehe ich nicht ganz. Das deutet dann auf einen Bug im UEFI hin oder vielleicht eine Instabilität im System, welches der iGPU zum falsche Zeitpunkt unterschiedliche RAM Größen zuteilt. Vielleicht sowas aber auch vorgesehen und Memtest86 merkt das einfach nicht und testet daher RAM Bereiche, die dem OS eigentlich inzwischen entzogen wurden. Da kenne ich mich auch nicht so aus was da inzwischen alles so möglich und vorgesehen ist, früher war das mal ein fester RAM Bereich und der wurde gleich für die iGPU reserviert und konnte gar nicht vom OS oder solche Testprogrammen angesprochen werden, aber die iGPU werden ja auch immer weiter entwickelt.
Wenn es so ist, wäre ggf. ein Treiberproblem auch die Ursache für die Abstürze, wenn auch unter Windows nicht erkannt wird, dass sich der RAM Bereich der für die iGPU ist, geändert hat. Das würde mich dann aber schon etwas wundern.
Werden beim Test mit Random Daten nun aber keine echte Randomdaten sind, sondern Pseudorandomdaten sie sich immer gleich ergeben, kann man gleich mal gar nichts darauf schliessen, dann ist es vielleicht einfach nur Zufall das es diesmal fehlerfrei läuft und unter anderen Umständen tritt der Fehler wieder auf.
Wenn es so ist, wäre ggf. ein Treiberproblem auch die Ursache für die Abstürze, wenn auch unter Windows nicht erkannt wird, dass sich der RAM Bereich der für die iGPU ist, geändert hat. Das würde mich dann aber schon etwas wundern.
Werden beim Test mit Random Daten nun aber keine echte Randomdaten sind, sondern Pseudorandomdaten sie sich immer gleich ergeben, kann man gleich mal gar nichts darauf schliessen, dann ist es vielleicht einfach nur Zufall das es diesmal fehlerfrei läuft und unter anderen Umständen tritt der Fehler wieder auf.
Nach nun gut 30 h fehlerfrei werde ich mal versuchen, das iGPU-Muster zu bestätigen.
Glaube, ich gehe mal mehr auf Memtest86 6.30 von Passmark, da das weiterentwickelt wird und im Gegensatz zu Memtest86+ 5.01 auch einen Hammer-Test und UEFI-Unterstützung dabei hat.
BTW: Was ist denn eigentlich für neuen RAM ein guter Burn-In-Test? 24 h Memtest laufenlassen oder doch Custom-Prime95 mit manuell möglichst viel RAM zugewiesen und deaktivierter Auslagerungsdatei?
Konnte bei 20 h Passmark Memtest inkl. Hammer-Test mit aktivierter iGPU keine Fehler mehr finden (wie beim letzten 30 h Memtest86+-Versuch mit deaktiverter iGPU) :-/
Das wurmt mich jetzt etwas, da ja eigentlich nichts verändert wurde und nun keine Fehler mehr auftreten, also keine konkrete Fehlerursache gefunden wurde.
Gerade lasse ich Memtest Pro mit "Enthusiasten-RAM" (2133 MHz/DDR3L 1,35 V) von zweifelhafter Qualität (Corsair, also kein Chip-Hersteller) laufen, der pragmatische Gedanke dahinter war, dass durch die höheren Frequenzen bei gleichzeitig niedrigerer Spannung eventuelle Leitungsprobleme beim Mainboard (CPU-Sockel, RAM-Plätze) ja forcierter zu Fehlern führen sollten.
Glaube, ich gehe mal mehr auf Memtest86 6.30 von Passmark, da das weiterentwickelt wird und im Gegensatz zu Memtest86+ 5.01 auch einen Hammer-Test und UEFI-Unterstützung dabei hat.
BTW: Was ist denn eigentlich für neuen RAM ein guter Burn-In-Test? 24 h Memtest laufenlassen oder doch Custom-Prime95 mit manuell möglichst viel RAM zugewiesen und deaktivierter Auslagerungsdatei?
Ergänzung ()
Konnte bei 20 h Passmark Memtest inkl. Hammer-Test mit aktivierter iGPU keine Fehler mehr finden (wie beim letzten 30 h Memtest86+-Versuch mit deaktiverter iGPU) :-/
Das wurmt mich jetzt etwas, da ja eigentlich nichts verändert wurde und nun keine Fehler mehr auftreten, also keine konkrete Fehlerursache gefunden wurde.
Gerade lasse ich Memtest Pro mit "Enthusiasten-RAM" (2133 MHz/DDR3L 1,35 V) von zweifelhafter Qualität (Corsair, also kein Chip-Hersteller) laufen, der pragmatische Gedanke dahinter war, dass durch die höheren Frequenzen bei gleichzeitig niedrigerer Spannung eventuelle Leitungsprobleme beim Mainboard (CPU-Sockel, RAM-Plätze) ja forcierter zu Fehlern führen sollten.
Zuletzt bearbeitet:
Konnte nun nirgens mehr Fehler feststellen, die 2133 MHz/1,350 V-Module laufen auch ohne Fehler, dafür sind sie bei der intensiveren Row Hammer-Methode anfällig und halten nur der schwächeren Variante stand:
Weiß jetzt nicht so recht, was ich von der ganzen Geschichte halten soll, aber schön zu erfahren, dass die ursprünglichen 2012er GeIL-Module völlig Row Hammer-resistent sind, auch bei 24 h Dauerstress bei 1866 MHz/1,500 V.
Weiß jetzt nicht so recht, was ich von der ganzen Geschichte halten soll, aber schön zu erfahren, dass die ursprünglichen 2012er GeIL-Module völlig Row Hammer-resistent sind, auch bei 24 h Dauerstress bei 1866 MHz/1,500 V.
