All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Proposed NMI handling interface...
@ 2003-10-07 20:21 Steven J. Hill
  2003-10-08  9:05 ` Maciej W. Rozycki
  2003-10-08 16:06 ` Ralf Baechle
  0 siblings, 2 replies; 6+ messages in thread
From: Steven J. Hill @ 2003-10-07 20:21 UTC (permalink / raw)
  To: linux-mips

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

Greetings.

I wanted to propose an NMI handling interface. I have attached
the header file and patches to 'arch/mips/kernel/traps.c'. The
user need only specify the offset address for the NMI vector
code and then they can also specify their own desired NMI
function. Comments?

-Steve

[-- Attachment #2: nmi.h --]
[-- Type: text/x-chdr, Size: 1672 bytes --]

/*
 * linux/include/asm-mips/nmi.h
 *
 * NMI interface definitions
 *
 * Copyright (C) 2003 TimeSys Corp.
 *                    S. James Hill (James.Hill@timesys.com)
 *                                  (sjhill@realitydiluted.com)
 *
 *  This program is free software; you can redistribute  it and/or modify it
 *  under  the terms of  the GNU General  Public License as published by the
 *  Free Software Foundation;  either version 2 of the  License, or (at your
 *  option) any later version.
 *
 *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
 *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
 *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
 *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
 *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
 *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
 *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 *  You should have received a copy of the  GNU General Public License along
 *  with this program; if not, write  to the Free Software Foundation, Inc.,
 *  675 Mass Ave, Cambridge, MA 02139, USA.
 */
#ifndef _ASM_NMI_H
#define _ASM_NMI_H

/*
 * NMI vector address offset.
 */
extern unsigned long nmi_addr;

/*
 * User-defined NMI function.
 */
extern void (*nmi_user_handler)(struct pt_regs *regs);

#endif

[-- Attachment #3: traps.c.diff --]
[-- Type: text/plain, Size: 838 bytes --]

--- traps.c.orig	Tue Oct  7 15:08:43 2003
+++ traps.c	Tue Oct  7 15:10:28 2003
@@ -64,6 +66,11 @@
 void (*board_be_init)(void);
 int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
+#ifdef CONFIG_NMI
+unsigned long nmi_addr = 0;
+void (*nmi_user_handler)(struct pt_regs *regs);
+#endif
+
 int kstack_depth_to_print = 24;
 
 /*
@@ -841,6 +1095,8 @@
  */
 void nmi_exception_handler(struct pt_regs *regs)
 {
+	if (nmi_user_handler)
+		nmi_user_handler(regs);
 	printk("NMI taken!!!!\n");
 	die("NMI", regs);
 	while(1) ;
@@ -1009,6 +1265,14 @@
 		restore_fp_context = fpu_emulator_restore_context;
 	}
 
+#ifdef CONFIG_NMI
+	{
+		extern char except_vec_nmi;
+
+		memcpy((void *)(KSEG0 + nmi_addr), &except_vec_nmi, 0x8);
+	}
+#endif
+
 	flush_icache_range(KSEG0, KSEG0 + 0x400);
 
 	atomic_inc(&init_mm.mm_count);	/* XXX UP?  */

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] Proposed NMI handling interface...
  2003-10-07 20:21 [PATCH] Proposed NMI handling interface Steven J. Hill
@ 2003-10-08  9:05 ` Maciej W. Rozycki
  2003-10-08 16:06 ` Ralf Baechle
  1 sibling, 0 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2003-10-08  9:05 UTC (permalink / raw)
  To: Steven J. Hill; +Cc: linux-mips

On Tue, 7 Oct 2003, Steven J. Hill wrote:

> I wanted to propose an NMI handling interface. I have attached
> the header file and patches to 'arch/mips/kernel/traps.c'. The
> user need only specify the offset address for the NMI vector
> code and then they can also specify their own desired NMI
> function. Comments?

 You should consider something like "#define nmi_user_handler ((void
(*)(struct pt_regs *))0)" for !CONFIG_NMI and possibly also a way to
return from the frontend gracefully if the backend says it's OK.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] Proposed NMI handling interface...
  2003-10-07 20:21 [PATCH] Proposed NMI handling interface Steven J. Hill
  2003-10-08  9:05 ` Maciej W. Rozycki
@ 2003-10-08 16:06 ` Ralf Baechle
  2003-10-09 12:55     ` Thomas Horsten
  1 sibling, 1 reply; 6+ messages in thread
From: Ralf Baechle @ 2003-10-08 16:06 UTC (permalink / raw)
  To: Steven J. Hill; +Cc: linux-mips

On Tue, Oct 07, 2003 at 04:21:20PM -0400, Steven J. Hill wrote:

> I wanted to propose an NMI handling interface. I have attached
> the header file and patches to 'arch/mips/kernel/traps.c'. The
> user need only specify the offset address for the NMI vector
> code and then they can also specify their own desired NMI
> function. Comments?

That hook you're proposing isn't even necessary in generic code.  NMI
on MIPS hardware is a fairly odd type of exception - it goes straight to
0xbfc00000 which usually is a a firmware address - and lots of firmware
doesn't even offer an NMI hook.  So for those cases where it's possible,
you need to do something firmware anyway before jumping to Linux's NMI
handler.  An additional problem with the NMI design of MIPS is it's using
ErrorEPC, just like cache errors so you better pray - or simply design
systems only to rely on NMI for debugging and catastrophic failures.

  Ralf

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] Proposed NMI handling interface...
@ 2003-10-09 12:55     ` Thomas Horsten
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Horsten @ 2003-10-09 12:55 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: Steven J. Hill, linux-mips

On Wed, 8 Oct 2003, Ralf Baechle wrote:

> That hook you're proposing isn't even necessary in generic code.  NMI
> on MIPS hardware is a fairly odd type of exception - it goes straight to
> 0xbfc00000 which usually is a a firmware address - and lots of firmware
> doesn't even offer an NMI hook.  So for those cases where it's possible,
> you need to do something firmware anyway before jumping to Linux's NMI
> handler.  An additional problem with the NMI design of MIPS is it's using
> ErrorEPC, just like cache errors so you better pray - or simply design
> systems only to rely on NMI for debugging and catastrophic failures.

On Lasat boards NMI is used to reboot into Service Mode. There's no hook
to override this behaviour.

// Thomas

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] Proposed NMI handling interface...
@ 2003-10-09 12:55     ` Thomas Horsten
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Horsten @ 2003-10-09 12:55 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: Steven J. Hill, linux-mips

On Wed, 8 Oct 2003, Ralf Baechle wrote:

> That hook you're proposing isn't even necessary in generic code.  NMI
> on MIPS hardware is a fairly odd type of exception - it goes straight to
> 0xbfc00000 which usually is a a firmware address - and lots of firmware
> doesn't even offer an NMI hook.  So for those cases where it's possible,
> you need to do something firmware anyway before jumping to Linux's NMI
> handler.  An additional problem with the NMI design of MIPS is it's using
> ErrorEPC, just like cache errors so you better pray - or simply design
> systems only to rely on NMI for debugging and catastrophic failures.

On Lasat boards NMI is used to reboot into Service Mode. There's no hook
to override this behaviour.

// Thomas

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] Proposed NMI handling interface...
  2003-10-09 12:55     ` Thomas Horsten
  (?)
@ 2003-10-09 16:03     ` Brian Murphy
  -1 siblings, 0 replies; 6+ messages in thread
From: Brian Murphy @ 2003-10-09 16:03 UTC (permalink / raw)
  To: linux-mips; +Cc: Thomas Horsten

Thomas Horsten wrote:

>On Wed, 8 Oct 2003, Ralf Baechle wrote:
>
>  
>
>On Lasat boards NMI is used to reboot into Service Mode. There's no hook
>to override this behaviour.
>
>// Thomas
>
>
>
>  
>
There could be...

/Brian

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-09 16:04 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-07 20:21 [PATCH] Proposed NMI handling interface Steven J. Hill
2003-10-08  9:05 ` Maciej W. Rozycki
2003-10-08 16:06 ` Ralf Baechle
2003-10-09 12:55   ` Thomas Horsten
2003-10-09 12:55     ` Thomas Horsten
2003-10-09 16:03     ` Brian Murphy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.