From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 24 Jul 2003 17:56:04 +0400 From: Sergey Vlasov To: ALT Linux kernel packages development Message-Id: <20030724175604.738164dd.vsu@altlinux.ru> In-Reply-To: References: <20030723213539.37be87a1.vsu@altlinux.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [d-kernel] Re: IO-APIC problem on UP kernels X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 13:56:15 -0000 Archived-At: List-Archive: List-Post: 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 воспроизводится устойчиво.