Acpi термальная зона драйвер что делает

Обновлено: 07.07.2024

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

Нет, конечно, я слышал про всякие программы, которые могут вмешиваться в управление охлаждением и вроде кто-то ими успешно пользуется, но лично мне с ними вечно не везло, точнее не везло с железом, на котором я пытался их завести. Например, какое-то время назад я пробовал настроить fancontrol на довольно старом ноутбуке HP nc8430 с Убунтой. В итоге, известный скрипт sensors-detect не смог найти ни одного вентилятора в системе, а без этого fancontrol не работает. На разных форумах периодически появляются люди с похожими проблемами, но никто им толком помочь не может.

Тогда я в очередной раз забросил эту тему и вернулся к ней только на днях, когда читал обзоры, подыскивая себе новый ноутбук, и уже вроде бы выбрал почти всем хороший Sony S15, как опять в одном из обзоров читаю про него, что вентилятор в нем вообще не останавливается никогда, даже когда точно можно. Постоянно шумящий ноутбук я больше не хочу, а выбирать как всегда особо не из чего, учитывая, что надо 15", что TN матрицу я тоже больше не хочу, и бюджет ограничен. Ну сами знаете, как оно бывает. Может быть на нем все-таки заведется fancontrol и все будет хорошо, но а если нет? Никаких отчетов по его установке на этот ноутбук найти не удалось. Это побудило меня еще раз копнуть тему программного управления вентиляторами и пройти довольно непростой, но очень увлекательный квест.

Как оно в Windows

Я решил, что если мне удастся разобраться с охлаждением моего HP, то и с новым Sony скорее всего справлюсь. Если нет, придется искать другой ноутбук. Погуглив немного, удалось узнать, что под Windows есть замечательная программа Notebook Hardware Control, она бесплатная, её все хвалят. Что же, надо попробовать. Перезагрузился в Windows, скачал, запустил – программа действительно работает. Можно задать температуры, при которых вентилятор будет выключен совсем, работать на низких оборотах, средних и высоких, а самое главное можно задать мощности моторчика вентилятора в процентах для всех трех режимов. Именно мощности, а не обороты в секунду, но какая разница.

Оказалось, что в этом ноутбуке по умолчанию самым низким оборотам соответствует 55% мощности. Т. е. либо вентилятор молчит совсем, либо довольно громко гудит на своих 55%, а при повышении температуры еще громче: 70%, 80% и 100%. При этом молчит он только до 50 градусов, а потом сразу начинает работать. Процессор стоит довольно горячий – Core 2 Duo T7600, меньше 50 градусов он бывает только сразу после включения, потом температура быстро становится выше, даже при нулевой нагрузке, и уже ни в какую не хочет опускаться ниже 50 C, только если раскрутить вентилятор на полную и оставить так на несколько минут, и то когда в комнате не очень жарко. На дефолтных 55% у вентилятора просто нет никаких шансов охладить процессор обратно ниже 50 С. Хотя может быть надо просто попробовать термопасту поменять, но сейчас речь не об этом.

С помощью программы я просто установил минимальную мощность равной 30% и поднял минимальную температуру, при которой включается вентилятор до 60 С. Температура корпуса при этом на ощупь почти не изменилась, как было довольно горячо, так и осталось, а вот тише стало намного. Днем вентилятор на 30% мощности можно услышать только если поднести к нему ухо. Ночью в тихой комнате его вполне слышно, но терпимо. Это гораздо лучше, чем было. Если еще чуть-чуть поднять минимальную температуру и перевести процессор и видеокарту в режим энергосбережения, можно получить абсолютно тихий ноутбук, только жесткий диск слышно как вращается, но это решается только заменой его на SSD, что вобщем-то в любом случае хорошо бы сделать. Короче, оказывается возможность полностью контролировать температуру и шум есть. Тут бы и сказочки конец, но это же под Windows, а мне надо под Linux!

Как оно под Linux

Под Linux такой программы нет. И как она работает, я честно говоря до сих пор до конца не понимаю, а на тот момент я там только подсмотрел ключевые слова, которые потом очень пригодились: ACPI и DSDT. К ним я еще вернусь позже. А пока, я перезагрузился обратно в Ubuntu и начал внимательно изучать предварительно нагугленный путь в sysfs: /sys/class/thermal. Там оказалось вот что:


Целых 10 cooling_devices и 6 thermal_zones. С термальными зонами более менее все ясно, температуры CPU, GPU, какие-то еще три точки, не особо важно. А последняя thermal_zone5 – это вовсе не температура, как выяснилось опытным путем, а текущая мощность вентилятора. Браво HP! Теперь понятно почему sensors-detect ничего не нашел, тут такой бардак, что черт ногу сломит. Вот так вот просто записав какое-нибудь число в thermal_zone5/temp поменять мощность нельзя. Файл только для чтения, оно и понятно.

Теперь посмотрим на cooling_device*, зачем их 10? Внутри каждой папки примерно вот такое содержание:


В файлах type для cooling_device c 0 по 6 написано Fan, в 7-8 — Processor, а в 9 — LCD. Хм, я точно знаю, что у меня в ноутбуке только один вентилятор. Процессоров, можно сказать, действительно два и есть один LCD экран, это правда. Но это же не cooling devices, зачем они тут? Ладно, будем пробовать разбираться дальше в этом бардаке. В файлах cur_state бывает либо 0, либо 1. Ага, похоже на какую-то такую развесистую битовую маску. Если попробовать во все cur_state записать нули с помощью «echo 0 | sudo tee /sys/thermal/cooling_device*/cur_state», то вентилятор остановится. А если записать единицу в cooling_device3/cur_state, то вентилятор закрутится на 55%. Ура, у меня получилось управлять вентилятором вручную в Убунте. Тут бы можно было бы сколхозить какой-нибудь демон на Питоне, который бы ставил нужные мощности при определенных температурах, но во-первых, так можно установить только «стандартные» мощности из набора 0, 55, 70, 80, 100, а мне теперь надо 30. А во-вторых, что-то же еще в системе меняет эти биты. Надо бы попробовать разобраться, что именно этим занимается и как на это можно влиять. Иначе говоря, «we have to go deeper». Тут я вспомнил про первое ключевое слово подсказанное той программой под Windows: ACPI.

Раз есть байт-код, значит где-то должен быть интерпретатор, который будет его исполнять. И действительно, ядро каждой ОС, которая поддерживает ACPI, должно содержать виртуальную машину для выполнения AML-кода DSDT и других таблиц. Есть она и в Linux. Вот и нашлось то, что меняет эти битики в файлах cur_state, это само ядро.

Код таблиц можно взять в sysfs, в директории /sys/firmware/acpi/tables/. Но сначала надо установить интеловский компилятор для ASL/AML, в Debian-based системах это делается так: «sudo apt-get install iasl». Потом просто сделав «sudo cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat» и «iasl -d /tmp/dsdt.dat», мы получим исходный код DSDT в файле /tmp/dsdt.dsl. ASL хоть и трудно читаемый, но довольно простой сам по себе язык, видимо, специально спроектированный так, чтобы было легче писать его интерпретаор, т. к. для каждой ОС он должен быть свой. Я довольно быстро разобрался как мне поменять мощности вентилятора, просто поискал те самые мощности (55, 70, 80, 100) переведя в шестнадцатеричную ситему и они сразу нашлись. Сборка делается командой «iasl -tc /tmp/dsdt.dsl».

При этом могут вылезти ошибки и предупреждения, причем в тех строках, которые вы и не трогали. Все говорят, что происходит это потому что почти все производители биосов пользуются компилятором от Microsoft, а он просто игнорирует многие ошибки, интеловский гораздо строже. Но у меня есть версия, что программисты просто отказываются нормально писать на этом дурацком языке. Помимо прочего, я в своем DSDT нашел довольно досадную опечатку в названии метода, который возвращает текущий уровень подсветки экрана из-за этого ядро при загрузке всегда ругалось «[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness», и при выходе из сна настройки подсветки всегда сбивались. Так что даже если с охлаждением у вас все в порядке, повод посмотреть на свой DSDT все равно есть. В сети полно рецептов, как исправлять те или иные ошибки в DSDT, здесь я не буду на этом подробно останавливаться.

Получается, что если мы можем декомпилировать, редактировать и компилировать обратно в байт-код DSDT и другие таблицы, то мы можем делать всё что угодно с питанием любых устройств. Теперь надо только как-то подсунуть ядру патченный DSDT. Делать это опасно, можно что-нибудь сжечь по неосторожности, поэтому 100 раз подумайте нужно ли оно вам, прежде чем делать что-либо из описанного ниже.

Как заставить ядро выполнять пропатченный DSDT

Весь AML-код хранится в BIOS и ядро, по умолчанию, берет его оттуда. Первое, что приходит в голову, сделать свой образ BIOS с патченной DSDT и прошить его. Риск получить кирпич очень велик, зато при удачном исходе все изменения будут доступны сразу во всех ОС, которые вы используете. Но, конечно, есть способы получше и побезопаснее.

Перед тем, как писать эту статью поискал, что есть на Хабре на эту тему и очень позавидовал тому, как просто это делается во FreeBSD.
Для Linux во всяких HowTo чаще всего советуют пересобрать ядро из исходников интегрировав туда свой DSDT. Таких инструкций много, там ничего сложного, на Хабре тоже про это есть, так что не буду про это ещё раз.

Раньше, до версии ядра 2.6, был удобный способ загрузки через initrd, но потом пришел Линус и сказал, что так делать плохо, а надо либо хорошо, либо никак, и способ убрали. Линусу придется поверить, раз он говорит, что так надо, значит надо.
Говорят, что ещё можно через GRUB2 ядру передать нужный DSDT. Ядро мне пересобирать очень не хотелось и я решил попробовать. Сначала я прописывал в конфиг груба только DSDT, у автора той статьи так работало, но ядро вообще его не грузило, в логе было примерно следующее:


Соответственно, ACPI вообще не работал. Страшное дело, между прочим. Wi-fi у меня при этом не работал, кнопка выключения выключала все сразу, а не запускала нормальный shutdown. Короче, пользоваться совсем нельзя. Потом я еще попробовал вообще все таблицы передать в параметрах, получилось так:


На этот раз была попытка загрузить DSDT, но там видимо есть какая-то ссылка на таблицу FACS, которую в данном окружении не получается разрешить. Немного помучившись с этим, раз 20 перезагрузив систему, мне так и не удалось заставить все работать этим способом. Плюнув на всё, поставил пересобираться ядро и лег спать, с утра все заработало как надо:


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

Я подготовил .aml файл с переписанным методом управления вентилятором и, радостно предвкушая как сейчас все замечательно заработает набираю «sudo cat ./fan-speeds.aml > /sys/kernel/debug/acpi/custom_method» и… получаю «zsh: permission denied: /sys/kernel/debug/acpi/custom_method». Как так permission denied? Я не забыл сделать sudo, директория /sys/kernel/debug/acpi/ судя по permissions открыта на запись для рута, нет никаких там immutable атрибутов и прочего. WTF? Оказалось, что эту фичу объявили дырой, т. к. якобы бывают такие окружения, где рут может не всё. Например, не может грузить модули ядра после того, как система полностью загрузится. Зачем и кому такое нужно, я честно говоря даже предполагать боюсь, но факт. Вроде бы в любой Убунте рут точно может делать все, что угодно, поэтому не очень понятно почему их Security Team тоже считает, что это очень серьезная уязвимость. К счастью, совсем это не выпилили из ядра, а просто выключили в конфиге по умолчанию и сделали возможность грузить отдельно, как модуль. Ну что же, собрать один модуль, это не тоже самое, что все ядро, а подключение модулей нам в Убунте, слава богу, пока не запретили.

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

Осталось как следует, а не по диагонали почитать спецификацию ACPI на досуге и подумать, что еще можно улучшить в ноутбуке. Программных проблем в системах охлаждения ноутбуков я теперь точно не боюсь. Надеюсь, что и вы теперь тоже, если вдруг боялись раньше.

В этом разделе представлены примеры проблем с управлением тепловыми режимами, а также обсуждаются требования и методы диагностики.

Примеры

В следующих примерах объясняется, как решать типичные проблемы с температурным управлением.

Датчики температуры для обложки

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

На следующей блоковой схеме показан пример макета системы с тремя устройствами и двумя температурными зонами.

макет системной платы с несколькими температурными датчиками и зонами

В этом примере датчик температуры 1 (TS1) и датчик температуры 2 (TS2) помещаются стратегически в местах, где устройства применяют наиболее тепло к обложке. Устройства 1, 2 и 3 могут иметь отдельный датчик температуры поверх каждого устройства. Эти датчики устройств нацелены на регулирование каждого устройства по отдельности. Как правило, цель датчика обложки — определить температуру на поверхности устройства как совокупность нескольких устройств в системе. Несмотря на то, что каждое устройство может выдавать больше тепла, чем может быть обнаружено на этих датчиках температуры, сочетание теплоотвода этих устройств, как правило, накапливается в этих расположениях датчиков.

TS1 помещается в середине между устройством 2 и устройством 3. Таким образом, термальная зона, которая принимает TS1 в качестве входных элементов управления для устройств 2 и 3. Когда TS1 становится горячий, термальная зона регулирует устройство 2 и 3. Аналогично, когда TS2 становится горячий, термальная зона регулирует все три устройства.

В этом примере датчики накладываются на те же самые далеко от отслеживаемых устройств. TS1 помещается в середине между устройством 2 и устройством 3, а TS2 помещается эквидистантная с устройств 1, 2 и 3. Если каждое устройство рассматривает тепло в радиальном режиме таким же образом, тепло от каждого устройства повлияет на показания температуры на датчике.

Постепенное регулирование температуры

Учитывая набор температурных констант (_TC1 и _TC2), в процентах пассивного регулирования в термальной зоне есть определенные характеристики: скорость изменения кривой и интенсивность, с которой регулировки зоны остаются далеко от точки поездки. В некоторых случаях может потребоваться изменить поведение термальной зоны. Например, если температура низкая, процент регулирования может быть менее агрессивным. Но если температура находится ближе к точке поездки, то поведение регулирования может потребоваться гораздо более агрессивно. В таком случае постепенное регулирование температуры можно использовать для применения различных поведений регулирования к набору устройств. Существует два способа реализации постепенного регулирования температуры:

  • Динамически изменяйте константы для термальной зоны во время выполнения или
  • Использование двух температурных зон с разными константами и точками путешествий.

Обновление констант для зон

Для любой термальной зоны Notify(thermal_zone, 0x81) можно использовать для обновления температурных констант в любое время.

Зоны с разными точками поездки

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

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

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

Две температурные зоны, показанные на предыдущей схеме, могут быть определены следующим образом:

Регулирование, зависящее от текущего

Если драйверу батареи требуется регулирование в зависимости от температуры и тока, то алгоритм ACPI в диспетчере температуры более не подходит, так как он не может принимать текущие учетные записи. Чтобы заменить этот алгоритм, необходимо предоставить драйвер политики, содержащий пользовательский алгоритм, и загрузить этот драйвер поверх стека драйверов для термальной зоны. Этот драйвер политики рассматривает как датчик температуры, так и текущий датчик как входные данные и приступает к политике температуры на основе настраиваемого алгоритма. Обратите внимание, что эта политика охлаждения должна действовать в рамках возможностей термальной зоны. Политика отправляется в Диспетчер температуры, который обновляет журналы и обновляет термальную зону. После этого термальная зона отправляет запросы к драйверу батареи через интерфейс охлаждения.

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

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

Требования к управлению тепловыми режимами

Требования к оборудованию

Для хорошего проектирования температурного оборудования необходимы следующие моменты:

Все системы соответствуют применимым отраслевым стандартам (например, IEC 62368) для обеспечения безопасности бытовой электроники.

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

Оборудование датчика должно быть точным до +/-2 o C.

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

Во время работы системная яркость экрана никогда не ограничена менее чем на 100 НИТС.

Заряд аккумулятора не регулируется в течение одного:

  • Система бездействует и находится в диапазоне окружающей температуры ниже 35 o C или
  • Температура окружающей среды ниже 25 o C при любых условиях.

Требования к тестированию ХКК для современных резервных ПК

Все современные резервные компьютеры должны отвечать определенным требованиям к температуре независимо от архитектуры процессора и конструктивного фактора. Эти требования проверяются в ХКК:

  • Все современные резервные компьютеры должны иметь по крайней мере одну тепловую зону.
  • Каждая тепловая зона должна сообщать о реальной температуре датчика.
  • По крайней мере одна тепловая зона должна иметь определенную частоту критических завершений работы. Исключение выполняется для динамической платформы Intel и термальной инфраструктуры (ДПТФ).
  • Все современные резервные компьютеры с вентиляторами должны обеспечивать работу вентилятора с операционной системой.
  • Вентилятору необходимо постоянно уведомлять операционную систему о его действиях, в том числе во время бездействия в современных ждущих режимах. В настоящее время эти уведомления не вызывают никаких действий с операционной системой. Основное назначение этих уведомлений — диагностика и телеметрии. уведомление о вентиляторе можно интегрировать с существующими средствами трассировки, включая анализатор производительности Windows. Разработчики систем могут использовать эти средства для настройки структуры платформы.
  • Все современные резервные компьютеры с вентиляторами должны отключить вентилятор в современном режиме ожидания, системное состояние "сон".
  • В этом тесте ХКК выполняется реалистичная современная Рабочая нагрузка, которая не должна приводить к включению вентилятора. Во время перехода на современные резервные вентиляторы могут оставаться в течение 30 секунд с момента отключения экрана.

Дополнительные сведения о тестах ХКК см. в разделе Проверка температурных зон.

Чтобы выполнить тесты ХКК, выполните следующие действия.

Сначала введите эту команду, чтобы установить драйвер кнопки:

Чтобы запустить все температурные тесты для ПК с вентилятором, введите следующую команду:

Чтобы запустить все температурные тесты для ПК без вентилятора, введите следующую команду:

>>RunCheckTz.cmd nofan all

Решения для управления тепловыми режимами

однако альтернативные решения для Windowsной тепловой инфраструктуры приемлемы, если соблюдены указанные выше требования. у основных поставщиков полупроводников и SoC могут быть собственные специализированные решения, совместимые с Windows — например, реализации на основе динамической платформы Intel и тепловой инфраструктуры (дптф) для процессоров x86 и реализаций PEP на ARM.

Диагностика

чтобы помочь проектировщикам системы диагностировать и оценивать температурное поведение системы, Windows предоставляет следующие входящие и автономные средства.

Журналы событий

Windows записывает важную информацию о температуре в журналы событий. эти сведения можно использовать для быстрого рассмотрения температурных условий на любом компьютере с Windows 8 или более поздней версии без необходимости дополнительной трассировки или средств. В следующей таблице содержится полный список.

Windows регистрирует это событие во время загрузки для каждой термальной зоны.

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

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

Уведомление о критическом событии

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

Используйте _CRT или метод _HOT термальной зоны ACPI, чтобы автоматически регистрировать критическое событие температуры. Дополнительная работа не требуется, кроме определения значения _CRT или _HOT.

Для всех других температурных решений драйвер может использовать следующий интерфейс событий термальной системы, который определен в файле заголовка Прокповр. h:

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

Version

Размер

Тип

Одно из значений THERMAL_EVENT_xxx из нтпоапи. h.

Температура

Температура (в десятых долях градуса Кельвина), на которую был получен датчик, после того как он пересекает точку поездки (или нуль, если она неизвестна).

триппоинттемпературе

Температура (в десятых долях градуса Кельвина) точки поездки (или ноль, если она неизвестна).

Инициатор

Указатель на строку расширенных символов, заканчивающуюся нулем и определяющую датчик, пороговое значение которого было перепутано.

Счетчики производительности

Счетчики производительности предлагают в режиме реального времени сведения о температуре системы. Для каждой термальной зоны опрашиваются следующие три части данных.

  • Процент пассивного ограничения— процент регулирования. 100 процентов означает, что зона не регулируется.
  • Температура— температура термальной зоны в градусах Кельвина.

Причина регулирования— причина регулирования зоны:

  • 0x0 — зона не регулируется
  • 0x1 — зона регулируется по соображениям температуры.
  • 0x2 — зона регулируется для ограничения тока в электрической сети.

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

Дополнительные сведения о счетчиках производительности в целом см. в разделе счетчики производительности.

Системный монитор

Системный монитор — это встроенное приложение для опроса и визуализации информации. Системный монитор может быть очень мощным средством для сравнения температурных условий для температурных схем системы. На следующих двух примерах снимков экрана показан монитор производительности в действии при запуске демонстрационной версии фишбовл в Internet Explorer. На первом снимке экрана монитор производительности показывает увеличение температуры для трех температурных зон с течением времени.

Диаграмма системного монитора, показывающая температуру трех температурных зон с течением времени

На втором снимке экрана монитор производительности сообщает о текущем проценте регулирования, температуре и причине регулирования.

Системный монитор сообщает о текущем проценте регулирования, температуре и причине регулирования

Дополнительные сведения см. в разделе Использование системного монитора.

Windows Анализатор производительности (WPA)

в составе ADK Windows предоставляет Windows производительности набор средств (WPT) для трассировки и анализа программного обеспечения. внутри WPT конструкторы систем могут использовать анализатор производительности Windows (WPA) для визуализации трассировок программного обеспечения и анализа поведения системы охлаждения. дополнительные сведения об установке и использовании WPA см. в разделе Windows Performance Analyzer (wpa).

включите "Microsoft-Windows-Kernel-ACPI", чтобы регистрировать события температуры, активности термальной зоны и работы вентиляторов.

включите «Microsoft-Windows-тепловый опрос», чтобы включить опрос температуры для каждой термальной зоны. Если этот параметр не включен, то сведения о температуре будут выводиться только при наведении на пассивные или активные точки поездки. Период опроса можно контролировать, указав флаг для поставщика.

Flag Период опроса
Нет 1 с
0x1 1 с
0x2 5 с
0x4 30 секунд
0x8 5 мин
0x10 30 минут

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

  1. Откройте ETL-файл с помощью средства WPA.
  2. в обозревателе Graphвыберите Power, а затем — служебная программа процессора.
  3. измените тип Graph на линии с накоплением.

На следующем снимке экрана показана диаграмма служебной программы процессора .

Диаграмма служебной программы процессора

Процент регулирования термальной зоны

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

  1. Откройте ETL-файл с помощью средства WPA.
  2. в обозревателе Graphвыберите Power, а затем сермалзоне регулирование устройства.
  3. Вы можете выбрать интересные устройства, Выменив фильтрацию.

На следующем снимке экрана показан график регулирования устройства сермалзоне и параметры фильтрации.

График регулирования устройства сермалзоне и параметры фильтрации

Температура термальной зоны

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

  1. Включите нужные поставщики при выполнении трассировки.
  2. Убедитесь, что счетчики производительности по-прежнему опрашиваются (системный монитор по-прежнему работает). Дополнительные сведения см. в разделе счетчики производительности.
  3. Откройте ETL-файл с помощью средства WPA.
  4. в обозревателе Graphвыберите Power, а затем — температура (K) по сермалзоне.
  5. Вы должны увидеть температуру по времени для каждой термальной зоны.

На следующем снимке экрана показана схема температуры по времени для пяти температурных зон.

Конфигурация компьютера
Процессор: Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
Память: PC3-12800 2x4Gb
HDD: APPLE SSD SM0256F 250GB
Видеокарта: Intel(R) Iris 5100
Блок питания: MAGSafe 2 60W
Ноутбук/нетбук: MacBook Pro MGX82RS/A
ОС: OS X 10.10.1 Yosemite

Принесли измученный детьми комп - мать DFI Lanparty UT 915P-T12, проц Intel P4 HT 531 3.0GHz LGA775.
Машинка, очевидно, давно страдала от перегрева (Prescott же), пытались менять термопасту и частично оборвали защёлки крепления кулера, БП был дрянной, да и хард, как позднее выяснилось, умер, впрочем не об этом речь.

Сменил сломанные защёлки (нашёлся кулер-донор), термопасту, установил проц как следует, сменил БП, сбросил CMOS, запускаем.
В биосе читаем температуру процессора 43-45, для прескотта в простое это вроде нормально, запускаем LiveCD и опа - через пару минут ядро орёт про критическую температуру ACPI CPU thermal zone 98C, и шатдаунит машину. Щупаю радиатор - чуть теплый. Может нету термоинтерфейса? ОК, отключаем вентилятор, запускаем машинку - радиатор сразу начинает ощутимо греться, следовательно, термоинтерфейс есть.

Вывод - датчик врёт! Или нет?

Выключаем в биосе ACPI, грузимся - полёт нормальный. Запускаем Cpuburn на час - вентилятор крутится на слух под 4000об/мин, радиатор терпимо горячий (

50C на ощупь), полёт нормальный. Не виснем, не выключаемся.

Тут бы и остановиться, но есть такие но:
- без ACPI не работает HT (польза от него спорная, но всё же);
- не работает саспенд, да и просто выключение не работает - приходится жать кнопку на корпусе;
- всё же хотелось бы мониторить температуру этой грелки.


Владельцы лэптопов (или ноутбуков, кому как удобнее), часто испытывают проблемы с охлаждением, тут сказывается недостаток места в корпусе и если охлаждение спроектировано не оптимально или электроника не качественная, то у пользователя рано или поздно появляются проблемы. Вентилятор гудит на полную мощность, хотя Вы ничего не делаете, а то и вовсе выключается. Раз Вы попали на эту страницу, значит этот вопрос Вас волнует. Что же, давайте разберёмся с этим вопросом. Если Вы начинающий пользователь, не бойтесь, я постараюсь сделать всё максимально доступно и сильно не вдаваться в технические вопросы.
Расставим точки над i - Описаное решение на 100% подходит Роса линуксу с рабочим окружением KDE, если у Вас другой дистрибутив или рабочее окружение, то некоторые команды следует заменить. Рассказывать про все варианты я не буду, это просто собьёт с толку.
Чистка кулеров (вентиляторов) тоже не входит, в руководство, на счёт этого скажу просто - кулер надо почистить В ПЕРВУЮ ОЧЕРЕДЬ и если не умеете, лучше отнесите в мастерскую, там его почистят, поменяют пасту и если что - переберут. (но не слушайте их, если скажут что линукс это не правильно, они его просто не знают)

Содержание

Как наблюдать за температурой

Запускаем системный монитор. Для этого нажмите на значок РокетЛаунчера (меню запуска приложений внизу слева на панели) и найдите Системный монитор и запустите его.


В список процессов можно сортировать по любому из столбцов Если не получается, не беда, вверху меню есть строка поиска, просто напишите в ней системный монитор он и появится. Что мы видим? список запущеных процессов, давайте сразу посмотрим, кто "ест" больше всех - нажмите вверху столбца % ЦП. Видите, больше всех ест системный монитор. Есть ещё одна вкладка Общая загрузка системы, посмотрим, загрузка процессора, занятая память, сеть, Температуры нет. Сейчас сделаем: в меню Файл выберите Новая вкладка.


Обратите внимание что как только частота поднимается, поднимается и температура.

Управление частотой процессора

Итак, начнём с проверки, загружен ли модуль ядра для управления частотой процессора (а вдруг). В РокетЛаунчере ищем Konsole (Терминал)

Kos-term1.jpg

В этом выводе нас интересуют строки:

driver: powernow-k8 Как видите, драйвер у меня загружен, у вас скорее всего будет другой драйвер, но главное он есть. available frequency steps 2.00 GHz, 1000 MHz, 500 MHz Частоты процессора на которых он может работать. The governor"ondemand" may decide which speed to use Политика энергосбережения, это тоже важно. ondemand - это хорошо. Итак всё в порядке, можете переходить к разделу Регулировка температуры

проблемы с модулем ядра

А тех же кому не повезло с драйвером (такое редко, но всётаки бывает), попрошу остаться. Если Вы видите это:

Видите? no or unknown cpufreq driver is active on this CPU Драйвер не загружен и поэтому не регулируется частота процессора. Что делать? Надо попробовать его загрузить, но какой выбрать? Есть много вариантов, но у Вас скорее всего один из этих:

  • acpi_cpufreq Если у Вас процессор Intel, то этот драйвер скорее всего подойдёт.
  • p4_clockmod, speedstep-ich, speedstep-smi - Линейка устаревших поцессоров Intel
  • powernow-k6, powernow-k7 и powernow-k8 процессоры AMD (старый, новее, новее)

Можете ввести команду cat /proc/cpuinfo, чтобы больше узнать о процессоре. Сильно не пугайтесь, если Вы попытаетесь загрузить не правильный драйвер - 1)он просто не загрузится, 2)его всегда можно выключить командой rmmod (и имя модуля) Теперь пробуем загрузить его вручную - переключаемся опять в консоль и пишем команду modprobe acpi_cpufreq или modprobe powernow-k8 или другой модуль, жмём Enter. Не ругается? Посмотрим, завелось ли? В консоли нажмите на клавиатуре клавишу "стрелка вверх", или "стрелка вниз", чтобы найти команду которой мы смотрели работу процессора (cpupower -c all frequency-info), потом нажмите Enter. Теперь показывает драйвер и частоту? Ура! Вы победили злобного дракона! Теперь команда cpupower -c all frequency-set -g ondemand указываем какую политику энергосбережения использовать Переходим к следующему разделу

Регулировка температуры

Посмотрим, что говорят наши датчики температуры? Опять же в консоли пишем sensors и видим:

Это у моего компьютера такое, обратите внимание на (crit = +105.0°C) - это температура до которой он не должен доходить, у вашего может и другая температура и датчик другой (но acpitz-virtual-0 всегда будет, на него и будем опираться).

Читайте также: