Serge wrote:Хак писала Вероника. Имхо в этом случае лучше включить APIC, пусть это и требует некоторых телодвижений.
Я тоже так думаю, но при текущем уровне развития системы это не вариант - даже если считать инструкцию по включению APIC очевидной, она таки требует, чтобы система могла хоть как-то загрузиться.
Mario_r4 wrote:Меня смущает процедура irq_serv в файле core/irq.inc. Пришлось убрать:
Mario_r4, весь этот хак предназначен для случая "драйвер устройства повесил обработчик на прерывание A, а устройство генерирует прерывание Б". Если управляющему коду приходит прерывание Б и все драйверы, сидящие на Б, говорят "нет, это не моё прерывание", то управляющий код начинает опрашивать всех-всех-всех с остальных прерываний, вдруг кто сознается. Очевидно, что для корректной работы этого механизма нужно, чтобы драйверы не врали в ответ на вопрос "твоё ли это прерывание?" Но некоторые врут, поэтому их нужно исключать при опросах.
Первая часть исключений, с "jz .fail", отвечает за то, чтобы не начинать опрос, если обработчик прерывания А говорит, что прерывание не его, хотя на самом деле оно его: таким свойством обладают А=6, 14, 15 - все они врут в отрицательную сторону. Поэтому отсюда 14 и 15 убирать нельзя, пока нет нормального обработчика.
Вторая часть исключений, с "jz .try_next_irq", отвечает за то, чтобы игнорировать обработчик прерывания Б, который говорит, что прерывание его, хотя на самом деле оно не его. Это как раз legacy ISA, Б=1, 12, где нет возможности проверить, действительно ли прерывание пришло от нужного источника. И сюда 14 и 15 добавить можно, если уж обработчик всегда говорит, что это его прерывание.
Serge wrote:Третий параметр может быть любым. Ядро передаёт его в установленный обработчик прерывания. Удобно передавать указатель на данные контроллера.
Mario_r4 wrote:Что подразумевается под "нормальным обработчиком"?
Обработчик, регистрируемый через attach_int_handler. Если таковой есть, но всегда возвращает единицу, то добавлять в часть А сравнения с 14,15 можно, но бессмысленно - они никогда не сработают.
; There is at least one configuration with one device which generates IRQ
; that is not the same as it should be according to PCI config space.
; For that device, the handler is registered at wrong IRQ.
; As a workaround, when nobody acknowledges the generated IRQ,
; try to ask all other registered handlers; if some handler acknowledges
; the IRQ this time, relink it to the current IRQ list.
; To make this more reliable, for every handler keep number of times
; that it has acknowledged an IRQ, and assume that handlers with at least one
; acknowledged IRQ are registered properly.
; Note: this still isn't 100% correct, because two IRQs can fire simultaneously,
; the better way would be to find the correct IRQ, but I don't know how to do
; this in that case.
; Also, [fdc_irq_func], [irq14_func], [irq15_func] could process interrupt
; but do not return whether they did it, so just ignore IRQs 6, 14, 15.
cmp ebp, 6
jz .fail
cmp ebp, 14
jz .fail
cmp ebp, 15
jz .fail
push ebp
xor ebp, ebp
.try_other_irqs:
cmp ebp, [esp]
jz .try_next_irq
cmp ebp, 1
jz .try_next_irq
cmp ebp, 12
jz .try_next_irq
cmp ebp, 14
jz .try_next_irq
cmp ebp, 15
jz .try_next_irq
lea esi, [irqh_tab+ebp*8]
mov ebx, esi
.try_next_handler:
SVN r.3771 - динамическая установка обработчика прерывания Floppy - IRQ6, через attach_int_handler.
Как всегда не обошлось без сюрпризов. Ревизия связанная с новым шедулером сломала работу с флопиком. Почему-то в самый не продходящий момент гасится двигатель флопика и все кирдык. Временно зако