Шины PCI, USB и FireWire
Шрифт:
• идентификатор шины, на которой расположен источник;
• идентификатор запроса на этой шине;
• идентификатор и номер входа APIC, к которому подключен данный запрос.
Согласно MPS, для симметричных систем допустимы векторы в диапазоне 10h—FEh. Уровень приоритета прерывания определяется номером его вектора, деленным на 16. Самый приоритетный уровень – нулевой.
Выделение для сообщений APIC отдельной локальной шины позволяет освободить системную шину процессора от трафика, связанного с обслуживанием прерываний (подачи подтверждений прерываний для получения вектора). В современных процессорах используется локальная шина, состоящая из трех сигнальных линий: PICD[1:0] – двунаправленная шина данных и PICCLK – сигнал синхронизации (тактовая частота). Протокол шины обеспечивает распределенный механизм арбитража: в любой момент времени каждый APIC (локальный и I/O APIC) имеет уникальное значение приоритета арбитража (0–15),
Контроллер I/O APIC позволяет вырабатывать значительное число запросов прерываний; каждому запросу соответствует свой элемент в таблице перенаправлений, находящейся в APIC. Каждый элемент определяет способ реакции на свой запрос, вектор прерывания и процессор (процессоры) назначения, которые должны его обработать. С запросами связаны индивидуальные входы INTINn; определенный уровень или перепад сигнала на этих входах вызывает соответствующие запросы. Чувствительность и вектор (следовательно, и приоритет) для каждого запроса программируется индивидуально. Более совершенные модели I/O APIC позволяют вызывать прерывание и записью номера входа в регистр контроллера, что, например, используются для поддержки прерываний MSI на шине PCI. При этом возможна и экономия сигнальных входов: APIC может иметь входы INTINn не для всех номеров запросов, посылаемых через запись в этот регистр. Однако число запросов всегда ограничивается размером таблицы перенаправлений.
Регистры контроллеров APIC отображаются на пространство памяти. Все локальные контроллеры APIC используют один и тот же диапазон адресов (по умолчанию базовый адрес FEE0 0000h) – к их регистрам обращаются только программы, исполняемые на их же процессорах, и эти обращения не выводятся на системную шину. Контроллеры I/O APIC доступны всем процессорам, по умолчанию базовый адрес первого I/O APIC – FEC0 0000h, базовые адреса остальных контроллеров (если таковые имеются) назначаются последовательно с шагом 1000h. Часть регистров адресуется непосредственно (табл. 3.4), большая часть регистров, включая и таблицу перенаправлений, адресуется косвенно (табл. 3.5).
Кроме использования последовательной локальной шины есть и иной вариант доставки сообщений к локальным APIC, использущий обращения к пространству памяти. Для этого локальные APIC настраиваются на отслеживание операций записи по определенным адресам. Источник сообщений выполняет операцию записи в пространство памяти, в которой и адрес и данные несут информацию о событии прерывания (табл. 3.8). В качестве источника сообщений может выступать расширенный контроллер, называемый I/O(x)APIC. Вышеупомянутый хаб ICH3 имеет возможность работы в режиме I/O(x)APIC.
Проблема разделяемых прерываний
Линии запросов прерываний в компьютере, насыщенном периферийными устройствами, являются самым дефицитным ресурсом, поэтому приходится использовать эти линии совместно, то есть применять разделяемые прерывания между несколькими устройствами (shared interrupts). Для шины PCI с аппаратной точки зрения проблема разделения прерываний решена – здесь активным уровнем запроса является низкий, и контроллер прерываний чувствителен к уровню, а не перепаду. Для шины ISA с ее запросами прерываний по положительному перепаду разделяемость прерываний невозможна. Исключения составляют системные платы и устройства с поддержкой ISA PnP, которые можно заставить работать и по низкому уровню.
После успешного решения аппаратной задачи обеспечения разделяемости линий запроса возникает задача идентификации источника каждого прерывания, чтобы запустить выполнение соответствующей процедуры обработки. Желательно, чтобы эта задача решалась средствами ОС и с минимальными потерями времени.
В первых версиях PCI (до PCI 2.2 включительно) не было общепринятого способа программной индикации и запрета прерываний. К сожалению, в конфигурационных регистрах не нашлось стандартного места для бита, индицирующего введение запроса прерывания данным устройством, – тогда бы в прерываниях для PCI не было бы проблем с унификацией поддержки разделяемых прерываний. В каждом устройстве для работы с прерываниями используются свои специфические биты операционных регистров, относящихся к пространству памяти или ввода/вывода (иногда и к конфигурационному). При этом определить, является ли данное устройство в текущий момент источником прерывания, может только его обработчик прерывания (ISR, Interrupt Service Routine),
входящий в драйвер данного устройства. Таким образом, у ОС нет иной возможности диспетчеризации разделяемых прерываний, кроме как выстроить их ISR-ы в цепочку. За расторопность и корректность ISR отвечает его разработчик. В PCI 2.3 наконец-то появился фиксированный бит (interrupt Status) в регистре состояния конфигурационного пространства устройства (функции), по которому ОС может определить источник разделяемого прерывания и вызвать только его ISR. Однако упоминание о поддержке PCI 2.3 в описаниях устройств и операционных систем встречается не часто.Обработчики прерываний устройств должны вести себя корректно, учитывая возможность попадания в цепочку обработчиков разделяемого прерывания. В процессе обработки прерывания очередной обработчик в цепочке чтением известного ему регистра своего устройства должен определить, не это ли устройство вызвало прерывание. Если это, то обработчик должен выполнить необходимые действия и сбросить сигнал запроса прерывания от своего устройства, после чего передать управление следующему обработчику в цепочке; в противном случае он просто передает управление следующему обработчику. Встречается типичная ошибка обработчика прерываний: прочитав регистр состояния устройства и не обнаружив признака запроса, драйвер «на всякий случай» выполняет сброс всех источников запроса (а то и сброс всего устройства). Эту ошибку порождает незадачливый разработчик драйвера, не учитывающий возможности разделяемости прерываний и не доверяющий разработчикам аппаратных средств. Увидев в процессе отладки эту неожиданную ситуацию (прерывание вызвано, а источник не виден), он ее «учитывает» введением вредного фрагмента программного кода. Вредность заключается в том, что с момента чтения регистра устройства (не давшего признака запроса) и до выполнения этого ненужного сброса в устройстве может возникнуть запрос прерывания, который будет «вслепую» сброшен и, следовательно, потерян.
Однако и при корректности обработчиков, выстроенных в цепочку, разделяемые прерывания для разнотипных устройств в общем случае работоспособными считать нельзя – возможны потери прерываний от устройств, требующих быстрой реакции. Это может происходить, если обработчик такого устройства окажется в конце цепочки, а предшествующие ему обработчики окажутся «нерасторопными» (не самым быстрым способом обнаружат, что прерывание – чужое). Поведение системы в такой ситуации может меняться в зависимости от порядка загрузки драйверов. Для нескольких однотипных устройств (например, сетевых адаптеров на однотипных микросхемах контроллеров), пользующихся одним драйвером, разделяемые прерывания работают вполне успешно.
Проявления конфликтов по прерываниям могут быть разнообразными. Сетевая карта не сможет принимать кадры из сети или будет их иногда терять (при этом она может их успешно посылать). У устройств хранения доступ к данным будет поразительно медленным (иногда можно минутами ожидать, например, появления информации о файлах и каталогах) или вообще невозможным. Звуковые карты будут молчать или «заикаться», на видеопроигрывателях изображение будет дергаться и т. д. Конфликты могут приводить и к внезапным перезагрузкам компьютера, например по приходу кадра из сети или сигналу от модема. Спасением от бед разделяемости может быть перестановка карт PCI в подходящий слот, в котором конфликты не наблюдаются (это может и не означать, что их нет). Однако попадаются «подарки разработчиков» интегрированных плат, у которых из нескольких слотов PCI неразделяемая линия прерывания есть только у одного (а то и нет вообще). Такие недуги без скальпеля и паяльника, как правило, не лечатся. Более радикальный способ – переход на сигнализацию прерываний через сообщения – MSI (см. ниже).
Традиционные прерывания PCI–INTx#
Для устройств PCI выделяется четыре проводных линии запросов (IRQX, IRQY, IRQZ, IRQW), соединяемых с контактами INTA#, INTB#, INTC# и INTD# всех слотов PCI с циклическим смещением цепей (см. рис. 3.1). Соответствие линий INTx# и входов IRQ для устройства любой шины PCI приведено в табл. 3.9. Мосты PCI просто электрически соединяют одноименные линии INTx своих первичных и вторичных шин. В системах с APIC, в которых число входов запросов увеличено до 24, дополнительные 8 входов могут использоваться периферийными устройствами, установленными на системной плате. На слотах PCI остаются доступными лишь четыре обычные линии запросов.
Устройство PCI вводит сигнал прерывания низким уровнем (выходом с открытым коллектором или стоком) на выбранную линию INTx#. Этот сигнал должен удерживаться до тех пор, пока программный драйвер, вызванный по прерыванию, не сбросит запрос прерывания, обратившись по шине к данному устройству. Если после этого контроллер прерываний снова обнаруживает низкий уровень на линии запроса, это означает, что запрос на ту же линию ввело другое устройство, разделяющее данную линию с первым, и оно тоже требует обслуживания.