CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
22.10.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

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

Всё ниженаписанное ни в коей мере не претендует на академический труд и является моими собственными выводами (допускаю, что не всегда правильными, но уж такие вот получились), которые основаны на результатах многочисленных экспериментов как по установке ОС 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 открыла, остальные нет. Значит-ли это, что всё так плохо и нельзя ничего поделать?

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

  1. Заменить непосредственно в ядре "умолчальную" таблицу DSDT на свою, "родную".
  2. Попытаться самостоятельно "развести" конфликты 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, и пр.) дело обстоит намного лучше.





Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds