Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!sun-barr!newstop!texsun!letni!merch!cpe!hal6000!trsvax!uhclem
From: uhclem@trsvax.UUCP
Newsgroups: comp.unix.xenix
Subject: Re: Trap types
Message-ID: <286100007@trsvax>
Date: 7 Jun 90 15:31:00 GMT
References: <239@wybbs.mi.org>
Lines: 62
Nf-ID: #R:wybbs.mi.org:239:trsvax:286100007:000:2106
Nf-From: trsvax.UUCP!uhclem    Jun  7 09:31:00 1990


<>
B>Trap 000D in system
B>prtrap: PANIC: general protection trap

The traps are discussed in your letnI songbook, sorry, your Intel
microprocessor handbook that you obtain from Intel.  The quick summary is:

	0	Divide Error
	1	Debug exceptions
	2	NMI interrupt
	3	Breakpoint
	4	Overflow
	5	Bounds Check
	6	Invalid Opcode
	7	Device not available
	8	Double fault
	9	486 Intel reserved - This means Microsoft may not use it :-)
		386 Coprocessor-segment overrun abort

	10	Invalid TSS
	11	Segment not present
	12	Stack Fault
	13	General protection
	14	Page fault
	15	Not mentioned in 386/486 book
	16	Floating point error
	17	Alignment check


A general protection trap (what you got) indicates that the processor
executed an instruction that *might* allow you to see out of your processes'
domain.  Since the 286/386 kernel performs some of its operations in a
restricted mode too, it can also get a general principles trap.
For example, if you (or the kernel) POP a value into *any* of the segment
registers in protected mode, that value better point to a valid descriptor,
otherwise you get a protection trap.  You didn't actually get the chance
to look at or write on anything in that segment, but you get the trap
just the same.  

In this case, the address says it all:

B>ax=0040 bx=F9C6 cx=0000 dx=0110 si=0018 di=03D4
B>bp=0392 fl=0286 uds=0018 es=0110
B>pc=0060:3B93 ksp=0378

Hop into adb with the kernel and find out what instruction is at that
address.  If the addresses for your various crashes are in some driver
you have added, contact that vendor.   If they are widespread
throughout the system (not a particular area of the kernel), then you
probably do have a hardware problem of some sort.  If it is failing
in the same non-driver routine in the kernel, XENIX is probably at fault.

<My opinion, and not that of my Golden Retriever who is building 68040 boxes.>
						
					"Thank you, Uh Clem."
					Frank Durda IV @ <trsvax!uhclem>
				...decvax!microsoft!trsvax!uhclem
				...hal6000!trsvax!uhclem

"The Knights who say 'letni'... demand a sacrifce! 
 We want... a Segment Register!"