Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Agora, caso for comprar um servidor novo numca compre IBM parador
FreeBSD, fui num cliente instalar um para ser servidor
banco de dados postgresql, a controladora reconhecia as vezes travava
e por ai vai.
Em 5 de janeiro de 2012 22:40, Paulo Henrique paulo.rd...@bsd.com.br escreveu:
Ainda querem alimentar um troll, cara, na boa, não confie em hardware, leva
anos para faze uma atualização.
Tenha sempre e mente que o pior é o que menos chama a atenção.
Chigling pode ser uma pessima escolha mais é o que o que resta antes de
gastar 20K de reais.
Se não gostou do resultado instala o seu windows ficaremos felizes com
menos um troll e você por não passar por um completa idiota !!!.
Bsd é para quem conhece hardware e software e não apenas software.
Att Paulo.Rddck !!!
Em 5 de janeiro de 2012 15:24, rollingbits (a.k.a. Lucas)
rollingb...@gmail.com escreveu:
On Thu, Jan 05, 2012 at 09:26:19AM -0200, Luiz Otavio O Souza wrote:
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.
Mas é exatamente este o ponto: o email original fala só em re-inícios:
sem perda de dados, sem letras estranhas ou outros bugs.
att,
--
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
--
:=)BlatterMaster(=:
#include stdio.h
char device[10] = '/dev/null'
void main(void) { printf(flamers %s,device); exit 0; }
Se não sabe o que está escrito ai acima, por favor não resposda !!
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
Alessandro de Souza Rocha
Administrador de Redes e Sistemas
FreeBSD-BR User #117
Long live FreeBSD
Powered by
(__)
\\\'',)
\/ \ ^
.\._/_)
www.FreeBSD.org
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
watchdog por hardware ? Em 4 de janeiro de 2012 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 -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
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,
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
On Thu, Jan 05, 2012 at 09:26:19AM -0200, Luiz Otavio O Souza wrote: 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. Mas é exatamente este o ponto: o email original fala só em re-inícios: sem perda de dados, sem letras estranhas ou outros bugs. att, -- 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 pgpe68XHofkjS.pgp Description: PGP signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Ainda querem alimentar um troll, cara, na boa, não confie em hardware, leva
anos para faze uma atualização.
Tenha sempre e mente que o pior é o que menos chama a atenção.
Chigling pode ser uma pessima escolha mais é o que o que resta antes de
gastar 20K de reais.
Se não gostou do resultado instala o seu windows ficaremos felizes com
menos um troll e você por não passar por um completa idiota !!!.
Bsd é para quem conhece hardware e software e não apenas software.
Att Paulo.Rddck !!!
Em 5 de janeiro de 2012 15:24, rollingbits (a.k.a. Lucas)
rollingb...@gmail.com escreveu:
On Thu, Jan 05, 2012 at 09:26:19AM -0200, Luiz Otavio O Souza wrote:
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.
Mas é exatamente este o ponto: o email original fala só em re-inícios:
sem perda de dados, sem letras estranhas ou outros bugs.
att,
--
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
--
:=)BlatterMaster(=:
#include stdio.h
char device[10] = '/dev/null'
void main(void) { printf(flamers %s,device); exit 0; }
Se não sabe o que está escrito ai acima, por favor não resposda !!
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
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
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
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
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
On 29/12/2011 12:09, Marcelo Gondim wrote: Eu por exemplo não pago R$8.000,00 em um hardware que não vá rodar FreeBSD. Por isso trabalho em conjunto com o meu fornecedor. Se não rodar o sistema de forma estável nós trocamos o equipamento. É o que todo mundo deveria fazer, quando o pessoal descobrir que os clientes estão cancelando as vendas e ouvir isso diretamente do cliente: Não quero porque não roda FreeBSD. algumas vezes eles vão mudar de postura. No começo aposto que com o Linux foi assim. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
On 29/12/2011 23:06, nervoso wrote: Eu por exemplo tomei uma decisao: 2) Dell so se for sem a controladora PERC...(e ai os caras só vendem com a controladora) ai eu mando o cliente tirar a controladora da maquina... e tudo funciona... ele briga com a dell e tudo se resolve... A postura é essa mesmo, fazer barulho por venderem coisa de baixa qualidade. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
A Dell nào homologa Linux e sim RedHat . Qq outra distro que vc usar é por sua conta e risco. Já passei por isto antes. Em 29 de dezembro de 2011 00:38, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... 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...) Eu só uso AMD 4,6 ou 8 cores... e nunca tive problemas... 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... Pois é, isso é a coisa mais idiota que existe. Imagine que o hardware sem o sistema não faz absolutamente nada, então a Dell como maior interessada deveria homologar seu hardware para os diversos sistemas existentes ou pelo menos os que o mercado usa: Linux, Windão e BSDs. Embora Linux seja apenas um kernel. :) De fato se as empresas que compram exigissem a homologação do FreeBSD isso já seria bem diferente hoje. Porque o hardware tem que rodar o sistema do cliente e não o que o fornecedor do hardware quer que ele rode. Isso não existe. Imagine a situação... você vai comprar um aparelho de dvd da Sony e na loja o vendedor lhe diz: ah esse aparelho só vai ler DVDs da Sony, os outros até podem ler mas os da Sony são homologados. Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. Simplesmente a máquina rebootava do nada rodando um FreeBSD 8.2 Stable 64 bits e com Linux ficava normal. Liguei para a Intel e a resposta foi exatamente essa: FreeBSD não é um sistema homologado para rodar nesse equipamento. Os sistemas homologados eram Linux e Windão. No final sabe qual era o problema real? Na configuração da velocidade das Funs eu deixei no máximo. Pronto, o barulho não era tão ruim e em compensação o sistema ficou estável e já tem mais de 80 dias sem dar 1 reboot. Provavelmente os processadores deviam estar aquecendo ou passando de algum valor que causava o reboot. Embora a sala seja muito bem refrigerada alguma coisa relacionada aos Funs estava causando o reboot. Ah! um dos meus servidores está usando a versão 9 64 bits recém atualizada e nenhum problema ainda. É isso ae pessoal, Grande abraço à todos. Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. - 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 -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Isso e verdade quando fui comprar um servidor novo para empresa, a pirmeira coisa que eles te perguntam qual sistema voce vai usar, linux ou windows, ai eles querem te empurrar RedHat ou windows 2008 Server , voce falar em FreeBSD, eles dizem olha nao sei se e compativel. Em 30 de dezembro de 2011 09:56, Otavio Augusto otavi...@gmail.com escreveu: A Dell nào homologa Linux e sim RedHat . Qq outra distro que vc usar é por sua conta e risco. Já passei por isto antes. Em 29 de dezembro de 2011 00:38, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... 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...) Eu só uso AMD 4,6 ou 8 cores... e nunca tive problemas... 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... Pois é, isso é a coisa mais idiota que existe. Imagine que o hardware sem o sistema não faz absolutamente nada, então a Dell como maior interessada deveria homologar seu hardware para os diversos sistemas existentes ou pelo menos os que o mercado usa: Linux, Windão e BSDs. Embora Linux seja apenas um kernel. :) De fato se as empresas que compram exigissem a homologação do FreeBSD isso já seria bem diferente hoje. Porque o hardware tem que rodar o sistema do cliente e não o que o fornecedor do hardware quer que ele rode. Isso não existe. Imagine a situação... você vai comprar um aparelho de dvd da Sony e na loja o vendedor lhe diz: ah esse aparelho só vai ler DVDs da Sony, os outros até podem ler mas os da Sony são homologados. Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. Simplesmente a máquina rebootava do nada rodando um FreeBSD 8.2 Stable 64 bits e com Linux ficava normal. Liguei para a Intel e a resposta foi exatamente essa: FreeBSD não é um sistema homologado para rodar nesse equipamento. Os sistemas homologados eram Linux e Windão. No final sabe qual era o problema real? Na configuração da velocidade das Funs eu deixei no máximo. Pronto, o barulho não era tão ruim e em compensação o sistema ficou estável e já tem mais de 80 dias sem dar 1 reboot. Provavelmente os processadores deviam estar aquecendo ou passando de algum valor que causava o reboot. Embora a sala seja muito bem refrigerada alguma coisa relacionada aos Funs estava causando o reboot. Ah! um dos meus servidores está usando a versão 9 64 bits recém atualizada e nenhum problema ainda. É isso ae pessoal, Grande abraço à todos. Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. - 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 -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Bom é mais que 10% A Fatia de Linux e Windows ainda é bem maior que FreeBSD. E com relação a compatibilidade a Dell faz bastante contribuições ao kernel do linux para mantê-lo compatível com o seu hardware, mas só homologa o RedHat pq tem uma empresa para dar suporte ao software, E tem o linux como opção por causa do seu nome difundido. Muitos Sysadmins que estão saindo do windows ou nunca ouviram falar de *BSDs ou acharam mais fácil ir pro linux por encontrar treinamento/suporte/documentação (howtos) mais fácil do que para outros sistemas. A Dell só está jogando pro lado que o mercado a leva. Para que o FreeBSD entre na jogada ele tem que crescer muito mais em fama e ter empresas grandes divulgando seu nome. Em 29 de dezembro de 2011 13:09, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 29/12/2011 12:33, rollingbits (a.k.a. Lucas) escreveu: On Thu, Dec 29, 2011 at 01:08:27AM -0200, Alexandre Silva Nano wrote: Sinceramente, essa querstão da homologação é pura jogada de marketing não tem como um hardware ser TOTALMENTE compatível com somente um S.O existente num mercado como o de hoje em dia... Complicada essa nossa situação, nesse caso... Em 29 de dezembro de 2011 00:38, Marcelo Gondimgon...@bsdinfo.com.brescreveu: Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... (...) 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... Pois é, isso é a coisa mais idiota que existe. (...) Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. (...) Os sistemas homologados eram Linux e Windão. (...) Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. Eu acho que vcs estão misturando as coisas: equipamentos high end como estes (tipo servidores e estações de trabalho) são otimizados para uma tarefa específica: isto pressupõe o uso de software específico (incluindo o sistema operacional). Vc não pode simplesmente substituir os programas de uma máquina destas e esperar que as coisas funcionem direito o tempo todo: quando a Dell fez o servidor Xeon citado acima, ela começou com a arquitetura meia boca de todo PC... e começou a modificar tanto o hardwere quando o *software* para que a /eficiência/ do conjunto se aproximasse do máximo (100% = 1). Se vc substitui o sistema, tem que lidar com a parte do software! Sistemas podem reiniciar sozinhos por inúmeras razões mas todas elas emitem mensagens informativas e nisto se inclui os casos onde o watchdog fez o serviço. rollingbits Seguindo essa linha de raciocínio continuo afirmando que é burrice da parte deles. O que adianta um hardware que vai atender 10% do comércio? Vamos dizer assim. Todos sabemos que existem diversas empresas que querem o melhor equipamento para o seu setor de TI mas isso não é maioria, muitas empresas procuram o melhor custo x benefício. Procuram hardware confiável e que rode seus sistemas, sistemas esses que podem ter saído muito mais caro que o hardware. De nada adianta gastar R$8.000,00 em um equipamento que vai servir de peso de papel. Continuo afirmando que eles poderiam muito bem homologar seus equipamentos para os sistemas profissionais existentes. Qual seria o custo de baixar um FreeBSD instalar no equipamento deles e fazer alguns testes de dias, semanas para ver como se comporta? Te garanto que seria muito mais interessante para eles ter mais sistemas homologados que ficar reduzido à 1 ou 2. Isso vale para todos os outros Sistemas. Para eles venderia muito mais se tivesse escrito lá: Sistemas homologados: Windows, Linux, BSD que apenas Windows por exemplo. Concordo que hardwares novos, com dispositivos novos não seriam suportados de primeira e não estariam homologados mas tudo é uma questão de tempo e boa vontade dos fabricantes em colaborar em conjunto com as comunidades e empresas que desenvolvem os sistemas. Eu por exemplo não pago R$8.000,00 em um hardware que não vá rodar FreeBSD. Por isso trabalho em conjunto com o meu fornecedor. Se não rodar o sistema de forma estável nós trocamos o equipamento. - 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 -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Em 29/12/2011 12:33, rollingbits (a.k.a. Lucas) escreveu: On Thu, Dec 29, 2011 at 01:08:27AM -0200, Alexandre Silva Nano wrote: Sinceramente, essa querstão da homologação é pura jogada de marketing não tem como um hardware ser TOTALMENTE compatível com somente um S.O existente num mercado como o de hoje em dia... Complicada essa nossa situação, nesse caso... Em 29 de dezembro de 2011 00:38, Marcelo Gondimgon...@bsdinfo.com.brescreveu: Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... (...) 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... Pois é, isso é a coisa mais idiota que existe. (...) Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. (...) Os sistemas homologados eram Linux e Windão. (...) Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. Eu acho que vcs estão misturando as coisas: equipamentos high end como estes (tipo servidores e estações de trabalho) são otimizados para uma tarefa específica: isto pressupõe o uso de software específico (incluindo o sistema operacional). Vc não pode simplesmente substituir os programas de uma máquina destas e esperar que as coisas funcionem direito o tempo todo: quando a Dell fez o servidor Xeon citado acima, ela começou com a arquitetura meia boca de todo PC... e começou a modificar tanto o hardwere quando o *software* para que a /eficiência/ do conjunto se aproximasse do máximo (100% = 1). Se vc substitui o sistema, tem que lidar com a parte do software! Sistemas podem reiniciar sozinhos por inúmeras razões mas todas elas emitem mensagens informativas e nisto se inclui os casos onde o watchdog fez o serviço. rollingbits Seguindo essa linha de raciocínio continuo afirmando que é burrice da parte deles. O que adianta um hardware que vai atender 10% do comércio? Vamos dizer assim. Todos sabemos que existem diversas empresas que querem o melhor equipamento para o seu setor de TI mas isso não é maioria, muitas empresas procuram o melhor custo x benefício. Procuram hardware confiável e que rode seus sistemas, sistemas esses que podem ter saído muito mais caro que o hardware. De nada adianta gastar R$8.000,00 em um equipamento que vai servir de peso de papel. Continuo afirmando que eles poderiam muito bem homologar seus equipamentos para os sistemas profissionais existentes. Qual seria o custo de baixar um FreeBSD instalar no equipamento deles e fazer alguns testes de dias, semanas para ver como se comporta? Te garanto que seria muito mais interessante para eles ter mais sistemas homologados que ficar reduzido à 1 ou 2. Isso vale para todos os outros Sistemas. Para eles venderia muito mais se tivesse escrito lá: Sistemas homologados: Windows, Linux, BSD que apenas Windows por exemplo. Concordo que hardwares novos, com dispositivos novos não seriam suportados de primeira e não estariam homologados mas tudo é uma questão de tempo e boa vontade dos fabricantes em colaborar em conjunto com as comunidades e empresas que desenvolvem os sistemas. Eu por exemplo não pago R$8.000,00 em um hardware que não vá rodar FreeBSD. Por isso trabalho em conjunto com o meu fornecedor. Se não rodar o sistema de forma estável nós trocamos o equipamento. - 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
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
On Thu, Dec 29, 2011 at 01:08:27AM -0200, Alexandre Silva Nano wrote: Sinceramente, essa querstão da homologação é pura jogada de marketing não tem como um hardware ser TOTALMENTE compatível com somente um S.O existente num mercado como o de hoje em dia... Complicada essa nossa situação, nesse caso... Em 29 de dezembro de 2011 00:38, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... (...) 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... Pois é, isso é a coisa mais idiota que existe. (...) Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. (...) Os sistemas homologados eram Linux e Windão. (...) Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. Eu acho que vcs estão misturando as coisas: equipamentos high end como estes (tipo servidores e estações de trabalho) são otimizados para uma tarefa específica: isto pressupõe o uso de software específico (incluindo o sistema operacional). Vc não pode simplesmente substituir os programas de uma máquina destas e esperar que as coisas funcionem direito o tempo todo: quando a Dell fez o servidor Xeon citado acima, ela começou com a arquitetura meia boca de todo PC... e começou a modificar tanto o hardwere quando o *software* para que a /eficiência/ do conjunto se aproximasse do máximo (100% = 1). Se vc substitui o sistema, tem que lidar com a parte do software! Sistemas podem reiniciar sozinhos por inúmeras razões mas todas elas emitem mensagens informativas e nisto se inclui os casos onde o watchdog fez o serviço. rollingbits -- 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 pgpI1F9LXIiYG.pgp Description: PGP signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Eu não sou o autor (óbvio), mas, pelo Google, On Mon, Dec 26, 2011 at 05:44:52PM -0200, Paulo Pires wrote: baseado numa placa-mãe Intel D525MW, com 4GiB de RAM e dois HDs Samsung de 1.5TB) usando ZFS nativo com mirror dos dois HDs. a placa mãe é (originalmente) de desktop [1] e aceita processadores Atom de 64 bits (modelo D525) [2]. 9.0-RC3 ... http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror, faznedo apenas as adaptações necessárias por estar usando um CD em vez de USB stick, e por estarem os pacotes de instalação em local diferente. ... As perguntas que faço, então, são: 1) Alguém tem alguma informação sobre problemas conhecidos de estabilidade do ZFS no 9.0-RC3 (ou do próprio 9.X)? http://www.freebsd.org/cgi/query-pr-summary.cgi?query é seu amigo... 2) Alguém com experiência em ZFS tem dicas sobre tuning, especialmente de parâmetros ligados a compressão e/ou deduplicação (talvez envolvendo parâmetros de memória do SO)? Minha dica seria $ man -a tuning e [3] mas eu não tenho experiência com ZFS. Experimentei bastante quase todo o resto mas não ZFS. 3) Alguma dica para que eu consiga pegar informação de depuração que seja útil, quer ao vivo, quer post mortem? O primeiro ponto é isolar um caso *reproduzível* do problema: se funciona algumas vezes e não outras você não está com um problema reproduzível (ports.txz e src.txz são arquivo bem grandes... e se ocorreu antes e ocorre depois eles podem não estar diretamente relacionados com o problema). Casos bons são pequenos e pontuais. No seu caso, ele deveria fazer o sistema re-iniciar imediatamente... O FreeBSD vem com várias ferramentas de depuração mas eu imagino que você deva começar lendo [4] (depois de ter lido [3]): O kdb/ddb vc já citou; também tem dtrace, kgdb, gdb, ... Referências: [1] http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-d525mw.html [2] http://ark.intel.com/pt-br/products/49490/Intel-Atom-processor-D525-%281M-Cache-1_80-GHz%29 [3] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ [4] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ -- 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 pgpaiiUQ29t75.pgp Description: PGP signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Eu por exemplo tomei uma decisao: 1) NUNCA comprar ACER 2) Dell so se for sem a controladora PERC...(e ai os caras só vendem com a controladora) ai eu mando o cliente tirar a controladora da maquina... e tudo funciona... ele briga com a dell e tudo se resolve... 3) Sempre comprar AMD... 4,6, ou 8 cores.. 4) chipset nvidia ou AMD... 5) montar a maquina e enviar ao cliente... 6) sempre usar MIRROR no ZFS Depois é só montar o FreeBSD, ZFS, e ser feliz. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... 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...) Eu só uso AMD 4,6 ou 8 cores... e nunca tive problemas... 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... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... 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...) Eu só uso AMD 4,6 ou 8 cores... e nunca tive problemas... 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... Pois é, isso é a coisa mais idiota que existe. Imagine que o hardware sem o sistema não faz absolutamente nada, então a Dell como maior interessada deveria homologar seu hardware para os diversos sistemas existentes ou pelo menos os que o mercado usa: Linux, Windão e BSDs. Embora Linux seja apenas um kernel. :) De fato se as empresas que compram exigissem a homologação do FreeBSD isso já seria bem diferente hoje. Porque o hardware tem que rodar o sistema do cliente e não o que o fornecedor do hardware quer que ele rode. Isso não existe. Imagine a situação... você vai comprar um aparelho de dvd da Sony e na loja o vendedor lhe diz: ah esse aparelho só vai ler DVDs da Sony, os outros até podem ler mas os da Sony são homologados. Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. Simplesmente a máquina rebootava do nada rodando um FreeBSD 8.2 Stable 64 bits e com Linux ficava normal. Liguei para a Intel e a resposta foi exatamente essa: FreeBSD não é um sistema homologado para rodar nesse equipamento. Os sistemas homologados eram Linux e Windão. No final sabe qual era o problema real? Na configuração da velocidade das Funs eu deixei no máximo. Pronto, o barulho não era tão ruim e em compensação o sistema ficou estável e já tem mais de 80 dias sem dar 1 reboot. Provavelmente os processadores deviam estar aquecendo ou passando de algum valor que causava o reboot. Embora a sala seja muito bem refrigerada alguma coisa relacionada aos Funs estava causando o reboot. Ah! um dos meus servidores está usando a versão 9 64 bits recém atualizada e nenhum problema ainda. É isso ae pessoal, Grande abraço à todos. Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. - 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
Re: [FUG-BR] ZFS no FreeBSD-9.0-RC3 causando reboots espontâneos
Sinceramente, essa querstão da homologação é pura jogada de marketing não tem como um hardware ser TOTALMENTE compatível com somente um S.O existente num mercado como o de hoje em dia... Complicada essa nossa situação, nesse caso... Em 29 de dezembro de 2011 00:38, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 28/12/2011 19:52, nervoso escreveu: Boa Noite Paulo... Voce esqueceu de dizer qual a arquitetura do seu sistema (32 ou 64 bits). o que é muito importante no caso do zfs... Eu uso somente 64 bits já ha muito tempo, inclusive o ultimo 9.0 RC3... e sem problemas algum ... 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...) Eu só uso AMD 4,6 ou 8 cores... e nunca tive problemas... 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... Pois é, isso é a coisa mais idiota que existe. Imagine que o hardware sem o sistema não faz absolutamente nada, então a Dell como maior interessada deveria homologar seu hardware para os diversos sistemas existentes ou pelo menos os que o mercado usa: Linux, Windão e BSDs. Embora Linux seja apenas um kernel. :) De fato se as empresas que compram exigissem a homologação do FreeBSD isso já seria bem diferente hoje. Porque o hardware tem que rodar o sistema do cliente e não o que o fornecedor do hardware quer que ele rode. Isso não existe. Imagine a situação... você vai comprar um aparelho de dvd da Sony e na loja o vendedor lhe diz: ah esse aparelho só vai ler DVDs da Sony, os outros até podem ler mas os da Sony são homologados. Outro dia mesmo comprei um Servidor todo Intel com processador Xeon, memória ECC tudo que tem direito. Simplesmente a máquina rebootava do nada rodando um FreeBSD 8.2 Stable 64 bits e com Linux ficava normal. Liguei para a Intel e a resposta foi exatamente essa: FreeBSD não é um sistema homologado para rodar nesse equipamento. Os sistemas homologados eram Linux e Windão. No final sabe qual era o problema real? Na configuração da velocidade das Funs eu deixei no máximo. Pronto, o barulho não era tão ruim e em compensação o sistema ficou estável e já tem mais de 80 dias sem dar 1 reboot. Provavelmente os processadores deviam estar aquecendo ou passando de algum valor que causava o reboot. Embora a sala seja muito bem refrigerada alguma coisa relacionada aos Funs estava causando o reboot. Ah! um dos meus servidores está usando a versão 9 64 bits recém atualizada e nenhum problema ainda. É isso ae pessoal, Grande abraço à todos. Sem noção esse pessoal da Dell, Intel e todos que tem essa postura. - 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 -- Att, Alexandre Silva Nano Tecnólogo em Gestão de Redes de Computadores, UNIFACS Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified Specialist - NAC www.ideiadigital.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
