memtest86plus
v7.20
Memtest86 + é um testador de memória autônomo, gratuito e de código aberto para computadores com arquitetura x86 e x86-64. Ele fornece uma verificação de memória muito mais completa do que a fornecida pelos testes de memória do BIOS.
Também é capaz de acessar quase toda a memória do computador, não sendo restringido pela memória utilizada pelo sistema operacional e não dependendo de nenhum software subjacente como bibliotecas UEFI.
Memtest86+ pode ser carregado e executado diretamente por um BIOS de PC (legado ou UEFI) ou por meio de um gerenciador de inicialização intermediário que suporta o protocolo de inicialização de transferência Linux de 16 bits, 32 bits, 64 bits ou EFI. Deve funcionar em qualquer classe Pentium ou CPU posterior de 32 ou 64 bits.
Versões binárias (compilações de desenvolvimento estáveis e noturnas) estão disponíveis em memtest.org.
Memtest86+ v6.00 foi baseado no PCMemTest, que foi uma bifurcação e reescrita do Memtest86+ v5 anterior, que por sua vez foi uma bifurcação do MemTest-86. O objetivo da reescrita do PCMemTest foi:
No processo de criação do PCMemTest, vários recursos do Memtest86+ v5 que não eram estritamente necessários para testar a memória do sistema foram eliminados. Em particular, nenhuma tentativa foi feita para medir a velocidade do cache e da memória principal, ou para identificar e relatar o tipo de DRAM. Esses recursos foram adicionados e expandidos no Memtest86+ v6.0 para criar uma versão unificada e completa.
Memtest86+ é lançado sob os termos da GNU General Public License versão 2 (GPLv2). Além das disposições da GPL, não há restrições de uso, privado ou comercial. Consulte o arquivo LICENSE para obter detalhes.
Build é testado apenas em um sistema Linux, mas deve ser possível em qualquer sistema usando o conjunto de ferramentas GNU e o formato de arquivo ELF. As ferramentas necessárias são:
Para construir uma imagem de 32 bits, mude o diretório para o diretório build32 e digite make . O resultado é um arquivo de imagem binária memtest.bin que pode ser inicializado diretamente por um BIOS legado (em modo de disquete) ou por um gerenciador de inicialização intermediário usando o protocolo de inicialização Linux de 16 bits e um arquivo de imagem binária memtest.efi que pode ser inicializado diretamente por um UEFI BIOS de 32 bits. Qualquer uma das imagens pode ser inicializada por um gerenciador de inicialização intermediário usando os protocolos de inicialização de transferência EFI de 32 bits ou EFI do Linux.
Para construir uma imagem de 64 bits, mude o diretório para o diretório build64 e digite make . O resultado é um arquivo de imagem binária memtest.bin que pode ser inicializado diretamente por um BIOS legado (em modo de disquete) ou por um gerenciador de inicialização intermediário usando o protocolo de inicialização Linux de 16 bits e um arquivo de imagem binária memtest.efi que pode ser inicializado diretamente por um UEFI BIOS de 64 bits. Qualquer uma das imagens pode ser inicializada por um gerenciador de inicialização intermediário usando os protocolos de inicialização de transferência EFI de 32 bits, 64 bits ou 64 bits do Linux.
Em ambos os casos, para construir uma imagem ISO que possa ser usada para criar um CD, DVD ou unidade flash USB inicializável, digite make iso . O resultado é um arquivo de imagem ISO memtest.iso . Isso pode então ser gravado diretamente em um CD ou DVD vazio ou em uma unidade flash USB, que pode ser inicializada diretamente por um BIOS de PC legado ou UEFI.
Observe que ao gravar em uma unidade Flash USB, a imagem ISO deve ser gravada diretamente ('despejada') no dispositivo bruto, usando o comando dd ou um utilitário que forneça a mesma funcionalidade.
Ao usar um gerenciador de inicialização intermediário, o arquivo memtest.bin ou o arquivo memtest.efi deve ser armazenado em uma partição de disco que o carregador de inicialização possa acessar e a configuração do carregador de inicialização deve ser atualizada para inicializar a partir desse arquivo como se fosse um kernel Linux com nenhum disco RAM inicial. Várias opções de linha de comando de inicialização são reconhecidas, conforme descrito abaixo. Se estiver usando o protocolo de inicialização de 16 bits, o Memtest86+ usará a exibição em modo texto (640x400). Se estiver usando protocolos de inicialização de 32 ou 64 bits, o Memtest86+ usará a exibição em modo de texto ou modo gráfico, conforme especificado na estrutura boot_params passada a ele pelo gerenciador de inicialização. Se estiver em modo gráfico, o framebuffer fornecido deve ter no mínimo 640x400 pixels; se for maior, a exibição será centralizada. Se o sistema foi inicializado no modo UEFI, o modo gráfico deverá ser usado.
Para fins de teste, também existe a opção de construir uma imagem ISO que usa GRUB como gerenciador de inicialização intermediário. Consulte o Makefile no diretório build32 ou build64 para obter detalhes. A imagem ISO é legada e inicializável por UEFI, então você precisa de módulos GRUB para inicialização herdada e EFI instalados em seu sistema de compilação (por exemplo, no Debian, os módulos GRUB necessários estão localizados nos pacotes grub-pc-bin , grub-efi-ia32-bin e grub-efi-amd64-bin ). Pode ser necessário ajustar alguns caminhos e nomes de arquivos no Makefile para corresponder à nomenclatura do seu sistema.
Os arquivos de configuração do GRUB contidos no diretório grub estão lá para uso no ISO de teste, mas também servem como exemplo de como inicializar o Memtest86+ a partir do GRUB.
Um bootloader intermediário pode passar uma linha de comando de inicialização para Memtest86+. A linha de comando pode conter uma ou mais opções, separadas por espaços. Cada opção consiste em um nome de opção, opcionalmente seguido por um sinal = e um ou mais parâmetros, separados por vírgulas. As seguintes opções são reconhecidas:
0x (por exemplo: 0xFEDC9000) Memtest86+ suporta tanto a interface de teclado herdada (usando portas de E/S 0x60 e 0x64) quanto teclados USB (usando seus próprios drivers de dispositivo USB). Um ou outro ou ambos podem ser selecionados através da linha de comando de inicialização. Se não for especificado na linha de comando, o padrão é usar ambos se o sistema foi inicializado no modo UEFI, caso contrário, usar apenas a interface legada.
BIOS mais antigos geralmente suportam emulação de teclado legado USB, o que faz com que os teclados USB atuem como teclados legados conectados às portas 0x60 e 0x64. Muitas vezes, isso pode ser ativado ou desativado nos menus de configuração do BIOS. Se os drivers de dispositivo USB do Memtest86+ estiverem habilitados, eles substituirão isso e acessarão diretamente qualquer teclado USB. A desvantagem disso é que os controladores USB e drivers de dispositivo exigem que alguma memória seja reservada para uso privado, o que significa que a memória não pode ser coberta pelos testes de memória. Portanto, para maximizar a cobertura do teste, se houver suporte, habilite a emulação de teclado legado USB e, se inicializar no modo UEFI, adicione keyboard=legacy na linha de comando de inicialização.
NOTA : Alguns BIOS UEFI suportam apenas emulação de teclado legado USB quando você habilita o Módulo do Sistema de Compatibilidade (CSM) na configuração do BIOS. Outros só o suportam quando inicializam no modo legado.
Muitos dispositivos USB não estão totalmente em conformidade com as especificações USB. Se o teste do teclado USB travar ou não conseguir detectar o teclado, tente as várias soluções alternativas fornecidas pela opção de inicialização “usbinit”.
NOTA : Hot-plugging não é atualmente suportado pelos drivers USB Memtest86+. Ao usá-los, seu teclado USB deve ser conectado antes de executar o Memtest86+ e permanecer conectado durante todo o teste.
Algumas máquinas 2 em 1 usam um painel LCD que é nativamente um display em modo retrato, mas é montado lateralmente quando conectado ao teclado. Ao usar a tela no modo gráfico, o Memtest86+ pode girar sua tela para corresponder. Adicione a opção “screen.rhs-up” ou “screen.lhs-up” na linha de comando de inicialização, dependendo da orientação do painel LCD. Ao usar a tela em modo texto, espera-se que o BIOS cuide disso automaticamente.
Quando inicializado no modo legado, o Memtest86+ usará a resolução de tela definida pelo BIOS ou pelo bootloader intermediário. Quando inicializado no modo UEFI, o Memtest86+ normalmente selecionará a menor resolução de tela disponível que abrange sua tela de 640x400 pixels. Alguns BIOS retornam informações incorretas sobre os modos de exibição disponíveis, portanto você pode substituir isso adicionando a opção "screen.mode=" na linha de comando de inicialização.
Observe que ao usar a rotação da tela, a resolução de tela especificada é para a tela não girada.
Uma vez inicializado, o Memtest86+ irá inicializar seu display e então pausar por alguns segundos para permitir que o usuário configure sua operação. Se nenhuma tecla for pressionada, todos os testes serão automaticamente iniciados usando um único núcleo de CPU, continuando indefinidamente até que o usuário reinicie ou pare a máquina.
Na inicialização e ao executar testes, o Memtest86+ responde às seguintes chaves:
Observe que o teste é interrompido quando o bloqueio de rolagem está ativado e a região de rolagem está cheia.
O menu de configuração permite ao usuário:
Em todos os casos, as teclas numéricas podem ser utilizadas como alternativas às teclas de função (1 = F1, 2 = F2, ... 0 = F10).
O modo de relatório de erros pode ser alterado a qualquer momento sem interromper a sequência de teste atual. As estatísticas de erros são coletadas independentemente do modo de relatório de erros atual (portanto, mudar para o modo de resumo de erros mostrará as estatísticas acumuladas desde o início da sequência de teste atual). Os padrões BadRAM só são acumulados no modo BadRAM. As regiões memmap do Linux são acumuladas apenas no modo memmap. Números de páginas ruins só são acumulados no modo de página ruim.
Qualquer alteração nos testes selecionados, intervalo de endereços ou modo de sequenciamento da CPU iniciará uma nova sequência de testes e redefinirá as estatísticas de erro.
O modo somente contagem de erros exibe apenas o número total de erros encontrados desde o início da sequência de teste atual.
O modo de resumo de erros exibe as seguintes informações:
O modo de erro individual exibe as seguintes informações para cada instância de erro:
O modo de padrões BadRAM acumula e exibe padrões de erro para uso com o recurso Linux BadRAM ou comando GRUB badram. As linhas são impressas no formato badram=F1,M1,F2,M2... Em cada par F,M , o F representa um endereço de falha e o M é uma máscara de bits para esse endereço. Esses padrões afirmam que ocorreram falhas em endereços iguais a F em todos os bits 1 em M. Esse padrão pode capturar mais erros do que realmente existem, mas pelo menos todos os erros são capturados. Esses padrões foram projetados para capturar padrões regulares de erros causados pela estrutura de hardware em uma sintaxe concisa.
Os padrões BadRAM crescem de forma incremental, em vez de serem calculados a partir de uma visão geral de todos os erros. O número de pares é limitado a 20 por uma série de razões práticas. Como resultado, a elaboração manual de padrões a partir da saída no modo de impressão de endereço pode, em casos excepcionais, produzir melhores resultados.
NOTA Conforme mencionado nas descrições de testes individuais, o teste de endereço de walk-ones (teste 0) e o teste de movimento de bloco (teste 7) não contribuem para os padrões BadRAM, pois esses testes não permitem que o endereço exato da falha seja determinado .
O modo memmap do Linux acumula e exibe regiões de memória defeituosas para uso com a [opção de linha de comando de inicialização do memmap do Linux] (https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt). As linhas são impressas no formato memmap=S1$A1,S2,A2... Em cada par S,A , A representa o primeiro endereço da região e S é o tamanho da região (em bytes). Até 20 regiões de memória defeituosas são registradas. Depois que mais de 20 regiões de locais defeituosos contíguos forem encontradas, as regiões serão mescladas, o que significa que algumas regiões incluirão locais não defeituosos. O programa tentará minimizar o número de locais não defeituosos incluídos.
NOTA Conforme mencionado nas descrições dos testes individuais, o teste de endereço dos ambulantes (teste 0) e o teste de movimento de bloco (teste 7) não contribuem para as regiões de memória defeituosas, pois esses testes não permitem que o endereço exato da falha seja determinado.
O modo de páginas ruins acumula e exibe números de páginas de memória com defeito. Eles podem ser usados com o comando bcdedit do Windows para adicionar essas páginas à lista de memória PFA do Windows. Os números das páginas são exibidos como um único número hexadecimal (por exemplo, 0x20 ) ou como um intervalo de números de páginas hexadecimais (por exemplo, 0x20..0x2a ). São registrados até 20 intervalos de páginas defeituosas. Depois que mais de 20 intervalos de páginas defeituosas contíguas forem encontrados, os intervalos serão mesclados, o que significa que alguns intervalos incluirão páginas não defeituosas. O programa tentará minimizar o número de páginas não defeituosas incluídas.
NOTA Conforme mencionado nas descrições dos testes individuais, o teste de endereço dos ambulantes (teste 0) e o teste de movimento de bloco (teste 7) não contribuem para os números de página com falha, pois esses testes não permitem que o endereço exato da falha seja determinado.
Esteja ciente de que nem todos os erros relatados pelo Memtest86+ são devido a memória ruim. O teste testa implicitamente a CPU, os caches e a placa-mãe. É impossível para o teste determinar o que causa a falha. A maioria das falhas será devido a um problema de memória. Quando não estiver, a única opção é substituir peças até que a falha seja corrigida.
Depois que um erro de memória for detectado, determinar o módulo com falha não é um procedimento claro. Com o grande número de fornecedores de placas-mãe e as possíveis combinações de slots de memória, seria difícil, se não impossível, reunir informações completas sobre como um erro específico seria mapeado para um módulo de memória com falha. No entanto, existem etapas que podem ser executadas para determinar o módulo com falha. Aqui estão algumas técnicas que você pode querer usar:
Removendo módulos
Módulos rotativos
Substituindo módulos
Às vezes, erros de memória aparecem devido à incompatibilidade de componentes. Um módulo de memória pode funcionar bem em um sistema e não em outro. Isto não é incomum e é uma fonte de confusão. Os componentes não são necessariamente ruins, mas certas combinações podem precisar ser evitadas.
Na grande maioria dos casos, os erros relatados pelo Memtest86+ são válidos. Existem alguns sistemas que fazem com que o Memtest86+ fique confuso sobre o tamanho da memória e tentará testar memória inexistente. Isso fará com que um grande número de endereços consecutivos sejam relatados como incorretos e geralmente haverá muitos bits com erro. Se você tiver um número relativamente pequeno de endereços com falha e apenas um ou dois bits com erro, poderá ter certeza de que os erros são válidos. Além disso, erros intermitentes são sempre válidos.
Todos os erros de memória válidos devem ser corrigidos. É possível que um erro específico nunca apareça durante a operação normal. No entanto, operar com memória marginal é arriscado e pode resultar em perda de dados e até mesmo em corrupção de disco.
Memtest86+ não consegue diagnosticar muitos tipos de falhas de PC. Por exemplo, uma CPU defeituosa que faz com que seu sistema operacional trave provavelmente fará com que o Memtest86+ trave da mesma maneira.
O tempo necessário para uma passagem completa do Memtest86+ irá variar muito dependendo da velocidade da CPU, velocidade da memória e tamanho da memória. Memtest86+ é executado indefinidamente. O contador de aprovação aumenta cada vez que todos os testes selecionados são executados. Geralmente, uma única passagem é suficiente para detectar todos os erros, exceto os mais obscuros. No entanto, para obter total confiança, quando há suspeita de erros intermitentes, é aconselhável testar por um período mais longo.
Existem muitas abordagens boas para testar a memória. No entanto, muitos testes simplesmente lançam alguns padrões na memória sem muita reflexão ou conhecimento da arquitetura da memória ou de como os erros podem ser melhor detectados. Isso funciona bem para falhas de memória rígida, mas faz pouco para encontrar erros intermitentes. Os testes de memória baseados em BIOS são inúteis para encontrar erros de memória intermitentes.
Os chips de memória consistem em um grande conjunto de células de memória compactadas, uma para cada bit de dados. A grande maioria das falhas intermitentes é resultado da interação entre essas células de memória. Freqüentemente, escrever uma célula de memória pode fazer com que uma das células adjacentes seja gravada com os mesmos dados. Um teste de memória eficaz tenta testar essa condição. Portanto, uma estratégia ideal para testar a memória seria a seguinte:
Deveria ser óbvio que esta estratégia requer um conhecimento exato de como as células de memória estão dispostas no chip. Além disso, há um número interminável de possíveis layouts de chips para diferentes tipos e fabricantes de chips, tornando esta estratégia impraticável. No entanto, existem algoritmos de teste que podem aproximar-se desta estratégia ideal.
Memtest86+ usa dois algoritmos que fornecem uma aproximação razoável da estratégia de teste ideal acima. A primeira dessas estratégias é chamada de inversões móveis. Os testes de inversão móvel funcionam da seguinte forma:
Este algoritmo é uma boa aproximação de um teste de memória ideal, mas existem algumas limitações. A maioria dos chips de alta densidade hoje armazena dados de 4 a 16 bits de largura. Com chips com mais de um bit de largura, é impossível ler ou escrever seletivamente apenas um bit. Isso significa que não podemos garantir que todas as células adjacentes tenham sido testadas quanto à interação. Neste caso o melhor que podemos fazer é usar alguns padrões para garantir que todas as células adjacentes tenham sido escritas pelo menos com todas as combinações possíveis de um e zero.
Também pode ser visto que o cache, o buffer e a execução fora de ordem interferirão no algoritmo de inversão móvel e o tornarão menos eficaz. É possível desativar o cache, mas o buffer de memória em novos chips de alto desempenho não pode ser desativado. Para resolver esta limitação foi criado um novo algoritmo denominado Módulo-20. Este algoritmo não é afetado pelo cache ou buffer. O algoritmo funciona da seguinte maneira:
Este algoritmo realiza quase o mesmo nível de teste de adjacência que as inversões móveis, mas não é afetado pelo armazenamento em cache ou buffer. Como as passagens de gravação (1.1, 1.2) e de leitura (1.4) separadas são feitas para toda a memória, podemos ter certeza de que todos os buffers e cache foram liberados entre as passagens. A seleção de 20 como tamanho da passada foi um tanto arbitrária. Passos maiores podem ser mais eficazes, mas levariam mais tempo para serem executados. A escolha de 20 pareceu ser um compromisso razoável entre velocidade e rigor.
Memtest86+ executa uma série de testes numerados para verificar erros. Esses testes consistem em uma combinação de algoritmo de teste, padrão de dados e cache. A ordem de execução desses testes foi organizada para que os erros sejam detectados o mais rápido possível. Segue uma descrição de cada teste.
Para permitir o teste de mais de 4 GB de memória em CPUs de 32 bits, o intervalo de endereços físicos é dividido em janelas de 1 GB que são mapeadas uma de cada vez em uma janela de memória virtual. Cada janela de 1GB pode conter uma ou mais regiões de memória contíguas. Para a maioria dos testes, o teste é executado em cada região da memória por vez. O cache está habilitado para todos, exceto para o primeiro teste.
Em cada região de memória, por sua vez, testa todos os bits de endereço usando um padrão de endereço ambulante. Os erros deste teste não contribuem para padrões BadRAM, regiões de memmap ou regiões de páginas inválidas.
Em cada região de memória, por sua vez, cada endereço é escrito com seu próprio endereço e então cada endereço é verificado quanto à consistência. Este teste é realizado sequencialmente com cada CPU disponível, independente do modo de sequenciamento da CPU selecionado pelo usuário.
Em todas as regiões de memória, cada endereço é escrito com seu próprio endereço virtual mais o número da janela (para imagens de 32 bits) ou seu próprio endereço físico (para imagens de 64 bits) e então cada endereço é verificado quanto à consistência. Isso detecta quaisquer erros nos bits de endereço de ordem superior que seriam perdidos ao testar cada janela por vez. Este teste é realizado sequencialmente com cada CPU disponível, independente do modo de sequenciamento da CPU selecionado pelo usuário.
Em cada região de memória por vez, e para cada padrão por vez, usa o algoritmo de inversões móveis com padrões de todos uns e todos zeros.
Em cada região da memória, por sua vez, e para cada padrão, por sua vez, usa o algoritmo de inversões móveis com padrões de uns e zeros ambulantes de largura de 8 bits.
Em cada região da memória por sua vez, e para cada padrão por sua vez, utiliza o algoritmo de inversões móveis com padrões de um número aleatório e seu complemento. O número aleatório é diferente em cada passagem de teste, portanto, múltiplas passagens aumentam a eficácia.
Em cada região de memória por vez, e para cada padrão por vez, usa o algoritmo de inversões móveis com padrões de largura de 32 bits (em compilações de 32 bits) ou de 64 bits (em compilações de 64 bits) andando uns e andando zeros . Ao contrário dos testes anteriores, o padrão é girado 1 bit em cada endereço sucessivo.
Este teste sobrecarrega a memória usando instruções de movimentação de bloco (movs) e é baseado no teste burnBX de Robert Redelmeier.
Em cada região de memória, por sua vez, a memória é inicializada com padrões de mudança que são invertidos a cada 8 bytes. Em seguida, os blocos de memória são movidos usando a instrução movs. Após a conclusão das movimentações, os padrões de dados são verificados. Como os dados são verificados somente após a conclusão das movimentações de memória, não é possível saber onde ocorreu o erro. Os endereços informados são apenas para onde o padrão incorreto foi encontrado. Conseqüentemente, os erros deste teste não contribuem para padrões BadRAM, regiões de memmap ou regiões de páginas inválidas.
Em cada região de memória, por sua vez, cada endereço é escrito com um número aleatório, então cada endereço é verificado quanto à consistência e escrito com o complemento dos dados originais, então cada endereço é novamente verificado quanto à consistência.
Em cada região de memória por vez, e para cada padrão por vez, utiliza o algoritmo Módulo-20 com padrões de um número aleatório e seu complemento. O número aleatório é diferente em cada passagem de teste, portanto, múltiplas passagens aumentam a eficácia.
Em todas as regiões de memória, e para cada padrão por vez, inicializa cada local de memória com um padrão, dorme por um período de tempo e, em seguida, verifica a consistência de cada local de memória. O teste é realizado com padrões de todos zeros e todos uns.
Consulte a lista de problemas abertos e solicitações de melhorias no GitHub.
Sinta-se à vontade para enviar relatórios de bugs!
Contribuições de código são bem-vindas, seja para corrigir bugs ou para fazer melhorias. Consulte README_DEVEL.md no diretório doc para obter algumas diretrizes básicas.
O Memtest86+ v6.0 foi baseado no PCMemTest, desenvolvido por Martin Whitaker, que foi baseado no Memtest86+ v5.01, desenvolvido por Samuel Demeulemeester, que por sua vez foi baseado no Memtest86, desenvolvido por Chris Brady com os recursos e assistência listados abaixo:
As versões iniciais dos arquivos fonte bootsect.S, setup.S, head.S e build.c são do kernel Linux 1.2.1 e foram fortemente modificadas.
Doug Sisk forneceu código para suportar um console conectado através de uma porta serial. (não usado atualmente)
O código para criar padrões BadRAM foi fornecido por Rick van Rein.
O teste de movimentação de bloco é baseado no teste burnBX de Robert Redelmeier.
O código do buffer de tela foi fornecido por Jani Averbach. (não usado pelo Memtest86+ v6.0)
Eric Biederman forneceu todo o conteúdo da versão 3.0, além de muitas correções de bugs e limpeza significativa de código.
Principais melhorias na detecção e relatórios de hardware nas versões 3.2, 3.3 e 3.4 fornecidas por Samuel Demeulemeester (de Memtest86+ v1.11, v1.60 e v1.70).
Além disso, diversas correções de bugs para Memtest86+ foram importadas do anphsw/memtest86.
