[d-kernel] IO-APIC problem on UP kernels

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 SV>  Ситуация, как выяснилось, следующая: для прерываний с типом
 SV>  IO-APIC-edge (именно такой тип в данном случае назначается для
 SV>  IDE) при обработке disable_irq() с APIC ничего не делается
 SV>  (io_apic.c:disable_edge_ioapic_irq - пустышка). Если прерывание
 SV>  приходит между disable_irq() и enable_irq(), для него просто
 SV>  выставляется флаг IRQ_PENDING (кстати, если прерывание придёт
 SV>  ещё раз, ack_edge_ioapic_irq его заблокирует - но это уже не
 SV>  имеет отношения к данной проблеме). Далее при выполнении
 SV>  enable_irq() обнаруживается IRQ_PENDING и вызывается
 SV>  hw_resend_irq(), чтобы всё-таки обработать это прерывание. Так
 SV>  вот, в однопроцессорном ядре hw_resend_irq() не работает - в
 SV>  результате прерывание пропускается, и получается hda: lost
 SV>  interrupt. В SMP-ядре этой проблемы нет - там hw_resend_irq()
 SV>  работает (я пробовал вставлять prinkt в irq.c:enable_irq() - на
 SV>  SMP hw_resend_irq() при граблении аудио вызывается 20-40 раз за
 SV>  минуту; на UP после каждого такого вызова hda блокируется на 20
 SV>  секунд, пока не сработает таймаут).
У меня такое было на некоторых конфигурациях, большое спасибо за
объяснение.

 SV>  Видимо, дело в том, что при граблении аудио передача идёт в PIO,
 SV>  поэтому обработчик прерывания от ide1 выполняется долго, и за
 SV>  это время успевает появиться запрос прерывания от ide0 - если
 SV>  обработчик прерывания от ide1 вызвался между disable_irq() и
 SV>  enable_irq() для ide0, происходит описанная ситуация.


 SV>  Приложенный патч вроде бы исправляет эту проблему (там
 SV>  скопирована функция из smp.c и включён её вызов в
 SV>  hw_resend_irq() для однопроцессорного варианта ядра с
 SV>  использованием IO-APIC).
Чудэсно !
Куда это включать ? kernel-fix-core ? Тестировал, помогает ?
  

-- 
Best regards,
Ed V. Bartosh