BSOD 0x09c на 50 машинах SuperMicro

8

Для проекта у нас есть 50 серверов, оснащенных (как правило) одним и тем же оборудованием. У нас здесь очень серьезная проблема, которая возникает на всех машинах. Несмотря на большие усилия и контакты с производителями и разработчиками программного обеспечения, все указывают друг на друга и даже отказываются дать мне подсказку о том, что происходит.

Сначала позвольте мне описать установку. Это серверное оборудование. Для моего первого опыта, servergrade - самое большое разочарование в моей жизни.

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540 (встроен в материнскую плату)
  • Индивидуально разработанный чехол 1U или оригинальный чехол SuperMicro
  • Серверный блок питания на 480 Вт или оригинальный блок питания SuperMicro на 200 Вт
  • Samsung Evo 850 500 ГБ SSD
  • 32 ГБ DDR4-2133 ECC или NON-ECC (но не смешанные на одном сервере)
  • Asus GT730 4GB DDR3 GPU
  • Графический процессор установлен с переходной платой PCIe (не ленточной), безымянной из Китая или оригинальной SuperMicro

Работа в системе - Windows Server 2012 R2 Enterprise - VMWare Workstation 12 - ВМ выполняет задачи, интенсивно использующие графические процессоры - Эта система стандартная, нет разгона вообще

Симптомы - случайный BSOD 0x09c (aka Machine_Check_Exception): иногда система работает без проблем в течение недели, иногда в сбоях через 10 минут, но в большинстве случаев она работает в течение нескольких часов.

Уже пробовал / проверял:

  • BIOS обновлен до последней версии (теперь я думаю, что это улучшило время стабильности системы, но это могло быть случайным).
  • Windows обновлена ​​до последней версии.
  • VMWare обновлен до последней версии.
  • Поменялись местами все компоненты и перепробовали разные варианты, даже попробовали настольный блок питания ATX и M.2 SSD.
  • Установлены все системы с нуля с Ubuntu. Я не знаком с Linux и никогда не видел Linux BSOD, и я все еще не видел, так как серверные системы безголовые, и я попробовал это в DC. РЕЗУЛЬТАТ: система зависает и после перезагрузки Linux сообщает о сбое XORG (связанном с GPU).
  • Изменил настройку графического процессора в BIOS на «выше 4G», остальная часть BIOS - заводская настройка по умолчанию.

Также информативно:

  • Системы расположены в центре обработки данных. Температура, воздух, мощность и сеть оптимальны.
  • Температура значительно ниже заводского максимума
  • У нас точно такая же настройка программного обеспечения , которая работает на настольных компьютерах (с настольным оборудованием). Эти системы могут нормально работать при сбое 1 из 100 наших ПК каждый месяц.
  • Я связался с VMWare, скажем, это проблема с оборудованием
  • Я связался с SuperMicro, они ничего не говорят, кроме некоторых вещей, и уже пытались, а также, что это все еще может быть проблемой программного обеспечения.

Мы в отчаянии здесь. К счастью, приложение, которое мы запускаем, является излишним. Если сервер и его виртуальная машина на нем сбрасываются, это не такая проблема, нагрузка на другие серверы наступает в течение 5 минут, но с такой скоростью я должен быть в сети весь день, чтобы перезапустить серверы.

У меня есть большие знания в области аппаратного обеспечения, но это выходит за рамки этого, я искал это целый день более месяца, пробуя все виды разных вещей. Тот факт, что эти материнские платы используются с хостинг-провайдерами в большом масштабе, заставляет меня подозревать, что плата сама по себе в порядке. Это определенно не специфическая аппаратная проблема для RMA, поскольку все 50 плат имеют одинаковые симптомы. Единственное, что отличается от нас - это графический процессор. Это в сочетании с экспериментом с Linux заставляет меня подозревать, что это определенно что-то на линии PCIe. Сам графический процессор стабилен на настольных компьютерах. Несмотря на большой объем памяти, это небольшой графический процессор, который не потребляет много энергии. Я бы заподозрил китайские карты райзеров, но опять же мы также используем сертифицированные райзеры SuperMicro, и они вообще не показывают улучшения.

Я очень отчаянно пытаюсь найти решение здесь. Это начнется с определения точной причины. Мы готовы выплатить хорошую награду эксперту, который может проанализировать некоторые свалки и предоставить нам более подробную информацию (или, что еще лучше, решение).

С уважением,

Саймон

supermicro bsod user349749
источник
Я немного знаком с этой доской, имея ее сам ... Здесь слишком много движущихся частей и слишком мало объяснений того, чем они являются. Какая польза от VMware Workstation? Какое приложение в них запускается? Как GPU передается на виртуальную машину?
Майкл Хэмптон
Виртуальная машина работает под управлением Windows, что требует некоторой загрузки графического процессора. Я не могу уточнить это намного дальше. Это VMWare Workstation, графический процессор виртуализирован. Это также не должно иметь большого значения, оно работает точно так же на настольном оборудовании без проблем.
user349749
Это важно, потому что вы не запускаете его на настольном оборудовании!
Майкл Хэмптон
2
Я подозреваю несовместимость между вашими материнскими платами и графическими процессорами. Если повезет, это может быть что-то, что может быть исправлено в BIOS, но я бы не стал много ставить на это. Поскольку это воспроизводимо с помощью стандартного ядра Linux, я постараюсь получить больше информации о возможной панике ядра.
Закон 29
Что работает внутри ВМ, не имеет значения. Это может быть предоставление порно или , может быть , это logaritm , чтобы найти лекарство от СПИДа. Все, что имеет значение, это стандартная загрузка графического процессора. @ Law29; Это именно то, что я чувствую. Я думаю, что Linux на самом деле не вызывал у меня паники в ядре. Сервер не падал, только графический интерфейс.
user349749

Ответы:

2

Ну, это супер поздно, я думаю, что проблема решена к этому моменту? В любом случае 0x9C обычно означает аппаратный сбой MCE. Наши системы с графическим процессором использовали Linux как хост, который сообщает об этих ошибках более подробно, чем Windows.

В любом случае, они случайно появлялись у нас на аналогичном оборудовании, произведенном HP некоторое время назад. В итоге это привело к недостаточной подаче питания на графический процессор. В частности, 75 Вт, который должен поставляться самим портом PCIe.

Мы подтвердили это с помощью мультиметра на плате PCIe. Напряжение упало, когда сильно пострадали одновременно и графические карты, и 10Gbe. В то время как материнская плата была способна выдавать 75 Вт в слот x16, секция питания немного пострадала, когда все другие карты потребляли энергию.

Подъемник может быть здесь подозрительным и сбрасывать напряжение при сильноточных нагрузках.

TriadicTech
источник
0

Спасибо за ответ. Сейчас 3 года спустя. Supermicro отказалась помогать нам всеми возможными способами. Мы отправили несколько машин (именно так, как мы их построили). По их словам, они проверяли их в течение нескольких недель и никогда не терпели крах.

Что касается стояка, то же самое происходит с графическим процессором непосредственно в слоте.

Supermicro продолжает обвинять VMWare, чему я был склонен верить, пока я не получу в руки их новую версию той же платы. Без каких-либо комментариев от Supermicro плата с Xeon D-1540 была обновлена ​​на Xeon D-1541 всего через несколько месяцев. Новая плата в основном такая же, как и для нового процессора (также такая же, чуть чуть выше тактовая скорость). Обновленная доска также имеет функцию и дополнительный заголовок вентилятора.

Эти доски больше не терпят крах. На точно такой же нагрузке они будут работать месяцами без проблем. Я даже клонировал машины здесь, они запускают точное аппаратное и программное обеспечение сбойных.

Этот вид подтверждает мое подозрение. Supermicro знает, что есть проблемы с платами, но не хочет говорить мне, почему, потому что почти 100 таких плат оказались бесполезными из-за сбоев. Их никогда не было и в RMA или в чём-то даже не обновлять BIOS для него, так что должно быть что-то на плате.

Излишне говорить, что это был мой первый и последний раз с Supermicro. Это может случиться с любым брендом, но поддержка была ниже нуля.

Саймон Алле
источник