BSOD 0x09c sur 50 machines SuperMicro

8

Pour un projet, nous avons 50 serveurs tous équipés (généralement) du même matériel. Le problème que nous avons ici est très grave et se produit sur toutes les machines. Malgré beaucoup d'efforts et de contacts avec les fabricants et les développeurs de logiciels, tout le monde se pointe et refuse même de me donner un indice sur ce qui se passe.

Permettez-moi d'abord de décrire la configuration. Il s'agit de matériel «servergrade». Pour ma première expérience, servergrade est la plus grande déception de ma vie.

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540 (intégré sur la carte mère)
  • Boîtier 1U personnalisé ou boîtier d'origine SuperMicro
  • PSU serveur 480 watts ou bloc d'alimentation SuperMicro original 200 watts
  • Disque SSD Samsung Evo 850 500 Go
  • 32 Go DDR4-2133 ECC ou NON-ECC (mais pas mélangés dans le même serveur)
  • Processeur graphique Asus GT730 4 Go DDR3
  • Le GPU est monté avec une carte de montage PCIe (pas de ruban), sans nom de Chine ou d'origine SuperMicro

Fonctionnant sur le système - Windows Server 2012 R2 Enterprise - VMWare Workstation 12 - Exécuter des tâches gourmandes en GPU - Ce système est en stock, il n'y a pas de sur / sous-cadencement du tout

Symptômes - BSOD aléatoire 0x09c (alias Machine_Check_Exception): parfois le système fonctionne pendant une semaine sans problème, parfois en panne après seulement 10 minutes, mais la plupart du temps il s'exécute pendant quelques heures.

Déjà essayé / vérifié:

  • BIOS mis à jour vers la dernière version (je pense maintenant que cela a amélioré le temps de stabilité du système, mais cela aurait pu être aléatoire).
  • Windows mis à jour vers la dernière version.
  • VMWare mis à jour vers la dernière version.
  • Échange tous les composants et a essayé toutes les options différentes, a même essayé une alimentation ATX de bureau et un SSD M.2.
  • Installé tous les systèmes à partir de zéro avec Ubuntu. Je ne connais pas Linux et je n'ai jamais vu de BSOD Linux et je ne l'ai toujours pas vu car les systèmes serveurs sont sans tête et j'ai essayé cela dans le DC. RÉSULTAT: le système se bloquait et après le redémarrage, Linux a signalé un crash XORG (lié au GPU).
  • Modification du paramètre GPU dans le BIOS en `` Au-dessus de 4G '', le reste du BIOS est réglé par défaut en usine.

Aussi informatif:

  • Les systèmes sont situés dans un centre de données. La température, l'air, l'électricité et le réseau sont optimaux.
  • Les températures sont bien en dessous du maximum d'usine
  • Nous avons exactement la même configuration logicielle exécutée sur les ordinateurs de bureau (avec le matériel de bureau). Ces systèmes peuvent fonctionner correctement avec 1 de nos 100 PC se brisant chaque mois.
  • J'ai contacté VMWare, disons qu'il s'agit d'un problème matériel
  • J'ai contacté SuperMicro, ils ne disent rien, sauf certaines choses et ont déjà essayé et aussi que cela pourrait encore être un problème logiciel.

Nous sommes désespérés ici. Heureusement, l'application que nous exécutons est en quelque sorte redondante. Si un serveur et ses machines virtuelles y tombent, ce n'est pas un problème, d'autres serveurs prendront en charge la charge dans les 5 minutes, mais à ce rythme, je dois être en ligne toute la journée pour redémarrer les serveurs.

J'ai une grande connaissance du matériel mais cela va au-delà, j'ai cherché toute la journée pendant plus d'un mois en essayant toutes sortes de choses différentes. Le fait que ces cartes mères soient utilisées avec des fournisseurs d'hébergement à grande échelle me fait suspecter que la carte en elle-même est correcte. Ce n'est certainement pas un problème matériel spécifique pour RMA car les 50 cartes présentent les mêmes symptômes. La seule chose différente avec nous est le GPU. Ceci en combinaison avec l'expérience Linux me fait suspecter que c'est définitivement quelque chose sur la voie PCIe. Le GPU lui-même est stable sur les mobos de bureau. Malgré sa grande capacité de mémoire, c'est un petit GPU qui ne consomme pas beaucoup d'énergie. Je soupçonnerais les cartes de montage chinoises, mais là encore, nous utilisons également des cartes de montage certifiées SuperMicro et elles ne montrent aucune amélioration.

Je cherche désespérément une solution ici. Cela commencera par déterminer la cause exacte. Nous sommes prêts à payer une belle prime à un expert qui peut analyser certaines décharges et nous donner plus de détails (ou encore mieux, une solution).

Sincères amitiés,

Simon

user349749
la source
Je connais un peu cette planche, j'en ai une moi-même ... Il y a trop de pièces mobiles ici et trop peu d'explications sur ce qu'elles sont. À quoi sert VMware Workstation? Quelle application y est exécutée? Comment le GPU est-il transmis aux machines virtuelles?
Michael Hampton
Les machines virtuelles exécutent une entreprise Windows qui nécessite une certaine charge GPU. Je ne peux pas développer cela beaucoup plus loin. Il s'agit de VMWare Workstation, le GPU est virtualisé. Cela ne devrait pas non plus vraiment avoir d'importance, cela fonctionne exactement de la même manière sur le matériel de bureau sans problème.
user349749
C'est important parce que vous ne l' exécutez pas sur du matériel de bureau!
Michael Hampton
2
Je soupçonnerais une incompatibilité entre vos cartes mères et vos GPU. Avec de la chance, cela pourrait être quelque chose qui peut être corrigé dans le BIOS, mais je ne parierais pas beaucoup là-dessus. Comme cela est reproductible avec un noyau Linux d'origine, j'essaierais d'obtenir plus d'informations sur la panique du noyau qui se produit probablement.
Loi29
Ce qui s'exécute à l'intérieur de la machine virtuelle n'a pas d'importance. Il pourrait s'agir de rendre du porno ou peut-être que c'est un logarithme pour trouver un remède contre le sida. Tout ce qui compte c'est une charge GPU standard. @ Law29; C'est exactement ce que je ressens. Linux ne m'a pas vraiment paniqué, je pense. Le serveur ne plantait pas, juste l'interface graphique.
user349749

Réponses:

2

Eh bien, c'est super tard, j'imagine que le problème est résolu par ce point? Dans les deux cas, 0x9C signifie généralement une défaillance matérielle MCE. Nos systèmes GPU exécutaient Linux en tant qu'OS hôte, ce qui rend ces erreurs un peu plus verbeuses que Windows.

Quoi qu'il en soit, ceux-ci surgissaient au hasard pour nous sur un matériel similaire fabriqué par HP il y a quelque temps, cela a fini par être une alimentation insuffisante du GPU. Plus précisément, le 75 W qui est censé être fourni par le port PCIe lui-même.

Nous l'avons confirmé avec un multimètre sur une carte de dérivation PCIe. La tension a chuté lorsque les cartes réseau GPU et 10Gbe ont été durement touchées en même temps. Alors que la carte mère était capable de fournir 75 W à l'emplacement x16, la section de fourniture d'énergie a connu un peu de difficulté lorsque les autres cartes consommaient toutes de l'énergie.

La colonne montante peut être suspecte ici et une chute de tension sur des charges de courant élevées.

TriadicTech
la source
0

Merci pour votre réponse. C'est maintenant 3 ans plus tard. Supermicro a refusé de nous aider de toutes les manières possibles. Nous avons envoyé plusieurs machines (exactement comme nous les avons construites). Selon eux, ils les ont harcelés pendant des semaines et ils ne se sont jamais écrasés.

Quant à la carte de montage, la même erreur se produit avec le GPU directement dans l'emplacement.

Supermicro continue de rejeter la faute sur VMWare, ce que j'étais enclin à croire jusqu'à ce que je mette la main sur leur nouvelle version de la même carte. Sans aucun commentaire de Supermicro, la carte avec le Xeon D-1540 a été mise à jour avec un Xeon D-1541 juste après quelques mois. La nouvelle carte est fondamentalement la même asside pour le nouveau processeur (également la même vitesse d'horloge légèrement plus élevée). La carte mise à jour comprend également un en-tête de ventilateur supplémentaire.

Ces planches ne plantent plus. Sur exactement la même charge, ils fonctionneront pendant des mois sans problème. J'ai même cloné des machines ici, elles exécutent le matériel et les logiciels exacts de celles qui plantent.

Ce genre de confirme ma suspicion. Supermicro sait qu'il y a un problème avec les planches mais ne veut pas me dire pourquoi parce que je me suis retrouvé avec près de 100 de ces planches inutiles à cause des plantages. Leur n'a jamais été et RMA ou ne corrige même pas la mise à jour du BIOS pour cela, donc il doit y avoir quelque chose sur la carte.

Inutile de dire que c'était ma première et dernière fois avec Supermicro. Cela pouvait arriver à n'importe quelle marque de cours, mais le soutien était inférieur à zéro.

Simon Allais
la source