memtest86plus
v7.20
Memtest86+ es un probador de memoria independiente, gratuito y de código abierto para computadoras con arquitectura x86 y x86-64. Proporciona una comprobación de la memoria mucho más exhaustiva que la que proporcionan las pruebas de memoria del BIOS.
También puede acceder a casi toda la memoria de la computadora, sin estar restringido por la memoria utilizada por el sistema operativo y sin depender de ningún software subyacente como las bibliotecas UEFI.
Memtest86+ se puede cargar y ejecutar directamente mediante el BIOS de una PC (heredado o UEFI) o mediante un cargador de arranque intermedio que admita el protocolo de arranque de transferencia EFI o de 16 bits, 32 bits o 64 bits de Linux. Debería funcionar en cualquier CPU de clase Pentium o posterior de 32 o 64 bits.
Las versiones binarias (tanto las versiones estables como las nocturnas para desarrolladores) están disponibles en memtest.org.
Memtest86+ v6.00 se basó en PCMemTest, que era una bifurcación y reescritura del anterior Memtest86+ v5, que a su vez era una bifurcación de MemTest-86. El propósito de la reescritura de PCMemTest fue:
En el proceso de creación de PCMemTest, se eliminaron una serie de funciones de Memtest86+ v5 que no eran estrictamente necesarias para probar la memoria del sistema. En particular, no se hizo ningún intento de medir la velocidad de la memoria caché y principal, ni de identificar e informar el tipo de DRAM. Estas funciones se agregaron y ampliaron en Memtest86+ v6.0 para crear una versión unificada y con todas las funciones.
Memtest86+ se publica bajo los términos de la Licencia Pública General GNU versión 2 (GPLv2). Aparte de las disposiciones de la GPL, no existen restricciones de uso, privado o comercial. Consulte el archivo de LICENCIA para obtener más detalles.
La compilación solo se prueba en un sistema Linux, pero debería ser posible en cualquier sistema que utilice la cadena de herramientas GNU y el formato de archivo ELF. Las herramientas requeridas son:
Para crear una imagen de 32 bits, cambie el directorio al directorio build32 y escriba make . El resultado es un archivo de imagen binaria memtest.bin que se puede iniciar directamente mediante un BIOS heredado (en modo disquete) o mediante un gestor de arranque intermedio utilizando el protocolo de inicio de Linux de 16 bits y un archivo de imagen binaria memtest.efi que se puede iniciar directamente. mediante una BIOS UEFI de 32 bits. Cualquiera de las imágenes puede iniciarse mediante un gestor de arranque intermedio utilizando los protocolos de arranque de transferencia EFI de Linux de 32 bits o de 32 bits.
Para crear una imagen de 64 bits, cambie el directorio al directorio build64 y escriba make . El resultado es un archivo de imagen binaria memtest.bin que se puede iniciar directamente mediante un BIOS heredado (en modo disquete) o mediante un gestor de arranque intermedio utilizando el protocolo de inicio de Linux de 16 bits y un archivo de imagen binaria memtest.efi que se puede iniciar directamente. mediante una BIOS UEFI de 64 bits. Cualquiera de las imágenes puede iniciarse mediante un gestor de arranque intermedio utilizando los protocolos de arranque de transferencia EFI de Linux de 32, 64 o 64 bits.
En cualquier caso, para crear una imagen ISO que pueda usarse para crear un CD, DVD o unidad flash USB de arranque, escriba make iso . El resultado es un archivo de imagen ISO memtest.iso . Luego, esto se puede escribir directamente en un CD o DVD en blanco, o en una unidad flash USB, que luego se puede iniciar directamente mediante un BIOS de PC heredado o UEFI.
Tenga en cuenta que al escribir en una unidad flash USB, la imagen ISO debe escribirse directamente ("volcarse") en el dispositivo sin formato, ya sea mediante el comando dd o mediante una utilidad que proporcione la misma funcionalidad.
Cuando se utiliza un cargador de arranque intermedio, el archivo memtest.bin o el archivo memtest.efi deben almacenarse en una partición del disco a la que el cargador de arranque pueda acceder, y la configuración del cargador de arranque debe actualizarse para arrancar desde ese archivo como si fuera un kernel de Linux con sin disco RAM inicial. Se reconocen varias opciones de línea de comando de arranque, como se describe a continuación. Si utiliza el protocolo de arranque de 16 bits, Memtest86+ utilizará la pantalla en modo texto (640x400). Si utiliza los protocolos de arranque de 32 o 64 bits, Memtest86+ utilizará la pantalla en modo texto o modo gráfico, como se especifica en la estructura boot_params que le pasa el gestor de arranque. Si está en modo de gráficos, el framebuffer suministrado debe tener al menos 640x400 píxeles; si es más grande, la pantalla estará centrada. Si el sistema se inició en modo UEFI, se debe utilizar el modo de gráficos.
Para fines de prueba, también existe una opción para crear una imagen ISO que utiliza GRUB como gestor de arranque intermedio. Consulte el Makefile en el directorio build32 o build64 para obtener más detalles. La imagen ISO es tanto heredada como de arranque UEFI, por lo que necesita módulos GRUB para arranque heredado y EFI instalados en su sistema de compilación (por ejemplo, en Debian, los módulos GRUB necesarios se encuentran en los paquetes grub-pc-bin , grub-efi-ia32-bin y grub-efi-amd64-bin ). Es posible que necesite ajustar algunas rutas y nombres de archivos en el Makefile para que coincidan con los nombres de su sistema.
Los archivos de configuración de GRUB contenidos en el directorio grub están ahí para usarse en la ISO de prueba, pero también sirven como ejemplo de cómo iniciar Memtest86+ desde GRUB.
Un gestor de arranque intermedio puede pasar una línea de comando de arranque a Memtest86+. La línea de comando puede contener una o más opciones, separadas por espacios. Cada opción consta de un nombre de opción, seguido opcionalmente por un signo = y uno o más parámetros, separados por comas. Se reconocen las siguientes opciones:
0x (por ejemplo: 0xFEDC9000) Memtest86+ admite tanto la interfaz de teclado heredada (usando los puertos de E/S 0x60 y 0x64) como los teclados USB (usando sus propios controladores de dispositivo USB). Se puede seleccionar uno u otro o ambos a través de la línea de comando de inicio. Si no se especifica en la línea de comando, el valor predeterminado es usar ambos si el sistema se inició en modo UEFI; de lo contrario, usar solo la interfaz heredada.
Los BIOS más antiguos generalmente admiten la emulación de teclado USB heredado, lo que hace que los teclados USB actúen como teclados heredados conectados a los puertos 0x60 y 0x64. A menudo, esto se puede habilitar o deshabilitar en los menús de configuración del BIOS. Si los controladores de dispositivo USB de Memtest86+ están habilitados, lo anularán y accederán directamente a cualquier teclado USB. La desventaja de esto es que los controladores USB y los controladores de dispositivos requieren que se reserve algo de memoria para su uso privado, lo que significa que las pruebas de memoria no pueden cubrir la memoria. Entonces, para maximizar la cobertura de la prueba, si es compatible, habilite la emulación de teclado USB heredado y, si arranca en modo UEFI, agregue keyboard=legacy en la línea de comando de arranque.
NOTA : Algunos BIOS UEFI solo admiten la emulación de teclado USB heredado cuando habilita el Módulo del sistema de compatibilidad (CSM) en la configuración del BIOS. Otros sólo lo admiten cuando arrancan en modo heredado.
Muchos dispositivos USB no cumplen totalmente con la especificación USB. Si la sonda del teclado USB se bloquea o no detecta su teclado, pruebe las diversas soluciones proporcionadas por la opción de inicio "usbinit".
NOTA : Actualmente, los controladores USB Memtest86+ no admiten la conexión en caliente. Al usarlos, su teclado USB debe estar conectado antes de ejecutar Memtest86+ y debe permanecer conectado durante toda la prueba.
Algunas máquinas 2 en 1 utilizan un panel LCD que es originalmente una pantalla en modo vertical pero que se monta de lado cuando se conecta al teclado. Cuando se utiliza la pantalla en modo de gráficos, Memtest86+ puede rotar su pantalla para que coincida. Agregue la opción "screen.rhs-up" o "screen.lhs-up" en la línea de comando de inicio, según la orientación del panel LCD. Cuando se utiliza la pantalla en modo texto, se espera que el BIOS se encargue de esto automáticamente.
Cuando se inicia en modo heredado, Memtest86+ utilizará la resolución de pantalla configurada por el BIOS o por el gestor de arranque intermedio. Cuando se inicia en modo UEFI, Memtest86+ normalmente seleccionará la resolución de pantalla más pequeña disponible que abarque su pantalla de 640x400 píxeles. Algunos BIOS devuelven información incorrecta sobre los modos de visualización disponibles, por lo que puede anular esto agregando la opción "screen.mode=" en la línea de comando de inicio.
Tenga en cuenta que cuando se utiliza la rotación de pantalla, la resolución de pantalla especificada es para la pantalla sin girar.
Una vez iniciado, Memtest86+ inicializará su pantalla y luego se detendrá durante unos segundos para permitir al usuario configurar su funcionamiento. Si no se presiona ninguna tecla, automáticamente comenzará a ejecutar todas las pruebas utilizando un único núcleo de CPU y continuará indefinidamente hasta que el usuario reinicie o detenga la máquina.
Al inicio y al ejecutar pruebas, Memtest86+ responde a las siguientes claves:
Tenga en cuenta que las pruebas se detiene cuando el bloqueo de desplazamiento está habilitado y la región de desplazamiento está llena.
El menú de configuración permite al usuario:
En todos los casos, las teclas numéricas se pueden utilizar como alternativa a las teclas de función (1 = F1, 2 = F2, ... 0 = F10).
El modo de informe de errores se puede cambiar en cualquier momento sin interrumpir la secuencia de prueba actual. Las estadísticas de errores se recopilan independientemente del modo de informe de errores actual (por lo que al cambiar al modo de resumen de errores se mostrarán las estadísticas acumuladas desde que comenzó la secuencia de prueba actual). Los patrones de BadRAM sólo se acumulan en el modo BadRAM. Las regiones de memmap de Linux solo se acumulan cuando está en modo memmap. Los números de páginas incorrectas sólo se acumulan cuando se está en modo de páginas incorrectas.
Cualquier cambio en las pruebas seleccionadas, el rango de direcciones o el modo de secuenciación de la CPU iniciará una nueva secuencia de prueba y restablecerá las estadísticas de error.
El modo de solo recuento de errores solo muestra el número total de errores encontrados desde que comenzó la secuencia de prueba actual.
El modo de resumen de errores muestra la siguiente información:
El modo de error individual muestra la siguiente información para cada instancia de error:
El modo de patrones BadRAM acumula y muestra patrones de error para usar con la función BadRAM de Linux o el comando badram de GRUB. Las líneas se imprimen en la forma badram=F1,M1,F2,M2... En cada par F,M , F representa una dirección de falla y M es una máscara de bits para esa dirección. Estos patrones indican que se han producido fallas en direcciones que son iguales a F en todos los bits 1 en M. Un patrón de este tipo puede capturar más errores de los que realmente existen, pero al menos se capturan todos los errores. Estos patrones han sido diseñados para capturar patrones regulares de errores causados por la estructura del hardware en una sintaxis concisa.
Los patrones de BadRAM crecen de forma incremental en lugar de calcularse a partir de una descripción general de todos los errores. El número de pares está limitado a 20 por varias razones prácticas. Como resultado, la elaboración manual de patrones a partir de la salida en el modo de impresión de direcciones puede, en casos excepcionales, producir mejores resultados.
NOTA Como se menciona en las descripciones de las pruebas individuales, la prueba de dirección de los caminantes (prueba 0) y la prueba de movimiento de bloque (prueba 7) no contribuyen a los patrones de BadRAM ya que estas pruebas no permiten determinar la dirección exacta de la falla. .
El modo Memmap de Linux acumula y muestra regiones de memoria defectuosas para usar con la [opción de línea de comando de inicio de Memmap de Linux] (https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt). Las líneas se imprimen con el formato memmap=S1$A1,S2,A2... En cada par S,A , la A representa la primera dirección de la región y la S es el tamaño de la región (en bytes). Se registran hasta 20 regiones de memoria defectuosas. Una vez que se hayan encontrado más de 20 regiones de ubicaciones defectuosas contiguas, las regiones se fusionarán, lo que significará que algunas regiones incluirán ubicaciones no defectuosas. El programa intentará minimizar la cantidad de ubicaciones no defectuosas que se incluyen.
NOTA Como se menciona en las descripciones de las pruebas individuales, la prueba de dirección de los caminantes (prueba 0) y la prueba de movimiento de bloque (prueba 7) no contribuyen a las regiones de memoria defectuosas ya que estas pruebas no permiten determinar la dirección exacta de la falla. determinado.
El modo de páginas malas acumula y muestra números de páginas de memoria defectuosos. Estos se pueden usar con el comando bcdedit de Windows para agregar esas páginas a la lista de memoria PFA de Windows. Los números de página se muestran como un único número hexadecimal (por ejemplo, 0x20 ) o como un rango de números de página hexadecimales (por ejemplo, 0x20..0x2a ). Se registran hasta 20 rangos de páginas defectuosas. Una vez que se hayan encontrado más de 20 rangos de páginas defectuosas contiguas, los rangos se fusionarán, lo que significará que algunos rangos incluirán páginas que no son defectuosas. El programa intentará minimizar la cantidad de páginas no defectuosas que se incluyen.
NOTA Como se menciona en las descripciones de las pruebas individuales, la prueba de dirección de los caminantes (prueba 0) y la prueba de movimiento de bloque (prueba 7) no contribuyen a los números de páginas defectuosas ya que estas pruebas no permiten determinar la dirección exacta de la falla. determinado.
Tenga en cuenta que no todos los errores informados por Memtest86+ se deben a mala memoria. La prueba prueba implícitamente la CPU, las cachés y la placa base. Es imposible que la prueba determine qué causa que se produzca la falla. La mayoría de fallos se deberán a un problema de memoria. Cuando no es así, la única opción es reemplazar piezas hasta que se corrija la falla.
Una vez que se ha detectado un error de memoria, determinar el módulo defectuoso no es un procedimiento claro. Con la gran cantidad de proveedores de placas base y posibles combinaciones de ranuras de memoria, sería difícil, si no imposible, reunir información completa sobre cómo se asignaría un error particular a un módulo de memoria defectuoso. Sin embargo, hay pasos que se pueden tomar para determinar el módulo que falla. A continuación se muestran algunas técnicas que quizás desee utilizar:
Quitar módulos
Módulos giratorios
Reemplazo de módulos
A veces aparecen errores de memoria debido a incompatibilidad de componentes. Un módulo de memoria puede funcionar bien en un sistema y no en otro. Esto no es infrecuente y es una fuente de confusión. Los componentes no son necesariamente malos, pero es posible que sea necesario evitar ciertas combinaciones.
En la gran mayoría de los casos los errores reportados por Memtest86+ son válidos. Hay algunos sistemas que hacen que Memtest86+ se confunda sobre el tamaño de la memoria e intentará probar la memoria inexistente. Esto hará que una gran cantidad de direcciones consecutivas se informen como incorrectas y, en general, habrá muchos bits erróneos. Si tiene una cantidad relativamente pequeña de direcciones fallidas y solo uno o dos bits con error, puede estar seguro de que los errores son válidos. También los errores intermitentes siempre son válidos.
Todos los errores de memoria válidos deben corregirse. Es posible que un error en particular nunca aparezca durante el funcionamiento normal. Sin embargo, operar con memoria marginal es riesgoso y puede provocar pérdida de datos e incluso corrupción del disco.
Memtest86+ no puede diagnosticar muchos tipos de fallas de PC. Por ejemplo, una CPU defectuosa que hace que su sistema operativo falle probablemente provocará que Memtest86+ falle de la misma manera.
El tiempo necesario para una aprobación completa de Memtest86+ variará mucho según la velocidad de la CPU, la velocidad de la memoria y el tamaño de la memoria. Memtest86+ se ejecuta indefinidamente. El contador de pases aumenta cada vez que se ejecutan todas las pruebas seleccionadas. Generalmente, una sola pasada es suficiente para detectar todos los errores excepto los más oscuros. Sin embargo, para obtener total confianza cuando se sospecha de errores intermitentes, se recomienda realizar pruebas durante un período más prolongado.
Existen muchos buenos enfoques para probar la memoria. Sin embargo, muchas pruebas simplemente arrojan algunos patrones a la memoria sin pensar ni conocer mucho la arquitectura de la memoria o la mejor manera de detectar los errores. Esto funciona bien para fallas de memoria dura, pero hace poco para encontrar errores intermitentes. Las pruebas de memoria basadas en BIOS son inútiles para encontrar errores de memoria intermitentes.
Los chips de memoria constan de una gran variedad de celdas de memoria muy compactas, una para cada bit de datos. La gran mayoría de los fallos intermitentes son el resultado de la interacción entre estas células de memoria. A menudo, escribir una celda de memoria puede hacer que una de las celdas adyacentes se escriba con los mismos datos. Una prueba de memoria eficaz intenta detectar esta condición. Por tanto, una estrategia ideal para probar la memoria sería la siguiente:
Debería ser obvio que esta estrategia requiere un conocimiento exacto de cómo están dispuestas las celdas de memoria en el chip. Además, existe un número interminable de posibles diseños de chips para diferentes tipos de chips y fabricantes, lo que hace que esta estrategia no sea práctica. Sin embargo, existen algoritmos de prueba que pueden aproximarse a esta estrategia ideal.
Memtest86+ utiliza dos algoritmos que proporcionan una aproximación razonable de la estrategia de prueba ideal anterior. La primera de estas estrategias se llama inversiones en movimiento. Las pruebas de inversión en movimiento funcionan de la siguiente manera:
Este algoritmo es una buena aproximación a una prueba de memoria ideal, pero existen algunas limitaciones. La mayoría de los chips de alta densidad actuales almacenan datos de 4 a 16 bits de ancho. Con chips que tienen más de un bit de ancho, es imposible leer o escribir selectivamente solo un bit. Esto significa que no podemos garantizar que se haya probado la interacción de todas las células adyacentes. En este caso, lo mejor que podemos hacer es utilizar algunos patrones para asegurarnos de que todas las celdas adyacentes se hayan escrito al menos con todas las combinaciones posibles de uno y cero.
También se puede ver que el almacenamiento en caché, el almacenamiento en búfer y la ejecución fuera de orden interferirán con el algoritmo de inversión en movimiento y lo harán menos efectivo. Es posible desactivar el almacenamiento en caché, pero la memoria intermedia en los nuevos chips de alto rendimiento no se puede desactivar. Para abordar esta limitación se creó un nuevo algoritmo llamado Módulo-20. Este algoritmo no se ve afectado por el almacenamiento en caché o el almacenamiento en búfer. El algoritmo funciona de la siguiente manera:
Este algoritmo logra casi el mismo nivel de pruebas de adyacencia que las inversiones en movimiento, pero no se ve afectado por el almacenamiento en caché o el almacenamiento en búfer. Dado que se realizan pases de escritura separados (1.1, 1.2) y de lectura (1.4) para toda la memoria, podemos estar seguros de que todos los buffers y el caché se han vaciado entre pases. La selección de 20 como tamaño de zancada fue algo arbitraria. Los pasos más grandes pueden ser más efectivos, pero llevarían más tiempo ejecutarlos. La elección de 20 parecía ser un compromiso razonable entre rapidez y minuciosidad.
Memtest86+ ejecuta una serie de pruebas numeradas para comprobar si hay errores. Estas pruebas constan de una combinación de algoritmo de prueba, patrón de datos y almacenamiento en caché. El orden de ejecución de estas pruebas se organizó de manera que los errores se detecten lo más rápido posible. A continuación se incluye una descripción de cada prueba.
Para permitir probar más de 4 GB de memoria en CPU de 32 bits, el rango de direcciones físicas se divide en ventanas de 1 GB que se asignan una a la vez en una ventana de memoria virtual. Cada ventana de 1 GB puede contener una o más regiones de memoria contiguas. Para la mayoría de las pruebas, la prueba se realiza en cada región de la memoria por turno. El almacenamiento en caché está habilitado para todas las pruebas excepto para la primera.
En cada región de memoria, a su vez, prueba todos los bits de dirección utilizando un patrón de dirección ambulante. Los errores de esta prueba no contribuyen a los patrones de BadRAM, regiones de memmap o regiones de páginas defectuosas.
En cada región de memoria, a su vez, cada dirección se escribe con su propia dirección y luego se verifica la coherencia de cada dirección. Esta prueba se realiza secuencialmente con cada CPU disponible, independientemente del modo de secuenciación de CPU seleccionado por el usuario.
En todas las regiones de la memoria, cada dirección se escribe con su propia dirección virtual más el número de ventana (para imágenes de 32 bits) o su propia dirección física (para imágenes de 64 bits) y luego se verifica la coherencia de cada dirección. Esto detecta cualquier error en los bits de dirección de orden superior que se perderían al probar cada ventana por turno. Esta prueba se realiza secuencialmente con cada CPU disponible, independientemente del modo de secuenciación de CPU seleccionado por el usuario.
En cada región de la memoria por turno, y para cada patrón por turno, se utiliza el algoritmo de inversiones en movimiento con patrones de todos unos y todos ceros.
En cada región de memoria por turno, y para cada patrón por turno, se utiliza el algoritmo de inversiones en movimiento con patrones de unos y ceros móviles de 8 bits de ancho.
En cada región de la memoria por turno, y para cada patrón por turno, se utiliza el algoritmo de inversiones en movimiento con patrones de un número aleatorio y su complemento. El número aleatorio es diferente en cada pasada de prueba, por lo que varias pasadas aumentan la efectividad.
En cada región de memoria por turno, y para cada patrón por turno, se utiliza el algoritmo de inversiones en movimiento con patrones de unos y ceros móviles de 32 bits de ancho (en compilaciones de 32 bits) o de 64 bits de ancho (en compilaciones de 64 bits). . A diferencia de las pruebas anteriores, el patrón gira 1 bit en cada dirección sucesiva.
Esta prueba enfatiza la memoria mediante el uso de instrucciones de movimiento de bloques (movs) y se basa en la prueba burnBX de Robert Redelmeier.
En cada región de la memoria, la memoria se inicializa con patrones de cambio que se invierten cada 8 bytes. Luego, los bloques de memoria se mueven usando la instrucción movs. Una vez completados los movimientos, se verifican los patrones de datos. Debido a que los datos se verifican solo después de que se completan los movimientos de memoria, no es posible saber dónde ocurrió el error. Las direcciones reportadas son solo de donde se encontró el patrón incorrecto. En consecuencia, los errores de esta prueba no contribuyen a los patrones BadRAM, regiones de memmap o regiones de páginas defectuosas.
En cada región de memoria, a su vez, cada dirección se escribe con un número aleatorio, luego se verifica la coherencia de cada dirección y se escribe con el complemento de los datos originales, luego se verifica nuevamente la coherencia de cada dirección.
En cada región de memoria por turno, y para cada patrón por turno, se utiliza el algoritmo Módulo-20 con patrones de un número aleatorio y su complemento. El número aleatorio es diferente en cada pasada de prueba, por lo que varias pasadas aumentan la efectividad.
En todas las regiones de la memoria, y para cada patrón por turno, inicializa cada ubicación de la memoria con un patrón, duerme durante un período de tiempo y luego verifica la coherencia de cada ubicación de la memoria. La prueba se realiza con patrones de todos ceros y todos unos.
Consulte la lista de problemas abiertos y solicitudes de mejora en GitHub.
¡No dudes en enviar informes de errores!
Se aceptan contribuciones de código, ya sea para corregir errores o realizar mejoras. Consulte README_DEVEL.md en el directorio doc para obtener algunas pautas básicas.
Memtest86+ v6.0 se basó en PCMemTest, desarrollado por Martin Whitaker, el cual se basó en Memtest86+ v5.01, desarrollado por Samuel Demeulemeester, que a su vez se basó en Memtest86, desarrollado por Chris Brady con los recursos y asistencia que se enumeran a continuación:
Las versiones iniciales de los archivos fuente bootsect.S, setup.S, head.S y build.c son del kernel Linux 1.2.1 y han sido muy modificadas.
Doug Sisk proporcionó un código para admitir una consola conectada a través de un puerto serie. (no utilizado actualmente)
Rick van Rein proporcionó el código para crear patrones BadRAM.
La prueba de movimiento de bloques se basa en la prueba burnBX de Robert Redelmeier.
El código del búfer de pantalla fue proporcionado por Jani Averbach. (no utilizado por Memtest86+ v6.0)
Eric Biederman proporcionó todo el contenido de las funciones para la versión 3.0, además de muchas correcciones de errores y una importante limpieza de código.
Mejoras importantes en la detección y generación de informes de hardware en las versiones 3.2, 3.3 y 3.4 proporcionadas por Samuel Demeulemeester (de Memtest86+ v1.11, v1.60 y v1.70).
Además, se importaron varias correcciones de errores para Memtest86+ desde anphsw/memtest86.
