NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/sysv386/12457

Internet Message Format | 1992-07-26 | 5.1 KB

Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!mtcusa
From: [e-mail] (Multilingual Technogies Corporation)
Newsgroups: comp.unix.sysv386
Subject: Re: How to debug a PANIC??
Keywords: unix panic interactive debug
Message-ID: <[e-mail]>
Date: 26 Jul 92 15:19:33 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (Zee News Genie)
Organization: JvNCnet, Princeton University, NJ
Lines: 115
Originator: [e-mail]
Nntp-Posting-Host: tigger.jvnc.net

In article <[e-mail]> [e-mail] (Ihno Krumreich) writes:
>[e-mail] (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 [phone]
>Generics Gmbh      | email: [e-mail]
>Breite Strasse 24  | FAX   [phone]
>D-W7500 Karlsruhe  |
>--
>Ihno Krumreich     | Phone [phone]
>Generics Gmbh      | email: [e-mail]
>Breite Strasse 24  | FAX   [phone]
>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 - [e-mail]