From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Authentication-Warning: pc213.sam-solutions.net: ed set sender to ed@altlinux.ru using -f X-Comment-To: Sergey Vlasov To: ALT Linux kernel packages development Subject: Re: [d-kernel] IO-APIC problem on UP kernels In-Reply-To: <20030723213539.37be87a1.vsu@altlinux.ru> (Sergey Vlasov's message of "Wed, 23 Jul 2003 21:35:39 +0400") References: <20030723213539.37be87a1.vsu@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Thu, 24 Jul 2003 10:39:32 +0400 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit 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 07:40:47 -0000 Archived-At: List-Archive: List-Post: >>>>> "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