DragonFlyBSD

:Hi,
:
:running sysutils/crashme from pkgsrc (using the values from the manual
:page) for ~10 seconds, panics my laptop reproducably with:
:
:panic: npxintr from nowhere
:
:I've put backtrace, kernel and crash dump on leaf in
:~swildner/crash/npx_intr.
:
:Regards,
:Sascha
:
:P.S. I wouldn't have thought that crashme still does its job. I had
:installed it more for nostalgic reasons. :)

Its getting an fpu exception when it should be getting a dna
    exception.

I need to know what arguments to 'crashme' you used.  I can run 
    crashme, but it core dumps after only a few tries.

-Matt

Matthew Dillon wrote:

Its getting an fpu exception when it should be getting a dna
exception.

I need to know what arguments to 'crashme' you used. I can run
crashme, but it core dumps after only a few tries.

Sorry,

I should have quoted them directly. I ran it with the default values
from the manual page, adding only verbose debugging output:

dim# crashme +2000 666 100 1:00:00 5

Regards,
Sascha

:Sorry,
:
:I should have quoted them directly. I ran it with the default values
:from the manual page, adding only verbose debugging output:
:
:dim# crashme +2000 666 100 1:00:00 5
:
:Regards,
:Sascha
:
:--
:http://yoyodyne.ath.cx

That did it.

I think I've figured it out.  The floating point exception is installed
    as a trap-gate, which leaves interrupts enabled.  If an interrupt occurs
    just as the FP exception occurs it can change the state of the FPU
    and confuse npx_intr().

Try this patch out and tell me if you still get the panic.  It isn't 
    the 'real' fix, but it will tell us if that is the problem.  The
    crash does not seem to occur with the patch.

The real fix is going to be simply to make npx_intr() and npxdna()
    handle each other's cases as well as their own, and then get rid of
    the assertion.  I think I also need to have them go into a critical 
    section.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Index: i386/machdep.c ===================================================================
RCS file: /cvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.88
diff u -r1.88 machdep.c
-- i386/machdep.c 24 Mar 2006 18:35:32 0000 1.88
++ i386/machdep.c 2 Apr 2006 19:01:12 -0000
@ -1912,7 +1912,7 @
setidt(4, &IDTVEC, SDT_SYS386TGT, SEL_UPL, GSEL);
setidt(5, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(6, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(7, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(7, &IDTVEC, SDT_SYS386IGT, SEL_KPL, GSEL);
setidt(8, 0, SDT_SYSTASKGT, SEL_KPL, GSEL);
setidt(9, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(10, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
@ -1921,7 +1921,7 @
setidt(13, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(14, &IDTVEC, SDT_SYS386IGT, SEL_KPL, GSEL);
setidt(15, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
- setidt(16, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
+ setidt(16, &IDTVEC, SDT_SYS386IGT, SEL_KPL, GSEL);
setidt(17, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(18, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);
setidt(19, &IDTVEC, SDT_SYS386TGT, SEL_KPL, GSEL);

Matthew Dillon wrote:

:dim# crashme +2000 666 100 1:00:00 5
:
:Regards,
:Sascha
:
:--
:http://yoyodyne.ath.cx

That did it.

I think I've figured it out. The floating point exception is installed
as a trap-gate, which leaves interrupts enabled. If an interrupt occurs
just as the FP exception occurs it can change the state of the FPU
and confuse npx_intr().

Try this patch out and tell me if you still get the panic. It isn't
the 'real' fix, but it will tell us if that is the problem. The
crash does not seem to occur with the patch.

The real fix is going to be simply to make npx_intr() and npxdna()
handle each other's cases as well as their own, and then get rid of
the assertion. I think I also need to have them go into a critical
section.

-Matt
Matthew Dillon
<dillon@backplane.com>

Yea,

it seems to no longer panic here either. I have it running for ~15
minutes now.

Sascha