From owner-freebsd-smp  Wed Nov 20 14:16:23 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA15858
          for smp-outgoing; Wed, 20 Nov 1996 14:16:23 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA15783
          for <freebsd-smp@freebsd.org>; Wed, 20 Nov 1996 14:16:14 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id GAA13894;
          Thu, 21 Nov 1996 06:15:34 +0800 (WST)
Message-Id: <199611202215.GAA13894@spinner.DIALix.COM>
X-Mailer: exmh version 1.6.9 8/22/96
To: Steve Passe <smp@csn.net>
cc: cbrown@aracnet.com, Barney Wolff <barney@databus.com>,
        freebsd-smp@freebsd.org
Subject: Re: reinventing vs copying 
In-reply-to: Your message of "Wed, 20 Nov 1996 15:05:38 MST."
             <199611202205.PAA27179@clem.systemsix.com> 
Date: Thu, 21 Nov 1996 06:15:33 +0800
From: Peter Wemm <peter@spinner.dialix.com>
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Steve Passe wrote:
> Hi,
> 
> >bit registers on a per-cpu basis, ie: cpu 2 cannot see what's masked in 
> >cpu 1's registers (without an APIC remote read) and so on.
> 
> beware, the P6 dropped the "Remote Read" delivery mode...

Ahh, ok..

> ---
> >- we need to be able to have the 8259's online for some (current) hardware.
> 
> I have an experimental model working where I am using ExtINT mode on APIC
> INT0 to read the 8254 timer via the 8259.  Using the 8259 to pass a vector
> for ONE INT source turns out to be rather painless, handling more than 1
> INT via the 8259 would be ugly, you have to start managing the masks & etc.
> in the 8259.  But I also realized that there is a more fundimental problem.
> The 'low priority' and 'ExtInt' delivery modes are mutually exclusive!
> This means that INTs deliveried via the 8259/ExtInt CANNOT be sent by
> the 'low priority' delivery mode.  They either go to a specific CPU
> or they can be "broadcast" (I think) to all CPUs.  This might be OK
> for the 8259 timer INT, but more general INTs would be "cumbersome"
> in this mode.

Hmm, there are three ints that the docs mention from memory, aren't there? 
 I think it was IRQ0(timer), IRQ8(rtc) and IRQ13(dma chaining/FPU).  IRQ 8 
is 'essential' (it drives process resource usage and profiling).  We don't 
care about IRQ13 from memory.

> ---
> >I personally think that the right "temporary" solution for the edge 
> >trigger problem is to never disable the IO apic pin (for edge only), and 
> >simply wear the cost of the relatively rare occasions when the interrupts 
> >*do* interrupt their own handlers.
> 
> what is this cost, panic or corruption?

Neither..  Just have the interrupt serviced.. It or's it's bit in 
_ipending and returns since it's masked.  If you have multiple interrupts 
during the handler execution, the effect is that the bit is set multiple 
times.  Bruce profiled this and found that this was "insignificant" from 
memory (it happens something like the order of a fraction of a percent of 
cases).

That way, we simply don't loose the edge interrupt, since we will see that 
another one arrived.  (of course, this depends on exactly when the bit in 
_ipending is cleared)

Cheers,
-Peter