Watchdog timer driver что это

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

Источник

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

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

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

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

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

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

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

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

Источник

AVR Урок 53. Watchdog Timer (WDT). Часть 1

Уже более года мною не публиковалось уроков по контроллерам AVR. На это были различного рода причины.

Во-первых, я считал, что основные виды периферии и прочих составляющих данного контроллера нами уже изучены.

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

В-третьих, с выходом более современных контроллеров интерес к данным контроллерам упал, хоть и незначительно, но всё же это есть.

Несмотря на это, я всё же, взвесив все «за» и «против», всё же решил ещё раз попытать счастья и выложить пару уроков (пока пару, а там посмотрим, как дело пойдёт) по данным микроконтроллерам.

Что же всё-таки сподвигло меня на данный шаг?

Во-первых, многочисленные просьбы посетителей моего ресурса, а также просьбы в личных сообщениях.

Во-вторых, новый хозяин данного семейства контроллеров Microchip, включил эти контроллеры в свою среду разработки MPLAB X, что позволит нам теперь обойтись сразу на два семейства одной средой разработки.

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

И вот одним из неизведанных ещё нами модулей оказался модуль Watchdog Timer (WDT), который, как оказалось, много где используется и выполняет очень важные роли в работе программ. Тем более, меня ранее многие просили сделать по нему урок, но я либо недопонимал ценность данной периферии, либо был увлечён чем-то другим.

Вот и настало время наконец-то восполнить данный пробел.

Watchdog Timer (WDT) – это сторожевой таймер (а если перевести дословно, «сторожевой пёс»), который представляет собой аппаратно-реализованную схему контроля над зависанием системы. Это таймер, который периодически сбрасывается контролируемой системой. Если вдруг сброса не произошло за определённый интервал времени после предыдущего сброса данного таймера, то происходит принудительная перезагрузка системы (в нашем случае микроконтроллера).

В каких конкретных случаях мы можем применить данный таймер?

Например, мы ждём ответа от какой-нибудь шины (например I2C или ещё какой-то) в виде отслеживания состояния определённого бита регистра. И вдруг произойдёт кратковременное отсоединение провода этой шины. После этого скорей всего произойдёт зависание программы, так как в шине будет сбой, и даже если что-то после и придёт от присоединённого узла, то мы вряд ли уже это отследим изменением состояния бита. Желательно, чтобы после какого-то таймаута система перезагрузилась. Тут-то и приходит нам на помощь WDT, который установлен на определённый интервал. Команду на перезагрузку сторожевого таймера мы расположим в нашем коде после того, как мы дождёмся отклика от шины. А если мы так его и не дождёмся, то мы не дойдём до команды перезагрузки WDT и через заветный интервал времени система будет перезагружена. После этого произойдёт заново инициализация шины и всё будет опять работать нормально.

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

При работе с таймером в нашем коде мы не будем напрямую работать с его регистрами, так как там ещё надо проделывать очень много различных подготовительных мероприятий. Для этого существует отличная библиотека wdt.h, которая находится в стандартном комплекте для AVR и не требует дополнительного подключения откуда-то. Но тем не менее о том, как именно устроен сторожевой таймер в контроллере ATMega328, которым мы и будем сегодня пользоваться, мы всё же поговорим.

Таймер питается от отдельного генератора, который вместе с ним входит в логику перезагрузки контроллера

А вот это диаграмма сброса контроллера по истечении интервала времени

Кроме того, что мы можем сбросить сторожевой таймер где-то в коде, мы можем также и отследить окончание интервала времени по прерыванию, которое надо включить отдельно.

WDT, как и было указано выше, работает от отдельного генератора.

Также следует отметить, что диапазон интервалов данного таймера не бесконечен.

Давайте посмотрим блок-схему WDT

На рисунке мы видим, что после генератора на 128 килогерц, сигнал проходит на предделитель, который содержит 10 различных выходов с различным коэффициентом деления. Предделитель настраивается с помощью битов WDP3:WDP0 регистра WDTCSR. Таким образом, интервал времени работы WDT лежит в диапазоне от 15 милисекунд до 8 секунд.

Также мы видим, что с помощью бита WDIE мы можем разрешить прерывания от сторожевого таймера и затем попасть в обработчик, отслеживая состояние бита WDIF. Включается таймер с помощью бита WDE.

Вот он – управляющий регистр сторожевого таймера

Хоть мы уже и говорили о битах данного регистра выше, но всё же давайте все их рассмотрим подробно, их не так и много, так как у таймера всего один регистр

WDIF (Watchdog Interrupt Flag): флаг прерывания. Устанавливается в 1 в случае истечения интервала времени таймера. Сбрасывается аппаратно.

WDIE (Watchdog Interrupt Enable): бит разрешения прерываний от таймера. если установлен в 1, то прерывания разрешены, если в 0 – запрещены.

Существует таблица зависимости от состояния бетов WDE, WDIE, а также фьюза WDTON

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

WDP2:WDP0 (Watchdog Timer Prescaler): биты, устанавливающие коэффициент деления предделителя сторожевого таймера.

Вот таблица возможных комбинаций данных битов

Здесь также даны сами интервалы в единицах времени.

WDCE (Watchdog Change Enable): бит изменения, который должен быть предварительно включен перед тем, как мы соберёмся внести изменения в предделитель с целью изменения коэффициента деления либо для отключения таймера путём занесения в бит WDE значения 0. Сбрасывается аппаратно после четырех тактов.

WDE (Watchdog System Reset Enable): бит включения таймера, а вернее бит включения режима перезагрузки системы по истечению интервала времени таймера WDT.

Ну вот, я думаю и всё насчёт теории по сторожевому таймеру. Если что-то пропустил, то исправим это в процессе сочинения кода.

Код наш выполнять будет следующие задачи.

У нас, помимо WDT, будет также работать ещё таймер TIM1, данный таймер будет работать по совпадению, следовательно в обработчик прерываний от него мы будем попадать через определённое время периодично. В обработчике таймера мы будем периодично включать 10 ножек различных портов, а состояние их на какой-то момент мы будем определять по светодиодам, которые мы к ним подключим. Вернее, мы подключим светодиодную планку с 10-ю светодиодами, не забывая конечно о токоограничивающих резисторах, которые я на всякий случай подключил на 680 Ом, при этом светодиоды светятся вполне ярко. В начале программы мы запустим наш сторожевой таймер WDT и зададим ему определённый интервал времени срабатывания. В процедуре обработки прерываний от таймера 1 мы будем своевременно сбрасывать сторожевой таймер, поэтому, если всё у нас будет нормально с ходом программы, то система у нас будет работать и не перезагрузится.

А для того, чтобы проверить, перезагрузится ли наш WDT по истечению интервала, мы сэмулируем ситуацию, что наш таймер перестанет работать. Для этого мы подключим кнопку к контакту INT0 и обработаем от неё внешнее прерывание, в обработчике которого мы запретим прерывания от нашего таймера. Светодиоды, соответственно перестанут бежать, тем самым сигнализируя нам о том, что наш таймер 1 «сломался». Поэтому сторожевой таймер не перезагрузится, тем самым перезагрузит нашу систему и весь процесс у нас начнётся заново.

В качестве контроллера для урока мы возьмём контролер ATMega328P, расположенный на плате Arduino Nano, к которой подключим обычный USB-программатор через разъём ISP. Вставим нашу плату в макетную плату, подведём к ножке PD2 (INT0) кнопку, а также от ножек D3-D12 (ножки портов PD3:PD7, PB0:PB4) подключим аноды светодиодов планки, а катоды через токоограничивающие резисторы подключим к общему проводу

Проект мы создадим в среде программирования MPLAB X, с которой мы постоянно работаем с микроконтроллерами PIC, так как у данных контроллеров владелец один и тот же, то нет смысла использовать несколько сред для разработки. Как установить данную среду разработки, показано здесь.

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

Запустим среду программирования MPLAB X и запустим создание проекта с помощью следующей кнопки

Выберем «Standalone Project» и идём далее

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

На следующем шаге в качестве программатора выберем Simulator и идём далее

На следующем шаге выберем компилятор и идём дальше

Дадим имя нашему проекту и жмём «Finish»

В дереве проекта в ветке Source Files добавим новый файл main.c с помощью контекстного меню на данной ветке

Исправим имя файла и нажмём «Finish»

Файл main.c создан, чуть позже мы его исправим немного.

А пока создадим ещё заголовочный файл main.h аналогичным образом, только выбрав в контекстном меню на ветке «Header Files» и затем выбрав соответствующий пункт

Для нормального функционирования функции задержки зайдём в свойства проекта и откроем там настройки компилятора, в которых выберем настройку оптимизации

Оставим уровень оптимизации 0 и установим чекбокс на пункте Debug

Источник

Серверы 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.

Источник