OSDev

8259 ;) Но, по большому счёту, всё опять-таки сводится к полной явной инициализации всего железа без расчёта на то, что что-то как-то сделано автоматически или ещё кем-нибудь.

Конкретно для данного исключения прерывания eoi не делается.

Кстати вопрос: как можно на ходу отличать программные прерывания от аппаратных, кроме как просмотром маски ISR?

Никак. Один из ляпов всех интеловских архитектур, начиная с 8008.

А ты в курсе, что I/O APIC может быть вообще не задействован в обработке прерываний? В PIC-режиме сигналы всегда направляются, минуя I/O APIC, а в Virtual Wire могут направляться, минуя I/O APIC.

Ты уже второй раз это пишешь. На самом деле зарезервированный диапазон - 0-0x1F. Поэтому тебе здесь и советовали установить "базу" на вектор 0x20 для мастера и соответственно 0x28 для слэйва.

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

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

А нафига? Аппаратные прерывания не должны конфликтовать с исключениями. У одного и того же аппаратного прерывания могут быть разные источники - для их определения ты должен опрашивать соотв. аппаратуру.

Где-то в MP-спецификации было написано, что в начальном состоянии (перед передачей управления от BIOS) APIC должен находиться в режиме PIC/Virtual Wire. Разработчики BIOS могут использовать разные варианты (это зависит от аппаратной конфигурации и их собственных предпочтений), но результат должен быть вполне определенный. Другое дело, что APIC нужно по-любому программировать, чтобы даже в одноядерной системе иметь больший диапазон номеров прерываний.

Кстати говоря, "зарезервированность" означает лишь то, что Интел объявила: первые 32 вектора предназначены для исключений, вырабатываемых самим процессором, поэтому использовать их для других целей не следует. Сие было благополучно проигнорировано ИБМ ещё при создании ИБМ ПЦ, поэтому одни и те же векторы используются и для исключений процессора, и для внешних прерываний, и для программных прерываний, вызывающих функции БИОС.



Винда работает на ВМ? Работает. Линух работает? Работает. Так что корень зла -- не в ВМ (хотя она действительно может создавать определённые проблемы), а в неверной инициализации чего-нибудь.

А нафига? Аппаратные прерывания не должны конфликтовать с исключениями. У одного и того же аппаратного прерывания могут быть разные источники - для их определения ты должен опрашивать соотв. аппаратуру.[/quote]

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



Да в спецификациях много что пишут, но время от времени что-нибудь где-нибудь неверно да реализуется. "Хочешь, чтобы что-то было сделано хорошо, -- сделай это сам" :)

Кстати, для заглушки на прерывания нужно не простой iret, а вот такой код:

Чтобы контроллер прерываний понял, что обработки прерывания завершена. Иначе все прерывания с номером больше или равным текущему перестанут поступать.

Это если используется обычный ПИК, а не АПИК.

1) На стеке не всегда есть кадр первого исключения, например при ошибке записи в стек. Но в любом случае, обработчик двойного исключения переключает указатель стека на свой - из своего TSS, поэтому кадра первого исключения здесь не будет никогда.
2) Значит это не двойное исключение, а скорей всего прерывание. После него ничего не происходит, потому что в обработчике не выполняется EOI, как я писал в прошлый раз. Думаю, проблема локализована.

Так если так, то пусть висит. Х.. ему, а не EOI. Заодно и всех своих сородичей в диапазоне 0х00-0х0F заблокирует.

Скорей всего это прерывание IRQ 0 от PIC 8259, оно по умолчанию настроено на Int 8. Поэтому IRQ 1...F останутся незаблокированными. По идее, при нажатии на клавишу клавиатуры возникнет IRQ 1 на Int 9. Попробуй вывести отладочную печать с Int 9 при срабатывании.