[andrey64]

walcot, я извиняюсь

Проблема в том, что обе платы с разной периодичностью подвисают »

. это как.можит операционная система подвисает ?

[walcot]

andrey64, сам бы хотел знать, ни bsod, ни в логах чего-н интересного, просто сервак становится недоступен - чёрный экран. Образ ОС официальный, не какая-н левая сборка, из софта только nod32, из ролей сервера только "файловый сервер". Абсолютно чистая ось, хз чё в ней может подвисать. Стоит ОС на отдельном SSD, ещё есть 4 HDD (RAID1+RAID1). Мне кажется что проблема железного характера, что-то связанное с платой.

[andrey64]

walcot, на сайте производителя материнок производитель указывает что тестировалось с этой мамкой .память производитель такой то модель этой памяти. у вас все совпадает ? какие HDD и SSD тестировались с этой мамкой https://www.supermicro.nl/products/m...0/X10DRL-i.cfm все соответствует вашему серваку?

[walcot]

andrey64, смотрел, есть моя комплектуха.

[andrey64]

walcot, я даже не знаю что посоветовать в вашей ситуации , я думаю что здесь вряд ли кто вплотную занимается серверами , хотя кто его знает, как вариант исключи зависание из-за операционной системы как это сделать есть в книге М. Руссинович, Д. Соломон, А. Ионеску
Внутреннее устройство Microsoft Windows. 6-е изд часть 2 на странице 655 . Зависание,.или.отсутствие.отклика
Если система перестает отвечать (то есть не реагирует на ввод с клавиатуры или при
помощи мыши), указатель мыши не перемещается или же вы можете его двигать, но
система не реагирует на щелчки мыши, говорят, что система зависла (hung). Для такого
поведения существует несколько причин:
‰ После процедуры обработки прерываний (Interrupt Service Routine, ISR) или
отложенного вызова процедуры (Deferred Procedure Call, DPC) управление не
вернулось к драйверу устройства.
‰ Выполняемый в режиме реального времени программный поток с высоким при-
оритетом вытеснил программные потоки ввода данных драйвера подсистемы
управления окнами.
‰ При выполнении кода в режиме ядра произошла взаимная блокировка (каждый
из двух программных потоков или процессоров удерживает ресурсы, необходимые
другому, и ни один из них не освобождает свой ресурс).
655 Углубленный вопмад хынйирава зилана
Найти взаимные блокировки позволяет механизм выявления взаимных блокировок
(deadlock detection) инструмента Driver Verifier. Он проверяет спин-блокировки,
обычные и быстрые мьютексы, выявляя закономерности, которые могут привести
к взаимной блокировке. (Информация об этих и других примитивах синхронизации
дана в главе 3 части I.) При обнаружении подобной ситуации Driver Verifier вызывает
системный сбой, указывая, какой драйвер является причиной взаимной блокиров-
ки. Простейшая взаимная блокировка возникает в ситуации, когда каждый из двух
программных потоков удерживает нужный другому потоку ресурс и не освобождает
его, ожидая, пока это сделает другой поток. Значит, первое, что нужно сделать для
устранения зависаний системы, — включить для подозрительных драйверов режим
обнаружения взаимных блокировок. Затем это нужно сделать для неподписанных
драйверов, а далее для всех драйверов, пока не произойдет системный сбой, который
позволит выявить вызывающий взаимную блокировку драйвер.
Существует два подхода к исследованию зависшей системы, позволяющие най-
ти драйвер или компонент, являющийся источником проблемы. Во-первых, можно
аварийно завершить работу зависшей системы, надеясь на получение доступного для
анализа дампа. Во-вторых, можно исследовать систему с помощью отладчика ядра.
Но при обоих подходах требуется предварительная настройка и перезагрузка. Для вы-
явления причины зависания в обоих случаях выполняется одно и то же исследование
состояния системы.
Чтобы вручную вызвать аварийное завершение работы зависшей системы, добавьте
в раздел HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\CrashOnCtrlScroll
реестра параметр типа DWORD со значением 1. После перезагрузки драйвер порта i8042,
который является драйвером порта ввода с PS/2-клавиатуры(как это сделать с USB клавиатурой в книге есть ссылка), в своей ISR-процедуре
отслеживает нажатия клавиш (эта тема рассматривается в главе 3 части I), ожидая
двукратного нажатия клавиши Scroll Lock при нажатой правой клавише Control . Обна-
ружив такую последовательность нажатий, драйвер вызывает функцию KeBugCheckEx
со стоп-кодом MANUALLY_INITIATED_CRASH ( 0xE2 ), указывающим на тот факт, что сбой
был инициирован вручную. После перезагрузки системы откройте аварийный дамп и с
помощью описанных ранее приемов попробуйте определить, почему зависла система
(например, узнайте, какой программный поток выполнялся в этот момент, что пока-
зывает стек ядра и т. п.). Следует заметить, что данный подход работает в большинстве
сценариев зависания, но не годится, если не выполняется ISR-процедура драйвера
порта i8042. (Последнее происходит, когда все процессоры зависли из-за того, что
их IRQL-уровень превышает IRQL-уровень ISR-процедуры, либо из-за того, что по-
вреждение системных структур данных затронуло код или данные, используемые для
обработки прерываний.) там много чего написано скачай книгу и почитай

[walcot]

andrey64, т.е. в момент повиса вызвать BSOD вручную для получения дампа? Если bsod будет, то искать в винде причину?

[andrey64]

walcot, да , искать в самом дампе