OSDev

ZarathustrA, чтобы на 100% убедиться, что Local APIC отсутствует, надо прочитать версию из его регистра версии. И желательно перед прочтением записать в него 0, т.к. этот регистр всё-равно не изменяемый. Если прочитается 0, то LAPICа нет, а если не ноль, то сообщи его здесь, будем думать.
Вообще LAPIC бывает разных конструкций. С процессорами i486 он был внешним (ищи доку на микросхему 82489DX), а c Pentuim стал внутренним. И у них разные номера версий, вот почему важно выяснить версию. Функционал у них тоже разный.

Вообще-то, Local APIC присутствует на каждом интеловском процессоре начиная с Intel Pentium (ядро P54C) (По крайней мере я так думал). В том числе и на моем ноутбучном Pentium M. Поэтому я даже не заморачивался насчет посмотреть его регистры или получить СPUID info, так как за базовый процессор брал именно этот, а не i386. Верил в спецификацию. Но как оказалось вы были правы. Товарищи из Интел решили сэкономить транзисторы (миливатты мощности) и не включили его в Pentium M, хотя спецификация Intel на Pentium подразумевает, что Local APIC является неотъемлемой частью процессора в настоящем и будущем. По крайней мере в графу "Осторожно! Может не присутствовать на будущих процессорах" он не попал.

В общем, проблема исчерпана. Нужно менять ноутбук.

Хотя нет. Есть еще один вопрос. Как в отсутствие Local APIC-а запись в несуществующий регистр TPR может менять содержимое регистров PPR и APR Local APIC-а. И как в отсутствии Local APIC-а может корректно отрабатывать встроенный в него высокочастотный таймер (отсчитывать значения, генерить прерывание по истечению заданного количества тактов)?

ZarathustrA, ты хочешь сказать, что регистр версии содержит 0, а некоторые функции всё-равно работают? Это вполне допустимая кривизна аппаратной реализации. Довольно часто реально существующие компоненты отключаются путём обнуления ключевого регистра, который является индикатором наличия компонента. Например, многие процессоры Intel и AMD физически содержат больше ядер, чем отображено на логическом уровне.
Я думаю, надо ориентироваться на регистр версии. Он должен быть главным показателем наличия или отсутствия устройства, тоесть в (полно)функциональном он состоянии или нет.

Спасибо за пояснение. Похоже все происходит именно тем образом, каким вы это и объясняете. Я как-то и не думал о частичной аппаратной реализации, хотя этот вариант выглядит очень правдоподобно. Вторым вариантом могут быть особенности реализации VmWare.

У меня тажа проблема. Выбрасывает двойную ошибку. Может все дело в APIC.



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

Корнень проблемы в том, что по умолчанию, PIC инициализирован таким образом, что переводит IRQ0 в INT8. В итоге я решил это следующим образом: В загрузчике просто стал маскировать все прерывания на PIC-е. И все. А вот когда ядро уже загрузится, поднимутся драйвера, в том числе и драйвер PIC-a, то тогда и будет программироваться/перепрограммироваться PIC.

P.S.:насколько я понял проблема является актуальной только для процессоров без APIC-а. На процессорах с APIC-ом решается она еще проще. Выставляется нужное значение в TPR (например 0х2F), и сам проц в не зависимости от желания контроллера прерываний на мамке, начинает игнорировать все прерывания у которых вектор меньше 0x30. То бишь PIC и IO APIC могут надрываться сколько хотят пытаясь отправить тебе сообщение о прерывании. Но до тех пор пока они не начнут отправлять прерывания с корректными векторами, твое ядро не будет даже подозревать об их существовании.