RAM-Fehler noch und nöcher

ReactivateMe347 schrieb:
Wenn XMP oder irgendwas anderes das "heimlich" tut,
XMP tut das nicht heimlich -> wenn du durch aktivieren vom XMP den "zertifizierten" Mem-Takt deiner CPU (SoC) überschreitest dann hast du das OCed, das Board macht das nicht von alleine, denn XMP muss aktivert werden von dir. Ob dir das bewusst ist oder nicht, hat mit heimlich nix zu tun. XMP tut genau das und ist genau dafür da, es stellt sturr die Werte ein die der Mem packen sollte!... Es ist einfach nur ein Profil. Der Mem weiß nicht wo er drin steckt, welche CPU drin steckt, welches Mobo du hast, wieviele RAM-Riegel da sind....

-Das alles bitte nur als Erklärung zu verstehen ;-)
 
@Nickel . Ich hab ja nicht geschrieben das Memtest(86) schlecht wäre, nur das eben Windows sowas schon mitliefert. Speicher mit Pattern vollschreiben, lesen und vergleichen ist ja bei beiden gleich. Memtest bietet halt mehr Pattern. Meiner Erfahrung nach läuft die Windowsversion öfter mal, da halt nicht jede Kiste mit der Linuxversion zurechtkommt und spielte auf die Versionen oben om Thread an (Version x zeigt Fehler, nimm Version y). Der erweiterte Test schreibt prüft den ganzen Ram https://www.wintotal.de/tipp/arbeitsspeicher-mit-boardmitteln-testen/ aber jedem das seine. Schlecht ist der mdsched damit aber nicht. Ich teste meist mit beiden um sicher zu gehen. ;)

@ReactivateMe347 . Wenn die RAM nachweislich ohne Fehler laufen und du auch schon das Board getauscht hast, kanns ja nur mehr deine CPU sein.
 
StEEE schrieb:
Ich hab ja nicht geschrieben das Memtest(86) schlecht wäre, nur das eben Windows sowas schon mitliefert.
Und ich hab geschrieben, dass wir das alle wissen, diesen aber eher nicht empfehlen.
Das ist alter Kram wie Memtest86+.
Sieh dir mal die Beispiele oben an, was Memtest86+ da so ablieferte.
StEEE schrieb:
da halt nicht jede Kiste mit der Linuxversion zurechtkommt
Der aktuelle Memtest86 hat seit Jahren nur UEFI Boot, ja,
dass sollte aber bei jedem System mit DDR4 kein Problem sein von dem Medium zu booten.
Auch UEFI mit CSM sollte kein Problem sein.
Nur alte Systeme mit BIOS können davon nicht booten, von dem Memtest86 Medium.
Aber hier kann man dann getrost auch "Memtest86+", da eh kein DDR4.

Ergänzung ()

StEEE schrieb:
Ich teste meist mit beiden um sicher zu gehen. ;)
Kann der TE ja gerne machen, wenn er zu viel Zeit hat. ;)
 
Zuletzt bearbeitet:
@Novocain: Wenn XMP aktiv ist, ohne dass ich es selbst aktiviert habe (weil es etwa ein Standradeinstellung ist oder die Nutzung eines kompatiblen RAMs die Verwendung auslöst), dann würde ich das "heimlich" nennen. Wenn ich es explizit aktivieren muss, dann ist es nicht heimlich.

@StEEE Wie gesagt: Es tritt mit 2 verschiedenen CPUs auf 3 verschiedenen Motherboards auf. Defekte CPU halte ich mit dem neuen Wissen um DDR4 und Memtest86+ nicht für das wahrscheinliche Problem.

@Nickel das "mit UEFI problemlos" stimmt leider so auch nicht. Auf dem Rechner mit der anderen CPU wollte Memtest86 nicht starten ("boot" in schwarzen Bildschirm über Minuten). Explizit habe ich dazu die (allgemeine, also board-unabhängige) Empfehlung gefunden, ein BIOS-Update durchzuführen (war von 2018, jetzt von 2021), was in diesem Fall wohl tatsächlich geholfen hat. Weiterhin dürfte Secure Boot Probleme machen können nach meinem Verständnis und natürlich Boot-Konfigurationen, die "CSM only" entsprechen.
Nachtrag: vgl. https://www.memtest86.com/tech_freezing-lockups.html

Zur Tool-Debatte:
Ich habe zu Memtest86 nun ein bisschen gelesen. So wie ich das verstehe kann Memtest86 den RAM nicht vollständig testen, da es sich nicht selbst verschiebt. Genauer: Jedes Programm, das ausgeführt wird, liegt ja selbst im RAM. memtest86+ schreibt sich zu gegebener Zeit selbst an eine andere Stelle im RAM, lässt die Ausführung da hin springen und testet den RAM-Bereich, an dem es vorher selbst lag. Memtest86 kann dies offenbar nicht und braucht zudem ziemlich sicher selbst mehr Speicher als Memtest86+ (hat z.B. zusätzlich Hauptmenü und Bootscreen).

Genau das ist auch schon ein wichtiger Grund, wieso ein RAM-Test mit einem vollständigen OS problematisch ist - erst recht unter Windows, wenn das OS schon hunderte MB bis einige GB belegt, die dann eben nicht getestet werden können. Treten Fehler auf, so sind alle diese eingeschränkten Tests aussagekräftig, treten jedoch keine Fehler auf, so ist das eben nicht absolut aussagekräftig. Der Windows-eigene Test läuft ja nicht im laufenden Windows, daher kann ich die RAM-Auslastung dazu nicht einschätzen, vollständig wird aber ziemlich sicher auch der nicht sein.
 
Zuletzt bearbeitet:
ReactivateMe347 schrieb:
das "mit UEFI problemlos" stimmt leider so auch nicht...
In der Regel ist das aber so und nach einem Bios Update ging es ja dann auch bei dir, warum auch immer.
ReactivateMe347 schrieb:
Weiterhin dürfte Secure Boot Probleme machen können
Davon hab ich noch nie was gelesen, ich habe Secure Boot aber schon immer aus bei mir.
Wenn da keine unsignierten Treiber versucht geladen zu werden,
sollte Secure Boot aber keine Probleme machen.
Hinweise hierzu sollte man bei Passmark finden.
 
Nickel schrieb:
Wenn da keine unsignierten Treiber versucht geladen zu werden,
sollte Secure Boot aber keine Probleme machen.
Hinweise hierzu sollte man bei Passmark finden.
Es überrascht mich, aber offenbar ist auch Free V9 entsprechend signiert, nur die alten Versionen nicht, siehe https://www.memtest86.com/compare.html

Also ja, das dürfte egal sein.
 
Zuletzt bearbeitet:
Naja, es basiert ja beides auf demselben Code und die wollen halt zeigen, wie viele tolle neue Sachen sie auch im Vergleich zu 86+ haben
 
Nicht allzu viel glauben in Wikipedia stecken.
Zumal Memtest86 3.0 jetzt ja uralt sein muss, kenne nur die Version 4 von 2014 als alte von Passmark. Ja, und jetzt ist's Version 9.3 und wir sind 2021.
 
Update1-3:
Auf meinem System (Mortar-Board und 2600) habe ich die G.Skill nun mit Memtest86 getestet.

Mit beiden Modulen in Slot 1 und 3 meldete Memtest86 Fehler, beide Module einzeln (in Slot1) laufen jedoch alle 4 Durchgänge ohne Fehler. Ich testete dann jedes Modul einzeln in Slot 3, um sicher zu gehen, dass es nicht an Slot 3 liegt.

Riegel A hatte nun tatsächlich 2 Fehler in Slot 3 (Selbe Adresse in 2 der 4 Durchläufe), Riegel B jedoch wieder keine Fehler.

Also wieder kein klares Fehlerbild - was nun?
 
Vom CPU Sockel aus gezählt Bank 2 und Bank 4 nutzen - wie es im Handbuch auch steht
 
Und bei nur einem Modul, wie empfohlen Slot "DimmA2" nehmen.
Ergänzung ()

Nimm den empfohlen Slot wenn möglich, wenn du die Riegel einzeln testen möchtest.
Ergänzung ()

ReactivateMe347 schrieb:
Riegel A hatte nun tatsächlich 2 Fehler in Slot 3 (Selbe Adresse in 2 der 4 Durchläufe), Riegel B jedoch wieder keine Fehler.
Das reicht doch wohl auch und du musst eh beide einsenden für eine RMA.
 
Zuletzt bearbeitet:
Nickel schrieb:
Das reicht doch wohl auch und du musst eh beide einsenden für eine RMA.
Wieso reicht das, ich kann es weder klar auf den Sockel noch auf den Riegel zurückführen?!

Novocain schrieb:
Vom CPU Sockel aus gezählt Bank 2 und Bank 4 nutzen - wie es im Handbuch auch steht

Ok, Bezeichnung im Handbuch anders, meinetwegen.

Slot 1 ist DIMMB2, Slot 3 ist DIMMA2. (Wer auch immer darauf kommt, die Slots, die man zuerst bestücken soll, 2 zu nennen)
Also haben beide Module einzeln in DIMMB2 fehlerfrei funktioniert, im "empfohlenen" DIMMA2 jedoch einer nicht. Im Test mit 2 Modulen war die Konfiguration wie empfohlen.

Wie soll ich Slot 1 (DIMMB2) einzeln testen, ohne gegen die "Empfehlung" zu verstoßen, zumal das Mapping von Riegeln zu Adressraum (bzw. umgekehrt) nicht trivial zu ermitteln ist (laut Memtest86 Dokumentation)
 
Das liegt am RAM, nicht an den Slots, ausser du hast diese wirklich beschädigt.
Und dann werden die RAMs eher gar nicht mehr erkannt und es gibt gleich Probleme, schon ohne Memtest86.
Am IMC liegt das mit an Sicherheit grenzender Wahrscheinlichkeit auch nicht, wenn Memtest86 Fehler bringt.
Ist der IMC defekt, ist die CPU defekt dann geht eher gar nichts mehr.
Aber ok, du wirst es schon herausfinden.
Gute Nacht.
 
ReactivateMe347 schrieb:
Ok, Bezeichnung im Handbuch anders, meinetwegen.
Klar ist die Bezeichnung anderes im Handbuch, da wird auch nicht von 1-4 gezählt, dies dient ja von meiner Seite her nur der Vereinfachung. Aber Pups egal wie die heißen die zu nutzenden Slots sind die genannten.
 
Novocain schrieb:
Klar ist die Bezeichnung anderes im Handbuch, da wird auch nicht von 1-4 gezählt, dies dient ja von meiner Seite her nur der Vereinfachung. Aber Pups egal wie die heißen die zu nutzenden Slots sind die genannten.
Was ich ja im Endeffekt auch getan habe, wie ich schrieb.
 
Also hier sieht man wie der RAM gesteckt werden muss:

1639522236406.png


ReactivateMe347 schrieb:
(Wer auch immer darauf kommt, die Slots, die man zuerst bestücken soll, 2 zu nennen)
Das hat was mit der Topologie der Boards zu tun.
Hier ist ein Video das die Unterschiede gut erklärt.


Willst du mehr über das B450M Mortar wissen, schau dir dieses Video an.
Das Video war damals ein entscheidender Aspekt in der Entscheidung mir dieses Board zuzulegen. OK nicht das Titanium sondern das normale aber außer der Farbe sind die gleich.

 
  • Gefällt mir
Reaktionen: ReactivateMe347
@Müritzer
Danke für die Referenz. Auch wenn die Erklärung am Ende "komplexe elektrotechnische Gründe" heißt in dem Video (dazu, warum im Daisy Chain der entferntere Slot typischer Weise favorisiert wird) war es definitiv interessant als Hintergrund.
Ich verstehe nicht, warum du das erste Bild zeigst - habe ich einen Verständnisfehler? Wie oben geschrieben meine ich, dass ich die jeweils "empfohlenen" Konfigurationen auch getestet habe, oder nicht?
 
  • Gefällt mir
Reaktionen: Müritzer
Zurück
Oben