memtest86plus
v7.20
Memtest86+ ist ein kostenloser, eigenständiger Open-Source-Speichertester für Computer mit x86- und x86-64-Architektur. Es bietet eine viel gründlichere Speicherprüfung als BIOS-Speichertests.
Es ist außerdem in der Lage, auf fast den gesamten Speicher des Computers zuzugreifen, ohne durch den vom Betriebssystem verwendeten Speicher eingeschränkt zu werden und nicht von zugrunde liegender Software wie UEFI-Bibliotheken abhängig zu sein.
Memtest86+ kann entweder direkt von einem PC-BIOS (Legacy oder UEFI) oder über einen Zwischen-Bootloader geladen und ausgeführt werden, der das Linux 16-Bit-, 32-Bit-, 64-Bit- oder EFI-Handover-Boot-Protokoll unterstützt. Es sollte auf jeder 32-Bit- oder 64-Bit-CPU der Pentium-Klasse oder höher funktionieren.
Binärversionen (sowohl stabile als auch nächtliche Entwickler-Builds) sind auf memtest.org verfügbar.
Memtest86+ v6.00 basierte auf PCMemTest, einem Fork und Rewrite des früheren Memtest86+ v5, der wiederum ein Fork von MemTest-86 war. Der Zweck der Neufassung von PCMemTest bestand darin:
Bei der Erstellung von PCMemTest wurden einige Funktionen von Memtest86+ v5 entfernt, die zum Testen des Systemspeichers nicht unbedingt erforderlich waren. Insbesondere wurde kein Versuch unternommen, die Cache- und Hauptspeichergeschwindigkeit zu messen oder den DRAM-Typ zu identifizieren und zu melden. Diese Funktionen wurden in Memtest86+ v6.0 wieder hinzugefügt und erweitert, um eine einheitliche, voll funktionsfähige Version zu schaffen.
Memtest86+ wird unter den Bedingungen der GNU General Public License Version 2 (GPLv2) veröffentlicht. Außer den Bestimmungen der GPL gibt es keine Einschränkungen für die private oder kommerzielle Nutzung. Einzelheiten finden Sie in der LICENSE-Datei.
Build wird nur auf einem Linux-System getestet, sollte aber auf jedem System möglich sein, das die GNU-Toolchain und das ELF-Dateiformat verwendet. Die benötigten Werkzeuge sind:
Um ein 32-Bit-Image zu erstellen, wechseln Sie in das Verzeichnis build32 und geben Sie make ein. Das Ergebnis ist eine binäre Image-Datei memtest.bin , die direkt von einem älteren BIOS (im Diskettenmodus) oder von einem Zwischen-Bootloader unter Verwendung des Linux 16-Bit-Boot-Protokolls gebootet werden kann, und eine binäre Image-Datei memtest.efi , die direkt gebootet werden kann durch ein 32-Bit-UEFI-BIOS. Jedes Image kann von einem Zwischen-Bootloader mit den Linux 32-Bit- oder 32-Bit-EFI-Handover-Boot-Protokollen gebootet werden.
Um ein 64-Bit-Image zu erstellen, wechseln Sie in das Verzeichnis build64 und geben Sie make ein. Das Ergebnis ist eine binäre Image-Datei memtest.bin , die direkt von einem älteren BIOS (im Diskettenmodus) oder von einem Zwischen-Bootloader unter Verwendung des Linux 16-Bit-Boot-Protokolls gebootet werden kann, und eine binäre Image-Datei memtest.efi , die direkt gebootet werden kann durch ein 64-Bit-UEFI-BIOS. Jedes Image kann von einem Zwischen-Bootloader mit den Linux 32-Bit-, 64-Bit- oder 64-Bit-EFI-Handover-Boot-Protokollen gebootet werden.
Um in beiden Fällen ein ISO-Image zu erstellen, das zum Erstellen einer bootfähigen CD, DVD oder eines USB-Flash-Laufwerks verwendet werden kann, geben Sie make iso ein. Das Ergebnis ist eine ISO-Image-Datei memtest.iso . Dies kann dann direkt auf eine leere CD oder DVD oder auf ein USB-Flash-Laufwerk geschrieben werden, das dann direkt von einem Legacy- oder UEFI-PC-BIOS gebootet werden kann.
Beachten Sie, dass beim Schreiben auf ein USB-Flash-Laufwerk das ISO-Image direkt auf das Rohgerät geschrieben („gedumpt“) werden muss, entweder mit dem Befehl dd oder mit einem Dienstprogramm, das die gleiche Funktionalität bietet.
Bei Verwendung eines Zwischen-Bootloaders sollte entweder die Datei memtest.bin oder die Datei memtest.efi in einer Festplattenpartition gespeichert werden, auf die der Bootloader zugreifen kann, und die Bootloader-Konfiguration sollte aktualisiert werden, um von dieser Datei zu booten, als wäre es ein Linux-Kernel mit keine anfängliche RAM-Disk. Es werden mehrere Boot-Befehlszeilenoptionen erkannt, wie unten beschrieben. Bei Verwendung des 16-Bit-Boot-Protokolls verwendet Memtest86+ die Anzeige im Textmodus (640 x 400). Wenn Sie die 32-Bit- oder 64-Bit-Boot-Protokolle verwenden, verwendet Memtest86+ die Anzeige entweder im Textmodus oder im Grafikmodus, wie in der boot_params Struktur angegeben, die ihm vom Bootloader übergeben wird. Im Grafikmodus muss der bereitgestellte Framebuffer mindestens 640 x 400 Pixel groß sein. Wenn es größer ist, wird die Anzeige zentriert. Wenn das System im UEFI-Modus gebootet wurde, muss der Grafikmodus verwendet werden.
Zu Testzwecken besteht auch die Möglichkeit, ein ISO-Image zu erstellen, das GRUB als Zwischen-Bootloader verwendet. Weitere Informationen finden Sie im Makefile im Verzeichnis build32 oder build64 . Das ISO-Image ist sowohl Legacy- als auch UEFI-bootbar, daher müssen Sie GRUB-Module für Legacy- und EFI-Boot auf Ihrem Build-System installiert haben (z. B. unter Debian befinden sich die erforderlichen GRUB-Module in den Paketen grub-pc-bin , grub-efi-ia32-bin und grub-efi-amd64-bin ). Möglicherweise müssen Sie einige Pfad- und Dateinamen im Makefile anpassen, damit sie mit der Benennung auf Ihrem System übereinstimmen.
Die im grub -Verzeichnis enthaltenen GRUB-Konfigurationsdateien dienen zur Verwendung auf der Test-ISO, dienen aber auch als Beispiel dafür, wie Memtest86+ von GRUB aus gestartet wird.
Ein zwischengeschalteter Bootloader kann eine Boot-Befehlszeile an Memtest86+ übergeben. Die Befehlszeile kann eine oder mehrere durch Leerzeichen getrennte Optionen enthalten. Jede Option besteht aus einem Optionsnamen, optional gefolgt von einem = -Zeichen und einem oder mehreren Parametern, getrennt durch Kommas. Folgende Möglichkeiten werden anerkannt:
0x Präfix (z. B.: 0xFEDC9000) Memtest86+ unterstützt sowohl die ältere Tastaturschnittstelle (unter Verwendung der I/O-Ports 0x60 und 0x64) als auch USB-Tastaturen (unter Verwendung seiner eigenen USB-Gerätetreiber). Eines oder das andere oder beide können über die Boot-Befehlszeile ausgewählt werden. Wenn nicht in der Befehlszeile angegeben, werden standardmäßig beide verwendet, wenn das System im UEFI-Modus gestartet wurde, andernfalls wird nur die Legacy-Schnittstelle verwendet.
Ältere BIOS unterstützen normalerweise die USB-Legacy-Tastaturemulation, wodurch sich USB-Tastaturen wie Legacy-Tastaturen verhalten, die an die Ports 0x60 und 0x64 angeschlossen sind. Dies kann häufig in den BIOS-Setup-Menüs aktiviert oder deaktiviert werden. Wenn die USB-Gerätetreiber von Memtest86+ aktiviert sind, überschreiben sie dies und greifen direkt auf alle USB-Tastaturen zu. Der Nachteil dabei ist, dass die USB-Controller und Gerätetreiber einen Teil des Speichers für den privaten Gebrauch reservieren müssen, was bedeutet, dass der Speicher dann nicht von den Speichertests abgedeckt werden kann. Um die Testabdeckung zu maximieren, aktivieren Sie, sofern unterstützt, die USB-Legacy-Tastaturemulation und fügen Sie beim Booten im UEFI-Modus keyboard=legacy in der Boot-Befehlszeile hinzu.
HINWEIS : Einige UEFI-BIOS unterstützen die USB-Legacy-Tastaturemulation nur, wenn Sie das Compatibility System Module (CSM) im BIOS-Setup aktivieren. Andere unterstützen es nur, wenn tatsächlich im Legacy-Modus gebootet wird.
Viele USB-Geräte entsprechen nicht vollständig der USB-Spezifikation. Wenn der USB-Tastaturtest hängen bleibt oder Ihre Tastatur nicht erkennt, probieren Sie die verschiedenen Problemumgehungen aus, die die Boot-Option „usbinit“ bietet.
HINWEIS : Hot-Plugging wird derzeit von den Memtest86+ USB-Treibern nicht unterstützt. Wenn Sie diese verwenden, sollte Ihre USB-Tastatur angeschlossen sein, bevor Sie Memtest86+ ausführen, und während des gesamten Tests angeschlossen bleiben.
Einige 2-in-1-Geräte verwenden ein LCD-Panel, bei dem es sich ursprünglich um ein Display im Hochformat handelt, das jedoch an der Seite montiert wird, wenn es an der Tastatur angebracht wird. Wenn Sie die Anzeige im Grafikmodus verwenden, kann Memtest86+ die Anzeige entsprechend drehen. Fügen Sie je nach Ausrichtung des LCD-Panels entweder die Option „screen.rhs-up“ oder die Option „screen.lhs-up“ in der Boot-Befehlszeile hinzu. Bei Verwendung des Displays im Textmodus wird davon ausgegangen, dass das BIOS dies automatisch erledigt.
Beim Booten im Legacy-Modus verwendet Memtest86+ die Bildschirmauflösung, die vom BIOS oder vom Zwischen-Bootloader festgelegt wurde. Beim Booten im UEFI-Modus wählt Memtest86+ normalerweise die kleinste verfügbare Bildschirmauflösung, die das 640 x 400 Pixel große Display umfasst. Einige BIOS geben falsche Informationen über die verfügbaren Anzeigemodi zurück. Sie können dies also überschreiben, indem Sie die Option „screen.mode=" in der Boot-Befehlszeile hinzufügen.
Beachten Sie, dass bei Verwendung der Anzeigedrehung die angegebene Bildschirmauflösung für die nicht gedrehte Anzeige gilt.
Nach dem Booten initialisiert Memtest86+ seine Anzeige und hält dann einige Sekunden inne, damit der Benutzer seinen Betrieb konfigurieren kann. Wenn keine Taste gedrückt wird, werden alle Tests automatisch mit einem einzigen CPU-Kern ausgeführt und auf unbestimmte Zeit fortgesetzt, bis der Benutzer den Computer neu startet oder anhält.
Beim Start und beim Ausführen von Tests reagiert Memtest86+ auf die folgenden Tasten:
Beachten Sie, dass der Test angehalten wird, wenn die Bildlaufsperre aktiviert ist und der Bildlaufbereich voll ist.
Das Konfigurationsmenü ermöglicht dem Benutzer:
In allen Fällen können die Zifferntasten alternativ zu den Funktionstasten verwendet werden (1 = F1, 2 = F2, ... 0 = F10).
Der Fehlermeldemodus kann jederzeit geändert werden, ohne den aktuellen Testablauf zu stören. Fehlerstatistiken werden unabhängig vom aktuellen Fehlerberichtsmodus erfasst (wenn Sie also in den Fehlerzusammenfassungsmodus wechseln, werden die akkumulierten Statistiken seit Beginn der aktuellen Testsequenz angezeigt). BadRAM-Muster werden nur im BadRAM-Modus akkumuliert. Linux-Memmap-Regionen werden nur im Memmap-Modus akkumuliert. Fehlerhafte Seitenzahlen werden nur im Fehlerseitenmodus akkumuliert.
Jede Änderung der ausgewählten Tests, des Adressbereichs oder des CPU-Sequenzierungsmodus startet eine neue Testsequenz und setzt die Fehlerstatistik zurück.
Im Modus „Nur Fehler zählen“ wird lediglich die Gesamtzahl der Fehler angezeigt, die seit Beginn der aktuellen Testsequenz gefunden wurden.
Im Fehlerzusammenfassungsmodus werden die folgenden Informationen angezeigt:
Der Einzelfehlermodus zeigt für jede Fehlerinstanz folgende Informationen an:
Der BadRAM-Mustermodus sammelt Fehlermuster und zeigt sie zur Verwendung mit der Linux-BadRAM-Funktion oder dem GRUB-Badram-Befehl an. Zeilen werden in der Form badram=F1,M1,F2,M2... gedruckt. In jedem F,M Paar stellt F eine Fehleradresse dar und M ist eine Bitmaske für diese Adresse. Diese Muster geben an, dass Fehler an Adressen aufgetreten sind, die auf allen 1 Bits in M gleich F sind. Ein solches Muster kann mehr Fehler erfassen, als tatsächlich vorhanden sind, aber zumindest werden alle Fehler erfasst. Diese Muster wurden entwickelt, um regelmäßige Fehlermuster, die durch die Hardwarestruktur verursacht werden, in einer knappen Syntax zu erfassen.
Die BadRAM-Muster werden inkrementell vergrößert und nicht aus einer Übersicht aller Fehler berechnet. Aus praktischen Gründen ist die Anzahl der Paare auf 20 beschränkt. Daher kann es in Ausnahmefällen zu besseren Ergebnissen führen, wenn Muster aus der Ausgabe im Adressdruckmodus handgefertigt werden.
HINWEIS Wie in den einzelnen Testbeschreibungen erwähnt, tragen der Walking-Ones-Adresstest (Test 0) und der Block-Move-Test (Test 7) nicht zu den BadRAM-Mustern bei, da diese Tests es nicht ermöglichen, die genaue Adresse des Fehlers zu bestimmen .
Der Linux-Memmap-Modus sammelt und zeigt fehlerhafte Speicherbereiche zur Verwendung mit der [Linux-Memmap-Boot-Befehlszeilenoption] (https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt) an. Zeilen werden in der Form memmap=S1$A1,S2,A2... gedruckt. In jedem S,A Paar stellt A die erste Adresse in der Region dar und S ist die Größe der Region (in Bytes). Es werden bis zu 20 fehlerhafte Speicherbereiche erfasst. Sobald mehr als 20 Regionen mit zusammenhängenden fehlerhaften Standorten gefunden wurden, werden die Regionen zusammengeführt, was bedeutet, dass einige Regionen nicht fehlerhafte Standorte enthalten. Das Programm versucht, die Anzahl der enthaltenen nicht fehlerhaften Standorte zu minimieren.
HINWEIS Wie in den einzelnen Testbeschreibungen erwähnt, tragen der Walking-Ones-Adresstest (Test 0) und der Block-Move-Test (Test 7) nicht zu den fehlerhaften Speicherbereichen bei, da diese Tests es nicht ermöglichen, die genaue Adresse des Fehlers zu ermitteln bestimmt.
Der Modus „Schlechtseiten“ häuft sich an und zeigt fehlerhafte Speicherseitennummern an. Diese können mit dem Windows-Befehl bcdedit verwendet werden, um diese Seiten zur Windows-PFA-Speicherliste hinzuzufügen. Die Seitenzahlen werden entweder als einzelne Hexadezimalzahl (z. B. 0x20 ) oder als Bereich hexadezimaler Seitenzahlen (z. B. 0x20..0x2a ) angezeigt. Es werden bis zu 20 Bereiche fehlerhafter Seiten erfasst. Sobald mehr als 20 Bereiche zusammenhängender fehlerhafter Seiten gefunden wurden, werden die Bereiche zusammengeführt, was bedeutet, dass einige Bereiche nicht fehlerhafte Seiten enthalten. Das Programm wird versuchen, die Anzahl der enthaltenen nicht fehlerhaften Seiten zu minimieren.
HINWEIS Wie in den einzelnen Testbeschreibungen erwähnt, tragen der Walking-Ones-Adresstest (Test 0) und der Block-Move-Test (Test 7) nicht zu den fehlerhaften Seitenzahlen bei, da diese Tests es nicht ermöglichen, die genaue Adresse des Fehlers zu ermitteln bestimmt.
Bitte beachten Sie, dass nicht alle von Memtest86+ gemeldeten Fehler auf fehlerhaften Speicher zurückzuführen sind. Der Test testet implizit die CPU, Caches und das Motherboard. Der Test kann nicht feststellen, was die Ursache des Fehlers ist. Die meisten Fehler sind auf ein Problem mit dem Speicher zurückzuführen. Ist dies nicht der Fall, besteht die einzige Möglichkeit darin, Teile auszutauschen, bis der Fehler behoben ist.
Sobald ein Speicherfehler erkannt wurde, ist die Bestimmung des fehlerhaften Moduls kein eindeutiges Verfahren. Angesichts der großen Anzahl an Motherboard-Anbietern und möglichen Kombinationen von Speichersteckplätzen wäre es schwierig, wenn nicht sogar unmöglich, vollständige Informationen darüber zusammenzustellen, wie ein bestimmter Fehler einem fehlerhaften Speichermodul zugeordnet werden könnte. Es können jedoch Schritte unternommen werden, um das fehlerhafte Modul zu ermitteln. Hier sind einige Techniken, die Sie möglicherweise verwenden möchten:
Module entfernen
Rotierende Module
Module austauschen
Manchmal treten Speicherfehler aufgrund von Komponenteninkompatibilität auf. Ein Speichermodul funktioniert möglicherweise in einem System einwandfrei und in einem anderen nicht. Dies ist nicht ungewöhnlich und sorgt für Verwirrung. Die Komponenten sind nicht unbedingt schlecht, bestimmte Kombinationen müssen jedoch möglicherweise vermieden werden.
In den allermeisten Fällen sind die von Memtest86+ gemeldeten Fehler gültig. Es gibt einige Systeme, die dazu führen, dass Memtest86+ hinsichtlich der Größe des Speichers verwirrt ist und versucht, nicht vorhandenen Speicher zu testen. Dies führt dazu, dass eine große Anzahl aufeinanderfolgender Adressen als fehlerhaft gemeldet wird und im Allgemeinen viele Bits fehlerhaft sind. Wenn Sie eine relativ kleine Anzahl fehlerhafter Adressen und nur ein oder zwei fehlerhafte Bits haben, können Sie sicher sein, dass die Fehler gültig sind. Auch sporadische Fehler sind immer gültig.
Alle gültigen Speicherfehler sollten korrigiert werden. Es kann sein, dass ein bestimmter Fehler im Normalbetrieb nie auftritt. Der Betrieb mit begrenztem Speicher ist jedoch riskant und kann zu Datenverlust und sogar zur Beschädigung der Festplatte führen.
Memtest86+ kann viele Arten von PC-Fehlern nicht diagnostizieren. Beispielsweise führt eine fehlerhafte CPU, die zum Absturz Ihres Betriebssystems führt, höchstwahrscheinlich auch dazu, dass Memtest86+ auf die gleiche Weise abstürzt.
Die für einen vollständigen Durchlauf von Memtest86+ erforderliche Zeit variiert stark je nach CPU-Geschwindigkeit, Speichergeschwindigkeit und Speichergröße. Memtest86+ wird auf unbestimmte Zeit ausgeführt. Der Erfolgszähler erhöht sich jedes Mal, wenn alle ausgewählten Tests ausgeführt wurden. Im Allgemeinen reicht ein einziger Durchgang aus, um alle bis auf die dunkelsten Fehler zu erkennen. Um bei Verdacht auf intermittierende Fehler jedoch absolute Sicherheit zu gewährleisten, wird empfohlen, über einen längeren Zeitraum zu testen.
Es gibt viele gute Ansätze, das Gedächtnis zu testen. Viele Tests werfen jedoch einfach einige Muster in den Speicher, ohne viel darüber nachzudenken oder Kenntnisse über die Speicherarchitektur oder darüber zu haben, wie Fehler am besten erkannt werden können. Dies funktioniert gut bei Ausfällen des Festplattenspeichers, hilft aber kaum bei der Suche nach zeitweise auftretenden Fehlern. BIOS-basierte Speichertests sind nutzlos, um zeitweilige Speicherfehler zu finden.
Speicherchips bestehen aus einer großen Anordnung dicht gepackter Speicherzellen, eine für jedes Datenbit. Die überwiegende Mehrheit der zeitweiligen Ausfälle ist auf die Interaktion zwischen diesen Gedächtniszellen zurückzuführen. Das Schreiben einer Speicherzelle kann häufig dazu führen, dass eine der benachbarten Zellen mit denselben Daten beschrieben wird. Ein effektiver Speichertest versucht, diesen Zustand zu testen. Daher wäre eine ideale Strategie zum Testen des Speichers die folgende:
Es sollte klar sein, dass diese Strategie eine genaue Kenntnis darüber erfordert, wie die Speicherzellen auf dem Chip angeordnet sind. Darüber hinaus gibt es eine unendliche Anzahl möglicher Chip-Layouts für verschiedene Chiptypen und Hersteller, was diese Strategie unpraktisch macht. Es gibt jedoch Testalgorithmen, die diese ideale Strategie annähern können.
Memtest86+ verwendet zwei Algorithmen, die eine angemessene Annäherung an die oben genannte ideale Teststrategie bieten. Die erste dieser Strategien wird Moving Inversions genannt. Die Bewegungsinversionstests funktionieren wie folgt:
Dieser Algorithmus stellt eine gute Annäherung an einen idealen Speichertest dar, es gibt jedoch einige Einschränkungen. Die meisten High-Density-Chips speichern heute Daten mit einer Breite von 4 bis 16 Bit. Bei Chips, die mehr als ein Bit breit sind, ist es unmöglich, nur ein Bit selektiv zu lesen oder zu schreiben. Das bedeutet, dass wir nicht garantieren können, dass alle benachbarten Zellen auf Interaktion getestet wurden. In diesem Fall können wir am besten einige Muster verwenden, um sicherzustellen, dass alle angrenzenden Zellen zumindest mit allen möglichen Eins- und Nullkombinationen geschrieben wurden.
Es ist auch ersichtlich, dass Caching, Pufferung und Ausführung außerhalb der Reihenfolge den Algorithmus für bewegliche Inversionen beeinträchtigen und ihn weniger effektiv machen. Es ist möglich, das Caching zu deaktivieren, aber die Speicherpufferung in neuen Hochleistungschips kann nicht deaktiviert werden. Um diese Einschränkung zu beheben, wurde ein neuer Algorithmus namens Modulo-20 entwickelt. Dieser Algorithmus wird durch Caching oder Pufferung nicht beeinflusst. Der Algorithmus funktioniert wie folgt:
Dieser Algorithmus erreicht nahezu das gleiche Maß an Adjazenztests wie bewegliche Inversionen, wird jedoch nicht durch Caching oder Pufferung beeinflusst. Da separate Schreibdurchgänge (1.1, 1.2) und der Lesedurchgang (1.4) für den gesamten Speicher durchgeführt werden, können wir sicher sein, dass alle Puffer und der Cache zwischen den Durchgängen geleert wurden. Die Wahl von 20 als Schrittgröße war etwas willkürlich. Größere Schritte sind möglicherweise effektiver, würden aber länger in der Ausführung dauern. Die Wahl von 20 schien ein vernünftiger Kompromiss zwischen Geschwindigkeit und Gründlichkeit zu sein.
Memtest86+ führt eine Reihe nummerierter Tests durch, um auf Fehler zu prüfen. Diese Tests bestehen aus einer Kombination aus Testalgorithmus, Datenmuster und Caching. Die Ausführungsreihenfolge dieser Tests wurde so gestaltet, dass Fehler möglichst schnell erkannt werden. Es folgt eine Beschreibung jedes Tests.
Um das Testen von mehr als 4 GB Speicher auf 32-Bit-CPUs zu ermöglichen, wird der physische Adressbereich in 1 GB große Fenster aufgeteilt, die einzeln einem virtuellen Speicherfenster zugeordnet werden. Jedes 1-GB-Fenster kann einen oder mehrere zusammenhängende Speicherbereiche enthalten. Bei den meisten Tests wird der Test nacheinander für jeden Speicherbereich durchgeführt. Caching ist für alle Tests außer dem ersten aktiviert.
In jedem Speicherbereich werden nacheinander alle Adressbits mithilfe eines Adressmusters mit wandernden Einsen getestet. Fehler aus diesem Test tragen nicht zu BadRAM-Mustern, Memmap-Regionen oder fehlerhaften Seitenregionen bei.
In jedem Speicherbereich wird nacheinander jede Adresse mit einer eigenen Adresse geschrieben und anschließend jede Adresse auf Konsistenz überprüft. Dieser Test wird nacheinander mit jeder verfügbaren CPU durchgeführt, unabhängig vom vom Benutzer ausgewählten CPU-Sequenzierungsmodus.
Über alle Speicherbereiche hinweg wird jede Adresse mit ihrer eigenen virtuellen Adresse plus der Fensternummer (für 32-Bit-Bilder) oder ihrer eigenen physischen Adresse (für 64-Bit-Bilder) geschrieben und anschließend jede Adresse auf Konsistenz überprüft. Dadurch werden alle Fehler in den höherwertigen Adressbits erfasst, die beim Testen jedes Fensters nacheinander übersehen würden. Dieser Test wird nacheinander mit jeder verfügbaren CPU durchgeführt, unabhängig vom vom Benutzer ausgewählten CPU-Sequenzierungsmodus.
In jedem Speicherbereich wird der Reihe nach und für jedes Muster der Reihe nach der Algorithmus der beweglichen Inversionen mit Mustern aus nur Einsen und nur Nullen verwendet.
In jedem Speicherbereich wird der Reihe nach und für jedes Muster der Reihe nach der Moving-Inversions-Algorithmus mit Mustern aus 8 Bit breiten wandelnden Einsen und wandelnden Nullen verwendet.
In jedem Speicherbereich wird der Reihe nach und für jedes Muster der Reihe nach der Bewegungsinversionsalgorithmus mit Mustern einer Zufallszahl und ihres Komplements verwendet. Die Zufallszahl ist bei jedem Testdurchlauf unterschiedlich, sodass mehrere Durchgänge die Wirksamkeit erhöhen.
In jedem Speicherbereich wird der Reihe nach und für jedes Muster der Reihe nach der Moving-Inversions-Algorithmus mit Mustern von 32 Bit breiten (bei 32-Bit-Builds) oder 64 Bit breiten (bei 64-Bit-Builds) wandelnden Einsen und wandelnden Nullen verwendet . Im Gegensatz zu früheren Tests wird das Muster bei jeder nachfolgenden Adresse um 1 Bit rotiert.
Dieser Test belastet den Speicher mithilfe von Blockverschiebungsanweisungen (movs) und basiert auf dem burnBX-Test von Robert Redelmeier.
In jedem Speicherbereich wird der Speicher der Reihe nach mit Schiebemustern initialisiert, die alle 8 Bytes invertiert werden. Anschließend werden Speicherblöcke mithilfe der movs-Anweisung verschoben. Nachdem die Bewegungen abgeschlossen sind, werden die Datenmuster überprüft. Da die Daten erst nach Abschluss der Speicherverschiebungen überprüft werden, ist es nicht möglich zu wissen, wo der Fehler aufgetreten ist. Die gemeldeten Adressen beziehen sich nur auf die Adressen, an denen das fehlerhafte Muster gefunden wurde. Folglich tragen Fehler aus diesem Test nicht zu BadRAM-Mustern, Memmap-Regionen oder fehlerhaften Seitenregionen bei.
In jedem Speicherbereich wird nacheinander jede Adresse mit einer Zufallszahl geschrieben, dann wird jede Adresse auf Konsistenz überprüft und mit dem Komplement der Originaldaten geschrieben, dann wird jede Adresse erneut auf Konsistenz überprüft.
In jedem Speicherbereich wird der Reihe nach und für jedes Muster der Reihe nach der Modulo-20-Algorithmus mit Mustern einer Zufallszahl und ihres Komplements verwendet. Die Zufallszahl ist bei jedem Testdurchlauf unterschiedlich, sodass mehrere Durchgänge die Wirksamkeit erhöhen.
Über alle Speicherbereiche hinweg und für jedes Muster wird nacheinander jeder Speicherort mit einem Muster initialisiert, für einen bestimmten Zeitraum in den Ruhezustand versetzt und dann jeder Speicherort auf Konsistenz überprüft. Der Test wird mit Mustern aus nur Nullen und nur Einsen durchgeführt.
Bitte sehen Sie sich die Liste der offenen Probleme und Verbesserungswünsche auf GitHub an.
Fühlen Sie sich frei, Fehlerberichte einzureichen!
Codebeiträge sind willkommen, entweder um Fehler zu beheben oder Verbesserungen vorzunehmen. Einige grundlegende Richtlinien finden Sie in der Datei README_DEVEL.md im Dokumentverzeichnis.
Memtest86+ v6.0 basierte auf PCMemTest, entwickelt von Martin Whitaker, das auf Memtest86+ v5.01 basierte, entwickelt von Samuel Demeulemeester, das wiederum auf Memtest86 basierte, entwickelt von Chris Brady mit den unten aufgeführten Ressourcen und Unterstützung:
Die ursprünglichen Versionen der Quelldateien bootsect.S, setup.S, head.S und build.c stammen aus dem Linux 1.2.1-Kernel und wurden stark verändert.
Doug Sisk stellte Code zur Unterstützung einer Konsole bereit, die über einen seriellen Port angeschlossen ist. (derzeit nicht verwendet)
Der Code zum Erstellen von BadRAM-Mustern wurde von Rick van Rein bereitgestellt.
Der Block-Move-Test basiert auf dem burnBX-Test von Robert Redelmeier.
Der Bildschirmpuffercode wurde von Jani Averbach bereitgestellt. (wird nicht von Memtest86+ v6.0 verwendet)
Eric Biederman stellte den gesamten Funktionsinhalt für Version 3.0 sowie viele Bugfixes und umfangreiche Codebereinigungen zur Verfügung.
Wesentliche Verbesserungen bei der Hardwareerkennung und -berichterstattung in den Versionen 3.2, 3.3 und 3.4, bereitgestellt von Samuel Demeulemeester (von Memtest86+ v1.11, v1.60 und v1.70).
Darüber hinaus wurden mehrere Fehlerkorrekturen für Memtest86+ von anphsw/memtest86 importiert.
