On Fri, 9 Feb 2001, Petr Vandrovec wrote:
> > Why do you need to mask NMI at all?
>
> Because of you must provide some function which handles NMI, and as
> you cannot switch IDT and CR3 atomically together, NMI handler has
> to be on same address in both address spaces - at least temporary.
On 9 Feb 01 at 13:10, Maciej W. Rozycki wrote:
> On Fri, 9 Feb 2001, Petr Vandrovec wrote:
>
> > Unfortunately both these ways needs intimate knowledge of how UP NMI
> > watchdog works in each kernel, and it is incompatible with other
> > perfctr uses. Probably I'll switch perfctr delivery to so
On Fri, 9 Feb 2001, Mikael Pettersson wrote:
> (I had a theory about inspecting the APIC_LVTPC "Delivery Status"
> field, but unfortunately it doesn't seem to get set if a counter
> overflowed while LVTPC was masked. Perhaps it's because NMIs are
> edge-triggered.)
The delivery status bit gets
On Fri, 9 Feb 2001, Petr Vandrovec wrote:
> Unfortunately both these ways needs intimate knowledge of how UP NMI
> watchdog works in each kernel, and it is incompatible with other
> perfctr uses. Probably I'll switch perfctr delivery to some real
> maskable interrupt while VMware VM owns CPU - if
On 9 Feb 01 at 0:06, Mikael Pettersson wrote:
> On Thu, 8 Feb 2001 12:32:01 MET-1, Petr Vandrovec wrote:
>
> >I have another question for UP APIC NMI: As I reported some time ago,
> >if performance counters overflow when LVTPC has 'disabled' bit set,
> >NMI is lost forever. This causes problems
On Thu, 8 Feb 2001 12:32:01 MET-1, Petr Vandrovec wrote:
>I have another question for UP APIC NMI: As I reported some time ago,
>if performance counters overflow when LVTPC has 'disabled' bit set,
>NMI is lost forever. This causes problems with VMware - it has to
>disable NMI deliveries during CR
On Thu, 8 Feb 2001, Petr Vandrovec wrote:
> So it came to my mind - why (on K7 we easy can, as counter has 48 bits)
> we do not reload NMI watchdog in each timer interrupt with 5sec timeout,
> and if we receive even one NMI, we are locked up? It should increase
> performance, as we'll do same num
On 8 Feb 01 at 6:04, Mikael Pettersson wrote:
> ordering and offsets in processor.h and head.S. The resulting
> kernel works ok on my UP P6.
> (Petr: can you check that it still works on your K7?)
I'll try.
I have another question for UP APIC NMI: As I reported some time ago,
if performance co
8 matches
Mail list logo
