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

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

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 2255 bytes --]

Hello!

А что, никто не замечал на последних ядрах такую проблему:

Jul 23 21:11:45 center4 kernel: hda: dma_timer_expiry: dma status == 0x24
Jul 23 21:11:45 center4 kernel: hda: lost interrupt
Jul 23 21:11:45 center4 kernel: hda: dma_intr: bad DMA status (dma_stat=30)
Jul 23 21:11:45 center4 kernel: hda: dma_intr: status=0x50 { DriveReady SeekComplete }

У меня это проявляется на двух машинах (ASUS A7V8X и Gigabyte 7ZXE)
при включении ACPI, если активно обращаться к диску (hda), когда
грабится аудио (grip) с hdc. Точнее, как выяснилось, имеет значение не
столько ACPI, сколько включение IO-APIC (просто на A7V8X включить
IO-APIC без ACPI не получается - там нет MP-таблиц в BIOS).

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

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

Приложенный патч вроде бы исправляет эту проблему (там скопирована
функция из smp.c и включён её вызов в hw_resend_irq() для
однопроцессорного варианта ядра с использованием IO-APIC).

-- 
Sergey Vlasov

[-- Attachment #1.2: 03_up-ioapic-resend-irq.patch --]
[-- Type: application/octet-stream, Size: 2256 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [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

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

[Sergey Vlasov]

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
воспроизводится устойчиво.

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

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 3065 bytes --]

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).

[-- Attachment #1.2: 03_io-apic-resend-irq.patch --]
[-- Type: application/octet-stream, Size: 1148 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Sergey Vlasov]

On Mon, 28 Jul 2003 18:35:57 +0400
Sergey Vlasov <vsu@altlinux.ru> wrote:

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

Точнее, ляжет, но воткнётся с fuzz 2 в странное место - работает, но
как-то некрасиво это...