BSOD 0x09c en 50 máquinas SuperMicro


8

Para un proyecto, tenemos 50 servidores, todos equipados (generalmente) con el mismo hardware. El problema que tenemos aquí es muy grave y ocurre en todas las máquinas. A pesar de mucho esfuerzo y contacto con los fabricantes y los desarrolladores de software, todos se señalan entre sí e incluso se niegan a darme una pista sobre lo que está sucediendo.

Primero déjame describir la configuración. Este es el hardware 'servergrade'. Para mi primera experiencia, servergrade es la mayor decepción de mi vida.

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540 (integrado en la placa base)
  • Funda personalizada de 1U o funda original SuperMicro
  • Fuente de alimentación del servidor de 480 vatios o fuente de alimentación original SuperMicro de 200 vatios
  • Samsung Evo 850 500 GB SSD
  • 32 GB DDR4-2133 ECC o NO ECC (pero no mezclado en el mismo servidor)
  • GPU Asus GT730 4GB DDR3
  • La GPU está montada con una tarjeta vertical PCIe (no cinta), sin nombre de China u original SuperMicro

Ejecutando en el sistema - Windows Server 2012 R2 Enterprise - VMWare Workstation 12 - VM ejecuta tareas intensivas de GPU - Este sistema está en stock, no hay over / underclocking en absoluto

Síntomas: BSOD aleatorio 0x09c (también conocido como Machine_Check_Exception): a veces el sistema funciona durante una semana sin problemas, a veces en bloqueos después de solo 10 minutos, pero la mayoría de las veces funciona durante unas horas.

Ya probado / comprobado:

  • BIOS actualizado a la última versión (creo que ahora esto mejoró el tiempo para que el sistema sea estable, pero eso podría haber sido aleatorio).
  • Windows actualizado a la última versión.
  • VMWare actualizado a la última versión.
  • Cambié todos los componentes y probé todas las opciones diferentes, incluso probé una fuente de alimentación ATX de escritorio y SSD M.2.
  • Instalé todos los sistemas desde cero con Ubuntu. No estoy familiarizado con Linux y nunca he visto un BSOD de Linux y todavía no lo hice, ya que los sistemas de servidor no tienen cabeza y probé esto en DC. RESULTADO: el sistema se bloqueará y después de reiniciar Linux informó un bloqueo XORG (relacionado con GPU)
  • Cambió la configuración de GPU en BIOS a 'Por encima de 4G', el resto del BIOS es el valor predeterminado de fábrica.

También informativo:

  • Los sistemas están ubicados en un centro de datos. La temperatura, el aire, la energía y la red son óptimos.
  • Las temperaturas están muy por debajo del máximo de fábrica.
  • Tenemos exactamente la misma configuración de software que se ejecuta en computadoras de escritorio (con hardware de escritorio). Este sistema puede funcionar bien con 1 de cada 100 PC que se cuelgan cada mes.
  • Me he puesto en contacto con VMWare, y digo que este es un problema de hardware
  • Me he puesto en contacto con SuperMicro, en realidad no dicen nada excepto algunas cosas y ya lo intenté y también que esto podría ser un problema de software.

Estamos desesperados aquí. La aplicación que ejecutamos por suerte es algo redundante. Si un servidor y sus máquinas virtuales caen, no es un problema, otros servidores se harán cargo de la carga en 5 minutos, pero a este ritmo, estoy obligado a estar en línea todo el día para reiniciar los servidores.

Tengo un gran conocimiento de hardware, pero esto va más allá, he buscado en esto todo el día durante más de un mes probando todo tipo de cosas diferentes. El hecho de que estas placas base se usen con proveedores de alojamiento a gran escala me hace sospechar que la placa en sí misma está bien. Este definitivamente no es un problema de hardware específico para RMA ya que las 50 placas tienen los mismos síntomas. Lo único diferente con nosotros es la GPU. Esto en combinación con el experimento de Linux me hace sospechar que esto es definitivamente algo en el carril PCIe. La GPU en sí es estable en los mobo de escritorio. A pesar de su gran capacidad de memoria, esta es una pequeña GPU que no consume mucha energía. Sospecharía de las tarjetas verticales chinas, pero, de nuevo, también usamos tarjetas verticales certificadas SuperMicro y no muestran ninguna mejora.

Estoy muy desesperado por encontrar una solución aquí. Esto comenzará con la determinación de la causa exacta. Estamos dispuestos a pagar una buena recompensa a un experto que pueda analizar algunos vertederos y darnos más detalles (o incluso mejor, una solución).

Saludos cordiales,

Simón


Estoy un poco familiarizado con este tablero, tengo uno ... Hay demasiadas partes móviles aquí y muy poca explicación de lo que son. ¿De qué sirve VMware Workstation? ¿Qué aplicación se está ejecutando en ellos? ¿Cómo se pasa la GPU a las máquinas virtuales?
Michael Hampton

Las máquinas virtuales ejecutan una compañía de Windows que requiere una carga de GPU. No puedo elaborar esto mucho más. Esta es la estación de trabajo VMWare, la GPU está virtualizada. Esto tampoco debería importar realmente, funciona exactamente igual en el hardware de escritorio sin problemas.
user349749

Es importante porque usted está no ejecuta en hardware de escritorio!
Michael Hampton

2
Sospecharía una incompatibilidad entre sus placas base y sus GPU. Con suerte, podría ser algo que pueda corregirse en BIOS, pero no apostaría mucho por ello. Como esto es reproducible con un kernel de Linux estándar, trataría de obtener más información sobre el pánico del kernel que probablemente ocurra.
Ley29

Lo que se ejecuta dentro de la VM no importa. Podría ser renderizar pornografía o tal vez sea un logaritmo encontrar una cura para las ayudas. Todo lo que importa es una carga de GPU estándar. @ Law29; Así es exactamente como me siento. Linux realmente no me dio ningún pánico de Kernel, creo. El servidor no se estaba bloqueando, solo la GUI.
user349749

Respuestas:


2

Bueno, esto es muy tarde, me imagino que el problema se resuelve en este punto De cualquier manera, 0x9C generalmente significa una falla de hardware MCE. Nuestros sistemas de GPU ejecutaron Linux como un sistema operativo host que informa estos errores un poco más detallado que Windows.

De todos modos, estos aparecieron aleatoriamente en un hardware similar fabricado por HP hace un tiempo, terminó siendo una entrega de energía insuficiente a la GPU. Específicamente, el 75W que supuestamente debe ser suministrado por el puerto PCIe mismo.

Lo confirmamos con un multímetro en una placa de conexión PCIe. El voltaje cayó cuando las tarjetas de red GPU y 10Gbe fueron golpeadas con fuerza al mismo tiempo. Mientras que la placa base era capaz de entregar 75W a la ranura x16, la sección de entrega de energía tuvo problemas cuando las otras tarjetas consumieron energía.

El elevador puede ser sospechoso aquí y caer voltaje en cargas de alta corriente.


0

Gracias por su respuesta. Ahora son 3 años después. Supermicro se ha negado a ayudarnos de todas las formas posibles. Enviamos varias máquinas (exactamente como las construimos nosotros). Según ellos, los estresaron durante semanas y nunca se estrellaron.

En cuanto al elevador, se produce el mismo error con la GPU directamente en la ranura.

Supermicro sigue echando la culpa a VMWare, algo que estaba inclinado a creer hasta que tuve en mis manos el nuevo lanzamiento de la misma placa. Sin ningún comentario de Supermicro, la placa con el Xeon D-1540 se actualizó con un Xeon D-1541 justo después de unos meses. La nueva placa es básicamente el mismo asistente para la CPU más nueva (también la misma velocidad de reloj un poco más alta). La placa actualizada también cuenta con un encabezado de ventilador adicional.

Estas tablas ya no se estrellan. Con exactamente la misma carga, se ejecutarán durante meses sin ningún problema. Incluso cloné máquinas aquí, ejecutan el hardware y el software exactos de los que fallan.

Este tipo de confirma mi sospecha. Supermicro sabe que hay un problema con las tablas, pero no quiere decirme por qué porque terminé con casi 100 de estas tablas inútiles debido a los bloqueos. Su nunca fue y RMA o reparó ni siquiera la actualización del BIOS, por lo que debe haber sido algo en el tablero.

No hace falta decir que esta fue mi primera y última vez con Supermicro. Esto podría sucederle a cualquier marca, pero el soporte fue bajo cero.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.