Apesar da complexidade, não é muito comum um processador vir com defeito de fábrica, geralmente eles são testados antes do encapsulamentos e os que não funcionam são simplesmente descartados. O problema mais comum com relação a eles é superaquecimento que pode ser resolvido com uma ventilação adequada
Mas, não podemos dizer o mesmo dos pentes de memória, onde os defeitos são muito mais comuns e infelizmente mais difíceis de detectar. Um agravante é que existem muitos fabricantes diferentes de memórias, todos trabalhando com margens muito baixas. Como a maior parte dos usuários e integradores compra mais pelo preço, acaba levando pra casa módulos genéricos que muitas vezes não são adequadamente testados em fábrica.
A placa mãe também pode ser responsável por vários erros, já que ela é a encarregada de transportar os dados dos pentes de memória até o processador. Se a placa mãe corromper os dados pelo caminho você terá travamentos e outros sintomas semelhantes aos causados por um pente de memória com defeito.
Estes erros são cruéis pois são muitas vezes difíceis de perceber. Eles muitas vezes são confundidos com problemas do sistema operacional e o usuário acaba aprendendo a conviver com eles...
Não podemos nos esquecer ainda da nossa velha amiga, a eletricidade estática :-) Os danos causados por ela geralmente não imediatos, as descargas geralmente não destroem os filamentos dos circuitos, mas apenas causam o aparecimento de falhas microscópicas, que vão aumentando com o tempo até finalmente romper e inutilizar o componente. Este processo pode demorar meses ou até anos, mas de qualquer forma abrevia sua vida útil.
Seja qual for a causa, erros de memória podem causar muita dor de cabeça, então a melhor forma de lidar com o problema é rodar um teste completo sempre que você montar um PC ou instalar um novo pente de memória.
Existem inúmeros programas deste tipo, já testei vários deles, mas o melhor disponível atualmente é o memtest86 que está disponível no:
http://www.memtest86.com/
A grande vantagem dele é que além de pequeno, gratuito e de código aberto ele é quase automático. Você precisa apenas gravar um CD ou disquete e dar boot para que o teste seja iniciado automaticamente. Ele fica num loop eterno, repetindo os testes e indicando os erros que encontrar até que você se sinta satisfeito.
Existem duas opções de download. O mais prático é baixar uma imagem ISO, que pode ser usada para fazer um CD bootável. O arquivo tem apenas 64 kb compactado e 1.6 MB depois de descompactado. Você pode baixar a última versão no site ou pegar a versão 3.0 aqui.
No site você vai encontrar também os programas para gerarem o disquete de boot no Windows e Linux. Tanto faz usar o CD ou o disquete, o programa é exatamente o mesmo. É necessário dar boot diretamente no memtest para que ele possa testar realmente toda a memória do sistema. Caso ele rodasse sobre o Windows ou Linux ele não teria como acessar áreas utilizadas pelo sistema e programas e o teste não seria confiável.
O memtest realiza um total de 11 testes. Os 7 primeiros são relativamente rápidos, demoram cerca de 15 minutos num Celeron 900 com 128 MB. Os outros quatro testas são chamados de teste extendido, eles são muito mais rigorosos, capazes de encontrar erros não detectados pelo teste rápido mas em compensação eles são muito demorados, de 10 a 12 vezes mais! Ou seja, o ideal é deixar o PC ligado de madrugada enquanto você não for precisar dele.
Por default são feitos apenas os testes básicos. Pressionando a tecla C e depois 2 (test selection) você pode ativar os testes avançados ativando a opção 3 (all tests):
Se por acaso a tabela inicial do memtest informar incorretamente a quantidade de memória, acesse a opção 4 (memory sizing) e a opção 3 (probe). Isso fará com que o Memtest detecte a memória, desprezando as informações do BIOS. Na tela principal, pressione a tecla 5 para ter um sumário com todos os erros encontrados em cada teste:
Basicamente é isto, não existe muita configuração a fazer, a alma do negócio é ter paciência e deixar ele fazer eu trabalho, se possível tempo suficiente para realizar o teste longo.
O tempo necessário varia de acordo com o desempenho e, principalmente da quantidade de memória. Dobrar a quantidade de memória dobra o tempo do teste, usar um processador mais rápido faz o teste correr um pouco mais rápido mas usar memória DDR ou Rambus que oferecem um barramento de dados mais largo é o que faz o teste correr realmente bem mais rápido.
Vamos ver então o que estes tais 11 testes fazem:
Teste 0 [Address test, walking ones, no cache]: Simplesmente testa o acesso a todos os endereços da memória, algo semelhante com o que o BIOS faz na contagem de memória durante o boot. Serve mais para checar a quantidade de memória disponível.
Teste 1 [Moving Inv, ones&zeros, cached]: Escreve bits 1 e depois bits 0 em todos os endereços da memória. Este algoritmo também utiliza os caches L1 e L2 do processador. É um teste rápido que serve apenas para verificar erros mais grosseiros.
Teste 2 [Address test, own address, no cache]: Este teste é semelhante ao 1, mas adota uma estratégia diferente, ele checa os endereços e não apenas os dados. Isso permite detectar problemas de endereçamento no módulo. Outra diferença é que este teste é feito sem utilizar os caches do processador.
Teste 3 [Moving inv, 8 bit pat, cached]: É aqui que os testes para detectar erros mais complexos começam. O terceiro teste escreve seqüências de dados de 8 bits, repetindo o teste 20 vezes com seqüências diferentes.
Teste 4 [Moving inv, 32 bit pat, cached]: Os dados gravados em cada bit de memória são lidos e movidos para o endereço adjacente. É mais ou menos uma combinação dos tres testes anteriores, pois testa o endereçamento, leitura e escrita de dados. A operação é repetida 32 vezes no total, para testar todas as combinações possíveis.
Este teste detecta um tipo de erro muito comum que é a "contaminação" de endereços. Isto ocorre quando por um defeito de fabricação o isolamento elétrico entre duas ou mais células de memória fica muito fino, permitindo que os elétrons saltem de um para o outro. Isso faz com que ao gravar um dos bits o outro também seja gravado com o mesmo valor. Esse tipo de problema pode ser bastante intermitente, acontecendo apenas quando o segundo bit estiver com um valor zero, ou apenas exporadicamente.
Teste 5 [Block move, 64 moves, cached]: É um pouco mais rigoroso que o teste 4. Continua movendo dados de um endereço para outro da memória, mas agora são movidos blocos de 4 megabits de cada vez. Este teste é repetido 64 vezes.
Teste 6 [Modulo 20, ones&zeros, cached]: Este teste usa um algoritmo diferente, chamado Modulo-X para descobrir defeitos que podem ter sidos marcarados pelos caches ou registradores do processador nos testes anteriores.
Teste 7 [Moving inv, ones&zeros, no cache]: Refaz o teste 6, mas agora desativando completamente os caches. Ele é capaz de detectar mais alguns erros, mas é um pouco mais demorado.
Isto conclui a etapa "básica" do testes, onde os mais demorados são o 4, 6 ou 7. Como disse, esta primeira etapa é relativamente rápidadentro do que se espera de um teste completo de memória. Mesmo num micro com 512 MB o teste não deve demorar mais que uma hora. Esta primeira bateria de testes é suficiente para detectar mais de 90% dos erros, os mais graves que realmente seriam percebidos no dia a dia.
A partir daqui você tem a opção de deixar o programa em loop por mais algum tempo, executando os testes mais duas ou três vezes, ou ativar logo os testes avançados que acabarão com qualquer resquício de dúvida sobre a confiabilidade dos pentes. O teste completo demorou pouco mais de 3 horas no Celeron 900 com 128 MB em que testei. Num micro com muita RAM pode demorar quase um dia inteiro.
Teste 8 [Block move, 512 moves, cached]: Faz a mesma coisa que o teste 5, mas é bem mais longo, repetindo todas as operações 512 vezes ao invés de 64. Demora proporcionalmente mais... :-)
Teste 9 [Moving inv, 8 bit pat, no cache]: Este é semelhante ao teste 3, mas agora realizado com todos os caches desativados e repetido mais vezes, por isso é muito mais demorado.
Teste 10 [Modulo 20, 8 bit, cached]: É uma evolução do teste 6. Ele utiliza o Módulo-X, mas ao invés de simplesmente gravar valores aleatórios nos endereços faz um teste bem mais completo, movendo os dados de várias maneiras de forma a detectar erros mais incomuns.
Teste 11 [Moving inv, 32 bit pat, no cache]: O teste final é semelhante ao teste 4, envolvendo inúmeras operações de leitura e escrita, mas desta vez sem o uso do cache, de forma a eliminar qualquer sombra de dúvida.
Ao detectar um erro, a primeira providencia é trocar o módulo de memória e refazer o teste. Em alguns casos o problema pode não ser no módulo, mas sim na placa mãe. Em alguns casos mais raros pode ser até mesmo que tanto o módulo quanto a placa estejam bons, e o problema seja apenas algum tipo de incompatibilidade entre eles. Eu observei isso na Tyan Tiger MPX que havia analisado no final do ano passado. A placa só ficou completamente estável com o terceiro pente de memória que testei.
Um dos motivos é que esta placa utiliza um valor CAS de 2.5 tempos ao invés dos dois 2 ou 3 tempos freqüentemente usados. Muitos módulos parecem ter problemas para trabalhar neste ritmo. Assim como ela, muitas outras placas utilizam configurações incomuns, que podem causar incompatibilidades com memórias de algumas marcas. Jamais jogue fora um pente com erros antes de testá-lo em outra placa mãe diferente, pois ele pode estar bom.
Finalmente, chegamos à questão final.. o que fazer com módulos que apresentam defeitos no teste? Naturalmente você não vai usa-los num micro de trabalho, mas dependendo da severidade do problema você ainda pode aprovetá-los numa máquina que será usada apenas para aplicativos leves. Se você tem um módulo de 256 MB que apresenta um defeito nos últimos 64 MB por exemplo, significa que você estará bem enquanto o sistema operacional estiver utilizando até 196 MB de RAM, o que dá pra fazer muita coisa.
Pode ser ainda que você queira um micro só para assistir vídeo e ouvir MP3 por exemplo, duas aplicações onde a integridade dos dados não é assim tão fundamental. Neste caso o problema pode até passar despercebido.
No Linux você pode especificar a quantidade de memória que será usada pelo sistema, fazendo com que ele ignore o restante. Esta fica foi enviada pelo MaxMoura:
"Tive um problema muito grave em minha máquina Linux e, por um conjunto de infelicidades, não tive acesso a outro pente. Minha simples solução foi indicar ao cerne ("kernel") do Linux que a máquina teria apenas 64 MB de RAM, e não 256 MB. Bastou adiciar "mem=64mb" às configurações do carregador (LILO, GRUB). Evidentemente a máquina ficou mais lenta em função de recorrer à memória swap muito antes, mas ao menos foi suficiente para não parar a máquina. Creio que esta sugestão poderia ser citada como solução temporária em caso de, por exemplo, os últimos 64 MB de memória estarem comprometidos."
Início 
