Современные х86-совместимые компьютеры с одним-двумя процессорами, все чаще применяемые в качестве серверов и узлов кластеров, являются достаточно сложным оборудованием, надежность работы которого определяется в первую очередь системой охлаждения.
Даже когда не требуются формальные показатели отказоустойчивости, практически для любых работающих круглосуточно компьютеров необходим мониторинг температуры и работы вентиляторов. Впрочем, если вентилятор остановится даже на домашнем компьютере, при отсутствии работающей программы, следящей за температурными условиями, это можно не заметить или заметить не сразу. Если же окажется, что ПК будет эксплуатироваться при повышенной температуре, то в микропроцессоре могут начаться необратимые физические процессы, что сократит срок его службы.
Предельные значения температур для микропроцессоров приводятся в соответствующей документации, и ориентироваться следует именно на них. В качестве грубой оценки предельной температуры для процессоров, изготовленных по 0,18-микронной технологии, можно назвать 70-75 ?С по внешнему термодатчику (для Athlon этому отвечает 90-95 ?С для встроенного диода). Нормальной температурой материнской платы обычно считается 30-40 ?С, но они могут работать и при температурах 45-55 ?С (это указывается в документации на плату).
В то же время, современные х86-совместимые микропроцессоры имеют встроенные температурные датчики, а материнские платы — специальные микросхемы, отвечающие за мониторинг состояния ПК — температуры в разных точках платы, скоростей вращения вентиляторов и уровней напряжения. Имеющиеся в микропроцессоре температурные датчики, конечно, реагируют на рост температуры с опозданием. Однако величина временной задержки невелика (по доступным автору неофициальным данным — около 125 мсек для Pentium 4, и 150-200 мсек для AMD Athlon). Кроме того, важной становится неравномерность нагрева микросхемы. Поэтому главным для обеспечения работы компьютера становится использование соответствующих программных средств, работающих с микросхемами мониторинга состояния аппаратуры.
Упования на то, что материнские платы сами отработают подобную ситуацию и при необходимости выключат компьютер, мало обоснованы — хотя бы потому, что таких плат у пользователей еще мало.
Удовлетворительные решения в этом смысле имеются для современных материнских плат на базе Pentium 4. Поддержка термодиода Athlon XP появилась в последнем «поколении» материнских плат, первой из которых стала Fujitsu Siemens D1289. Однако на более старых серверных платах, например, от Tyan, термодиод не поддерживается.
Желательно, чтобы в подобных ситуациях происходило корректное завершение работы операционной системы, для чего, естественно, должны применяться программные средства самих ОС. Кроме того, целесообразно учесть и ситуации иного рода: если сгорел не процессорный вентилятор, а вентилятор системного блока, это скажется не сразу, однако могут начать сбоить и другие компоненты ПК.
В качестве примера программного обеспечения, специализированного для известных плат ASUSTek, можно указать Windows-программу PC Probe. Для Windows существуют и более универсальные решения, например, Motherboard Monitor (mbm.livewiredev.com). Ниже подробно будет рассмотрен известный пакет lm_sensors. Также приводится краткая информация об используемых при этом аппаратных средствах — микросхемах мониторинга аппаратуры и шинах доступа к ним; эта информация полезна, в частности, для правильного конфигурирования пакета lm_sensors.
Аппаратные средства
Устройства, о которых пойдет речь, подключаются обычно посредством шин I2C, SMBus и, возможно, ISA. Если последняя шина известна хорошо, то про I2C и SMBus можно прочесть, пожалуй, только в некоторых профессиональных монографиях (см., например, [1, 2]) или в специализированных публикациях (http://www.tk.uni-linz.ac.at/~simon/private/i2c). Достаточно подробная информация об этих шинах содержится в документации, поставляемой вместе с программным обеспечением i2c, установить которое необходимо для работы lm_sensors.
I2C (точнее, I2C, Inter-Integrated Circuit) — очень простая последовательная двухпроводная шина с синхронной передачей, разработанная компанией Philips и использовавшая первоначально частоту не более 100 КГц. Обычно она работает с адресами длиной 7 разрядов; имеется экспериментальный режим с расширенной до 10 разрядов длиной адресов. I2C используется, в том числе, для связи микроконтроллеров со специализированными микросхемами, для работы с цифровым каналом связи с монитором (Data Display Channel, DDC) и получения информации о характеристиках модулей памяти DIMM и др.
Шина SMBus (System Management Bus) является «частным случаем» I2C в том смысле, что протокол SMBus можно эмулировать средствами шины I2C (обратное неверно). Если программировать драйверы, ориентируясь на применение SMBus, то они будут работать и с адаптерами I2C. Поддержку SMBus имеют очень много современных материнских плат. Классические примеры применения SMBus — модули DRAM, имеющие EEPROM-память, работающую через эту шину, и микросхемы здоровья (мониторинга аппаратуры). С описанием протокола SMBus можно ознакомиться, например, в документации к программным средствам I2C.
|
| Рис. 1. Типичная схема подсоединения микросхем контроля аппаратуры |
Поддержка интерфейса I2C/SMBus реализуется благодаря наличию встроенных адаптеров в большинстве современных наборов микросхем (рис. 1). Такую поддержку предлагают, например, южный мост Intel PIIX4/PIIX4E, наборы микросхем i810/815/840, AMD 756/766/768, наборы микросхем ServerWorks OSB4 и CSB5, наборы микросхем VIA Appolo, nVidia nForce и даже набор микросхем Compaq/DEC Tsunami 21272/Typhoon 21274 (в частности, в платах U2000 на базе микропроцессоров Alpha/21264A; напомним, что Linux работает и на этой платформе).
Правда, в последнем случае шина I2C применяется для чтения данных SPD из DIMM-модулей SDRAM. Аналогично, в известном северном мосте Intel, GMCH, имеется два интерфейса I2C, которые также применяются вовсе не для мониторинга аппаратуры (для этого используется южный мост).
Микросхемы мониторинга аппаратуры обычно подсоединяются к I2C-адаптерам южного моста. Основные характеристики некоторых распространенных микросхем такого рода приведены в таблице 1, составленной на основе документации к пакету lm_sensors. Такие микросхемы обычно отслеживают следующие параметры: уровни напряжений, температурные показатели датчиков, скорости вращения вентиляторов и, возможно, признак «внешнего вмешательства» (открытие корпуса).
В большинстве материнских плат, с которыми приходилось сталкиваться автору, применяются микросхемы National Semiconductor или Winbond (см. таблицу 1). Понятно, что для серверов требуется отслеживать больше показателей, чем для обычных ПК, и в этом смысле микросхемы Winbond обладают некоторым преимуществом. Кроме того, на материнской плате можно разместить более одной такой микросхемы, что позволяет повысить число отслеживаемых параметров. В качестве примера можно привести популярные среди тех, кто создает кластеры Beowulf, двухпроцессорные платы Tyan Tiger серии S246x, работающие с AMD Athlon MP. На них имеется сразу две микросхемы Winbond — W83782d и W83627hf.
Наиболее важный показатель «здоровья» ПК — температура (если сгорел вентилятор, то неприятностью будет именно рост температуры). Используемые температурные датчики базируются либо на транзисторах (диодах), либо на термисторах, которые имеют на порядок более высокую чувствительность, поскольку их сопротивление экспоненциально зависит от температуры. За дополнительными деталями отсылаем читателя к документации по lm_sensors. В микропроцессорах (например, Intel Pentium II, Celeron) обычно используются диоды. Микросхемы W83782d и W83783s — единственные, способные работать с обоими типами температурных датчиков.
Коротко рассмотрев аппаратные средства, с которыми работает lm_sensors, обратимся собственно к программному обеспечению.
Программный инструментарий i2c
Повторимся, инструментарий i2c необходим для обеспечения работы собственно lm_sensors, по отношению к которым i2c является «базовым» программным обеспечением. Как i2c, так и lm_sensors можно бесплатно загрузить с сайта www.netroedge.com/~lm78. (Наиболее свежая версия обоих продуктов, доступная на момент написания статьи, — 2.6.3; уже при сдаче статьи в печать вышла версия 2.6.4, поэтому мы отметим некоторые новые возможности.)
Работа с обоими продуктами предполагает модификацию ядра Linux, что проще сделать через модули ядра, хотя можно корректировать и текст «монолитной части». Начиная с версии lm_sensors 2.5.0, поддерживаются только ядра Linux версии не ниже 2.2.0. Последняя версия lm_sensors требует установки i2с версии не ниже 6.1. Именно эта версия i2c включена в состав ядер с версиями не ниже 2.4.13; таким образом, для таких ядер нет формальной необходимости устанавливать i2c, можно сразу ставить lm_sensors. Cредства lm_sensors становятся неотъемлемой частью среды Linux и включаются в последние версии дистрибутивов (например, Red Hat). Однако с учетом того, что установка обоих пакетов достаточно проста, как правило, имеет смысл установить последние версии как i2c, так и lm_sensors, что способно обеспечить стабильную работу новых аппаратных средств.
Установка i2c после распаковки исходного текста состоит в вызове make all (включает трансляцию модулей) в инсталляционном каталоге, а затем make install (переписывает модули ядра на нужное место; можно сделать и вручную). Потом нужно, как обычно, выполнить depmod -a (если это не будет сделано автоматически при перезагрузке). Напомним также, что если исходные тексты ядра только что распакованы, то необходимо выполнить первые две стадии его генерации (make config; make dep).
Среди параметров Makefile пакета i2c, которые может понадобиться модифицировать, упомянем MODDIR (каталог, в который заносятся модули ядра, по умолчанию —lib/modules/версия_ядра/misc, в RedHat 7.2, например, его нужно поменять), LINUX (каталог, где находится исходный текст ядра, по умолчанию — /usr/src/linux) и SMP (по умолчанию будет предпринята попытка автоматического определения, включена ли на компьютере поддержка симметричной многопроцессорности).
Обратимся теперь к общей схеме построения программных средств i2c.
В состав i2c входят драйверы, которые в рассматриваемом нами наиболее популярном варианте установки i2c и lm_sensors реализуются в виде модулей ядра.
Драйверы, отвечающие за работу с шиной, бывают двух типов: драйвер алгоритма и драйвер адаптера. Драйвер алгоритма используется для всего класса адаптеров I2C. Драйверы адаптеров зависят от специфических особенностей адаптера шины и используют средства драйвера алгоритма.
Драйверы, обеспечивающие работу с устройствами на шине I2C, также бывают двух типов — драйвер драйвера (это не тавтология!) и драйвер клиента. Подобно предыдущему случаю, драйвер драйвера содержит общие коды, необходимые для работы с определенным типом устройств. Каждое обнаруженное на шине устройство получает собственные данные в структуре клиента. В отличие от драйвера алгоритма и драйвера адаптера, драйвер драйвера тесно интегрирован с драйвером клиента, так что можно говорить о едином драйвере. Собственно, драйверы устройств, которые представляют для нас интерес, вынесены из пакета i2c и относятся уже к lm_sensors, хотя имена соответствующих модулей часто имеют префикс i2c.
В состав i2c входит три базовых модуля: i2c-core (интерфейс файловой системы /proc); i2c-dev (интерфейс /dev); i2c-proc (предоставляемый /proc интерфейс для драйверов клиентских устройств).
В качестве примера модулей драйверов алгоритма назовем i2c-algo-bit и i2c-algo-pcf. Модуль i2c-algo-bit используется, например, драйверами адаптеров параллельных портов i2c-elv и i2c-phillips-par.
При написании драйверов устройств I2C лучше использовать команды SMBus, тогда этот драйвер будет способен работать как с адаптерами SMBus, так и с I2C; в последнем случае команды SMBus будут автоматически транслироваться в команды I2C.
dev-интерфейс
Устройства на шине I2C обычно обслуживаются драйверами ядра, однако к ним можно обращаться и из адресного пространства пользователя, для чего служит специальный dev-интерфейс. Для его использования необходимо загрузить модуль i2c-dev. При обычной работе lm_sensors этого не происходит, поскольку соответствующие драйверы являются модулями ядра.
Адаптеров I2C может быть несколько; они нумеруются, начиная с нуля. Какой номер отвечает какому адаптеру, можно увидеть, посмотрев файл /proc/bus/i2c. Файлы устройств I2C являются символьными, причем старший (major) номер равен 89, а младший (minor) лежит в интервале от 0 до 255. Соответствующие файлы устройств имеют вид /dev/i2c-0, /dev/i2c-1 и т.д. Для создания этих файлов можно воспользоваться сценарием, поставляемым в составе дистрибутива lm_sensors (lm_sensors-2.6.3/prog/mkdev/mkdevsh.sh). Вообще в каталоге prog можно найти много полезных исполняемых файлов; упомянем prog/config/grab_busses.sh, который позволяет обнаруживать шины и адаптеры I2C.
При программировании различных драйверов для I2C надо иметь в виду, что glibc ничего об этой шине «не знает», а потому необходимо пользоваться заголовками ядра (, ). Обычной практикой автоматической загрузки i2c и lm_sensors является включение вызовов modprobe или insmod в выполняемый при загрузке ОС Linux сценарий наподобие rc.local. Однако для загрузки i2c-dev можно добавить в /etc/modules.conf строку:
alias char-major-89 i2c-dev
Параметры модулей i2c
Рассмотрим формат команд modprobe/insmod, используемых для загрузки модулей i2c и lm_sensors. Главное в нем — это возможный список параметров, разделяемых пробелами:
modprobe имя_модуля [cписок_параметров]
В нормальной ситуации системному администратору нет необходимости создавать этот список параметров (см. ниже описание lm_sensors). Однако в отдельных случаях (с ними, в частности, столкнулся автор в процессе эксплуатации lm_sensors в Центре компьютерного обеспечения химических исследований ИОХ РАН) для обеспечения работоспособности lm_sensors с этими параметрами приходится возиться.
Все параметры условно можно разбить на три группы. Первая группа (force) «заставляет» модуль считать, что на материнской плате имеются определенные аппаратные средства (шины, микросхемы и т.д.). Вторая группа (ignore) служит для того, чтобы игнорировать соответствующие аппаратные средства, имеющие заданные адреса. Третья группа (probe) указывает модулю на необходимость сканировать определенные адреса и шины.
Кроме того, есть еще один параметр, init, принимающий значения 0 или 1 (значение по умолчанию — 1), который предписывает драйверу обойти инициализацию микросхемы при init = 0. Это может понадобиться, если BIOS уже инициализировал микросхему определенным образом, и инициализация ее драйвером не нужна. В настоящее время этот параметр поддерживается только в драйвере W83781d (cм. также описание lm_sensors ниже).
Список_параметров, который может отсутствовать (что обозначено выше квадратными скобками), представляет собой набор параметров, разделенных пробелами. В кодировке каждого параметра пробелы использовать нельзя.
Как мы увидим ниже, фактически параметр может быть неким списком, элементы которого разделяются запятыми. Все элементы являются десятичными, если нет префикса 0x. Кроме init, имеются следующие параметры:
force=шина,адрес[,шина,адрес]
force_addr=адрес[,адрес]
force_<имя_микросхемы>
=шина,адрес,[,шина,адрес]
ignore=шина,адрес[,шина,адрес]
ignore_range=шина,start,end[шина,start,end]
probe=шина,адрес[шина,адрес]
probe_range=шина,start,end[,шина,start,end]
Аргумент «шина» в этих параметрах указывает номер адаптера I2C/SMBus, иначе говоря, номер шины. Он лежит в диапазоне от 0 до 15, и его можно найти в /proc/bus/i2c. ISA-шина имеет фиксированный номер 9191. Для задания «любой шины» нужно указать в качестве номера -1 или 65535.
Аргумент «адрес» — целое число в диапазоне от 0 до 65535, но его можно кодировать также в шестнадцатеричном виде. Аргументы «start» и «end» задают соответственно начальный и конечный адреса требуемого диапазона. Допустимый диапазон адресов для шин I2C — от 0х00 до 0х7f, а для шины ISA — от 0х0000 до 0хffff.
Остановимся в качестве примера на некоторых параметрах важной группы force. Собственно параметр force говорит модулю, что на данном адресе такой-то шины находится поддерживаемая данным модулем микросхема. Его указание может помочь, если автоматического обнаружения микросхемы не происходит (например, модуль обслуживает несколько типов микросхем, но не смог распознать, какую именно микросхему обнаружил, и не пометил как найденную).
Параметр force_<имя_микросхемы> указывает модулю не только то, что на данном адресе имеется поддерживаемая модулем микросхема (что делает параметр force), но и задает ее тип. При этом модуль не будет проводить собственные процедуры сканирования и распознавания. Параметр force_subclients указывает модулю на наличие подклиентов определенной микросхемы. Например,
force_subclients=0,0x2d,0x4a,0x4b
указывает на наличие для микросхемы с адресом 0x2d, находящейся на нулевой шине I2C, подклиентов с адресами 0x4a и 0x4b. Этот параметр в настоящее время поддерживается только для драйвера W83781d, и бывает необходим для работы с некоторыми популярными серверными материнскими платами Tyan.
proc-интерфейс
Когда загружен базовый модуль i2c-core, появляется файл /proc/bus/i2c. В нем содержится список адаптеров I2C, по одной строке на адаптер. Строки включают ряд полей, разделяемых символом табуляции. Первое поле содержит текст «i2c-<номер_адаптера>», например, i2c-3 для третьего адаптера было бы в четвертой строке (напомним, шины нумеруются с нуля). Этому полю отвечает спецфайл /dev/i2c-<номер_адаптера> и файл proc/bus/i2c-<номер_адаптера>; в последнем содержится список всех подключенных к адаптеру устройств.
Второе поле задает тип адаптера, например, I2C или SMBus. Если указано I2C, то поддерживается и SMBus. В документации говорится, что в третьем поле указывается алгоритм (он может быть общим для ряда адаптеров), а в четвертом — имя адаптера. Приведем в качестве примера реальное содержимое файла /proc/bus/i2c для плат Tyan S2460:
i2c-0 smbus "SMBus AMD7X6 adapter at 80e0" "Non-I2C SMBus adapter"
(для наглядности третье и четвертое поля мы заключили в кавычки, в файле их нет). Каждому адаптеру в этом списке отвечает файл /proc/bus/i2c-<номер_адаптера>, в котором содержится список устройств, подключенных к шине данного адаптера. Для Tyan S2460 файл /proc/bus/i2c-0 содержит:
2c W83627HF chip W83781D Sensor driver 2d W83782D chip W83781D Sensor driver 48 W83782D subclient W83781D Sensor driver 49 W83782D subclient W83781D Sensor driver 4a W83627HF subclient W83781D Sensor driver 4b W83627HF subclient W83781D Sensor driver
Поля в строках этого файла также разделяются табуляцией. В первой колонке указывается шестнадцатеричный адрес клиента (в нашем примере две цифры — 2с, 2d, 48 и т.д.). Во второй колонке задается имя клиента (W83627HF chip, W83782D chip и т.д.), а в третьей — имя драйвера, обслуживающего данного клиента (W83781D Sensor driver).
Пакет lm_sensors
Установка и настройка
Процедура установки lm_sensors, как и i2c, достаточно тривиальна. При вызове make произойдет трансляция необходимых модулей, а make install переписывает объектные модули в нужное место (что легко сделать и вручную). Для Red Hat 7.2, как и в случае с i2c, необходимо изменить в Makefile переменную MODDIR на /lib/modules/версия_ядра/kernel/drivers/sensors, а переменную LINUX установить в /usr/src/linux-2.4. Единственная возможная неожиданность состоит в том, что при вызове make требуются средства bison, которые входят в дистрибутив Red Hat, но могут быть не установлены.
Ряд модулей lm_sensors имеют префикс i2c (i2c-viapro, i2c-piix4, i2c-amd756 и т.п.), и некоторые из них раньше входили в состав пакета i2c. В числе основных модулей lm_sensors, отвечающих за работу с микросхемами контроля аппаратуры, — lm75/78/80/87, w83781d и др.
Для завершения инсталляции нужно выполнить depmod -a, в /etc/ld.so.conf добавить строку /usr/local/lib и вызвать ldconfig. Далее начинается настройка lm_sensors, с которой, собственно, и могут быть некоторые неприятности. В обычной ситуации все разрешается благодаря вызову системным администратором утилиты sensors-detect, которая сканирует оборудование на шинах I2C/SMBus (и, возможно, ISA), и в диалоговом режиме запрашивая разрешения на те или иные действия, сообщает, что нашла, какие модули следует загрузить через modprobe, и даже может самостоятельно их загрузить.
Если все в порядке и необходимые модули загружены, то вызов sensors -s позволяет произвести подготовку библиотеки libsensors к пересчету получаемых от микросхем контроля значений в соответствии с файлом /etc/sensors.conf. Последующие вызовы утилиты sensors (уже без ключа -s) приведут к появлению долгожданных величин — показаний температурных датчиков, скоростей вращения вентиляторов и уровней напряжений на материнской плате. Периодически вызывая sensors и контролируя возвращаемые результаты, можно реализовать необходимую стратегию мониторинга работы аппаратуры.
В качестве примера ситуации, в которой sensors-detect не помогает, укажем на плату Tyan S2460. Программа рекомендует вызывать посредством modprobe модули i2c-amd756 и w83781d без параметров. При этом удается получить показания только от одной из двух имеющихся микросхем контроля (W83627HF по адресу 0x2c и W83782d по адресу 0x2d). Однако температура процессоров контролируется одной микросхемой, а, скажем, процессорные вентиляторы — другой. По умолчанию эти микросхемы располагаются по адресу 0x2d, так что BIOS должен уметь корректно инициализировать микросхему по адресу 0x2c. После регистрации W83627HF по этому адресу, микросхему W83782d пытаются зарегистрировать по адресу 0x2d, однако это не получается, поскольку при этом происходит попытка зарегистрировать подклиента по адресу 0x49, а этот адрес уже занят подклиентом микросхемы W83627HF.
Для того чтобы при вызове sensors получать показания от датчиков обоих микросхем, необходимо проделать следующий трюк. При загрузке необходимо зайти в BIOS Setup, чтобы инициализировать там микросхемы контроля при просмотре значений температуры и т.п. (для того чтобы увидеть правильные показания, необходимо нажать на клавиатуре клавишу, скажем, ENTER; иначе будут высвечены завышенные значения). В ОС Linux необходимо загрузить модуль w83781d с параметрами
83781d init=0 force_subclients=0, 0x2c,0x4a,0x4b
Что эти параметры означают, ясно из изложенного выше. Хотя все после этого работает, сама процедура с заходом в BIOS при загрузке обременительна, особенно при большом числе узлов в кластере.
Конфигурирование
Конфигурационные параметры libsensors в файле /etc/sensors.conf, как уже отмечалось, указывают, как пересчитывать формальные значения, полученные от датчиков, в измеряемые физические характеристики. Формат этого файла, конечно, не так «недружественен», как конфигурация sendmail, однако задание этих параметров системным администратором не только неудобно, но и требует достаточно специфических знаний об используемых микросхемах контроля.
К счастью, доступный «пробный» файл sensors.conf содержит нужные параметры для основных типов микросхем. В планах разработчиков — создание базы данных параметров для различных материнских плат. Однако на практике иногда приходится менять эти параметры самостоятельно. Дадим их краткий обзор.
Комментарии в sensors.conf — это строки, начинающиеся с символа «#». Они, как и пустые строки, игнорируются. Внутри строк поля в этом файле отделяются не менее чем одним пробелом. Признаком продолжения на следующую строку служит обратный слэш. Всего в этом файле имеется шесть типов предложений:
bus ИМЯ1 ИМЯ2 ИМЯ3 chip CПИСОК_ИМЕН label ИМЯ1 ИМЯ2 compute ИМЯ ВЫР1,ВЫР2 ignore ИМЯ set ИМЯ ВЫР
Здесь ИМЯ и т.п. — это цепочки, которые содержат буквенно-цифровые символы и почерк; при более широком диапазоне используемых символов цепочку следует заключать в двойные кавычки. СПИСОК_ИМЕН — это список «величин» типа ИМЯ, разделенных пробелом. Что касается выражений (ВЫР и т.п.), то они записываются с использованием обычных для популярных языков программирования операций +, -, *, / и круглых скобок. В выражениях используются числа с плавающей запятой (допустимо — «273», «12.8», но не допустимо — «3.» или «4.8Е1»). В выражениях может присутствовать одна специальная переменная, «@», смысл которой объяснен чуть ниже.
В предложении bus цепочка ИМЯ1 есть название шины (например, «i2c-0»), а ИМЯ2 и ИМЯ3 содержат краткое описание адаптера и алгоритма по аналогии с полями /proc/bus/i2c. Эти предложения можно сгенерировать, вызвав сценарий prog/config/grab_busses.sh из дистрибутива lm_sensors.
Предложение chip содержит несколько полей, относящихся к описанию микросхемы контроля аппаратных средств. Первое поле — имя микросхемы, второе — имя шины, а третье — шестнадцатеричный адрес. Возможно использование символа «*» (wildcard). За исключением этой возможности, данное предложение содержит то же, что указано в имени соответствующего каталога, имеющегося в /proc/sys/dev/sensors. Все последующие предложения конфигурационного файла относятся к этому предложению, пока не встретится новое предложение chip.
Предложение compute указывает (через ВЫР1), как рассчитать физическую величину ИМЯ, исходя из значения «@», непосредственно считанного соответствующим контактом (row), и (через ВЫР2) — наоборот, как рассчитать значение непосредственно на контакте, зная физическую величину, задаваемую @.
Предложение label cвязывает переменную ИМЯ1 с ее кратким описанием ИМЯ2. Например, «описание»
label in3 «+5V»
используется для формирования результатов работы утилиты sensors. В предложении ignore аргумент ИМЯ задает физическую величину, значение которой будет игнорироваться. Это применяется обычно для тех величин, которые реально не измеряются (например, датчик вентилятора не подсоединен). В ИОХ РАН для плат Tyan S2460 мы для простоты «игнорируем» вообще все уровни напряжений: во-первых, неизвестно, как правильно рассчитывать некоторые из них, а во-вторых, в первом приближении достаточно контролировать только температуры и скорости вращения вентиляторов.
|
| Рис. 2. Фрагменты файла /etc/sensors.f |
На рис. 2 приведены фрагменты из используемого конфигурационного файла для S2460. Мы не рассматриваем здесь всех особенностей sensors.conf, в частности понятие «класса» физических величин (подробности заинтересованный читатель может найти в документации). Упомянем еще только предложение set, которое обычно используется для установки минимально и максимально допустимых значений величин или задания типа термического сенсора.
Заключение
Результаты вызова утилиты sensors могут быть использованы как для целей мониторинга, так и — при необходимости — для принятия неотложных решений типа выполнения процедуры shutdown. С lm_sensors поставляется программа sensord, работающая в режиме демона с периодической записью показаний датчиков в журнал и «поднимающая тревогу» в критических ситуациях. В lm_sensors 2.6.4 она доработана и теперь использует базу данных Round Robin Database.
В prog/daemon имеется сценарий health.sh, который вызывает утилиту sensors, просматривает ее результаты на предмет наличия «сигнала» ALARM, и если он обнаружен, посылает электронное сообщение системному администратору. Имеется немало средств (часть из них поставляется с lm_sensors), которые позволяют образовывать базы данных показаний сенсоров, использовать X-интерфейс и средства Web для обеспечения удобной работы с lm_sensors. Обычно такие программные настройки (например, Monitor Sensors, sens2web, tellerstars) требуют каких-либо дополнительных инсталлированных средств. Мы разработали не зависящие ни от чего «лишнего» собственную программу и соответствующий сценарий для мониторинга и выполнения shutdown в критических ситуациях.
С учетом того, что с ростом тактовой частоты процессоров проблемы охлаждения будут нарастать, очевидно, что lm_sensors будет все более востребована в Linux-системах на базе х86.
Работа поддержана РФФИ, проект 01-07-90072 и МКНТ, проект 1.2.63.
Литература
- D. Paren, C. Fenger, The I2C Bus from Theory to Practice. John Wiley&Son, 1997
- М. Гук, "Аппаратные средства IBM PC. Энциклопедия", Издание 2. СПб.: "ПитерКом", 2002
Михаил Кузьминский — старший научный сотрудник ИОХ РАН.
