[FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos

[Renato Frederick]

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)"<rollingbits em 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 -- rollingbits em gmail.com, rollingbits em terra.com.br
>> lucasnm em ig.com.br, rollingbits em yahoo.com, rollingbits em 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