BSOD 0x09c em 50 máquinas SuperMicro


8

Para um projeto, temos 50 servidores, todos equipados (geralmente) com o mesmo hardware. O problema que temos aqui é muito sério e acontece em todas as máquinas. Apesar de muito esforço e do contato com os fabricantes e os desenvolvedores de software, todos apontam um para o outro e até se recusam a me dar uma pista sobre o que está acontecendo.

Primeiro, deixe-me descrever a configuração. Este é o hardware 'servergrade'. Para minha primeira experiência, servergrade é a maior decepção da minha vida.

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540 (incorporado na placa-mãe)
  • Caixa 1U personalizada ou caixa original SuperMicro
  • PSU de servidor de 480 watts ou PSU original SuperMicro de 200 watts
  • SSD Samsung Evo 850 de 500 GB
  • DDR4-2133 ECC ou NÃO ECC de 32 GB (mas não misturado no mesmo servidor)
  • GPU Asus GT730 DDR3 de 4 GB
  • A GPU é montada com uma placa riser PCIe (sem fita), sem nome da China ou do SuperMicro original

Executando no sistema - Windows Server 2012 R2 Enterprise - VMWare Workstation 12 - Tarefas intensivas de execução de GPU da VM - Este sistema é estoque, não há over / underclocking

Sintomas - Aleatório BSOD 0x09c (também conhecido como Machine_Check_Exception): às vezes o sistema é executado por uma semana sem problemas, às vezes em falhas após apenas 10 minutos, mas na maioria das vezes é executado por algumas horas.

Já experimentado / verificado:

  • BIOS atualizado para a versão mais recente (acho que agora isso melhorou o tempo para o sistema ficar estável, mas isso poderia ter sido aleatório).
  • Windows atualizado para a versão mais recente.
  • VMWare atualizado para a versão mais recente.
  • Trocou todos os componentes e tentou todas as opções diferentes, até tentou uma ATU PSU de mesa e SSD M.2.
  • Instalou todos os sistemas do zero com o Ubuntu. Eu não estou familiarizado com o Linux e nunca vi um BSOD do Linux e ainda não o vi, pois os sistemas de servidor não têm cabeça e tentei isso no DC. RESULTADO: o sistema travou e, após a reinicialização, o Linux relatou uma falha no XORG (relacionada à GPU).
  • Alteração da configuração da GPU no BIOS para 'Acima de 4G', o restante do BIOS é o padrão de fábrica.

Também informativo:

  • Os sistemas estão localizados em um datacenter. Temperatura, ar, energia e rede são ótimos.
  • As temperaturas estão bem abaixo do máximo de fábrica
  • Temos exatamente a mesma configuração de software em execução em computadores de mesa (com hardware de mesa). Esse sistema pode funcionar bem com 1 de 100 PCs travando todos os meses.
  • Entrei em contato com o VMWare, digamos que este é um problema de hardware
  • Entrei em contato com o SuperMicro, eles não dizem nada realmente, exceto algumas coisas e já tentaram e também que isso ainda pode ser um problema de software.

Estamos desesperados aqui. O aplicativo que executamos com sorte é meio redundante. Se um servidor e suas VMs caírem, esse não é um problema; outros servidores assumirão a carga em 5 minutos, mas, nesse ritmo, sou obrigado a ficar on-line o dia todo para reiniciar os servidores.

Eu tenho um grande conhecimento de hardware, mas isso vai além, eu pesquiso isso o dia todo por mais de um mês tentando todo tipo de coisas diferentes. O fato de essas placas-mãe serem usadas com provedores de hospedagem em larga escala me faz suspeitar que a placa em si esteja correta. Definitivamente, esse não é um problema específico de hardware para o RMA, pois todas as 50 placas têm os mesmos sintomas. A única coisa diferente conosco é a GPU. Isso em combinação com o experimento Linux me faz suspeitar que isso é definitivamente algo na pista PCIe. A GPU em si é estável nos mobo de desktop. Apesar de sua grande capacidade de memória, esta é uma pequena GPU que não consome muita energia. Eu suspeitaria das placas riser chinesas, mas também usamos risers certificadas SuperMicro e elas não mostram nenhuma melhoria.

Estou muito desesperado para encontrar uma solução aqui. Isso começará com a determinação da causa exata. Estamos dispostos a pagar uma boa recompensa a um especialista que possa analisar alguns lixões e nos fornecer mais detalhes (ou melhor ainda, uma solução).

Atenciosamente,

Simon


Estou um pouco familiarizado com este quadro, tendo um eu mesmo ... Há muitas partes móveis aqui e poucas explicações sobre o que são. Qual é o uso do VMware Workstation? Qual aplicativo está sendo executado neles? Como a GPU está sendo passada para as VMs?
Michael Hampton

As VMs executam uma empresa Windows que requer alguma carga de GPU. Não posso elaborar isso muito mais. Esta é a estação de trabalho VMWare, a GPU é virtualizada. Isso também não deve importar, pois funciona exatamente da mesma maneira no hardware da área de trabalho sem problemas.
user349749

É importante porque você não o está executando no hardware da área de trabalho!
Michael Hampton

2
Eu suspeitaria de uma incompatibilidade entre suas placas-mãe e suas GPUs. Com sorte, pode ser algo que possa ser corrigido no BIOS, mas eu não apostaria muito nisso. Como isso é reproduzível com um kernel Linux padrão, eu tentaria obter mais informações sobre o pânico do kernel que provavelmente acontece.
Law29

O que é executado dentro da VM não importa. Pode estar renderizando pornografia ou talvez seja um logaritmo para encontrar uma cura para a aids. Tudo o que importa é uma carga de GPU padrão. @ Law29; É exatamente assim que me sinto. O Linux realmente não me deu nenhum pânico no Kernel, eu acho. O servidor não estava travando, apenas a GUI.
user349749

Respostas:


2

Bem, isso é super tarde, eu imagino que o problema seja resolvido por este ponto? De qualquer maneira, 0x9C geralmente significa uma falha de hardware do MCE. Nossos sistemas de GPU executavam o Linux como um host que relata esses erros um pouco mais detalhadamente do que o Windows.

De qualquer forma, eles apareceram aleatoriamente para nós em hardware semelhante fabricado pela HP há algum tempo; acabou sendo uma entrega insuficiente de energia à GPU. Especificamente, os 75W que devem ser fornecidos pela própria porta PCIe.

Confirmamos com um multímetro em uma placa PCIe breakout. A tensão caiu quando as placas de rede GPU e 10Gbe estavam sendo atingidas com força ao mesmo tempo. Enquanto a placa-mãe era capaz de fornecer 75W ao slot x16, a seção de fornecimento de energia teve um pouco de dificuldade quando as outras placas consumiram energia.

O riser pode ser suspeito aqui e queda de tensão em cargas de alta corrente.


0

Obrigado pela sua resposta. Agora são 3 anos depois. A Supermicro se recusou a nos ajudar de todas as maneiras possíveis. Enviamos várias máquinas (exatamente como construídas por nós). Segundo eles, eles os testaram por semanas e nunca caíram.

Quanto ao riser, o mesmo erro ocorre com a GPU diretamente no slot.

A Supermicro continua colocando a culpa no VMWare, algo em que eu estava inclinado a acreditar até ter minhas mãos em seu novo lançamento da mesma placa. Sem nenhum comentário da Supermicro, a placa com o Xeon D-1540 foi atualizada com um Xeon D-1541 logo após alguns meses. A nova placa é basicamente a mesma ajuda para a CPU mais nova (também a mesma velocidade de relógio apenas um pouco maior). A placa atualizada também possui um cabeçalho de ventilador extra.

Essas placas não travam mais. Exatamente na mesma carga, eles serão executados por meses sem problemas. Eu até clonei máquinas aqui, elas executam o hardware e o software exatos dos que estão travando.

Isso meio que confirma minha suspeita. A Supermicro sabe que há um problema com as placas, mas não quer me dizer por que, porque acabei com quase 100 delas sendo inúteis por causa das falhas. Eles nunca foram e nem RMA, nem consertam nem mesmo a atualização do BIOS, portanto deve ter sido algo a bordo.

Escusado será dizer que esta foi a minha primeira e última vez com a Supermicro. Isso poderia acontecer com qualquer marca de curso, mas o suporte era abaixo de zero.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.