Watchdog в биосе что это

Аппаратный «watchdog» или незаменимый помощник в борьбе с зависанием

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

В итоге мы получили устройство, которое подключается к расширительному спаренному USB-разъему на материнской плате.

Данное устройство имеет следующие возможности:

Алгоритм работы прост: внутри находятся два настраиваемых таймера, которые постоянно отсчитывают заданное время, по истечению которого имитируется нажатие соответствующих кнопок (POWER и RESET). Чтобы предотвратить случайную перезагрузку, необходимо периодически послать команду сброса таймера.

Лучше, чтобы за процедуру сброса таймеров отвечало целевое приложение, а не стороннее или системное (Cron, служба расписаний) по причине того, что вероятность сбоя в системе меньше, чем в приложении (хотя, у кого как).
Обмен информацией аналогичен консольному.

В случае удачного выполнения команды возвращает «OK».
В случае некорректных данных возвращает «ERROR».
Признаком конца строки служит символ возврата каретки «\r». Также поддерживается режим «\r\n».

Устройство выполнено на базе контроллера STM32F103CA с аппаратной поддержкой USB. Библиотека работы с USB версии V4.0.0. Напряжение работы 3.3В получаем с помощью линейного стабилизатора из 5В на USB. Во всех управляющих цепях используются транзисторы в ключевом режиме. Также не забываем про защитный диод от токов самоиндукции в катушки реле (в моем случае он оказался встроенным).

Источник

Watchdog Timer

Персональный компьютер или сервер имеют встроенный таймер операций – он называется WatchDog Timer или WDT (в русской компьютерной терминологии – контрольный таймер материнской платы). Необходим он потому как такая сложная техника, как компьютер имеет свойство сбоить и выходить из строя. Именно поэтому в неё зачастую встраивают различные независимые опции контроля и коррекции, в частности таймер операций, который ограничивают время, затрачиваемое системой ввода-вывода на одно действие(шаг).

В большинстве случаев контрольный таймер доступен прямо в BIOS-е. Впрочем, некоторые производители материнских плат страдают недоверием к пользователям и оснащают свои платы только самыми безопасными и «пользовательскими» функциями. Если вам так не повезло – увы, доступ к настройкам WDT вам закрыт. К счастью, таких производителей немного.

Как работает контрольный таймер

WDT запускается вместе со стартом системы и тут же начинает отслеживание её действий. Впрочем, некоторые модели плат имеют технологическую особенность: первый шаг WDT в них является холостым, а значит, по-настоящему работу таймер начнет только по прохождении 0,6 секунды. Стандартное значение WDT– 4h, что означает 4 шага. Если программа не успевает выполнить операцию за четыре шага (1,8 – 2,4 секунды) система принудительно останавливает её и производит корректировку программы. Ну или перезагружает/выключает компьютер, если эта программа системная. При этом вы получите BSoD (Blue Screenof Death) с описанием произошедшей ошибки, например DPC_WATCHDOG_VIOLATION.

Максимальное значение WDT– 3Fh, то есть 62 шага или 37,5 секунд, но устанавливать его не стоит: в случае какого-либо сбоя вы потеряете доступ к ПК не на жалкие две секунды, а почти на полминуты. К тому же любой современный ПК способен выполнить стандартную операцию меньше чем за секунду, а значит, даже двухсекундная задержка уже сбой.

Стоит ли включать эту опцию?

Да, определенно. WDT крайне необходим при работе с нестабильными или зараженными системами, так как он помогает находить и устранять программные и аппаратные ошибки, мешающие нормальной работе вашего ПК. Но вот если вы работаете с очень устаревшим оборудованием (или же невероятно сложными и/или плохо написанными программами), то значение WDT в BIOS стоит сделать побольше или же вообще выключить, если другие варианты не работают. Только помните, что в этом случае ваш компьютер может начать чаще зависать и тратить процессорное время на выполнение некорректно совершенных запросов.

Источник

Как исправить код остановки ДРАЙВЕР PNP WATCHDOG

Ошибка DRIVER PNP WATCHDOG BSOD в основном возникает из-за неправильных настроек контроллера SATA в BIOS, неправильных значений реестра, проблем службы теневого тома, заражений вредоносным ПО, исключений системной службы или проблем Центра обновления Windows.

Что вызывает DRIVER PNP WATCHDOG Ошибка BSOD?

После тщательного анализа пользовательских отчетов мы смогли сделать вывод, что эта ошибка может возникать из-за проблем, связанных с программным обеспечением. Некоторые из этих проблем:

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

Решение 1. Измените настройки контроллера SATA в BIOS

BIOS является основным компонентом вашей системы, и если у него возникают проблемы с подключением к устройству, то у ОС также будет проблема с подключением к устройству. При поиске и устранении ошибки Driver PNP Watchdog проверка BIOS является одним из наиболее важных шагов. Как правило, виновником является настройка контроллера SATA, и изменение его с AHCI на IDE может решить проблему.

Перезапустите систему и проверьте, была ли устранена ошибка BSD Driver PNP Watchdog.

Решение 2. Проверьте службу теневого копирования томов

Служба теневого копирования томов (VSS) управляет и реализует теневые копии томов, используемые для резервного копирования и других целей. Если эта служба не работает должным образом, это может вызвать проблемы. Чтобы убедиться, что служба Volume Shadow Copy работает правильно, выполните следующие действия:

Перезагрузите компьютер, чтобы убедиться, что на нем нет ошибки Driver PNP Watchdog.

Решение 3. Запустите полное сканирование системы

Вирусы и вредоносные программы могут вызвать ошибку Driver PNP Watchdog, так как это может повлиять на любой важный файл / сервис, который необходим системе для связи с любым аппаратным устройством. Поэтому вы должны сканировать ваш компьютер на наличие вирусов и вредоносных программ, чтобы удалить их. Вы можете использовать встроенный антивирус Windows Defender Windows или любой сторонний антивирус по своему вкусу (см. Наш список рекомендуемых антивирусов) для запуска полной проверки системы.

После перезагрузки системы проверьте, не вышла ли ошибка Driver PNP Watchdog на вашем компьютере.

Решение 4: настройка со службами

Системные службы — это компоненты, необходимые системе для правильной работы, и если какая-либо из служб неисправна, система может выдать несколько ошибок, включая ошибки BSOD. Ошибка драйвера драйвера PNP Watchdog BSOD также может возникать из-за неисправного обслуживания. Так что настройка некоторых необходимых сервисов может решить проблему.

чистые стартовые биты

net start msiserver

Проверьте, исчезла ли ошибка Watchdog драйвера PNP, если нет, перейдите к следующему решению.

Решение 5. Запустите средство устранения неполадок обновлений Windows

Известно, что Центр обновления Windows создает BSOD, если он не выполняет определенную операцию. А устранение неполадок Центра обновления Windows является важным шагом при устранении ошибок BSOD. В Windows 10 имеется несколько встроенных средств устранения неполадок, и одним из них является средство устранения неполадок обновлений Windows. Поэтому запуск его для устранения неполадок Центра обновления Windows может решить нашу проблему.

Перезагрузите систему и убедитесь, что проблема Driver PNP Watchdog BSoD решена.

Решение 6. Сбросьте настройки ПК до настроек по умолчанию

Windows 10 позволяет своим пользователям сбросить свои ОС до заводских настроек, и все приложения, драйверы, службы, которые не поставлялись с компьютером, будут удалены, а все изменения, сделанные пользователем в настройках и настройках системы, будут аннулированы. Что касается файлов и данных пользователя, хранящихся на компьютере, то пользователю будет предложено отказаться от сохранения или удаления их при перезагрузке компьютера.

Надеюсь, вы решили проблему и используете свой компьютер в обычном режиме. Если у вас по-прежнему есть ошибка Driver PNP Watchdog BSOD, возможно, у вас неисправный дисковод или неисправная материнская плата. Чтобы проверить диск, замените его на любой другой диск и попробуйте описанные выше методы с этим замененным диском. И даже если у вас по-прежнему возникает ошибка драйвера PNP Watchdog BSOD, вполне вероятно, что это драйвер материнской платы; для чего вы должны взять свою систему в сервисный центр.

Источник

Серверы IBM/Lenovo и сторожевой таймер: эпизод II

Более чем полгода я потратил на совместное с аппаратной и программной технической поддержкой IBM расследование по поводу работы сторожевого таймера на серверах IBM/Lenovo в Linux. Начало этой детективной истории было описано в моей статье SLES 12, сторожевой таймер и серверы IBM/Lenovo. Сейчас, похоже, ситуация разъяснилась, и можно дать конструктивные рекомендации счастливым обладателям железа IBM/Lenovo xSeries.

Итак, вначале повторяем краткий ликбез из предыдущей статьи. В составе серверных и промышленных платформ имеется специальная схема – сторожевой таймер. Будучи активированным, он начинает отсчитывать заданное время (например, одну минуту). Если за это время к нему повторно не обратиться, то в конце интервала будет выполнена аппаратная перазагрузка. Если обратиться, то интервал начинает отсчитываться заново. Это нужно для того, чтобы автоматически восстановить работоспособность компьютера в случае зависания операционной системы или предоставляющего какой-то важный сервис программного обеспечения. Такое решение в обязательном порядке применяется в кластерах высокой готовности (HA) и других применениях, требующих постоянной готовности системы. Для компьютеров с архитектурой Intel используется несколько аппаратных интерфейсов сторожевого таймера, в зависимости от производителя системы, из них наиболее распространённым является Intel TCO (iTCO). В Linux драйверы сторожевого таймера реализованы как модули ядра, которые предоставляют программный интерфейс к нему в виде устройства /dev/watchdog.

На этом описание широко известных вещей закончено, дальнейшие факты мало отражены в интернете и не очень хорошо известны даже технической поддержке фирм-производителей оборудования и программного обеспечения.

Повсеместно принято считать, что в оборудовании с чипсетами Intel, в том числе и в Intel-серверах IBM, которые теперь выпускаются фирмой Lenovo, за интерфейс к сторожевому таймеру отвечает аппаратный уровень Intel TCO и поддерживающий его модуль ядра Linux iTCO_wdt. Тут следует отметить, что, при внимательном рассмотрении, архитектура Intel TCO сама по себе оказывается имеющей довольно существенный недостаток, а именно, получается, что процессор контролирует сам себя. Хотя теоретически ничто не должно помешать программе, работающей в режиме SMM, всегда выполнять свою работу, но ведь теоретически и операционная система не должна виснуть, не так ли? Поэтому наличие единой аппаратной точки уязвимости для процессора как исполнителя программ и для его же собственного сторожевого таймера выглядит не очень хорошо, если вы собираетесь строить систему с повышенной надёжностью.

Впрочем, я, вероятно, никогда бы не стал вдаваться в эти подробности и даже о них не узнал бы, если бы не то обстоятельство, что драйвер iTCO_wdt оказался совершенно неработоспособен на IBMовских серверах под SLES 12: драйвер загружается в память, но устройство /dev/watchdog не создаётся, а в системном журнале остаётся маленькое неприметное сообщение: “iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS”.

Поначалу я думал, что это регресс в SLES 12 по сравнению со SLES 11, так как в SLES 11 устройство /dev/watchdog было доступно. Однако, благодаря взаимодействию с IBM и SUSE, выяснилось, что всё гораздо хуже. Оказывается, в SLES 11, в отличие от SLES 12, запись в каталоге /dev/watchdog создаёт само ядро при загрузке, а драйвер сторожевого таймера просто цепляется к этой записи. Поэтому в SLES 11 сторожевой таймер iTCO точно так же неработоспособен, как и в SLES 12, но заметить это гораздо сложнее, так как его неработоспособность маскируется наличием нефункционального /dev/watchdog.

Думаю, излишне добавлять, что никакие манипуляции с настройками BIOS, IMM, AMM и прочими замечательными приблудами, которых в xSeries имеется изобилие, никакого влияния на работоспособность Intel TCO не оказывают.

К счастью, после более чем полугода активной работы с технической поддержкой IBM по аппаратному и программному обеспечению, IBMерам удалось обнаружить один древний манускрипт, датированный 2008 годом. Оказывается, у фирмы Intel есть и другая архитектура для работы со сторожевым таймером – IPMI watchdog, которая поддерживается на платформе xSeries.

Суть IPMI (Intelligent Platform Management Interface) совершенно другая, чем у iTCO. В соответствии с архитектурой IPMI, где-то на материнской плате имеется специальный контроллер – по сути, отдельный компьютер – с собственным процессором, программным обеспечением, сетевым интерфейсом и прочими прибамбасами, предназначенный для отслеживания параметров работы основного компьютерного оборудования и имеющий возможность реагировать на их изменение заданным образом. В терминологии описания интерфейса IPMI, этот контроллер называется BMC (Baseboard Management Controller) или просто MC. В терминологии IBM/Lenovo, реализующее его функции устройство называется IMM (Integrated Management Module) или IMM2. BMC может делать много разных вещей, которые описаны в упомянутом манускрипте, но для нас сейчас существенно, что одной из его функций является сторожевой таймер. Понятно, что сторожевой таймер IPMI – это честное, отдельное от процессора Intel устройство, которое, в общем случае, работает независимо, пока не вышла из строя материнская плата в целом.

Само описание работы со сторожевым таймером в манускрипте выполнено в жанре комментария авторов к некой не дошедшей до нас инструкции MIGR-5069505, при этом базируется на материале устаревших версий программного обеспечения и их не всегда актуальных возможностей. Но разобраться, о чём идёт речь, вполне можно, и краткое актуализированное содержание этого тайного знания представлено ниже.

Приятным сюрпризом является то, что поддержка IPMI интегрирована в современные дистрибутивы Linux. Сама эта поддержка состоит из нескольких компонентов, из которых нас будут интересовать три.

Во-первых, это сервис ipmi.service, предоставляющий возможность коммуникации программ с BMC. В SLES 12 этот сервис устанавливается и стартует автоматически. Это можно проверить так:

systemctl status ipmi

и, при, необходимости, далее, как обычно:

systemctl start ipmi
systemctl enable ipmi

Во-вторых, это собственно драйвер сторожевого таймера IPMI, который так и называется: ipmi_watchdog. Он устанавливается автоматически, но автоматически не стартует (видимо, считается, что администратор должен быть уверен в настройках оборудования, прежде чем разрешать его аппаратную перезагрузку по таймауту). Загрузить этот драйвер вручную можно командой:

Включить его автоматическую загрузку при старте системы можно, создав в каталоге /etc/modules-load.d файл ipmi_watchdog.conf, состоящий из одной строчки “ipmi_watchdog”:

echo ipmi_watchdog > /etc/modules-load.d/ipmi_watchdog.conf

В-третьих, это утилита ipmitool, которая устанавливается автоматически и позволяет выполнять различные команды BMC, в том числе, например, проверять статус сторожевого таймера:

ipmitool mc watchdog get

Если у вас в системе имеется BMC, в ответе на указанную команду вы получите что-нибудь вроде:

Watchdog Timer Use: SMS/OS (0x04)
Watchdog Timer Is: Stopped
Watchdog Timer Actions: No action (0x00)
Pre-timeout interval: 0 seconds
Timer Expiration Flags: 0x00
Initial Countdown: 300 sec
Present Countdown: 300 sec

Если у вас запускается, например, кластер высокой готовности, то он сам сконфигурирует правильные параметры работы сторожевого таймера (например, у меня в системе это период 5 секунд и акция Hard reset).

К сожалению, даже правильно установленные служба ipmi и драйвер ipmi_watchdog и наличие файла /dev/watchdog ещё не гарантируют, что всё работает, как надо. В чём же дело? Оказывается, что некоторые версии SLES 12 имеют отвратительную привычку по собственной инициативе загружать драйвер softdog, пытающийся эмулировать работу сторожевого таймера программным путём (занятие абсолютно бессмысленное и вредоносное). А так как при этом softdog загружается до ipmi_watchdog, то последний, не имея возможности создать уже созданный файл /dev/watchdog, по традиции ничего не делает, скромно пробурчав что-то в недра системного журнала. Поэтому наша последняя задача – поискать собаку, дав команду

и проанализировав её результат. Если мы видим там ipmi_watchdog и не видим softdog, то, скорее всего, всё у нас работает правильно. Если там есть softdog – то его надо как-то изжить из системы, что в некоторых версиях SLES 12 может оказаться не вполне тривиальным делом.

Предполагаю, что работоспособность сторожевого таймера IPMI на оборудовании IBM/Lenovo может быть связана со значением параметра OSWatchdog, устанавливаемого в модуле IMM при помощи веб-интерфейса или утилиты asu (asu64). Этот параметр может принимать значение некоторого количества минут или быть выключенным. У меня он включён в 2.5 минуты (минимальное значение), но на интервал сторожевого таймера, программируемый в BMC, это не влияет.

Итак, резюме. Корректным способом использования сторожевого таймера на платформе IBM/Lenovo могут показаться softdog, Intel TCO или IPMI, но, в действительности, работоспособным является только IPMI. Драйвер сторожевого таймера IPMI устанавливается в SLES автоматически, но требует ручного прописывания загрузки. Драйвер softdog устанавливается автоматически и иногда требует ручного запрещения загрузки. Драйвер Intel TCO устанавливается и загружается автоматически, но абсолютно ни на что не влияет, так как полностью неработоспособен на этой платформе.

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

Источник

Как правильно настроить демон сторожевого таймера Debian для BIOS Watch Dog?

Настройте веб-сервер Raspberry Pi (Linux, Apache, MySQL, PHP, SSH)

Основные платы Supermicro содержат функцию BIOS под названием «Watch Dog Function». Имея Debian 6.0.6 с ядром «Linux debian 2.6.32-5-amd64 # 1 SMP», мы сделали:

Ожидается: этого достаточно для правильной установки сторожевой схемы.

Результат: система перезагружается каждые (примерно) 5 минут.

+ Изменить BIOS ‘Функция Watch Dog«с Включено на Отключено исправляет нежелательные перезагрузки.

Похоже, что процесс загрузки правильно включает сторожевой таймер. По крайней мере, консоль отображает (когда BIOS Watch Dog отключен):

И при перезагрузке генерируется этот вывод:

Что еще нужно сделать для правильной совместной работы функции сторожевого таймера BIOS и сторожевого таймера ОС Linux?

1. Загрузите аппаратный модуль

Во-первых, для того, чтобы действительно «кормить» сторожевой таймер, вам необходимо загрузить аппаратный модуль сторожевого таймера. Это может не произойти автоматически, так как большинство драйверов сторожевого таймера занесены в черный список, если нет демона сторожевого таймера (например, в /etc/modprobe.d/blacklist-watchdog.conf в системе Ubuntu / Debian). Проверить, есть ли /dev/watchdog (или подобное), поскольку это означало бы, что модуль загружен.

Успех выглядит так:

Отказ ничего не показывает после:

Также проверьте системный журнал. В противном случае ознакомьтесь с инструментами IPMI, поскольку они включают сторожевой драйвер.

2. Изменить /etc/watchdog.conf

Так что на самом деле используйте /dev/watchdog доступ устройства к модулю. В противном случае сторожевой таймер не будет использовать оборудование и будет полагаться только на свой внутренний код для мягкой перезагрузки сломанной машины (что не так полезно).

Опять же, при запуске сторожевого пса поищите в системном журнале сообщения о его запуске и о том, какой аппаратный модуль он нашел.

Источник