O Supermicro X9SCA-F não será mais POST

2

Eu tenho cerca de 20 anos de experiência na construção de sistemas (principalmente para mim), mas nunca vi uma coisa assim:

Desde cerca de 3 anos, eu tenho um Xeon 1230V2 em um Supermicro X9SCA-F rev 1.01 e 32GiB ECC RAM como minha estação de trabalho / gamestation. A utilização foi relativamente baixa em geral, por vezes, houve alguns períodos de codificação ou jogos mais pesados. Sempre foi estável em rock. Não é o menor hickup de todos os tempos.

Na semana passada, fiz uma atualização & & atualizar na minha instalação do Debian Jessie. Nada muito especial lá, mas um novo pacote do kernel fazia parte dessa atualização. Na próxima reinicialização, notei que mover as janelas no X é bastante lento, acho que devo ter esquecido de compilar o fglrx para minha GPU AMD novamente. Estranhamente, o módulo do kernel já estava carregado. Eu decidi compilá-lo novamente de qualquer maneira, e reiniciei no modo de resgate para fazer isso em um terreno limpo. Eu não obtive um console de resgate, o init pareceu bem-sucedido, mas não houve sessão de terminal aberta para mim. Em geral, desde a atualização para Jessie, algumas partes menores não funcionam como planejadas (talvez porque eu mudei de volta para o sysvinit).

De qualquer forma, eu reiniciei e mudei o init para / bin / sh para tentar isso. De repente, um kernel em pânico, e depois de alguns segundos, um reboot. Eu realmente não consigo me lembrar do que o pânico estava dizendo, foi rápido demais. Monitor fica preto. Eu aperto o botão de reset, ainda em branco. Desligue, espere, tente novamente - preto. Resumindo: desde o pânico do kernel, o sistema não está mais colocando POST. Fãs start-up, IPMI é acessível (eu posso ver o sistema de bicicleta através de alguns códigos POST - não tenho certeza qual é a média como eu não consigo encontrar uma referência confiável), mas nenhum sinal sonoro e nenhum display. Eu removi tudo, pedi RAM, mudei a PSU, removi a placa do gabinete, limpando o CMOS, limpando-a durante a noite, CTRL-HOME, DEL / INSERT, ... nada ajuda.

O que é especialmente estranho, além do fato de que init = / bin / sh leva a um kernel panic que leva a um sistema não POSTing: Se eu remover toda a memória, a placa ainda não está apitando. Então, eu só posso suspeitar que há danos graves ao hardware, mas ainda não entendi a conexão causal.

Eu pedi uma nova diretoria, não da Supermicro, pois eles negam a RMA (como a Amazon depois de mais de 2 anos) e têm uma garantia de apenas 1y.

Alguma idéia se a placa ou a CPU pode ser torrada? Como o controlador de memória está na CPU, não tenho certeza de quem é o responsável por não bipar se nenhuma RAM estiver conectada. Espero que não seja a CPU, já que o mesmo modelo é hoje 30% mais caro que o final de 2012! / p>

Alguma idéia sobre o que eu poderia tentar?

    
por tmr 28.10.2015 / 08:34

0 respostas