Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback

[Vivek Goyal <vgoyal@redhat.com>]

On Thu, Sep 04, 2008 at 05:24:53PM -0400, Don Zickus wrote:
> On Thu, Sep 04, 2008 at 05:21:34PM -0400, Vivek Goyal wrote:
> > On Thu, Sep 04, 2008 at 09:05:37PM +0000, Mingarelli, Thomas wrote:
> > > Ok regarding question #1. The die_notifier works as you mentioned; however, the fact that the watchdog timer ticks also come through as NMIs is a hinderance. Now, when the watchdog timer is configured through the LOCAL_APIC the issue isn't so bad. I think the hpwdt driver handles the NMI coming in because there isn't a flood of timer ticks coming through as in the IOAPIC case.
> > 
> > Ok, so how does replacing the nmi callback help here? You driver handler
> > be still called upon timer ticks. So you will be called on watchdog tick
> > whether you are on die chain or you replace nmi handler with nmi callback.
> > So watchdog ticks can't be a reason for not being on die chain.
> 
> Prarit's patch disabled the timer upon registering a callback to prevent
> this case.  The thought was if you have your own handler you could provide
> your own watchdog.
> 

In theory, you could do the same while registering the handler on die
chain?

I don't get the whole point. So we are looking for a system where no body
else uses an NMI for any purpose and the moment NMI happens, this driver
will go and panic() the system. I don't get, what do we achive by that?

Looks like you got some device in platform which raises an NMI and which
indicates that something is wrong and log the message and do a panic(). 
But you don't have a way to find out if that device has raised the
interrupt or something else has raised the NMI, hence you want to stop the
watchdog timer and assume any NMI henceforth is from device?

So any functionality which is dependent on NMI, will not work as long as
this driver is loaded. 

Thanks
Vivek