diff options
Diffstat (limited to 'static/netbsd/man8/man8.vax/crash.8 2.html')
| -rw-r--r-- | static/netbsd/man8/man8.vax/crash.8 2.html | 175 |
1 files changed, 0 insertions, 175 deletions
diff --git a/static/netbsd/man8/man8.vax/crash.8 2.html b/static/netbsd/man8/man8.vax/crash.8 2.html deleted file mode 100644 index c24425b8..00000000 --- a/static/netbsd/man8/man8.vax/crash.8 2.html +++ /dev/null @@ -1,175 +0,0 @@ -<table class="head"> - <tr> - <td class="head-ltitle">CRASH(8)</td> - <td class="head-vol">System Manager's Manual (vax)</td> - <td class="head-rtitle">CRASH(8)</td> - </tr> -</table> -<div class="manual-text"> -<section class="Sh"> -<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> -<p class="Pp"><code class="Nm">crash</code> — <span class="Nd">UNIX - system failures</span></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> -<p class="Pp">This section explains what happens when the system crashes and - (very briefly) how to analyze crash dumps.</p> -<p class="Pp">When the system crashes voluntarily it prints a message of the - form</p> -<p class="Pp"></p> -<div class="Bd Bd-indent"><code class="Li">panic: why i gave up the - ghost</code></div> -<p class="Pp">on the console, takes a dump on a mass storage peripheral, and - then invokes an automatic reboot procedure as described in - <a class="Xr">reboot(8)</a>. (If auto-reboot is disabled on the front panel - of the machine the system will simply halt at this point.) Unless some - unexpected inconsistency is encountered in the state of the file systems due - to hardware or software failure, the system will then resume multi-user - operations.</p> -<p class="Pp">The system has a large number of internal consistency checks; if - one of these fails, then it will panic with a very short message indicating - which one failed. In many instances, this will be the name of the routine - which detected the error, or a two-word description of the inconsistency. A - full understanding of most panic messages requires perusal of the source - code for the system.</p> -<p class="Pp">The most common cause of system failures is hardware failure, - which can reflect itself in different ways. Here are the messages which are - most likely, with some hints as to causes. Left unstated in all cases is the - possibility that hardware or software error produced the message in some - unexpected way.</p> -<dl class="Bl-tag Bl-compact"> - <dt>iinit</dt> - <dd>This cryptic panic message results from a failure to mount the root - filesystem during the bootstrap process. Either the root filesystem has - been corrupted, or the system is attempting to use the wrong device as - root filesystem. Usually, an alternative copy of the system binary or an - alternative root filesystem can be used to bring up the system to - investigate.</dd> - <dt>Can't exec /sbin/init</dt> - <dd>This is not a panic message, as reboots are likely to be futile. Late in - the bootstrap procedure, the system was unable to locate and execute the - initialization process, <a class="Xr">init(8)</a>. The root filesystem is - incorrect or has been corrupted, or the mode or type of /sbin/init forbids - execution.</dd> - <dt>IO err in push</dt> - <dd style="width: auto;"> </dd> - <dt>hard IO err in swap</dt> - <dd>The system encountered an error trying to write to the paging device or an - error in reading critical information from a disk drive. The offending - disk should be fixed if it is broken or unreliable.</dd> - <dt>realloccg: bad optim</dt> - <dd style="width: auto;"> </dd> - <dt>ialloc: dup alloc</dt> - <dd style="width: auto;"> </dd> - <dt>alloccgblk: cyl groups corrupted</dt> - <dd style="width: auto;"> </dd> - <dt>ialloccg: map corrupted</dt> - <dd style="width: auto;"> </dd> - <dt>free: freeing free block</dt> - <dd style="width: auto;"> </dd> - <dt>free: freeing free frag</dt> - <dd style="width: auto;"> </dd> - <dt>ifree: freeing free inode</dt> - <dd style="width: auto;"> </dd> - <dt>alloccg: map corrupted</dt> - <dd>These panic messages are among those that may be produced when filesystem - inconsistencies are detected. The problem generally results from a failure - to repair damaged filesystems after a crash, hardware failures, or other - condition that should not normally occur. A filesystem check will normally - correct the problem.</dd> - <dt>timeout table overflow</dt> - <dd>This really shouldn't be a panic, but until the data structure involved is - made to be extensible, running out of entries causes a crash. If this - happens, make the timeout table bigger.</dd> - <dt>KSP not valid</dt> - <dd style="width: auto;"> </dd> - <dt>SBI fault</dt> - <dd style="width: auto;"> </dd> - <dt>CHM? in kernel</dt> - <dd>These indicate either a serious bug in the system or, more often, a glitch - or failing hardware. If SBI faults recur, check out the hardware or call - field service. If the other faults recur, there is likely a bug somewhere - in the system, although these can be caused by a flakey processor. Run - processor microdiagnostics.</dd> - <dt id="description">machine check %x: - <a class="permalink" href="#description"><i class="Em">description</i></a></dt> - <dd style="width: auto;"> </dd> - <dt>   machine dependent machine-check information</dt> - <dd>Machine checks are different on each type of CPU. Most of the internal - processor registers are saved at the time of the fault and are printed on - the console. For most processors, there is one line that summarizes the - type of machine check. Often, the nature of the problem is apparent from - this message and/or the contents of key registers. The VAX Hardware - Handbook should be consulted, and, if necessary, your friendly field - service people should be informed of the problem.</dd> - <dt>trap type %d, code=%x, pc=%x</dt> - <dd>A unexpected trap has occurred within the system; the trap types are: - <div class="Bd Pp Bd-indent Li"> - <pre>0 reserved addressing fault -1 privileged instruction fault -2 reserved operand fault -3 bpt instruction fault -4 xfc instruction fault -5 system call trap -6 arithmetic trap -7 ast delivery trap -8 segmentation fault -9 protection fault -10 trace trap -11 compatibility mode fault -12 page fault -13 page table fault</pre> - </div> - <p class="Pp">The favorite trap types in system crashes are trap types 8 and - 9, indicating a wild reference. The code is the referenced address, and - the pc at the time of the fault is printed. These problems tend to be - easy to track down if they are kernel bugs since the processor stops - cold, but random flakiness seems to cause this sometimes. The debugger - can be used to locate the instruction and subroutine corresponding to - the PC value. If that is insufficient to suggest the nature of the - problem, more detailed examination of the system status at the time of - the trap usually can produce an explanation.</p> - </dd> - <dt>init died</dt> - <dd>The system initialization process has exited. This is bad news, as no new - users will then be able to log in. Rebooting is the only fix, so the - system just does it right away.</dd> - <dt>out of mbufs: map full</dt> - <dd>The network has exhausted its private page map for network buffers. This - usually indicates that buffers are being lost, and rather than allow the - system to slowly degrade, it reboots immediately. The map may be made - larger if necessary.</dd> -</dl> -<p class="Pp">That completes the list of panic types you are likely to see.</p> -<p class="Pp">When the system crashes it writes (or at least attempts to write) - an image of memory into the back end of the dump device, usually the same as - the primary swap area. After the system is rebooted, the program - <a class="Xr">savecore(8)</a> runs and preserves a copy of this core image - and the current system in a specified directory for later perusal. See - <a class="Xr">savecore(8)</a> for details.</p> -<p class="Pp">To analyze a dump you should begin by running - <code class="Ic">adb</code> with the <code class="Fl">-k</code> flag on the - system load image and core dump. If the core image is the result of a panic, - the panic message is printed. Normally the command “$c” will - provide a stack trace from the point of the crash and this will provide a - clue as to what went wrong. For more detail see “Using ADB to Debug - the UNIX Kernel”.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE - ALSO</a></h1> -<p class="Pp"><a class="Xr">gdb(1)</a>, <a class="Xr">reboot(8)</a> - <br/> - “VAX 11/780 System Maintenance Guide” and “VAX Hardware - Handbook” for more information about machine checks. - <br/> - “Using ADB to Debug the UNIX Kernel”</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">June 5, 1993</td> - <td class="foot-os">NetBSD 10.1</td> - </tr> -</table> |