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

[Luiz Otavio O Souza]

On Jan 4, 2012, at 9:45 PM, rollingbits (a.k.a. Lucas) wrote:

> 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.
> 


Tanto no aquecimento da CPU quanto na falha aleatoria de bits da RAM os resultados são imprevisíveis... um único bit que tem seu valor alterado pode resultar nos mais diversos (e estranhos) problemas.

Uma vez corrompida a memória (e como você falou, realmente não há tanta diferença entre dados e programas, os dois estão - ou estavam - na memória), não se pode executar mais nada, não há como saber ou prever o que mais foi afetado, se o proprio programa em execução tem condições ou não de continuar... dai a única solução é o panic().

A lentidão nas CPUs modernas quando há o sobre aquecimento é por conta da forma de controlar o aquecimento dos chips, pois basta reduzir o clock para que a temperatura (e o consumo da CPU) também reduza. A CPU esta fria ? clock++ : clock--;

Embora seja raro ver CPUs derretendo nos dias de hoje, esse controle nem sempre consegue atuar a tempo de evitar corrupções dos dados (e algumas marcas são melhores que outras... CPUs de outras arquiteturas também não costumam ter esse tipo de proteção - mips, arm, ppc - então não conte com ela para nada que não seja evitar que seu processador derrata :)

Att.,
Luiz


> 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