Eu também sou dos tempos velhos, em que memórias EDO de 72 vias dos 386 ou 486 com defeito faziam o sistema reiniciar, imprimir caracteres estranhos na tela....
Enfim, problema de hardware é um saco diagnosticar, a melhor maneira é ir trocando peça por peça até descobrir, eu já peguei um problema medonho em que um BSD 6.x reiniciava/travava e no final a IBM(depois de me mandar instalar Linux ou Windows "certificados" - já que eles não acreditavam - assim como eu - que o problema era físico) descobriu que era um cabinho de 10cm que ligava o backplane á placa mãe, mas até descobrirem isto trocaram praticamente tudo da máquina. Já presenciei também problemas de cabo IDE que estavam sem isolamento(desencapou devido ao contato com o metal) e fazia o BSD acusar erro de I/O, enfim, em se tratando de hardware, principalmente se for xingling montado no paraguay tudo pode :-) Em 04/01/12 22:29, Eduardo Schoedler escreveu: > Nao acho difícil ser superaquecimento, sou do tempo que placa-mãe > simplesmente reiniciava o pc qdo atingia os valores configurados na bios, > > -- > Eduardo Schoedler > Enviado via iPhone > > Em 04/01/2012, às 21:45, "rollingbits (a.k.a. Lucas)"<rollingb...@gmail.com> > escreveu: > >> On Wed, Dec 28, 2011 at 07:52:40PM -0200, nervoso wrote: >>> Se o reboot ocorre quando na compressao/descompressao.. entao o >>> problema é overheat de CPU... tenta ver no bios qual a temperatura >>> maxima permitida... pode ser problema de memoria tb... (retire um >>> pente de memoria e tente denovo...) >> Desculpe minha (falta de) imaginação mas eu não consigo imaginar um >> sistema re-iniciando espontâneamente por causa de >> super-aquecimento. Também não acho fácil este comportamento vir de >> memória danificada. >> >> Eu sei que quando um sistema super-aquece, a temperatura de superfície >> do CPU sai da sua faixa de trabalho (prá mais). Daí, em CPUs modernas, >> um sub-circuito entra em ação e trava (e não re-inicia) o sistema >> todo. O sistema volta a funcionar como antes quando a temperatura de >> superfície diminui mas, no geral, o que se observa é uma queda no >> desempenho, não re-inicios. Em CPUs antigas, a temperatura pode >> continuar subindo (quer dizer, se o circuito não parar de funcionar, >> ele vai continuar emitindo sinais mas estes não terão correspondência >> com as entradas) e o que se observa é que o sistema trava de vez (nem >> botão resolve). Se um CPU destes ficar aquecido assim tempo de mais >> ele pode ficar danificado permanentemente (as estruturas internas >> derretem) ou até pegar fogo. >> >> Memória danificada causa perda de dados, não re-inícios. Na verdade os >> bits de dados não são assim, tão diferentes dos bits de programas e os >> dois ficam igualmente sujeitos ao problema mas o software já é >> desenvolvido para lidar com um pouco disto e, o resultado geral é a >> perda de dados: programas podem parar de funcionar, passam a ter >> comportamento estranho, crash dumps espontâneos e inexplicáveis além >> dos re-inícios. >> >> Mas neste último ponto, eu ainda devo lembrar que um re-início como o >> descrito ocorre sempre que o kernel não sabe o que fazer. Ele >> normalmente consegue fazer mais que o descrito mas o que faz um >> sistema re-iniciar é quando o kernel não sabe o que fazer. Funciona >> assim: sempre que o kernel encontra uma situação imprevista (pode ser >> qualquer coisa: uma resposta estranha, atrazada ou adiantada de >> qualquer coisa; algoritmos de correção de erros normalmente lidam bem >> com bits a mais ou a menos e estes algoritmos são um requisito para >> que o sistema funcione) o kernel chama 'panic()' e esta chamada faz o >> despejo de memória e o re-início. O despejo de memória é feito na >> memória virtual, se tiver espaço. Um script em /etc/rc.d detecta e >> chama o construtor do arquivo core no próximo início. Este arquivo >> core acaba num subdiretório do /var (/var/crash). >> >> Mensagens de erro são geradas sempre que ocorre um erro, não só >> durante o panic()... e acabam ecoadas, na maioria dos casos, em algum >> arquivo debaixo de /var/log. As pessoas que programaram o panic() o >> fizeram porque, dada a natureza do kernel, não existe nada mais a ser >> feito se o mesmo entrar em qualquer beco sem saída: panic(), caso >> fique sem resposta. >> >> Por falar em mensagens de erro, se for possível, seria bom ler as >> mensagens do dmesg e também dos scripts do rc.d: quando o inicio >> ocorre, qualquer problema é reportado nelas. Pode ter alguma dica do >> porque que os core não estão sendo gerados depois do panic(). Talvez >> seja necessário esperar pelo próximo panic() para ler as mensagens de >> erro que vão aparecer durante o início imediatamente após. >> >>> O unico problema que tive foi em um dell dual xeon 6 cores, em que a >>> controladora trava de vez em quando... e é preciso resetar o sistema >>> no botao... A Dell diz que nao tem nada com isso pois FreeBSD não é >>> homologado. e o cliente pagou R$8000 (oito mil) pela maquina... >> ... então... quando vc diz vc, vc quer dizer seu cliente (não vc), né? >> Aliás, R$8k é uma pechincha, especialmente para um servidor. Da última >> vez que o Papai Noel bateu na minha porta e perguntou o que eu queria >> de Natal disse que queria um workstation que não saia por menos de >> US$10k... foi a bastante tempo e ainda estou esperando. >> >> -- >> rollingbits -- rollingb...@gmail.com, rollingb...@terra.com.br >> luca...@ig.com.br, rollingb...@yahoo.com, rollingb...@globo.com >> Get my public GPG key in http://rollingbits.tripod.com/mykey.html >> ------------------------- >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
