public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* NMI handling rework
@ 2002-11-07  6:44 Corey Minyard
  2002-11-07  6:20 ` Zwane Mwaikambo
  0 siblings, 1 reply; 16+ messages in thread
From: Corey Minyard @ 2002-11-07  6:44 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, John Levon

Ingo et al...

Since a lot of things have started tying into the NMI handler (oprofile, 
nmi watchdog, memory errors, bus error, now the IPMI watchdog), I think 
it better to use a request/release mechanism for the NMI handlers. 
 Plus, I think the current NMI code is actually not correct, it's 
theoretically possible to miss NMIs if two occur at the same time.  So 
I'm proposing the patch at 
http://home.attbi.com/~minyard/linux-nmi-v8.diff, relative to current 
2.5.  This has been posted on lkml, and reviewed by John Levon and others.

Thanks,

-Corey


^ permalink raw reply	[flat|nested] 16+ messages in thread
* RE: NMI handling rework
@ 2002-11-08 15:00 Heater, Daniel (IndSys, GEFanuc, VMIC)
  2002-11-08 20:30 ` Zwane Mwaikambo
  0 siblings, 1 reply; 16+ messages in thread
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2002-11-08 15:00 UTC (permalink / raw)
  To: 'Corey Minyard'; +Cc: linux-kernel


-- Snipped from the patch --

If the handler actually handles the NMI, it should return NOTIFY_OK.
If it did not handle the NMI, it should return NOTIFY_DONE.  It may "or"
on NOTIFY_STOP_MASK to the return value if it does not want other
handlers after it to be notified.

-- End snip --

> 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.

Am I reading this correctly? As long as no one passes back NOTIFY_STOP_MASK,
all handlers are run. Assuming that all external NMI sources have a means of
checking whether they were the source, this would work like shared PCI
interrupts.

> Not on the i386 family.  Once an NMI is accepted by the CPU, it gets
> internally masked until an iret instruction gets executed.  If another NMI
> happens maenwhile, it's latched by the processor internally and dispatched
> as soon as NMIs are unmasked.  Further NMIs received when masked are lost.

So... We're running through the handler list servicing an NMI, two more NMIs
come in and we latch one (the other is dropped). It doesn't matter. Either
the
affected handlers have not run yet and will get run on the current pass, or
they will run on the next pass. You may have two handlers run on a single
pass
but you should not drop any. True??

This assumes i386 architecture and all handlers are run. I don't know about
other archs.

^ permalink raw reply	[flat|nested] 16+ messages in thread
* RE: NMI handling rework
@ 2002-11-11 15:26 Heater, Daniel (IndSys, GEFanuc, VMIC)
  2002-11-15  3:45 ` Corey Minyard
  0 siblings, 1 reply; 16+ messages in thread
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2002-11-11 15:26 UTC (permalink / raw)
  To: 'Zwane Mwaikambo', Heater, Daniel (IndSys, GEFanuc, VMIC)
  Cc: 'Corey Minyard', linux-kernel


>> Am I reading this correctly? As long as no one passes back
NOTIFY_STOP_MASK,
>> all handlers are run.

> For sanity's sake stick to running through all of them, there should be no

> partial handling, every registered handler should get serviced once per 
> NMI interrupt.

I agree. Unless there is some good justification for it, I think the
NOTIFY_STOP_MASK stuff should go away.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2002-11-15  5:12 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox