Bios aml acpi table что это
1. На оверах и на ROM.BY мне периодически встречались статьи (темы в форумах) людей о модификации ACPI таблиц своего компьютера.
2. В конце любой последовательности действий измененные таблицы предлагается шить в BIOS. Однако это не всем подходящая операция. Что же делать, куда нести свой ваучер?
3. Проклятая память! Если она меня не подводит - то года три назад я встречал на microsoft/hwdev (он был еще в .htm) упоминание о том, как можно сделать это гораздо изящнее - драйвер ACPI умеет загружать ACPI таблицы прописанные в реестре. К сожалению сохраненная статья сгинула с винчестером, по причине кривых hands - не моих
4. Однако поиск в сети (Google) в текущее время не приносил ничего - статья с microsoft/hwdev сгинула (к вопросу о постоянстве знаний в интернете). Только недавно обнаружилась презентация, из которой стало ясно, что память у меня хорошая и где была дана последовательность действий по загрузке ACPI таблиц в реестр. Бинго! За прошедшие три года MS оказывается даже автоматизировала данный процесс (к нашему удобству).
(Заодно можно взять и ASL первой версии).
2. Читаем help к нему. К нашей радости обнаруживаем искомое
asl [/nologo] [/loadtable [-v] [-d]] <AMLFile>
loadtable [-v] [-d] <AMLFile>
- overload existing table with one in the given AML file
<-d> - delete overridden tables
<-v> - Verbose
3. Каким либо образом корежим взятую из биоса исходную ACPI таблицу (извлекаем ее как голый BIN файл, декомпилируем интеловским iASL - ASL ассемблером/дизассемблером, правим текстовый файл, компилируем обратно микрософтовским или интеловским ассемблером).
4. Прописываем ее в реестр asl второй версии
asl /loadtable <скомпилированный ACPI таблица>
Вуаля - перегружаемся и наслаждаемся новой ACPI таблицей в работе.
Если хотим удалить - либо
asl /loadtable -d <скомпилированный ACPI таблица>
либо грохаем в реестре соответсвующую ветку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ACPI\Parameters\<имя ACPI таблицы>
ОТМАЗКА.
1. Микрософт упоминает, что для работы всего этого добра под XP/2003 необходима checked версия ACPI.SYS:
Microsoft Windows XP and Windows Server 2003 operating systems running checked versions of the ACPI driver allow for loading certain ACPI tables from the Windows registry instead of loading the table from the system's BIOS ROM.
.
The checked version of the ACPI driver acpi.sys must be running on the system.
Проверка работоспособности:
1. Для проверки я сначала загнал пустую DSDT таблицу в реестр - результат хорош - 98SE запустилась на VGA экране без одного одинешенького устройства, перечисляемого обычно в ACPI ветке. Но к ее чести загрузилась.
2. Затем грохнул в DSDT все упоминания COM портов - они не менее замечательно пропали из списка оборудования.
Если вам интересно, что именно изменилось за 10 месяцев разработки стандарта, и какими новшествами нас порадуют или огорчат будущие системы с поддержкой ACPI 6.0 — добро пожаловать под кат.
Что вообще такое ACPI
ACPI 6.0
С момента выпуска предыдущей версии 5.1. прошел почти год, но каких-то радикальных изменений в новом стандарте не случилось, что позволит производителям прошивок реализовать его поддержку в достаточно короткие сроки.
Для начала я перечислю все заметные изменения, а потом уже постараюсь дать развернутый комментарий по каждой группе. Поехали!
Поддержка NVDIMM
Поддержка USB-C
Add USB-C Connection support to _UPC — теперь у каждого USB-порта можно узнать, является ли он портом USB Type C и если да, то какие именно новые режимы поддерживает.
Обновление для языка ASL
Температуры, питания и производительность
Standby Thermal Trip — возможность при сильном превышении температуры какой-либо части платы перейти в S3 вместо полного отключения, что позволит потерять меньше данных.
Adding Support for Faster Thermal Sampling — возможность для производителя платы указать период опроса датчиков температуры (минимальное значение — 0,1 с), которой не было ранее. Позволит улучшить скорость реакции драйвера OSPM на изменения температуры компонентов.
Adjust max p-states — поддержка более 16 промежуточных состояний питания (по простому — пар «множитель CPU — желаемое напряжение») для находящейся под нагрузкой (т.е в состоянии С0) системы. Позволит точнее сэкономить еще немного энергии на мобильных ПК.
ACPI Low Power Idle Table and _LPD proposal — новые таблица и метод для перехода в энергосберегающие состояния LPI. Работают они пока только на Haswell и более новых процессорах Intel, только в Windows и только при наличии Intel Power Engine Plug-in, так что пока толку от этого новшества не много.
CPPC heterogeneous performance capabilities — поддержка технологии CPPC от Intel. Еще один способ управления нагрузкой, в добавок к десятку уже имеющихся. Тоже только для Haswell+, но на этот раз драйвером для Linux не обделили.
Поддержка архитектуры ARM
Остальное
Совсем немного про NVDIMM
Обещал рассказать, чем поддержка NVDIMM чревата простому пользователю — и расскажу.
Даже без самой NVDIMM (о плюсах которой можно почитать, например, здесь) таблица NFIT позволит прошивке отобразить любой непрерывный файл в память и сообщить ОС, что он там и что с него можно загрузиться. Это, в свою очередь, позволит UEFI загружаться не только с физических носителей, но и из ISO-образов, с виртуальных дисков, с любых блочных устройств (даже без ФС) и т.п. Фишку, скорее всего, подсмотрели у GRUB'а, который так умеет уже лет десять, но она от этого не становится менее полезной.
Заключение
В отличие от PI 1.4, в котором почти ничего интересного и не было, в новой версии ACPI добавилось несколько приятных как пользователю (NFIT, кнопки, USB-C), так и разработчику (ASL 2.0, новые макросы, больше возможностей для контроля температуры) вещей. Ну и самих себя UEFI Forum не обделили, добавив скопом все недавние энергосберегающие технологии Intel и оставив задел на будущую версию для ARM и Linaro.
Ждем теперь, когда производители UEFI-платформ (т.е AMI, Phoenix и Insyde) объявят и поддержке ACPI 6.0 в своих продуктах.
Итак, ACPI — это универсальный интерфейс к некоторым функциям аппаратного обеспечения современных компьютеров, от управления питанием и контроля состояния батарей до запроса возможностей подключенных внешних дисплеев.
Он состоит из нескольких конфигурационных таблиц, одна из которых содержит код для виртуальной машины, работающей в ядре операционной системы. Виртуальная машина, существенно усложняющая реализацию ACPI, была добавлена для того, чтобы сделать систему настолько гибкой, насколько это возможно.
Компьютер, который у меня есть — нетбук Samsung N250+. У него достаточно неплохое «железо» (за исключением охочей до батарейки и вообще кривой WiFi-карточки Broadcom, которую я сразу же заменил на аналогичую Atheros), но качество BIOS-а весьма печальное. На момент релиза не было даже возможности включить (или выключить) WiFi из Linux-системы: его состояние можно было изменить только через CMOS Setup Utility. На данный момент драйвер есть, но он использует фундаментально порочный подход, и страдает от некоторых проблем.
Исследование текущего состояния
Поддержка возможностей нетбука, для которых код в ACPI отсутствовал, изначально была реализована в модуле ядра easy slow down manager, который в итоге был принят в ядро как samsung-laptop.c.
Как видно на строке 725 исходного кода, этот драйвер использует вызовы SMI (и интерфейс Samsung под названием SABI) для того, чтобы устанавливать уровень подсветки, изменять «режим производительности» (который на самом деле всего лишь меняет скорость вращения вентиляторов) и включать питание беспроводному модулю. SMI-вызов — это команда, которая заставляет ЦП активировать так называемый режим управления системой (SMM), специальную возможность чипсета и процессора, одинаково похожую на гипервизор и руткит.
BIOS может настроить чипсет так, чтобы он перехватывал определенные операции (например, доступ к выбранным регионам памяти или портов ввода-вывода) и активировал SMM, ОС не может ни обнаружить факт входа в SMM (кроме как косвенными методами), ни прервать его, ни предотвратить. После этого, BIOS может выполнить произвольный код: например, SMM используется для того, чтобы сэмулировать для старых ОС (например, ДОС) поддержку PS/2-мыши в тех случаях, когда подключена USB-мышь. Более того, область памяти, выделенная для обработчика SMM, ни при каких обстоятельствах не доступна ОС, делая прямой анализ логики ее работы невозможным.
К счастью, в этом случае вызовы SMI, скорее всего, меняют лишь пару байтов, и, если повезет, можно будет определить их расположение, не изучая код режима SMM.
Рассмотрим поближе таблицы ACPI. Существует множество их типов, но в данном случае важна только одна, DSDT — таблица с байткодом обработчиков многих системных событий.
Для извлечения таблицы из системы и модификации ее кода нам потребуются две утилиты: «acpidump» и «iasl». На Debian-подобной ОС они находятся в пакетах с тем же названием.
Для наглядности, я оформил таблицу с историей моих изменений как репозиторий github; начальное состояние содержится в этом коммите. Как видно, таблица весьма длинная: более 5000 строк. Таблицы длиной более чем в 25000 строк встречаются вполне регулярно.
Чиним подсветку
У моего нетбука светодиодная подсветка, и поэтому ее яркость можно менять, просто включая ее на определенную долю одинаковых интервалов времени, например, для затемнения на 30% можно держать ее включенной 70% времени. Чтобы мерцание не было заметно, это переключение (ШИМ) происходит на частоте, заведомо превышающей чувствительность человеческого глаза — скажем, 200кГц вполне достаточно.
В данном случае, скважность ШИМ, вероятно, изменяется встроенным графическим контроллером. Вот он на шине PCI:
Цифры «00:02.0» — адрес устройства на шине. Зная этот адрес, можно запросить или изменить параметры устройства, так как Linux предоставляет множество точек управления через sysfs. Одна из них позволяет читать и записывать конфигурационное пространство PCI: блок из 256 байтов, в котором хранятся настройки устройства. Первые 64 байта в этом блоке имеют определенное спецификацией значение, а остальные могут свободно использоваться производителем для своих нужд.
Проверим, что происходит с конфигурацией при изменении уровня подсветки (несмотря на то, что здесь приведен пример для Linux с открытым драйвером, все это можно сделать и для закрытого драйвера или даже на Windows; считать конфигурационное пространство можно и в ней):
Таким образом, байт по адресу 0xf4 управляет уровнем подсветки. Можно в этом убедиться, запустив команду sudo setpci -s 00:02.0 f4.b=80 (заменив 80 на нужный уровень подсветки).
Теперь перепишем DSDT так, чтобы обновлялось это значение (и, возможно, в процессе этого получится узнать, почему управление подсветкой через ACPI вообще не работает):
Согласно спецификации ACPI (приложение B, раздел 6.2, стр. 704), совместимое описание графического адаптера должно реализовывать методы _BCL , _BCM и _BQC . В нашем DSDT эти методы определены на строке 1767. Вот их откоментированный исходный код:
Чтобы изменить этот код для работы через конфигурационное пространство PCI, нужно добавить новое поле в структуру, описывающую это пространство. Адрес адаптера 00:02.0 соответствует значению 0x0002000 в ACPI (раздел 6.1.1, стр. 200). Устройство с таким адресом определено на строке 1325; за определением следует описание конфигурационного пространства PCI.
Как было упомянуто, первые 64 (0x40) байтов в этом пространстве зарезервированы для внутреннего испольования. Из-за этого ACPI даже не включает их в регион; он определен как OperationRegion(IGDP, PCI_Config, 0x40, 0xC0) , где третий аргумент означает отступ с начала области PCI_Config. Поле, управляющее яркостью, расположено по адресу 0xf4 во всем пространстве, и 0xb4 в этом регионе.
За определением региона следуют определения полей. Вся конструкция Field представляет из себя поток битовых полей (длина определена в битах, а не байтах), одно за другим, перемежающееся указанием смещений (Offset), задаваемых, напротив, в байтах. Назовем наше поле BLVL и включим его в структуру:
Так как система имен ACPI иерархическая, это поле теперь доступно глобально под именем _SB.PCI0.IGD0.BLVL (имя составлено из вложенных конструкций Device и Scope), и методы для управления яркостью теперь можно переписать так, чтобы они обращались к полю BLVL напрямую:
Обновленная DSDT также лежит в репозитории.
Можно собрать ядро, установить его и перезагрузиться. Вуаля: теперь изменение яркости подсветки работает со стандартным драйвером ACPI. (Например, echo 7 >/sys/class/backlight/acpi_video0/brightness ).
Другие функции
Для того, чтобы найти другие похожие поля, изменяемые кодом в SMM, я написал простой скрипт. Нужно отметить, что некоторые устройства, а именно мосты PCI Express и сетевые адаптеры, порождают множество самопроизвольных изменений.
К сожалению, ни скорость вентилятора, ни выключатель беспроводного модуля не оказались связаны ни с какими изменениями в конфигурационном пространстве. Вероятно, они производятся через Embedded Controller или интерфейс SMBus, что означает отсутствие постоянных изменений в системной памяти.
Более того, даже если бы я обнаружил интерфейс отключения беспроводного модуля, я бы не смог использовать стандартный способ его представления системе — из-за отсутствия такого способа в природе. На ноутбуках, где этот интерфейс действительно задан в ACPI, существует платформенно-специфичный драйвер для его обработки (в отличие от подсветки, для которой существует общий стандарт).
Не знаю почему, но я всегда воспринимал системы охлаждения в ноутбуках как некий закрытый черный ящик. Тупость алгоритмов, по которым вентилятор начинал надрывно завывать при еще вполне холодном процессоре, изрядно раздражала во многих ноутбуках, но мне казалось, что все параметры там производители прибили гвоздями и поменять их можно разве что расковыряв 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 на досуге и подумать, что еще можно улучшить в ноутбуке. Программных проблем в системах охлаждения ноутбуков я теперь точно не боюсь. Надеюсь, что и вы теперь тоже, если вдруг боялись раньше.
Читайте также: