OSDev

Всё гораздо проще. Вот из доков Intel на мой любимый PIIX4.

In both the edge and level triggered modes, the IRQ inputs must remain active until after the falling edge of
the first INTA#. If the IRQ input goes inactive before this time, a default IRQ7 occurs when the CPU
acknowledges the interrupt. This can be a useful safeguard for detecting interrupts caused by spurious noise
glitches on the IRQ inputs. To implement this feature, the IRQ7 routine is used for “clean up” simply executing
a return instruction, thus ignoring the interrupt. If IRQ7 is needed for other purposes, a default IRQ7 can still
be detected by reading the ISR. A normal IRQ7 interrupt sets the corresponding ISR bit; a default IRQ7 does
not set this bit. However, If a default IRQ7 routine occurs during a normal IRQ7 routine, the ISR remains set.
In this case, it is necessary to keep track of whether or not the IRQ7 routine was previously entered. If another
IRQ7 occurs, it is a default.

В обоих режимах тригера: "фронта" и "уровеня" входы IRQ должны оставаться активными пока не будет обратный фронт от первого INTA. Если вход IRQ переходит в неактивное состояние, то происходит прерывание по умолчанию IRQ7, во время одобрение прерывания. Это может быть полезной гарантией для того, чтобы обнаружить перерывания, вызванные шумом, искажениями на входах IRQ. Чтобы реализовать эту опцию, обработчик IRQ7 используется для, "очистки" просто напросто выполняет инструкцию
инструкция по возвращению, таким образом игнорируя перерывания. Обычный, неподдельный, не ошибочный IRQ7 также возможно распознать при помощи чтения ISR.

А да да и в доке на сам 8259A PROGRAMMABLE INTERRUPT CONTROLLER (8259A/8259A-2)
От 1988 года тоже самое говорится.

If no interrupt request is present at step 4 of either
sequence (i.e., the request was too short in duration)
the 8259A will issue an interrupt level 7. Both the
vectoring bytes and the CAS lines will look like an
interrupt level 7 was requested.
When the 8259A PIC receives an interrupt, INT becomes
active and an interrupt acknowledge cycle is
started. If a higher priority interrupt occurs between
the two INTA pulses, the INT line goes inactive immediately
after the second INTA pulse. After an unspecified
amount of time the INT line is activated
again to signify the higher priority interrupt waiting
for service. This inactive time is not specified and
can vary between parts. The designer should be
aware of this consideration when designing a system
which uses the 8259A. It is recommended that
proper asynchronous design techniques be followed.

И в чём именно бред?



Что значит "фиксация прерывания"? Если фиксация _запроса_ прерывания, то она производится только для запросов, распознаваемых по фронту, а запросы по уровню не фиксируются, почему и могут быть потеряны. Если же имеется в виду фиксация факта передачи запроса прерывания на обработку процессору (установкой соответствующего бита в ISR), то она производится в во время передачи запроса процессору, а в этот момент собственно запрос может быть потерян (если он распознавался по уровню и соответствующая линия IRQ вдруг стала неактивной), что, собственно, и создаёт проблемы.



Я ж написал -- "не совсем понятно". Разбираться у меня особого желания с этим не было, а из документации на ICH10 не всё было очевидно.

Кстати говоря, ссылаться на документацию на сам 8259 рискованно: реализация PIC в чипсетах далеко не соответствует оригинальной (хотя б потому, что половина функций и режимов не реализована вообще, поскольку на ПК она использоваться не может). Так что надо разбираться именно с документацией на достаточно современные южные мосты.

Вы не правы.
Цитирую ICH10


Написано что фиксируется.
Поэтому вы не правы.


Снова ошибка. ISR устанавливается не во время передачи запросу процессору, а во время ответа процессора.



Это домыслы.



Интел сами пишут что прерывание должны быть активны.


Все проще. Вектор 7 служи для обнаружения дребизка в контактах. Если будет кратковременное срабатывание прерывания. То оно будет выглядит как будто оно потерялось. На самом деле это признак шума в проводах.



Да ладно какие там не реализованы? Там только нет 8085/8088. А во вторых ломать проще чем строить. Кто в здравом уме будет переписывать отлаженный код? Так и инженерам интел проще было скопировать готовый PIC8259 в тот-же мост. Вот и все дела. Убрать лишнее.

Им даже полярность было проще поменять чем расширение для PIC делать.
Так что ссылаться на старые источники можно. Я бы сказал нужность. Да коэффициент доверия со временем падает.

Что произойдёт, если в режиме запроса уровнем линия IRQ сначала будет активной, а потом перестанет таковой быть? Соответствующий бит IRR останется установленным или тоже упадёт в 0? Вот сначала разберитесь с этим вопросом, а потом заявляйте, что я не прав.



Формально -- ошибка, фактически -- нет, поскольку передача запроса процессору идёт совместно с получением от него ответа. Но выразился неправильно, так что спорить не буду.



Это не домыслы, а суровая правда жизни. Линии запросов _должны_ оставаться активными, чтобы такой ситуации не возникало, однако реальная жизнь тем и отличается от теории, что там регулярно происходят "неправильные" вещи. Так что приходится учитывать, что сигнал запроса _может_ пропасть в самый неподходящий момент -- и тогда PIC сделает то, что написано -- а именно сгенерирует прерывание по вектору для IRQ7. Соответственно, обработчик этого прерывания должен проверять, что послужило его источником, иначе будут проблемы.



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



Убрана там не только поддержка 8080 (а отнюдь не 8088), но не в этом дело. Никто готовый кусок оригинального 8259 не брал, его проще было переделать -- хотя бы потому, что сейчас электронные схемы описывают на специальных языках (VHDL, Verilog, ещё что-то), а не делают на схемном уровне, как это было во времена создания 8259. Другое дело, что при переносе из чипсета в чипсет никто это переделывать не будет.



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

Все забывал написать. Насколько помню PCI держит прерывание пока его не сбросят. Поэтому потери из-за того что оно нежданно сбросилось быть не должно.

Не должно, но может -- хотя бы из-за неисправности. Поэтому предусматривать возможность потери прерываний необходимо.

Добавил очередной перевод.
Прошу помощи в викификации и правки.
http://ru.osdev.wikia.com/wiki/IAM:Глава_5

Было б время, блин...

Я написал касательно Вики здесь. viewtopic.php?p=3795#p3795