В ходе проведения очередной процедуры обновления ОС Windows Server 2025 на аппаратной платформе HPE ProLiant DL380p Gen8 после установки обновлений и штатной перезагрузки сервера столкнулись с невозможностью нормального запуска сервера. При загрузке сервера в тот момент, когда обычно начинается запуск ОС с дисков RAID контроллера Smart Array, на консоли сервера появилось сообщение "1706-The Extended BIOS Data Area in Server Memory has been Overwritten - Smart Array Interrupt 13h BIOS Cannot Continue - System Halted". После этого дальнейшая загрузка сервера останавливается. Попытки повторной перезагрузки и даже временного обесточивания сервера проблему не решают.
В рассматриваемом случае используется сервер HPE ProLiant DL380p Gen8 (Product ID 642106-421) с последней актуальной версией микрокода System ROM P70 05/24/2019 и укомплектованный стандартным для этой модели RAID контроллером HPE Smart Array P420i с актуальным микрокодом 8.32.
Следует учесть, что в представленном примере используется неподдерживаемая конфигурация связки железа и серверной ОС, так как с точки зрения HPE и, согласно опубликованной информации в Windows Server Support matrix, для данной серверной платформы последняя поддерживаемая ОС была Windows Server 2016.
Попробуем в ходе загрузки попасть в интерфейс встроенной утилиты управления Smart Array Administrator (SSA), нажав "F5" в тот момент, когда происходит вывод информации о RAID контроллере
Альтернативный вариант – использовать "F10" для запуска оболочки Intelligent Provisioning, из которой, в свою очередь, можно будет вызвать утилиту Smart Array Administrator.
В интерфейсе SSA убеждаемся в том, что RAID контроллер и подключенные к нему накопители находятся в исправном состоянии. Этот шаг важен перед следующим для исключения ситуации, когда мы будем пытаться решать одну проблему имея при этом в качестве ключевого фактора другую проблему.
Если с конфигурацией Smart Array всё хорошо, то отправляем сервер в перезагрузку и в ходе следующей загрузки с помощью кнопки "F9" падаем в ROM-Based Setup Utility (RBSU). В разделе "System Default Options" выбираем пункт "Restore Default System Settings" и подтверждаем запрос пунктом "Yes, Select to Restore".
После этого сервер автоматически будет перезагружен и следующая загрузка системы будет более длительной, чем обычно.
Когда ход следующей загрузки доходит до приглашения с помощью кнопки "F9", снова входим в RBSU и повторно настраиваем все параметры, которые использовались нами ранее до сброса настроек. Сохраняем настройки и сервер снова отправляется в перезагрузку.
В нашем случае при последующей загрузке ошибка 1706 пропала, а хостовая ОС с RAID-диска была загружена успешно.
Попробуем разобрать ситуацию на уровне архитектуры BIOS, распределения адресного пространства и работы Option ROM, обратившись к ИИ за помощью в описании механизма сбоя.
Проблема, с которой мы столкнулись, лежит в плоскости управления ресурсами Legacy BIOS (Real Mode) и конфликта в области Conventional Memory.
- Ограничение адресного пространства (640 KB Barrier)
Рассматриваемый сервер поколения Gen8 не имеет нативной поддержки UEFI и работает в режиме Legacy BIOS. В этом режиме процессор на этапе POST работает в реальном режиме адресации (Real Mode), где доступно только 1 МБ адресного пространства. Из этого объема только первые 640 КБ (Conventional Memory) доступны для операционных нужд BIOS и DOS-подобных сред. Extended BIOS Data Area (EBDA) - это сегмент памяти, динамически выделяемый в самом верху этих 640 КБ (непосредственно перед видеопамятью и областью Shadow RAM, 0xA0000).
- Механизм возникновения ошибки 1706
Контроллер Smart Array P420i имеет собственный BIOS, называемый Option ROM (OpROM). При инициализации сервера происходит следующее:
- System BIOS (RBSU) инициализирует базовое оборудование и передает управление OpROM контроллера P420i;
- OpROM контроллера должен зарегистрировать себя как загрузочное устройство, перехватив прерывание Int 13h (стандартный интерфейс BIOS для работы с дисками).
Для работы Int 13h контроллеру требуется сохранить свои переменные состояния и таблицы трансляции геометрии дисков. Для этого он запрашивает у System BIOS выделение участка памяти в EBDA.
Суть сбоя заключается в том, что когда OpROM контроллера обратился по указателю к выделенной ему области EBDA, он обнаружил несоответствие (checksum error или неверный signature). Это происходит, если:
- Указатель на начало EBDA в сегменте данных BIOS сместился.
- Другое устройство (или сам системный BIOS) записало данные в диапазон адресов, зарезервированный под P420i, из-за ошибки адресации.
- Роль NVRAM и почему помог сброс
В современных серверах конфигурация распределения ресурсов PCI и памяти (Memory Map) не пересчитывается с нуля при каждой "горячей" перезагрузке для ускорения POST. Эти данные кэшируются в Non-Volatile RAM (NVRAM).
В рассматриваемом случае в NVRAM накопилась ошибка в карте распределения памяти (Memory Map). Это могло произойти из-за "bit flip" (одиночного сбоя бита), некорректного завершения предыдущей сессии записи конфигурации или микро-конфликта версий прошивок.
- В NVRAM сохранилась информация, что определенный адрес памяти свободен или принадлежит устройству "А", тогда как фактически в текущей конфигурации он требовался устройству "Б" (RAID-контроллеру).
- При загрузке BIOS использовал эту поврежденную карту из кэша NVRAM.
- Smart Array P420i попытался инициализировать Int 13h, но столкнулся с коллизией адресов. Чтобы избежать corrupting data (записи данных на диск с использованием неверных таблиц трансляции), контроллер выдал исключение и остановил систему (System Halted).
Процедура сброса ("Restore Default System Settings") выполнила функцию Invalidate & Re-enumerate:
- Очистка таблицы ESCD: Сброс принудительно очистил область, где хранятся данные Extended System Configuration Data или их проприетарный аналог HPE.
- Full Re-enumeration: При следующей загрузке BIOS был вынужден проигнорировать кэшированные значения и заново просканировать шину PCI/PCIe.
- Re-allocation of EBDA: BIOS заново рассчитал размер необходимой EBDA, сдвинул указатель вершины памяти (Top of Memory) и выделил контроллеру P420i гарантированно чистый, непрерывный блок памяти.
Вывод: Ошибка была вызвана логическим повреждением карты ресурсов в энергонезависимой памяти. Физически оборудование исправно. Сброс настроек заставил систему пересоздать карту ресурсов "с чистого листа", устранив конфликт адресации.
Из представленного выше описания можно получить общее представление о механизме возникновения сбоя, но "за кадром" остаётся то, что именно стало триггером для возникновения описанной ситуации.
RSS - Записи
Добавить комментарий