Техчасть под катом.
Желание поставить Ubuntu на свою машинку возникло через месяц после покупки ноута. Черно-серенькая Toshiba A200 13O была куплена так сказать по любви, а не по расчету. Началось все с убийства шедшей на борту Висты, которая по некоторым субъективным причинам и из-за программной регулировки яркости была ликвидирована. Был установлен с сайта произодителя биос под хрюшу(под Висту на сайте свой биос, под ХРюшу-свой). Появилась аппаратная регулировка яркости и тп. Но после не очень удобных, но приятных на вид красивостей под Вистой, на Хрюше было работать довольно уныло. Все-таки охота идти вперед. А еще хотелось не париться с вирусней — приходить в офис с ноутом с линухой и не думать, что при обслуживании можешь заразить кучку виндовских машинок с проектами, что в денежном выражении принесет конторе нехилый убыток.

Ещё в Ubuntu 7.10 было включено довольно спорное нововведение, позволяющее экономить заряд батареи ноутбука, вводя с частым промежутком времени жёсткий диск в спящий режим. При текущих установках, за 100 часов работы с ноутбуком жесткий диск переводился в спящий режим 7000 раз (ресурс диска — 600000), т.е. почти раз в минуту.
Однако лишь сейчас в тестовый репозиторий «proposed» для версий дистрибутива 8.04, 8.10 и 9.04 была помещена исправленная версия пакета acpi-support. Ожидается, что в скорейшем времени пакет будет включён в основные репозитории.

Мне было влом гемороиться со скриптами acpi, да и на ноутбуке 2 пользователя, использующих разный набор программ, поэтому я решил написать простой скрипт

Здравствуй, хабра-человек.
Как известно, Microsoft очень хорошо потрудилась над своим последним детищем по имени Windows 7 и внесла много различных нововведений, об одном из которых я и хочу рассказать. Особенно актуально, я думаю, это будет для владельцев ноутбуков и нетбуков, но и пользователи настольных систем так же могут получить профит.
Как известно, самое большое новшество в «семерке» (после GUI) — это переработанная подсистема ACPI. Тут и нормальная поддержка многоядерных систем, и управление питанием устройств, мониторинга аппаратных средств, да и много чего еще, но одна очень интересная возможность остается за кадром — речь идет об энергопотреблении и управлении ядрами многоядерных/многопроцессорных систем.

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

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

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

Несколько лет назад, когда CardBus и FireWire (IEEE 1394) еще были относительно «в ходу», многие производители ноутбуков в своей продукции использовали контроллеры семейства PCIXX21 и PCIXX11 фирмы Texas Instruments: один небольшой чип обеспечивал поддержку не только упомянутых интерфейсов, но и многих популярных стандартов сменных карт памяти.

Такой чип (а именно, PCI7411) стоит и в моей NEC Versa S950. Этот малоизвестный ноутбук я в свое время предпочел даже ThinkPad-серии практически исключительно из-за более лучшей поддержки FreeBSD (оборудования в целом и спящего режима в частности) — специально тестировал в новосибирском Техносити перед покупкой. Долгое время я не пользовался встроенным кард-ридером, по привычке обходясь USB'шными «свистками». Но недавно я обнаружил, что FreeBSD до сих пор его не поддерживает. И если лет пять-шесть назад это можно было объяснить отсутствием нормального драйвера для этих контроллеров (нужно было что-то скачивать и собирать самому), то теперь я точно знал, что они «из коробки» поддерживаются во FreeBSD драйвером sdhci(4), о чем прямо сказано на странице руководства (и позже подтвердилось чтением исходников).

Я начал неспешно гуглить на эту тему, и картина стала вырисовываться невеселая. Оказалось, что таких «счастливчиков», как я, немало. Многие постили в рассылки и форумы «портянки» dmesg и pciconf -lv, заводили баги в трекерах (например, OpenBSD PR i386/5843), но решения никто не предлагал. Более того, фактически поставив точку в вопросе, Александр Мотин, автор драйвера sdhci(4), в 2010 г. написал на форуме, что-де TI документацию на чип не дают, а значит, если производитель сконфигурировал чип неверно, а его настройка через BIOS не предусмотрена, сделать что-либо затруднительно. В свою очередь, Theo de Raadt закрыл i386/5843 со словами: «We do what we can. This vendor, amongst other, have their sdhc controllers locked out and hidden behind little undocumented bits. We've strugged before to find this information, and failed. If you can find this information on some other operating system, or in some vendor documentation, we would be thrilled.»

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

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

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

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

Просто так выполнять какие-то вычисления на ядрах процессора – скучно, поэтому нужна задача, которая требует больших вычислительных ресурсов, хорошо раскладывается на параллельные вычисления, да и выглядит прикольно. Предлагаем сделать программу, которая рендерит простенькую 3D-сцену, используя алгоритм обратной трассировки лучей, или, по-простому, Ray Tracing.

Начнем с самого начала: наша цель параллельные вычисления на всех ядрах процессора. Все современные процессоры для PC, да и ARM уже тоже (я молчу про GPU) – это многоядерные процессоры. Что же это означает? Это означает, что вместо одного вычислительного ядра у процессора на одном компьютере присутствует несколько ядер. В общем случае, все выглядит несколько сложнее: на компьютере может быть установлено несколько сокетов (чипов процессора), в рамках каждого чипа (в рамках одного кристалла) может находиться сразу несколько физических ядер, а в рамках каждого физического ядра может находиться несколько логических ядер (например, те, что возникают при использовании технологии Hyper Threading). Все это схематично представлено на рисунке ниже, и называется топологией.

Wake-on-LAN (WOL; в переводе с англ. — «пробуждение по [сигналу из] локальной сети») — технология, позволяющая удалённо включить компьютер посредством отправки через локальную сеть специальной последовательности байтов. wiki

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

В современных десктопных и (в особенности) мобильных процессорах применяется целый ряд энергосберегающих технологий: ODCM, CxE, EIST и др. Сегодня нас будет интересовать, пожалуй, самая высокоуровневая из них: гибкое управление частотой и напряжением процессорного ядра во время работы — Cool 'n' Quiet, PowerNow! у AMD и Enhanced SpeedStep (EIST) у Intel.

Чаще всего пользователю компьютера или ноутбука достаточно просто включить (поставить галочку) поддержку той или иной технологии в BIOS и/или операционной системе — никакой тонкой настройки обычно не предусмотрено, хотя, как показывает практика, она может оказаться весьма полезной. В этой статье я расскажу о том, как можно управлять рабочим напряжением ядра процессора из операционной системы (на примере Intel Pentium M и FreeBSD), и зачем это может понадобиться.

Несмотря на большое количество руководств, редко где встретишь обстоятельное описание технологии Enhanced SpeedStep с точки зрения операционной системы (а не конечного пользователя), особенно на русском языке, поэтому значительная часть статьи посвящена деталям реализации и носит в некоторой степени теоретический характер.

Надеюсь, статья окажется полезной не только пользователям FreeBSD: мы также немного коснемся GNU/Linux, Windows и Mac OS X. Впрочем, в данном случае конкретная операционная система имеет второстепенное значение.

OEM-версии ОС от Microsoft, начиная с Vista, используют проверку подлинности, основанную на сличении трех компонентов:

• OEM-сертификата, вшитого в дистрибутив ОС
• бинарного ключа, вшитого в BIOS, а конкретно — в таблицу ACPI SLIC
• лицензионного 25-значного ключа производителя, вшитого в дистрибутив ОС

При успешном сличении трех этих компонентов происходит оффлайн-активация ОС. На корпусе ПК в этом случае имеется наклейка, содержащая лицензионный ключ конкретного экземпляра ОС (а не производителя), которым можно произвести онлайн-активацию ОС в случае ее установки не с образа, предоставляемого производителем ПК, а с «чистого» (MSDN) OEM-образа от Microsoft.

Кроме того, лицензионный ключ конкретного экземпляра ОС может быть вшит в текстовом виде в BIOS, в таблицу ACPI MSDM. В этом случае, при установке ОС ключ будет извлечен из BIOS и вшит в конкретный экземпляр ОС. OEM-наклейка на корпусе ноутбука в этом случае может уже не содержать лицензионный ключ. Такой способ используется для активации Windows 8/8.1

После полугода разработки организация UEFI Forum выложила наконец в открытый доступ документацию по новым стандартам Platform Initialization 1.4, Advanced Configuration and Power Interface 6.0 и Unified Extensible Firmware Interface 2.5, на базе которых сейчас разрабатывается абсолютное большинство прошивок для ПК и серверов.
Обычно между выпуском новых версий стандартов и первыми прошивками на их базе проходит обычно от 4 до 6 месяцев, но уже сейчас можно предсказать с высокой долей вероятности, какие именно новые возможности появятся в UEFI для платформ на базе процессоров Intel Skylake и AMD Falcon Series.
Я решил разделить описание новшеств на 3 части, иначе оно рискует оказаться очень длинным и читать его никто не станет. Если вас интересуют новшества, описанные в стандарте PI 1.4 и мои комментарии к ним — добро пожаловать под кат.

Продолжаем знакомство с новыми возможностями недавно вышедших из под пера UEFI Forum стандартов, и если в предыдущей части речь шла о внутреннем стандарте PI, то на этот раз она пойдет об ACPI 6.0 и его отличиях от предыдущей версии 5.1.
Если вам интересно, что именно изменилось за 10 месяцев разработки стандарта, и какими новшествами нас порадуют или огорчат будущие системы с поддержкой ACPI 6.0 — добро пожаловать под кат.

Лирика

За прошедшие пару месяцев мне довольно часто приходилось вступать в дискуссии о всевозможных портативных компьютерах: ломать копья в спорах какой производитель лучше и почему, обсуждать совместимость с GNU/Linux и то, как в этой системе настроить ту или иную функцию и, периодически, меня таки просят поделиться конфигами. Под влиянием этих самых обсуждений и родилась данная статья.

Большую часть своего компьютерного стажа я пользуюсь лаптопами так называемой «бизнес серии»: IBM ThinkPad 600, HP-Compaq nc2400, Lenovo ThinkPad X61T, Lenovo ThinkPad X220.



Были кратковременные перерывы, когда приходилось перебиваться абы-чем, то бишь компьютерами потребительского сегмента: Apple ibook G4 и Acer aspire 5112 и именно в эти моменты приходило понимание того, как сильно не хватает таких очевидных и привычных вещей, как трекпоинт и док-станция.

У каждого админа, пожалуй, был случай, когда что-то внезапно ломается, а ты где-нибудь в дороге: едешь на машине, садишься на поезд или, банально, сидишь где-то на скамейке в парке и срываться и куда-то нестись желания нет ни малейшего. А чинить надо. Или, как минимум, оценить масштабы пришедшего белого пушного зверька.

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



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

Постановка задачи

В Linux есть стандартный интерфейс для работы с GPIO через sysfs. Документацию на него можно посмотреть тут.

Если кратко, то в папке "/sys/class/gpio" есть файлы «export» и «unexport». С помощью записи числа X в файл export можно открыть интерфейс в user space для управления GPIOX

# открыть интерфейс в user space для управления GPIO12
$ echo 12 > /sys/class/gpio/export

После открытия интерфейса появится папка /sys/class/gpio/gpioX/ в которой будут такие файлы как «value» или «direction», и путём записи «in» или «out» в файл «direction» и записи 1 или 0 в файл «value» можно управлять выводом GPIO напрямую через командную строку.

# настроить GPIO на вывод
$ echo "out" > /sys/class/gpio/gpio12/direction

# установить 1 на выводе GPIO
$ echo 1 > /sys/class/gpio/gpio12/value

Чтобы команда «echo X > /sys/class/gpio/export» приводила к созданию папки «gpioX», в ядре должен быть зарегистрирован драйвер контроллера GPIO, открывающий интерфейс к линиям GPIO.

Так получилось, что я работаю над портированием coreboot для кастомной платы на базе процессора Intel Haswell i7 [Для тех, кто не знает, coreboot это open source проект по созданию BIOS с открытым исходным кодом (https://www.coreboot.org/)]. В мой процессор встроен южный мост LynxpointLP в котором есть 94 линии GPIO. И я захотел открыть их в sysfs…

В данной статье хотелось бы рассмотреть механизмы доставки прерываний от внешних устройств в системе x86 и попытаться ответить на вопросы:

• что такое PIC и для чего он нужен?
• что такое APIC и для чего он нужен? Для чего нужны LAPIC и I/O APIC?
• в чём отличия APIC, xAPIC и x2APIC?
• что такое MSI? В чём отличия MSI и MSI-X?
• как с этим связаны таблицы $PIR, MPtable, ACPI?

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

В предыдущей части мы рассмотрели эволюцию доставки прерываний от устройств в x86 системах (PIC → APIC → MSI), общую теорию и все необходимые термины.

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

• pci=nomsi
• noapic
• nolapic

Также мы посмотрим на порядок, в котором ОС смотрит таблицы роутинга прерываний (ACPI/MPtable/$PIR) и какое влияние на него окажет добавление опций загрузки:

• pci=noacpi
• acpi=noirq
• acpi=off

Возможно вы пробовали комбинации из всех этих опций, когда какое-либо устройство не работало из-за проблемы с прерываниями. Разберём, что именно они делают и как они меняют вывод /proc/interrupts.