OSDev

Может кто-нибудь сталкивался с такой ситуацией или знает как ее можно разрулить.
Загружается ядро. Во время загрузки формируются все системные таблицы. IDT заполняется только для исключений (первые 20 элементов). После завершения инициализации ядра разрешаются прерыванияю. После этого через случайный но небольшой промежуток времени возникает Double Fault exception, но при этом есть два странных момента:
1) Нет первого исключения
2) Проц не ложит в стек error code.

Традиционные вопросы: кто виноват и что делать?

З.Ы.: Запускается все это барохло под VmWare Workstation 6.5.

А инициализация контроллера прерываний и запрет прерываний прямо в нём выполнены? Ведь, если прерывания процессора разрешены, то любое прерывание, которое сгенерирует контроллер прерываний, будет передано процессору на обработку -- ну а раз у Вас IDT подготовлена только для прерываний процессора (кстати говоря, должно быть 32 элемента, а не 20, хотя изрядная их часть и пустая), то обработка внешних прерываний попросту не может выполняться должным образом...

Виноват программист, не настроивший обработчики прерываний. Что делать: настроить контроллер прерываний на генерацию прерываний IO IRQ -> CPU IRQ, на номера выше 0x20. И соответственно настроить для них в IDT "шлюзы прерываний" в диапазоне 0x20...0x3F.
Ещё желательно научиться пользоваться эмулятором Bochs, он выдаёт более детальную информацию об ошибках, и записывает в файл bochsout.txt.

Спасибо за ответы.

То есть как я понимаю, процессор не проверяет наличие соответствующей записи в IDT перед тем как начать обработку прерывания? Я просто предполагал, что после получения прерывания и передачей управления обработчику процессор проверяет наличие дескриптора обработчика в IDT. И если он отсутствует, то проц игнорирует прерывание.

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

Кстати говоря, флажок IF разрешает/запрещает внешние прерывания, т.е. те, что приходят на процессор извне, от контроллера прерываний (а на контроллер они попадают от внешних устройств -- таймера, клавы, портов, контроллеров дисков и т.д.). На внутренние прерывания самого процессора (деление на 0, нарушение границы, тот же двойной отказ и т.п.) он никакого влияния не оказывает.

Значит этот вопрос решен и понятен. Непонятно только почему он не отражен в спецификации на проц.
Второй вопрос: есть ли возможность использовать для обработки прерывания trap gate.

Описываю case: инициализирую весь IDT(256 дескрипторов). Исключения обрабатываются нормально, прерывания направляются на заглушку типа iretd. Весь IDT инициализирован trap gate-ами. Валятся ошибки типа stack fault.
Включаю локальный APIC и выставляю в нем приоритет задачи в значение 255. Ошибки продолжают валиться.

Вопрос - в чем фишка? дамп стека выглядит следующим образом:

kernel stack bottom
-------
task SS
task ESP
task flags
task CS ------ конец кадра прерывания
kernel SS
kernel ESP
kernel flags
kernel CS
kernel EIP -- указывает на iretd инструкцию.
....

Если использую вместо trap gate interrupt gate - все ок.
Как сделать trap gate работоспособной. Мне необходимо preemption обработчиков прерываний.

А зачем он должен отражаться в спецификации? Там достаточно ясно написано, как прерывания обрабатываются, и всё. Если не сказано, что они игнорируются, то автоматически получается, что никакого игнорирования не бывает. Да и здравый смысл говорит о том же самом: не существует в природе процессоров, которые по собственному желанию что-то там игнорируют.

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

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

Кадр стека какой-то странный. Обычно вверху находится вершина стека (top), а не дно; дно -- это последний адрес, отведённый под стек (численно минимальный на ИА-32 и большинстве других архитектур, хотя иногда встречаются и стеки, растущие вверх). В любом случае, если произошёл сбой стека, то причин не шибко много: выход за пределы сегмента стека, отсутствие сегмента в памяти и нарушение канонического вида адреса в 64-разрядном режиме. Если ОС 32-разрядная, третий случай отпадает, а значит, надо проверять, что находится в текущем дескрипторе сегмента стека и чему указатель стека равен. Возможно, из-за незапрещённых прерываний стек просто переполняется или ещё что... Ну или в шлюзе что-то напортачили. Внимательно смотреть все биты надо, в общем.

Наверняка можно. Но только для прерываний, а для исключений лучше использовать interrupt gate, иначе возможны коллизии в логике, и в результате двойные исключения. Для прерываний начала отладь код, используя interrupt gate, и затем, для эффекта вытеснения, у обработчика в самом начале можно поставить команду разрешения прерывания (sti). По функциональности это будет полным эквивалентом trap gate. Даже лучше, до доманды sti проверять наличие свободного места в стеке для вложенного прерывания, и если места мало, то sti не выполнять.

Ещё для эксперимента можно попробовать просто поставить cli в начале обработчика trap gate, станет ли работать нормально. Это будет эквивалентно interrupt gate.

Не уверен, а мануал листать лень. Ведь прерывание может произойти в момент, когда предыдущее уже выполнено, но первая команда обработчика (т.е. cli) ещё не выполнена. Тут надо смотреть, а будет ли прерывание запрещено в этот промежуток времени независимо от состояния флага IF или не будет.

Вопрос остается открытым.

Еще раз подробно описываю ситуацию.
При переключении на задачу у которой в TSS в флагах разрешены прерывания из задачи, в которой эти прерывания запрещены происходит double fault exception. При этом создается впечатление, что на самом деле это не исключение. а прерывание т.к.:
1) На стеке нет кадра первого исключения (как мы понимаем, double fault это всегда второе исключение)
2) Процессором на стек не ложится error code, хотя по мануалу он должен там быть сегда и быть нулевым.
Но, по книге "Pentium processor system architecture" аппаратное прерывание не может иметь вектор в диапазоне 0х0-0хF.

Танцы с Local APIC-ом не помогают. В танцы входили следующие па:
1) Включался APIC.
2) Поднимался приоритет задача (относительно прерываний) на максимальный уровень, путем записи в регистр TPR значения 0хFF.
3) На всякий пожарный, в расчете на то, что на шине APIC-CPU уже может висеть запрос на прерывание, делался End of Interruption, путем записи нуля в регистр EOI.

Предполагается, что эти танцы должны иметь эффект инструкции cli, то есть запрета прерываний.

Выводы: с одной стороны double fault подозрительно похож на прерывание, с другой получение всех прерываний запрещено.

Вопрос в студию: Что ж это такое твориться, господа? И как с этим быть?