On Thu, 24 Jul 2003 17:56:04 +0400
Sergey Vlasov <vsu@altlinux.ru> wrote:

> On Thu, 24 Jul 2003 10:39:32 +0400
> ed@altlinux.ru (Ed V. Bartosh) wrote:
> 
> > 
> > >>>>> "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 ? Тестировал, помогает ?
> 
> Видимо, как раз kernel-fix-core.
> 
> На двух машинах (ASUS A7V8X и Gigabyte 7ZXE) это помогает. Без CD-ROM
> ситуацию воспроизвести сложно (хотя пару раз было), зато с Audio-CD
> воспроизводится устойчиво.

Ну вот, пока я спал, это уже в 2.6 пофиксили, и в 2.4-ac тоже :-)

<alex@ssi.bg>
	[PATCH] Fix irq handling of IO-APIC edge IRQs on UP
	
	send_IPI_self is needed to resend irqs with IRQ_PENDING status when
	enabled.
	
	Checked with Ingo, and it's in 2.4-ac for some time.
	
	This should fix ide lost interrupts on UP with IO-APIC
	
	Ide trigers it this way:
	 - disable_irq
	 - do stuff that triggers IRQ.
	 - irq is IRQ_PENDING
	 - enable_irq
	 - IRQ is lost, needs to be resend.
	
	I'll send the patch to fixup IDE disable_irq logic to Bart.

Вот обновлённый патч, сделанный из 2.4.22-pre6-ac1 (предыдущий вариант
не ляжет без ACPI).