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
next prev parent 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