What do panic messages mean?

Chris Lewis It's loose again! clewis at spectrix.UUCP
Fri Jun 24 07:31:59 AEST 1988


In article <170 at pigs.UUCP> haugj at pigs.UUCP (The Beach Bum) writes:
|In article <446 at sysco>, chapman at sco.COM (brian chapman) writes:
|] In article <2375 at rpp386.UUCP> jfh at rpp386.UUCP (The Beach Bum) writes:
|] [ DNA trap in kernel mode
|] [ 
|] [ now, what i want to know is what is a DNA trap?  does this mean the
|] [ machine has been genetically mutated?
|] 
|] On the chance that this is a serious question I will attempt
|] to answer it.
|] DNA is Device Not Availible (floating point device, that is)
|] Meaning the kernel is executing *87 instructions.  Or trying to.
|] -- 
|] Brian Chapman	 uunet!sco!chapman
|
|OK - i thought it was a typo version of DMA trap.  now that i know
|its True Meaning(tm), how come i don't see it when i am executing
|80387 instructions?  i mean, i use floating point code, but never
|see the message.  does this only apply if the kernel thought there
|was an 80387 and then later found out it had disappeared?  you've
|made me curious now!

My suspicion is that "DNA trap in kernel mode" would only occur
if the kernel itself tried to issue a FPU (or some other co-processor)
instruction when no FPU (or other co-processor) was present.
Though it is possible that this would occur if the ROM BIOS was
so stupid as to tell the kernel during boot that the FPU was present,
but it wasn't.

Usually, UNIX kernels are designed to not have FPU instructions of their
own.  During system boot, the 386 kernel (this applies to most kernels
all the way back to PDP-11 V7 or V6) determines whether the FP hardware
is present.  If the FP hardware is not present, then the kernel makes
arrangements so that if a user tries to execute a FPU instruction, the
kernel will catch the exception, emulate the instruction in *software*,
and then continue the user's code.  So, the user is never really aware 
whether there's a true FPU present except that software emulation is slower.
Therefore, the compiler *always* emits true FPU instructions.

[Just consider all the grief that wouldn't happen if DOS did the emulation
of non-existant instructions in software too!]

However, if the kernel does detect that an FP instruction was issued
from itself, obviously something is wrong (the kernel should never
depend on optional co-processors) and it panics.  Sort of like having
a page fault while in kernel mode (unless your kernel can page itself
that is).

ISC 386/ix used to (and I suspect Microport and Bell Tech still do)
crash if the ROM BIOS was so stupid to tell the kernel during boot
that the FPU was present but it really wasn't (which was a bug in
several earlier 386 ROM BIOSes).

Not all systems work this way (eg: Spectrix programs are linked with
different libraries depending on whether a real hardware FPU is present),
but 386 UNIXes do.
-- 
Chris Lewis, Spectrix Microsystems Inc, Phone: (416)-474-1955
UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis
Moderator of the Ferret Mailing List (ferret-list,ferret-request at spectrix)



More information about the Comp.unix.xenix mailing list