Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!nosc!logicon.arpa!trantor.harris-atd.com!x102c!wdavis
From: wdavis@x102c.harris-atd.com (davis william 26373)
Newsgroups: comp.unix.aux
Subject: Re: Kernel Debugging
Message-ID: <3152@trantor.harris-atd.com>
Date: 2 Feb 90 17:45:11 GMT
References: <3138@trantor.harris-atd.com> <6468@internal.Apple.COM>
Sender: news@trantor.harris-atd.com
Reply-To: wdavis@x102c.harris-atd.com (davis william 26373)
Distribution: comp
Organization: Harris Corporation GSS, Melbourne, Florida
Lines: 19

Thanks to everyone that sent instructions on using the modem port
and NMI switch to access the debugger.o code when it is built
into the kernel.

With the debugger I was able to track the problem far enough
to guess at what was wrong.  Apparently, there is some problem
with interrupt routines interacting with the floating point
coprocessor.  The panic I wad getting was an unexpected trap.
The trap I was getting was 13 (the 68881 coprocessor interrupt?).
It was coming in during the context switch that follows
an interrupt routine that has done a wakeup() call.
Since I don't use floating point in the driver,
I used the -F option to the C compiler.  This eliminated the
save of floating point state at the front of each function and
its restoration at the end of the function.  I already knew from
previous experience not to use the -O option on a driver.
Perhaps someone at Apple would like to add these options to the
Release Notes for the Device Driver Kit?  Or maybe this
is actually a latent bug in the A/UX support routines?