Date: Thu, 21 Nov 1996 06:15:33 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Steve Passe <smp@csn.net> Cc: cbrown@aracnet.com, Barney Wolff <barney@databus.com>, freebsd-smp@freebsd.org Subject: Re: reinventing vs copying Message-ID: <199611202215.GAA13894@spinner.DIALix.COM> In-Reply-To: Your message of "Wed, 20 Nov 1996 15:05:38 MST." <199611202205.PAA27179@clem.systemsix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611202215.GAA13894>