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, и они вообще не показывают улучшения.

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

С уважением,

Саймон


Я немного знаком с этой доской, имея ее сам ... Здесь слишком много движущихся частей и слишком мало объяснений того, чем они являются. Какая польза от 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, секция питания немного пострадала, когда все другие карты потребляли энергию.

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


0

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

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.