Дистрибутивы Linux и IRQ, или еще одна причина для пересборки ядра

Александр Еремеев aka Shurik

2005-09-27

Всё ниженаписанное ни в коей мере не претендует на академический труд и является моими собственными выводами (допускаю, что не всегда правильными, но уж такие вот получились), которые основаны на результатах многочисленных экспериментов как по установке ОС Linux (как пример: http://linux.alhimia.ru/projects/doc/asplinux-install/), так и последующей "доводке" конкретных дистрибутивов этой системы до рабочего состояния.

На написание этой статьи меня подтолкнули заявления разработчиков дистрибутивов (Red Hat(Fedora Core), ALTLinux, ASPLinux и пр.) о том, что ядро теперь нет необходимости пересобирать под конкретное "железо". Мол, и так всё хорошо работает. Именно по этой причине из дистрибутивов начали убирать исходники ядра. Зачастую - со специфическими патчами, которые влияют на стабильность системы в целом.

Хорошо... Только не всегда и не везде. На тематических форумах, наверное, каждому приходилось быть свидетелем того, что у одного... всё работает отлично, прямо из коробки..., а вот другой, примерно с таким-же "железом", мучается и не может понять - почему? Вот я и задался выяснить этот вопрос - почему?

Почему модем начинает набирать номер и в итоге может "повесить" всю систему? Почему не работает мышь, или клавиатура? Или плохо работает сетевая карта, или звук? И что-то мне начало смутно припоминаться... Поскольку всё это я уже проходил, только давно, когда ещё был Windows 95. Симптомы - один в один.

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

Но время шло, усложнялись как чипсеты для материнских плат, так и сами устройства, которые в эти материнские платы вставлялись. И вот тут инженеры, разрабатывающие материнские платы, пришли к выводу, что количество IRQ, управляемых BIOS, подошло к концу: всего их 16, а требовалось намного больше. В результате в BIOS появились 2 дополнительные опции - ACPI и APIC.

ACPI управляла питанием, результат - автоматическое включение/выключение компьютера, а так же являлось менеджером дополнительных (виртуальных) прерываний.

Функция APIC предоставила возможность без конфликтов работать двум устройствам на одном IRQ. Работая в паре, эти две опции прекрасно дополняют друг друга и "разводят" конфликлы оборудования на почве IRQ. Но! Процесс этот закрыт и на него нет специфической документации.

Основное при работе ACPI и APIC - это таблица DSDT, определяющая правила их работы. Она имеется в любой прошивке BIOS в бинарном виде. Intel открыла спецификацию на свои материнские платы и на алгоритм работы ACPI и APIC. Остальные производители - нет.

Всё правильно, вы абсолютно правильно догадались - именно это, в подавляющем большинстве случаев, и является причиной некорректной работы, или даже ощибок при непосредственной установке Linux и других UNIX. Всё зависит от того - как именно собрали ядро разработчики того или иного дистрибутива. И как распределил IRQ ACPI-менеджер, и включена в ядре опция APIC, или нет.

Можно задать вопрос:

Ну хорошо, INTEL открыла, остальные нет. Значит-ли это, что всё так плохо и нельзя ничего поделать?

Конечно-же нет! Можно и нужно! Для этого имеются два пути:

Заменить непосредственно в ядре "умолчальную" таблицу DSDT на свою, "родную".
Попытаться самостоятельно "развести" конфликты IRQ.

На первом способе я останавливаться не буду - он достаточно подробно описан на сайте http://mcmcc.bat.ru/ в статье Решение проблемы с IRQ на NForce2 материнках в Linux. Хочу только заметить, что способ этот, хотя и даёт 100-процентный результат, отнюдь не прост, и требует достаточно высоких знаний по програмированию и дизассемблированию.

А вот второй способ рассмотрим подробнее - на примере довольно распространённого чипсета NForce2. Вроде как никакого интереса он представлять не может - всё уже изучено и всё работает. Однако есть маленькое но, точнее 3 маленьких но - AGPGART, каскадный DMA-Mode и Dual Mode. Мною чётко выведена зависимость самой быстрой работы всех трёх позиций:

AGPGART - модулем
Каскад DMA-Mode (поддержка чипсета NForce2) - модулем
MTR - встроен в ядро
APIC - встроен в ядро

Самое забавное - Dual Mode начинает работат только в одном случае - если из секции Character Device убраны вообще все модули, кроме, естественно, NForce2.

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

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

Парадокс заключается в том, что для чипсета Intel, исходники драйвера для которого открыты, требования практически с точностью до наоборот - желательна поддержка AGPGART и чипсета на уровне ядра, а не модулем. Объясню - почему.

Поскольку спецификация открыта и таблица DSDT уже изначально "правильная", то и драйвера для данного чипсета тоже "правильные", и IRQ там распределено на уровне кода. Вполне естественно, что и работа вкомпилированных драйверов будет намного лучше и правильнее, чем модулей драйвера, где распределение IRQ доверено менеджеру ACPI. Соответственно, точно так же от этого зависит и работа мостов (северного и южного), всяких HUB-USB, IEE1394, IrDA, и прочих устройств. Распределились чётко IRQ, раскинулись на первые 16, управляемые BIOS, - чёткая работа всяких звуковух, сетевух, модемов (в особенности - WIN-модемов) гарантирована. Не распределились - жди проблем!

Распределение IRQ же напрямую зависит от реализации ACPI-менеджера и таблицы реализации виртуальных IRQ, то есть тех, которые выходят за 16-ый IRQ (19. 20. 21. и т.д.). При правильном распределении IRQ аппаратные устройства - те, которые выполнены в виде отдельно вставляемых модулей, как то звуковые, видео и прочие карты, а так же всевозможные контроллеры, должны "садиться" на распределение по таблице BIOS материнской платы.

Исключение - програмно реализуемый WIN-модем. WIN-модем - это виртуальный модем, который должен "садиться" на виртуальный IRQ, назначаемый ACPI-менеджером. Равно как и виртуальные устройства, подключённые к USB-HUB'у. Сам USB-HUB - вполне "материален", и должен занимать "реальный" IRQ. Устройства же, которые подключены к нему, - виртуальные, и соответственно должны иметь IRQ из виртуальной части. Но, если таблица IRQ в Intel открыта, то в NForce2 она закрыта и распределение IRQ происходит по по принципу - как Бог подаст. А подаёт он не всегда корректно.

Возникает вопрос: а как же тогда быть? Выход есть! Но он требует экспериментов для конкретного "железа", установленного в компьютере. Этот способ - вкомпилированный драйвер-модульный драйвер. Дело в том, что вкомпиленный драйвер и модульный драйвер по разному распределяют IRQ для одного и того же устройства. И именно на этом и можно сыграть!

Пример: звуковая карта Aureal Vortex2. Ещё в 1998 году под неё был написан драйвер. И по старой традиции присвоили ей IRQ5, как и положено для звуковой карты. Если драйвера вкомпилены в ядро, то именно IRQ5 этой карте и назначается, и работает она, как Т-34. Но! Стоит собрать те-же драйвера в виде модуля, как начинаются... варианты.

1. Звуковая карта может вообще не работать. Никак. Модули подгружены, всё вроде нормально, но висит она на IRQ19 (виртуальном). Вот и нет звука. Куда рыть?

2. Ладно, берём более старшую ветку ядра - 2.6.ххх. То же самое - модулем. IRQ вообще "улетает" на IRQ22. Класс... Результат:

ALSA - "тянет" звук;
eSound - наоборот, как пластинка на 33 оборота, проигрывается на 66 оборотов;
OSS - "квакает" и идёт рывками.

Вопрос - как и куда "рыть", скажем, начинающему? Да и не только начинающему - с таким может столкнуться любой. Что искать и как спросить? И какие рекомендации кто-либо может дать в этом случае человеку? Кривые руки? Или - а у меня всё работает?

Но ведь выход-то есть! Этот выход очень прост - достаточно пересобрать ядро, вкомпилировав драйвера для этой звуковой карты в ядро. И всё!

Еще пример: драйвера для сетевой карты - Intel Express PRO 100+. Там вообще имеются 2 драйвера - производителя (Intel) и свободный драйвер. Свободный драйвер можно как вкомпилировать в ядро, так и подгрузить модулем, драйвер Intel - доступен только как модуль. И комбинация модуль-вкомпиленный даёт 3 (три!!!) совершенно разных распределения IRQ! Но дело в том, что в свободном драйвере нет возможности чётко задать IRQ, в отличии от драйвера Intel, в котором, при загрузке модулем, имеется возможность не только установить IRQ, но и задать дополнительные параметры, как-то Full Duplex, Half Duplex и т.д. С одной стороны свободный драйвер работает хорошо (если IRQ распределился правильно), с другой стороны менять его параметры и IRQ нельзя. Ставится он в любом дистрибутиве "по умолчанию". С другой стороны драйвер Intel - подгружать можно только модулём, но зато с любыми параметрами, включая принудительный IRQ.

Точно в такой же мере это относится, к примеру, и к сетевым картам 3COM.

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

В любом случае пересборка ядра именно под свою систему и именно под своё "железо" необходима. Во всяком случае, для платформы NForce2. Хотя не думаю, что на других закрытых чипсетах (VIA, SIS, и пр.) дело обстоит намного лучше.