From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 07:11:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E01016A4CE for ; Mon, 11 Apr 2005 07:11:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E22EB43D4C for ; Mon, 11 Apr 2005 07:11:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3B7FU8p028935; Mon, 11 Apr 2005 01:15:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A2283.7040405@samsco.org> Date: Mon, 11 Apr 2005 01:08:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <200504110658.j3B6w2nb048552@apollo.backplane.com> In-Reply-To: <200504110658.j3B6w2nb048552@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 07:11:59 -0000 Matthew Dillon wrote: > Hmm. I can think of two solutions that avoid masking: > > * Change the trigger mode from level to edge as a means of masking the > interrupt, then change it back to level triggered to unmask. This > would be done in the IO APIC. > > * Change the delivery mode to low-priority for the interrupt that occured > and use the priority field to mask the interrupt to the cpu. This > would be done in the IO APIC with the LAPIC's TPR set appropriately. > > These are off-the-cuff ideas. I don't know how easy or hard it would be > to implement (yet). But, certainly, changing the trigger mode can't be > any more complicated then messing around with the mask. > > -Matt This is a place where two-level interrupt handling like in Mac OSX starts looking attractive. You have the driver quench the source right away in what is basically a fast interrupt handler, then you have an ithread come along later and process the data. I somewhat approximate this with the AAC driver, though I use a taskqueue instead of an ithread. There are definite trade-offs here; sometimes the only way to quench the hardware is to dequeue a status byte that is needed for later data processing. Queueing up this data byte to an ithread, and accounting that there might be more interrupts before the ithread runs, is ugly. Btw, AAC doesn't exhibit aliasing problems in the chipsets that I mentioned precisely because we don't mask the IOAPIC for fast handlers. Unfortunetaly, moving the entire OS to this scheme is quite labor-intensive. It would make just as much sense to implement MSI infrastructre and convert a number of drivers to that. And again, Linux seems immune to this problem, so it's very intriguing to find out why. Scott