What do panic messages mean?

David F. Carlson dave at micropen
Fri May 6 23:44:12 AEST 1988


In article <308 at conexch.UUCP>, root at conexch.UUCP (Larry Dighera) writes:
> 
> Does anyone have any idea what is causing these panics?   
> Is the format of the panic message documented anywhere so that one
> can interpret them?  I realize that the third through fifth lines are
> register dumps of the 80286, and the last line apparently refers to
> an out of bounds address (?).  But, how does one glean any meaning 
> from this?  Is the cause hardware or software related?  Should I be 
> looking at the accounting file to see what was running at the time of
> the panic?
> 
> Fri Apr 8 13:41:40
> TRAP 000D in SYSTEM
> ax=5600, bx=00BC, cx=0000, dx=0020, si=002F, di=6936
> bp=03A4, fl=0206, uds=0018, es=0020
> pc=0038:9AA1,  ksp=0388
> panic: general protection trap
> Thanks in advance.
> Larry Dighera

Welcome to the Intel 80286!  We Microport users know *exactly* what that
error message means.  In the Intel '286 reference manual their are several
types of faults: TSS, protection, etc.  It seems that the stack region for
any process is 64K (ie., one segment).  But so is the kernel stack!  When
the kernel stack pointer rolls over its segment it causes the above panic.
There is really no efficient means to correct this as kernel stack is used
very frequently and to have multiple stack segments would require nasty
segment loads, etc.  In fact, even the Microsoft huge model compilers don't
allow multiple stack segments.  However, the UNIX (Xenix) kernel is large
and each process that runs will occupy area on the kernel stack.  In addition,
interrupt handlers also use the kernel stack and can cause very large (albeit
short term) stack usage.  Bottom line is that there are many circumstances
of a kernel stack requiring more that 64K to live and no practical way for
the '286 architecture to provide it.  Now just wait until the naive DOS
losers get suckered into OS/2 with exactly the same '286 limitations and 
no 386 version in sight!  (This architecture issue is exactly why I would
never recommend less than a 32 bit address space for UNIX:  buy a '386.



-- 
David F. Carlson, Micropen, Inc.
...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave

"The faster I go, the behinder I get." --Lewis Carroll



More information about the Comp.unix.xenix mailing list