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

[rollingbits (a.k.a. Lucas)]

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
-------------- Próxima Parte ----------
Um anexo não texto foi limpo...
Nome  : não disponível
Tipo  : application/pgp-signature
Tam   : 196 bytes
Descr.: não disponível
Url   : http://www.fug.com.br/historico/html/freebsd/attachments/20120104/9ae78e0f/attachment.bin