memtest86plus
v7.20
Memtest86+ est un testeur de mémoire autonome, open source et gratuit pour les ordinateurs à architecture x86 et x86-64. Il fournit une vérification de la mémoire beaucoup plus approfondie que celle fournie par les tests de mémoire du BIOS.
Il est également capable d'accéder à presque toute la mémoire de l'ordinateur, sans être limité par la mémoire utilisée par le système d'exploitation et sans dépendre d'un logiciel sous-jacent comme les bibliothèques UEFI.
Memtest86+ peut être chargé et exécuté soit directement par un BIOS PC (hérité ou UEFI), soit via un chargeur de démarrage intermédiaire prenant en charge le protocole de démarrage de transfert Linux 16 bits, 32 bits, 64 bits ou EFI. Il devrait fonctionner sur n'importe quelle classe Pentium ou processeur ultérieur 32 bits ou 64 bits.
Les versions binaires (versions de développement stables et nocturnes) sont disponibles sur memtest.org.
Memtest86+ v6.00 était basé sur PCMemTest, qui était un fork et une réécriture du précédent Memtest86+ v5, qui à son tour était un fork de MemTest-86. Le but de la réécriture de PCMemTest était de :
Lors du processus de création de PCMemTest, un certain nombre de fonctionnalités de Memtest86+ v5 qui n'étaient pas strictement requises pour tester la mémoire système ont été supprimées. En particulier, aucune tentative n'a été faite pour mesurer la vitesse du cache et de la mémoire principale, ni pour identifier et signaler le type de DRAM. Ces fonctionnalités ont été rajoutées et étendues dans Memtest86+ v6.0 pour créer une version unifiée et complète.
Memtest86+ est publié selon les termes de la licence publique générale GNU version 2 (GPLv2). Hormis les dispositions de la GPL, il n'y a aucune restriction d'utilisation, privée ou commerciale. Voir le fichier LICENSE pour plus de détails.
Build n'est testé que sur un système Linux, mais devrait être possible sur n'importe quel système utilisant la chaîne d'outils GNU et le format de fichier ELF. Les outils requis sont :
Pour créer une image 32 bits, changez de répertoire en répertoire build32 et tapez make . Le résultat est un fichier image binaire memtest.bin qui peut être démarré directement par un BIOS existant (en mode disquette) ou par un chargeur de démarrage intermédiaire utilisant le protocole de démarrage Linux 16 bits et un fichier image binaire memtest.efi qui peut être démarré directement. par un BIOS UEFI 32 bits. L'une ou l'autre image peut être démarrée par un chargeur de démarrage intermédiaire à l'aide des protocoles de démarrage de transfert Linux 32 bits ou EFI 32 bits.
Pour créer une image 64 bits, changez de répertoire en répertoire build64 et tapez make . Le résultat est un fichier image binaire memtest.bin qui peut être démarré directement par un BIOS existant (en mode disquette) ou par un chargeur de démarrage intermédiaire utilisant le protocole de démarrage Linux 16 bits et un fichier image binaire memtest.efi qui peut être démarré directement. par un BIOS UEFI 64 bits. L'une ou l'autre image peut être démarrée par un chargeur de démarrage intermédiaire à l'aide des protocoles de démarrage de transfert EFI Linux 32 bits, 64 bits ou 64 bits.
Dans les deux cas, pour créer une image ISO pouvant être utilisée pour créer un CD, un DVD ou une clé USB amorçable, tapez make iso . Le résultat est un fichier image ISO memtest.iso . Celui-ci peut ensuite être écrit directement sur un CD ou un DVD vierge, ou sur une clé USB, qui peut ensuite être démarrée directement par un BIOS PC existant ou UEFI.
Notez que lors de l'écriture sur une clé USB, l'image ISO doit être écrite directement (« vidée ») sur le périphérique brut, soit à l'aide de la commande dd , soit à l'aide d'un utilitaire offrant la même fonctionnalité.
Lors de l'utilisation d'un chargeur de démarrage intermédiaire, le fichier memtest.bin ou le fichier memtest.efi doit être stocké dans une partition de disque à laquelle le chargeur de démarrage peut accéder, et la configuration du chargeur de démarrage doit être mise à jour pour démarrer à partir de ce fichier comme s'il s'agissait d'un noyau Linux avec pas de disque RAM initial. Plusieurs options de ligne de commande de démarrage sont reconnues, comme décrit ci-dessous. Si vous utilisez le protocole de démarrage 16 bits, Memtest86+ utilisera l'affichage en mode texte (640x400). Si vous utilisez les protocoles de démarrage 32 bits ou 64 bits, Memtest86+ utilisera l'affichage en mode texte ou en mode graphique, comme spécifié dans la structure boot_params qui lui est transmise par le chargeur de démarrage. En mode graphique, le framebuffer fourni doit être d'au moins 640x400 pixels ; s'il est plus grand, l'affichage sera centré. Si le système a été démarré en mode UEFI, le mode graphique doit être utilisé.
À des fins de test, il existe également une option permettant de créer une image ISO qui utilise GRUB comme chargeur de démarrage intermédiaire. Consultez le Makefile dans le répertoire build32 ou build64 pour plus de détails. L'image ISO est à la fois héritée et amorçable UEFI, vous avez donc besoin de modules GRUB pour le démarrage hérité et EFI installés sur votre système de build (par exemple sur Debian, les modules GRUB requis se trouvent dans les packages grub-pc-bin , grub-efi-ia32-bin et grub-efi-amd64-bin ). Vous devrez peut-être ajuster certains chemins et noms de fichiers dans le Makefile pour qu'ils correspondent à la dénomination de votre système.
Les fichiers de configuration GRUB contenus dans le répertoire grub sont là pour être utilisés sur l'ISO de test, mais servent également d'exemple sur la façon de démarrer Memtest86+ à partir de GRUB.
Un chargeur de démarrage intermédiaire peut transmettre une ligne de commande de démarrage à Memtest86+. La ligne de commande peut contenir une ou plusieurs options, séparées par des espaces. Chaque option se compose d'un nom d'option, éventuellement suivi d'un signe = et d'un ou plusieurs paramètres, séparés par des virgules. Les options suivantes sont reconnues :
0x (ex : 0xFEDC9000) Memtest86+ prend en charge à la fois l'interface clavier existante (en utilisant les ports d'E/S 0x60 et 0x64) et les claviers USB (en utilisant ses propres pilotes de périphérique USB). L'un ou l'autre ou les deux peuvent être sélectionnés via la ligne de commande de démarrage. S'il n'est pas spécifié sur la ligne de commande, la valeur par défaut est d'utiliser les deux si le système a été démarré en mode UEFI, sinon d'utiliser uniquement l'interface héritée.
Les BIOS plus anciens prennent généralement en charge l'émulation de clavier USB hérité, ce qui fait que les claviers USB agissent comme des claviers hérités connectés aux ports 0x60 et 0x64. Cela peut souvent être activé ou désactivé dans les menus de configuration du BIOS. Si les pilotes de périphériques USB de Memtest86+ sont activés, ils remplaceront cela et accéderont directement à tous les claviers USB. L'inconvénient est que les contrôleurs USB et les pilotes de périphériques nécessitent qu'une certaine quantité de mémoire soit réservée à leur usage privé, ce qui signifie que la mémoire ne peut alors pas être couverte par les tests de mémoire. Ainsi, pour maximiser la couverture des tests, si elle est prise en charge, activez l'émulation du clavier USB hérité et, si vous démarrez en mode UEFI, ajoutez keyboard=legacy sur la ligne de commande de démarrage.
REMARQUE : certains BIOS UEFI ne prennent en charge l'émulation de clavier USB hérité que lorsque vous activez le module système de compatibilité (CSM) dans la configuration du BIOS. D'autres ne le prennent en charge que lors du démarrage en mode hérité.
De nombreux périphériques USB ne sont pas entièrement conformes aux spécifications USB. Si la sonde du clavier USB se bloque ou ne parvient pas à détecter votre clavier, essayez les différentes solutions de contournement fournies par l'option de démarrage "usbinit".
REMARQUE : Le branchement à chaud n'est actuellement pas pris en charge par les pilotes USB Memtest86+. Lorsque vous les utilisez, votre clavier USB doit être branché avant d'exécuter Memtest86+ et doit rester branché tout au long du test.
Certaines machines 2-en-1 utilisent un panneau LCD qui est nativement un écran en mode portrait mais qui est monté sur le côté lorsqu'il est fixé au clavier. Lors de l'utilisation de l'écran en mode graphique, Memtest86+ peut faire pivoter son affichage pour correspondre. Ajoutez l'option "screen.rhs-up" ou "screen.lhs-up" sur la ligne de commande de démarrage, en fonction de l'orientation du panneau LCD. Lors de l'utilisation de l'écran en mode texte, il est prévu que le BIOS s'en occupe automatiquement.
Lorsqu'il est démarré en mode hérité, Memtest86+ utilisera la résolution d'écran définie par le BIOS ou par le chargeur de démarrage intermédiaire. Lorsqu'il est démarré en mode UEFI, Memtest86+ sélectionnera normalement la plus petite résolution d'écran disponible qui englobe son affichage de 640 x 400 pixels. Certains BIOS renvoient des informations incorrectes sur les modes d'affichage disponibles, vous pouvez donc ignorer cela en ajoutant l'option "screen.mode=" sur la ligne de commande de démarrage.
Notez que lorsque vous utilisez la rotation de l'affichage, la résolution d'écran spécifiée concerne l'affichage non pivoté.
Une fois démarré, Memtest86+ initialisera son affichage, puis fera une pause de quelques secondes pour permettre à l'utilisateur de configurer son fonctionnement. Si aucune touche n'est enfoncée, tous les tests seront automatiquement exécutés en utilisant un seul cœur de processeur, et continueront indéfiniment jusqu'à ce que l'utilisateur redémarre ou arrête la machine.
Au démarrage et lors de l'exécution des tests, Memtest86+ répond aux touches suivantes :
Notez que les tests sont bloqués lorsque le verrouillage du défilement est activé et que la région de défilement est pleine.
Le menu de configuration permet à l'utilisateur de :
Dans tous les cas, les touches numériques peuvent être utilisées comme alternatives aux touches de fonction (1 = F1, 2 = F2, ... 0 = F10).
Le mode de rapport d'erreurs peut être modifié à tout moment sans perturber la séquence de test en cours. Les statistiques d'erreurs sont collectées quel que soit le mode de rapport d'erreurs actuel (le passage au mode résumé des erreurs affichera donc les statistiques accumulées depuis le démarrage de la séquence de test actuelle). Les modèles BadRAM ne sont accumulés qu’en mode BadRAM. Les régions memmap Linux ne sont accumulées qu’en mode memmap. Les numéros de page incorrects ne sont accumulés qu'en mode page incorrecte.
Toute modification des tests sélectionnés, de la plage d'adresses ou du mode de séquençage du processeur démarrera une nouvelle séquence de tests et réinitialisera les statistiques d'erreur.
Le mode de comptage d'erreurs uniquement affiche simplement le nombre total d'erreurs trouvées depuis le début de la séquence de test en cours.
Le mode récapitulatif des erreurs affiche les informations suivantes :
Le mode d'erreur individuel affiche les informations suivantes pour chaque instance d'erreur :
Le mode modèles BadRAM accumule et affiche les modèles d'erreur à utiliser avec la fonctionnalité Linux BadRAM ou la commande GRUB badram. Les lignes sont imprimées sous la forme badram=F1,M1,F2,M2... Dans chaque paire F,M , le F représente une adresse de défaut et le M est un masque de bits pour cette adresse. Ces modèles indiquent que des erreurs se sont produites dans des adresses égales à F sur tous les bits 1 de M. Un tel modèle peut capturer plus d'erreurs qu'il n'en existe réellement, mais au moins toutes les erreurs sont capturées. Ces modèles ont été conçus pour capturer des modèles réguliers d'erreurs provoquées par la structure matérielle dans une syntaxe concise.
Les modèles BadRAM sont développés progressivement plutôt que calculés à partir d'un aperçu de toutes les erreurs. Le nombre de paires est limité à 20 pour plusieurs raisons pratiques. Par conséquent, la création manuelle de motifs à partir de la sortie en mode d’impression d’adresses peut, dans des cas exceptionnels, donner de meilleurs résultats.
REMARQUE Comme mentionné dans les descriptions des tests individuels, le test d'adresse des marcheurs (test 0) et le test de déplacement de bloc (test 7) ne contribuent pas aux modèles BadRAM car ces tests ne permettent pas de déterminer l'adresse exacte du défaut. .
Le mode Linux memmap accumule et affiche les régions de mémoire défectueuses à utiliser avec l'[option de ligne de commande de démarrage Linux memmap] (https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt). Les lignes sont imprimées sous la forme memmap=S1$A1,S2,A2... Dans chaque paire S,A , le A représente la première adresse de la région et le S est la taille de la région (en octets). Jusqu'à 20 régions de mémoire défectueuses sont enregistrées. Une fois que plus de 20 régions d’emplacements défectueux contigus auront été trouvées, les régions seront fusionnées, ce qui signifie que certaines régions incluront des emplacements non défectueux. Le programme tentera de minimiser le nombre d'emplacements non défectueux inclus.
REMARQUE Comme mentionné dans les descriptions des tests individuels, le test d'adresse de marche (test 0) et le test de déplacement de bloc (test 7) ne contribuent pas aux régions de mémoire défectueuses car ces tests ne permettent pas d'obtenir l'adresse exacte du défaut. déterminé.
Le mode pages incorrectes accumule et affiche les numéros de pages mémoire erronées. Celles-ci peuvent être utilisées avec la commande Windows bcdedit pour ajouter ces pages à la liste de mémoire Windows PFA. Les numéros de page sont soit affichés sous forme d'un seul nombre hexadécimal (par exemple 0x20 ) ou d'une plage de numéros de page hexadécimaux (par exemple 0x20..0x2a ). Jusqu'à 20 plages de pages défectueuses sont enregistrées. Une fois que plus de 20 plages de pages défectueuses contiguës ont été trouvées, les plages seront fusionnées, ce qui signifie que certaines plages incluront des pages non défectueuses. Le programme essaiera de minimiser le nombre de pages non défectueuses incluses.
REMARQUE Comme mentionné dans les descriptions des tests individuels, le test d'adresse de ceux qui marchent (test 0) et le test de déplacement de bloc (test 7) ne contribuent pas aux numéros de page erronés car ces tests ne permettent pas d'obtenir l'adresse exacte du défaut. déterminé.
Veuillez noter que toutes les erreurs signalées par Memtest86+ ne sont pas dues à une mauvaise mémoire. Le test teste implicitement le processeur, les caches et la carte mère. Il est impossible pour le test de déterminer la cause de la défaillance. La plupart des échecs seront dus à un problème de mémoire. Si ce n’est pas le cas, la seule option est de remplacer les pièces jusqu’à ce que la panne soit corrigée.
Une fois qu'une erreur de mémoire a été détectée, déterminer le module défaillant n'est pas une procédure claire. Avec le grand nombre de fournisseurs de cartes mères et les combinaisons possibles d'emplacements de mémoire, il serait difficile, voire impossible, de rassembler des informations complètes sur la façon dont une erreur particulière serait mappée à un module de mémoire défaillant. Cependant, certaines mesures peuvent être prises pour déterminer le module défaillant. Voici quelques techniques que vous souhaiterez peut-être utiliser :
Suppression de modules
Modules rotatifs
Remplacement des modules
Parfois, des erreurs de mémoire apparaissent en raison d'une incompatibilité de composants. Un module de mémoire peut fonctionner correctement dans un système et pas dans un autre. Ce n’est pas rare et c’est une source de confusion. Les composants ne sont pas forcément mauvais mais certaines combinaisons peuvent être à éviter.
Dans la grande majorité des cas, les erreurs signalées par Memtest86+ sont valides. Certains systèmes font que Memtest86+ est confus quant à la taille de la mémoire et essaiera de tester une mémoire inexistante. Cela entraînera le signalement d'un grand nombre d'adresses consécutives comme étant mauvaises et il y aura généralement de nombreux bits en erreur. Si vous avez un nombre relativement faible d'adresses défaillantes et seulement un ou deux bits erronés, vous pouvez être certain que les erreurs sont valides. De plus, les erreurs intermittentes sont toujours valables.
Toutes les erreurs de mémoire valides doivent être corrigées. Il est possible qu'une erreur particulière n'apparaisse jamais en fonctionnement normal. Cependant, fonctionner avec une mémoire marginale est risqué et peut entraîner une perte de données, voire une corruption du disque.
Memtest86+ ne peut pas diagnostiquer de nombreux types de pannes de PC. Par exemple, un processeur défectueux qui provoque le crash de votre système d'exploitation entraînera très probablement le crash de Memtest86+ de la même manière.
Le temps requis pour une réussite complète de Memtest86+ varie considérablement en fonction de la vitesse du processeur, de la vitesse de la mémoire et de la taille de la mémoire. Memtest86+ s'exécute indéfiniment. Le compteur de réussite s'incrémente chaque fois que tous les tests sélectionnés ont été exécutés. Généralement, un seul passage suffit pour détecter toutes les erreurs, sauf les plus obscures. Cependant, pour une confiance totale lorsque des erreurs intermittentes sont suspectées, il est conseillé de procéder à des tests sur une période plus longue.
Il existe de nombreuses bonnes approches pour tester la mémoire. Cependant, de nombreux tests envoient simplement certains modèles en mémoire sans trop réfléchir ni connaître l'architecture de la mémoire ou la meilleure façon de détecter les erreurs. Cela fonctionne bien pour les pannes de mémoire dure, mais ne permet pas de détecter les erreurs intermittentes. Les tests de mémoire basés sur le BIOS sont inutiles pour détecter les erreurs de mémoire intermittentes.
Les puces mémoire sont constituées d’un large éventail de cellules mémoire étroitement regroupées, une pour chaque bit de données. La grande majorité des pannes intermittentes résultent d’une interaction entre ces cellules mémoire. Souvent, l'écriture d'une cellule mémoire peut entraîner l'écriture de l'une des cellules adjacentes avec les mêmes données. Un test de mémoire efficace tente de tester cette condition. Par conséquent, une stratégie idéale pour tester la mémoire serait la suivante :
Il va de soi que cette stratégie nécessite une connaissance exacte de la manière dont les cellules mémoire sont disposées sur la puce. De plus, il existe un nombre infini de configurations de puces possibles pour différents types de puces et fabricants, ce qui rend cette stratégie peu pratique. Cependant, il existe des algorithmes de test qui peuvent se rapprocher de cette stratégie idéale.
Memtest86+ utilise deux algorithmes qui fournissent une approximation raisonnable de la stratégie de test idéale ci-dessus. La première de ces stratégies est appelée inversions mobiles. Les tests d'inversion mobile fonctionnent comme suit :
Cet algorithme est une bonne approximation d'un test de mémoire idéal, mais il présente certaines limites. La plupart des puces haute densité stockent aujourd'hui des données d'une largeur de 4 à 16 bits. Avec des puces de plus d'un bit de large, il est impossible de lire ou d'écrire sélectivement un seul bit. Cela signifie que nous ne pouvons pas garantir que toutes les cellules adjacentes ont été testées pour leur interaction. Dans ce cas, le mieux que nous puissions faire est d'utiliser certains modèles pour garantir que toutes les cellules adjacentes ont au moins été écrites avec toutes les combinaisons possibles de un et zéro.
On peut également constater que la mise en cache, la mise en mémoire tampon et l'exécution dans le désordre interféreront avec l'algorithme d'inversions mobiles et le rendront moins efficace. Il est possible de désactiver la mise en cache, mais la mise en mémoire tampon des nouvelles puces hautes performances ne peut pas être désactivée. Pour remédier à cette limitation, un nouvel algorithme appelé Modulo-20 a été créé. Cet algorithme n'est pas affecté par la mise en cache ou la mise en mémoire tampon. L'algorithme fonctionne comme suit :
Cet algorithme réalise presque le même niveau de tests de contiguïté que les inversions mobiles, mais n'est pas affecté par la mise en cache ou la mise en mémoire tampon. Étant donné que des passes d'écriture séparées (1.1, 1.2) et de lecture (1.4) sont effectuées pour toute la mémoire, nous pouvons être assurés que tous les tampons et le cache ont été vidés entre les passes. La sélection de 20 comme taille de foulée était quelque peu arbitraire. Des progrès plus importants peuvent être plus efficaces, mais leur exécution prendrait plus de temps. Le choix de 20 semble être un compromis raisonnable entre rapidité et rigueur.
Memtest86+ exécute une série de tests numérotés pour vérifier les erreurs. Ces tests consistent en une combinaison d'algorithme de test, de modèle de données et de mise en cache. L'ordre d'exécution de ces tests a été organisé de manière à ce que les erreurs soient détectées le plus rapidement possible. Une description de chaque test suit.
Pour permettre de tester plus de 4 Go de mémoire sur des processeurs 32 bits, la plage d'adresses physiques est divisée en fenêtres de 1 Go qui sont mappées une par une dans une fenêtre de mémoire virtuelle. Chaque fenêtre de 1 Go peut contenir une ou plusieurs régions de mémoire contiguës. Pour la plupart des tests, le test est effectué tour à tour sur chaque région de mémoire. La mise en cache est activée pour tous les tests sauf le premier.
Dans chaque région de mémoire, teste tour à tour tous les bits d'adresse en utilisant un modèle d'adresse ambulant. Les erreurs de ce test ne contribuent pas aux modèles BadRAM, aux régions memmap ou aux régions de page incorrectes.
Dans chaque région de mémoire, tour à tour, chaque adresse est écrite avec sa propre adresse, puis la cohérence de chaque adresse est vérifiée. Ce test est effectué séquentiellement avec chaque CPU disponible, quel que soit le mode de séquençage du CPU sélectionné par l'utilisateur.
Dans toutes les régions de mémoire, chaque adresse est écrite avec sa propre adresse virtuelle plus le numéro de fenêtre (pour les images 32 bits) ou sa propre adresse physique (pour les images 64 bits), puis la cohérence de chaque adresse est vérifiée. Cela détecte toutes les erreurs dans les bits d'adresse d'ordre supérieur qui seraient manquées lors du test de chaque fenêtre tour à tour. Ce test est effectué séquentiellement avec chaque CPU disponible, quel que soit le mode de séquençage du CPU sélectionné par l'utilisateur.
Dans chaque région de mémoire tour à tour, et pour chaque motif tour à tour, utilise l'algorithme d'inversions mobiles avec des motifs composés uniquement de uns et de zéros.
Dans chaque région de mémoire tour à tour, et pour chaque motif tour à tour, utilise l'algorithme d'inversions mobiles avec des motifs de uns ambulants et de zéros ambulants de 8 bits de large.
Dans chaque région mémoire tour à tour, et pour chaque motif tour à tour, on utilise l'algorithme d'inversions mobiles avec des motifs d'un nombre aléatoire et son complément. Le nombre aléatoire est différent à chaque passage de test, donc plusieurs passages augmentent l'efficacité.
Dans chaque région de mémoire tour à tour, et pour chaque modèle tour à tour, utilise l'algorithme d'inversions mobiles avec des modèles de 32 bits de large (sur les versions 32 bits) ou de 64 bits de large (sur les versions 64 bits), des uns et des zéros ambulants. . Contrairement aux tests précédents, le motif subit une rotation de 1 bit à chaque adresse successive.
Ce test met l'accent sur la mémoire en utilisant des instructions de déplacement de bloc (movs) et est basé sur le test burnBX de Robert Redelmeier.
Dans chaque région de mémoire, la mémoire est initialisée avec des modèles de décalage qui sont inversés tous les 8 octets. Ensuite, les blocs de mémoire sont déplacés à l’aide de l’instruction movs. Une fois les déplacements terminés, les modèles de données sont vérifiés. Étant donné que les données sont vérifiées uniquement une fois les déplacements de mémoire terminés, il n'est pas possible de savoir où l'erreur s'est produite. Les adresses indiquées concernent uniquement l'endroit où le mauvais modèle a été trouvé. Par conséquent, les erreurs de ce test ne contribuent pas aux modèles BadRAM, aux régions memmap ou aux régions de page incorrectes.
Dans chaque région de mémoire tour à tour, chaque adresse est écrite avec un nombre aléatoire, puis la cohérence de chaque adresse est vérifiée et écrite avec le complément des données d'origine, puis la cohérence de chaque adresse est à nouveau vérifiée.
Dans chaque région mémoire tour à tour, et pour chaque motif tour à tour, utilise l'algorithme Modulo-20 avec des motifs d'un nombre aléatoire et son complément. Le nombre aléatoire est différent à chaque passage de test, donc plusieurs passages augmentent l'efficacité.
Dans toutes les régions de mémoire, et pour chaque modèle tour à tour, initialise chaque emplacement mémoire avec un modèle, se met en veille pendant un certain temps, puis vérifie la cohérence de chaque emplacement mémoire. Le test est effectué avec des modèles composés uniquement de zéros et de uns.
Veuillez consulter la liste des problèmes ouverts et des demandes d'amélioration sur GitHub.
N'hésitez pas à soumettre des rapports de bugs !
Les contributions au code sont les bienvenues, que ce soit pour corriger des bugs ou pour apporter des améliorations. Voir le README_DEVEL.md dans le répertoire doc pour quelques directives de base.
Memtest86+ v6.0 était basé sur PCMemTest, développé par Martin Whitaker, lui-même basé sur Memtest86+ v5.01, développé par Samuel Demeulemeester, lui-même basé sur Memtest86, développé par Chris Brady avec les ressources et l'assistance répertoriées ci-dessous :
Les versions initiales des fichiers sources bootsect.S, setup.S, head.S et build.c proviennent du noyau Linux 1.2.1 et ont été fortement modifiées.
Doug Sisk a fourni du code pour prendre en charge une console connectée via un port série. (pas utilisé actuellement)
Le code pour créer des modèles BadRAM a été fourni par Rick van Rein.
Le test de déplacement de bloc est basé sur le test burnBX de Robert Redelmeier.
Le code du tampon d'écran a été fourni par Jani Averbach. (non utilisé par Memtest86+ v6.0)
Eric Biederman a fourni tout le contenu des fonctionnalités de la version 3.0 ainsi que de nombreuses corrections de bugs et un nettoyage important du code.
Améliorations majeures de la détection matérielle et du reporting dans les versions 3.2, 3.3 et 3.4 fournies par Samuel Demeulemeester (à partir de Memtest86+ v1.11, v1.60 et v1.70).
De plus, plusieurs corrections de bugs pour Memtest86+ ont été importées depuis anphsw/memtest86.
