Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!rochester!ur-tut!ur-valhalla!micropen!dave From: dave@micropen (David F. Carlson) Newsgroups: comp.unix.xenix Subject: Re: What do panic messages mean? Message-ID: <480@micropen> Date: 6 May 88 13:44:12 GMT References: <308@conexch.UUCP> Organization: Micropen Dirent Writing Systems, Pittsford, NY Lines: 45 Keywords: panic message interpretation Xenix 80286 help Summary: panics: welcome to the 80286! In article <308@conexch.UUCP>, root@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