public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <cminyard@mvista.com>
To: root@chaos.analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: NMI handling rework
Date: Thu, 07 Nov 2002 13:58:52 -0600	[thread overview]
Message-ID: <3DCAC5FC.2010205@mvista.com> (raw)
In-Reply-To: Pine.LNX.3.95.1021107115259.9343A-100000@chaos.analogic.com

Richard B. Johnson wrote:

>On Thu, 7 Nov 2002, Zwane Mwaikambo wrote:
>
>  
>
>>On Thu, 7 Nov 2002, Corey Minyard wrote:
>>
>>    
>>
>>>NMIs cannot be masked, they are by definition non-maskable :-).  You can 
>>>get an NMI while executing an NMI.
>>>      
>>>
>>"After an NMI interrupt is recognized by the P6 family, Pentium, Intel486, 
>>Intel386, and Intel 286 processors, the NMI interrupt is masked until the 
>>first IRET instruction is executed, unlike the 8086 processor."
>>
>>- 18.22.2 NMI Interrupts, Intel IA32 System Developer's Manual vol3d 
>>
Thanks, and thanks to everyone else that pointed this out.

It is still possible, though unlikely, that two NMI sources could occur 
at the same time.  Maybe that's not worth worrying about, and maybe for 
the APICs it works fine.

>>>An NMI-based timer?  I can see the use if you REALLY need accurate 
>>>intervals, but you can't do much in an NMI, no spinlocks, even.
>>>      
>>>
>[SNIPPED...]
>
>You can use a spinlock and, in fact, that's the only way you can
>protect a critical section. The other CPU will spin of course, just
>like the other CPU in a maskable interrupt. That's what spin-locks
>are for. With maskable interrupts, the "cli" affects only the CPU
>that actually fetches that instruction. That's why you need spin-lock
>protection when you have more than one CPU. With NMI, no CPU has
>the effect a "cli" would provide, so they just spin at the lock
>until the lock is released.
>
I should have been more precise here.  You cannot use a spinlock that 
you use outside of the NMI, too.  You might be holding the spinlock when 
the NMI occurs, and you would then be in deadlock.

-Corey


  reply	other threads:[~2002-11-07 18:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-07  6:44 NMI handling rework Corey Minyard
2002-11-07  6:20 ` Zwane Mwaikambo
2002-11-07 16:51   ` Corey Minyard
2002-11-07 15:59     ` Maciej W. Rozycki
2002-11-07 16:38     ` Zwane Mwaikambo
2002-11-07 16:59       ` Richard B. Johnson
2002-11-07 19:58         ` Corey Minyard [this message]
2002-11-08 15:34     ` Alan Cox
2002-11-07 17:05   ` John Levon
  -- strict thread matches above, loose matches on Subject: below --
2002-11-08 15:00 Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-11-08 20:30 ` Zwane Mwaikambo
2002-11-11 15:26 Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-11-15  3:45 ` Corey Minyard
2002-11-15  4:12   ` Zwane Mwaikambo
2002-11-15  4:50     ` Corey Minyard
2002-11-15  5:12       ` Zwane Mwaikambo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DCAC5FC.2010205@mvista.com \
    --to=cminyard@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox