From: mtcusa@tigger.jvnc.net (Multilingual Technogies Corporation)
Newsgroups: comp.unix.sysv386
Subject: Re: How to debug a PANIC??
Keywords: unix panic interactive debug
Date: 26 Jul 92 15:19:33 GMT
Organization: JvNCnet, Princeton University, NJ
Originator: mtcusa@tigger.jvnc.net

In article <1992Jul24.171942.13964@generics.ka.sub.org> ihno@generics.ka.sub.org (Ihno Krumreich) writes:
>howardl@wb3ffv.ampr.org (Howard Leadmon - WB3FFV) writes:
>
>
>>    Hello,
>
>>I am currently running Interactive UNIX version 3.0, and things have 
>>generally been great.  The other day I had my system PANIC and crash
>>twice within a couple hours.  I know there is supposed to be a way I
>>can find what program was dying by using the kernel debugger, but am
>>not sure how to do this.  If somenody on the net would be so kind as
>>to give me a little instruction it would be most appreicated...
>
>>Just for information sake, the panic was a Trap 0x0000000E
>
>Bad luck for you trap 0xe says nearly nothing.
>
>The way to find the programm probably killing the machine is the following:
>
>1) After the panic the system should report how many pages it has written to
>   the swap space. If that does not happen, no need to read the rest.
>
>2) When the system comes up again, the system shouls ask you, whether you
>   want to save the memory dump. Save it. (if you want to save to diskettes,
>   prepare enough. If you have 16 Meg of memory you need 14 diskettes)
>
>3) If the system is up again load the dump to the disk with the command
>   ldsysdump.
>   Now you can use the command crash to analyse the dump.
>   All commands, wich are discribed now are within crash
>
>   crash>  p	# gives you all processes that have been on the system
>		# when it crashed. In the second coloum (ST) the state of
>		# process is noted. s for sleeping, r for runnable and
>		# p for on processor. So the one with the p should be
>		# of intressed for you..
>		# Have a look at the slot number (first coloum).
>   crash> t #s  # t with the slot number gives you a trace of the called
>		# procedures of the numbered process. This may give you an
>		# idea which driver was the bad one.
>
>   crash uses the /unix for the symbols and other information. If you want
>   to analyze the dump on a different machine, you always need the kernel from
>   the machine which paniced. 
>
>   hope that helped you.
>
>Ihno
>
>=======================================================
>
>Ihno Krumreich     | Phone (49) 721 38 70 94
>Generics Gmbh      | email: ihno@generics.ka.sub.org
>Breite Strasse 24  | FAX   (49) 721 38 56 22
>D-W7500 Karlsruhe  |
>-- 
>Ihno Krumreich     | Phone (49) 721 38 70 94
>Generics Gmbh      | email: ihno@generics.ka.sub.org
>Breite Strasse 24  | FAX   (49) 721 38 56 22
>D-W7500 Karlsruhe  |

Using crash is good advice.  I have found that the floppy dump is a pain
however.  Here's some other ways to find the offending system call:

SCO:
	After the panic, when the system boots, it stops and asks you
	if you want to go into maint. mode.  Type in the password and
	go into single user.   You can then use crash directly on /dev/swap,
	or do a 'dd' of /dev/swap to some (real big) file somewhere.

	You have to do this in single user because as soon as you go 
	multi user the system may use swap, and 'crash' won't work any more.

	This method doesn't work on INTERACTIVE.  I can get into single
	user by changing 'initdefault' to '1' in 'inittab', but once
	there, crash gets confused by whatever is in /dev/swap.
	I really don't need it because of the following, so haven't
	really tried to figure out why it doesn't like /dev/swap.

INTERACTIVE:
	First you have to get the kernel debugger going.  You can do that
	by configuring it into the kernel using 'kconfig'.  Manual section
	8 has some documentation on how to use this debugger.  Beside
	being able to access addresses by symbol name, there is a single
	stepping mode, and the ability to set break points on the running
	kernel.   Single step mode is only useful if you speak assembler.

	You enter debug mode with CTRL-ALT-D and exit with CTRL-D.

	Once you get this in the kernel, activate the debugger (CTRL-ALT-D)
	and set a break point on "panic".  You can do this as:

			panic .i brk0
	
	(I don't have the manual in front of me, so check this out.  I also
	 can't remember how to turn off a break point.   I think it's
	 something like:
	 
			0 .i brk0

	If you can produce the panic on demand, do so.  If not, wait for
	it.  When it happens, the system will dump all that register muck
	and then break on the 'panic' kernel call.

	You can now type 't' for 'trace' and get a backtrace to the
	system call that caused the panic.

	GURU question:  What is the meaning of all that stuff in
			parentheses after the system calls.  It's not
			function call arguments.   More to the point
			where can I read for myself about it.

Hope this helps.

George Bogatko - mtcusa@tigger.jvnc.net