Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 9 Sep 2002 15:33:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 9 Sep 2002 15:33:16 -0400 Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:57275 "EHLO delta.ds2.pg.gda.pl") by vger.kernel.org with ESMTP id ; Mon, 9 Sep 2002 15:33:15 -0400 Date: Mon, 9 Sep 2002 21:38:20 +0200 (MET DST) From: "Maciej W. Rozycki" To: Zwane Mwaikambo cc: Linus Torvalds , Ingo Molnar , Robert Love , Linux Kernel Subject: Re: [PATCH][RFC] per isr in_progress markers In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1175 Lines: 27 On Mon, 9 Sep 2002, Zwane Mwaikambo wrote: > > Which is kind of sad. Is there some fast way to read the status of a > > level-trigger irq off the IO-APIC in case it is still pending, and to do > > the mitigation even for level-triggered? > > perhaps Remote IRR might help there? I don't think so. As far as I understand the I/O APIC operation, you can't really know the state of an interrupt input when Remote IRR is set (i.e. an interrupt from the input is being processed). You can only read a sort of state of an input from the Delivery Status bit when Remote IRR is cleared. For the i82489DX you could have read the state of an individual interrupt request from the IRR register of the local unit handling the IRQ. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/