E então pessoal. Eis a questão:

Como travar um Phenom? Não sei como fazê=lo chegar a 100% de uso em todos os cores e, então, venho aqui pedir ajuda para finalmente eu ver o que é o bug na TLB.

Segundo o Paulo Couto:


Então, como faço para atingir 100% de uso nos 4 cores se o amigo Marcos Antonio disse que:


Há algum programa que faça acontecer o BUG na TLB? Se eu executar várias aplicações cada uma com apenas um core eu consigo ver o bug acontecer?

Não faltam programas que usem todo o potencial do processador, mas normalmente são para fins de testes de estabilidade ou para avaliar o desempenho do processador. Tenta rodar o Orthos, Cinebench ou mesmo 4 super pi ao mesmo tempo (selecionando no gerenciador do windows um para cada nucleo).

Fiquei curioso quanto a essa falha também !


EDIT: Erro de portugues corrigido.

Tenta abrir quatro programas desses ao mesmo tempo e observe no gerenciador de tarefas se vai usar 100% da CPU:

prime95 (testar desempenho/estabilidade), cpu burn-in (calcular aquecimento), super pi (calcular resultados) etc...

Tem vários tópicos sobre esses programas aqui, mas tenta dar uma olhada nesse link aqui http://forum.cgartdomain.com/index.php?showtopic=4235

Posta aí os resultados depois, pois acredito que a galera aqui vai ficar curiosa

é facil, abre 4 super pi ou 1 orthos (que roda o prime em todos os cores ao mesmo tempo)...............

rode o orthos por umas 12 horas para ver...

Não sei se você conseguirá ver o problema só usando SuperPI, Prime e similares. Pelo que eu li sobre o assunto, o erro (travamento do sistema) ocorre em condições específicas de uso do cache L3 e parece que ocorre com mais frequência quando se está usando algum software de virtualização. Para entender melhor, vale a pena ler o artigo Understanding AMD's "TLB" Processor Bug. Vou citar aqui as partes importantes:



Segundo o Revision Guide for AMD Family 10h Processors, página 22:



Se você não conseguir nada usando os programas citados pelos colegas acima, tente usar o VMware Server ou o Virtual PC, crie 4 máquinas virtuais e rode o SuperPI ou o Prime em cada uma delas. Vamos ver se o bug "dá as caras"

[]'s

100% de uso em todos os cores? Olha, se tivesse um à mão, acho que seria fácil conseguir isso. Bastaria rodar o Virtualdub, o TMPEGEnc, e duas sessões do DVDShrink ao mesmo tempo, atribuindo a afinidade de cada um para um núcleo específico. Quero ver se os quatro não vão ficar em 100% ao mesmo tempo

Phenom travando? Resultado dos testes:

Olá amigos do fórum!

Primeiramente quero agradecer a todas as sugestões dadas e dizer que o teste até me surpreendeu, pois ocorreram dois fatos inesperados.

Outra observação:



Correto. Eu não vou especificar logo de cara o ocorrido, para dar aquele suspense bacana, mas de fato, não consegui achar a parte de "menos freqüencia" de ocorrência do bug, ou seja, só encontrei-o emulando VMs.

Bem amigos, vamos ao teste!

Teste 1 - Super PI, Shrink e WinRAR

Para saturar a CPU totalmente sem nem dar picos de uso abaixo de 100%, apliquei em cada um dos cores a execução do Super PI no cálculo de 32M. Logicamente, foram 4 Super PI, cada um sendo executado por um core simultaneamente. Para completar, fiz outras compactações pelo WinRAR e algumas conversões de vídeo pelo DVD Shrink (obrigado pela dica), só para me certificar que a CPU não saíra de modo algum do 100% de uso.

Resultado: 100% de uso nos 4 cores e nada de bug.

Teste 2 - Teste 1 + Benchmark de caches

Simulando o teste anterior para estressar a CPU, com o PC Wizard, fiz um benchmark nos caches.

Resultado: 100% de uso nos 4 cores e nada de bug.

Teste 4 - Prime95

Com o Prime95, executei uma instância para cada core simultaneamente. Este teste foi tedioso: durou mais de 6 horas e nada aconteceu além de a CPU permanecer bem estressada.

Resultado: 100% de uso nos 4 cores e nada de bug e uma decepção grande por perder 1/4 do dia com este teste.

Teste 5 - VM 1

Com o VM Ware, criei e emulei uma VM comum com o Windows Vista HP de 64bits. Nesta VM emulei todos os testes anteriores, exceto o 4°. Em todos os testes de VMs, o meu sistema hospedeiro é de 64bits.

Resultado: 100% de uso nos 4 cores e nada de bug.

Teste 6 - VM 2

Com o VM Ware, criei e emulei uma VM comum com o Windows Vista HP de 32bits. Nesta VM emulei todos os testes anteriores até o 3°. Um fato curioso aconteceu: o computador reiniciou e o arquivo que foi a VM emulada se corrompeu. Segundo o log de eventos do Windows, o problema foi na aplicação "svchost.exe", o que me pareceu curioso, pois nunca havia ocorrido tal.

Resultado: Não atingi 100% de uso nos 4 cores, o bug não ocorreu e algo que eu nem tinha percebido me ocorreu: a única VM de 32bits que não consigo emular sobre a de 64bits é a do Vista HP. Já mudei o disco de instalação, utilizei outro, verifiquei o hardware, etc. Nada de errado.
Off-Test=Alguém pode me dar uma explicação sobre isso?

Teste 7 - VM 3

Com o VM Ware, criei e emulei duas VMs comuns com o Windows Vista Ultimate de 64bits. Nestas VMs emulei todos os testes até o 3°, mas defini dois cores por VM.

Resultado: 100% de uso nos 4 cores e nada de bug.

Teste 8 - VM 4

Com o VM Ware, criei e emulei quatro VMs comuns com o Windows Vista Ultimate de 64bits. Nestas VMs emulei todos os testes até o 3°, mas defini um core por VM.

Resultado: És tu BUG?

No teste 8, a CPU reiniciou espontaneamente quando, segundo o gerenciador de tarefas do sistema hospedeiro, os Cores 1# e 4# atingiram 100% de uso, o #2 com cerca de 50% e o terceiro com pouco mais de 80% de uso. Começei emulando os testes na 3ª VM.
Vasculando os 5 logs de eventos do Windows (hospedeiro + 4 VMs), não achei absolutamente nenhuma informação sobre o porquê o sistema foi reiniciado.

Só por uma feliz curiosidade, desabilitei o Cool'n' Quiet e fui para a bateria de testes número 9. (PS.: Já eram altas horas e eu estava caindo sobre o teclado!)

Teste 9 - VM 4 sem Cool'n'Quiet

Neste teste eu repeti exatamente o que fiz no teste 8, mas o Cool'n'Quiet permaneceu desabilitado todo o tempo.

Resultado: 100% de uso nos 4 cores e nada de bug.

Por mais estranho que pareça (apesar de não conseguir nem mais raciocinar devido ao sono), percebi que sem o Cool'n'Quiet a CPU executou todas as tarefas normalmente.

Fui dormir.

Logo pela manhã executei mais algums testes como o 9° usando o Prime 95 e todos os demais programas sem o Cool'n'Quiet. E o bug? Se assustou e foi embora? Acho que sim... Cheguei ao uso total dos 4 cores e não aconteceu nada, mas como emular 4 VMs não é tarefa fácil, facilmente atingi esta utilização de CPU.

Conclusão:

4 VMs + Cool'n'Quiet = BUG

Muito obrigado pelas dicas. Espero que eu consigo achar uma respota ao problema no teste 6, pois pesquisei muito e nada encontrei. Fora esta anomalia, o bug só ocorreu na situação 8.

Em todos os testes, eu descarto completamente a possibilidade de aquecimento. Troquei meu coolerzinho box (que nunca me deixou na mão) por um watercooler de um amigo (obrigado Fábio!) e com o CPU Burn-in (obrigado pela recomendação Dan.F! Eu carecia deste programa) a temperatura não passou dos 48°. Como nunca usei um watercooler antes, nem um programada de log de aquecimento, não sei dizer se esta temperatura é muito alta para um sistema melhorado de resfriamento como este em relação ao meu anterior.

Caso haja algum erro de grafia ou interpretação, por favor, não deixem de me avisar para que eu faça a correção o mais rápido possível.

E se ele tiver reiniciado não por causa do bug, mas por causa de alguma incompatibilidade entre o CnQ e o VMWare?

Ou takvez você achou outro bug

Impossível.

Todos os testes anteriores, até o 8° eu rodei com o C'n'Q ativado.

Não houve problema algum.

Schakal, ainda não estou certo se vimos a cara do bug, talvez tenhamos que prosseguir na caçada . A sua motherboard é uma ASUS M3A certo? Qual a versão de BIOS dela? No site da ASUS só existe a versão 0301, marcada como "Initial release". A sua é a mesma? Será que ela já não está com o "patch do TLB" aplicado? Pois os fabricantes de motherboard o estão implementando sem possibilidade de desativação pelo usuário. No entanto, li que é possível desabilitá-lo com o AMD OverDrive 2.0.12 ou superior, ativando uma opção chamada "Turbo". Seria interessante que você fizesse um benchmark (especialmente da vazão de memória) do sistema atual e com o OverDrive nesse modo "Turbo" para ver se há alguma diferença de desempenho. Se houver, pode ser que sua BIOS já tenha o "patch do TLB" e então seria interessante repetir os testes usando o OverDrive para desabilitá-lo e ver o que acontece.

Quanto ao erro do Teste 6, não acredito que seja o bug, mas algum driver/software incompatível desse disco da HP. O melhor mesmo seria usar instalações limpas, somente com o VMware Tools. Você não conseguiu mais entrar nessa VM por que o VMware não deixa ou por que o Windows não carrega?

Por fim, seria interessante, no host e nas VMs, desativar a Reinicialização automática, para que você pudesse ver se a reincialização era por causa de um erro de STOP ou se foi uma reinicialização sumária, pois dependendo do erro de STOP, pode ser que nem tenha sido possível gravá-lo nos eventos do sistema.