![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to crash.8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / man / manb|
Return to crash.8 CVS log | Up to [Research Unix] / researchv10dc / man / manb |
1.1 ! root 1: .TH CRASH 8 VAX-11 ! 2: .UC 4 ! 3: .SH NAME ! 4: crash \- what happens when the system crashes ! 5: .SH DESCRIPTION ! 6: This section explains what happens when the system crashes and how ! 7: you can get a crash dump for analysis of non-transient problems. ! 8: .PP ! 9: When the system crashes voluntarily it prints a message of the form ! 10: .IP ! 11: panic: why i gave up the ghost ! 12: .LP ! 13: on the console, and then invokes an automatic reboot procedure as ! 14: described in ! 15: .IR reboot (8). ! 16: If the auto-reboot switch is off on the console, then the processor ! 17: will simply halt at this point. ! 18: Otherwise the registers and the top few locations of the stack will ! 19: be printed on the console, and then the system will check the disks ! 20: and (unless some unexpected inconsistency is encountered), resume ! 21: multi-user operations. ! 22: .PP ! 23: The system has a large number of internal consistency checks; if one ! 24: of these fails, then it will panic with a very short message indicating ! 25: which one failed. In the absence of a dump, little can be done about ! 26: one of these. If the problem recurs, you should arrange to get a dump ! 27: for further analysis by running with auto-reboot disabled during normal ! 28: working hours and then following the procedure described below. ! 29: .PP ! 30: The most common cause of system failures is hardware failure, which ! 31: can reflect itself in different ways. Here are the messages which ! 32: you are likely to encounter, with some hints as to causes. ! 33: Left unstated in all cases is the possibility that hardware or software ! 34: error produced the message in some unexpected way. ! 35: .TP ! 36: IO err in push ! 37: .ns ! 38: .TP ! 39: hard IO err in swap ! 40: The system encountered an error trying to write to the paging device ! 41: or an error in reading critical information from a disk drive. ! 42: You should fix your disk if it is broken or unreliable. ! 43: .TP ! 44: Timeout table overflow ! 45: .ns ! 46: .TP ! 47: ran out of bdp's ! 48: .ns ! 49: .TP ! 50: ran out of uba map ! 51: These really shouldn't be panics, but until we fix up the data structures ! 52: involved, running out of entries causes a crash. If the timeout table ! 53: overflows, you should make it bigger. If you run out of bdp's or uba map ! 54: you probably have a buggy device driver in your system, allocating and ! 55: not releasing UNIBUS resources. ! 56: .TP ! 57: KSP not valid ! 58: .ns ! 59: .TP ! 60: SBI fault ! 61: .ns ! 62: .TP ! 63: Machine check ! 64: .ns ! 65: .TP ! 66: CHM? in kernel ! 67: These indicate either a serious bug in the system or, more often, ! 68: a glitch or failing hardware. For the machine check, the top part of ! 69: the resulting stack frame gives more information. You can refer to a ! 70: VAX 11/780 System Maintenance Guide for information on machine checks. ! 71: If machine checks or SBI faults recur, check out the hardware or call ! 72: field service. If the other faults recur, there is likely a bug somewhere ! 73: in the system, although these can be caused by a flakey processor. ! 74: Run processor microdiagnostics. ! 75: .TP ! 76: trap type %d, code=%d ! 77: A unexpected trap has occurred within the system; the trap types are: ! 78: .RS ! 79: .TP 10 ! 80: 0 ! 81: reserved addressing mode ! 82: .br ! 83: .ns ! 84: .TP 10 ! 85: 1 ! 86: privileged instruction ! 87: .br ! 88: .ns ! 89: .TP 10 ! 90: 2 ! 91: BPT ! 92: .br ! 93: .ns ! 94: .TP 10 ! 95: 3 ! 96: XFC ! 97: .br ! 98: .ns ! 99: .TP 10 ! 100: 4 ! 101: reserved operand ! 102: .br ! 103: .ns ! 104: .TP 10 ! 105: 5 ! 106: CHMK (system call) ! 107: .br ! 108: .ns ! 109: .TP 10 ! 110: 6 ! 111: arithmetic trap ! 112: .br ! 113: .ns ! 114: .TP 10 ! 115: 7 ! 116: reschedule trap (software level 3) ! 117: .br ! 118: .ns ! 119: .TP 10 ! 120: 8 ! 121: segmentation fault ! 122: .br ! 123: .ns ! 124: .TP 10 ! 125: 9 ! 126: protection fault ! 127: .br ! 128: .ns ! 129: .TP 10 ! 130: 10 ! 131: trace pending (TP bit) ! 132: .RE ! 133: .IP ! 134: The favorite trap type in system crashes is trap type 9, indicating ! 135: a wild reference. The code is the referenced address. If you look ! 136: down the stack, just after the trap type and the code are the pc and ! 137: the ps of the processor when it trapped, showing you where in the ! 138: system the problem occurred. These problems tend to be easy to track ! 139: down if they are kernel bugs since the processor stops cold, but random ! 140: flakiness seems to cause this sometimes, e.g. we have trapped with ! 141: code 80000800 three times in six months as an instruction fetch went across ! 142: this page boundary in the kernel but have been unable to find any reason ! 143: for this to have happened. ! 144: .TP ! 145: init died ! 146: The system initialization process has exited. This is bad news, as no new ! 147: users will then be able to log in. Rebooting is the only fix, so the ! 148: system just does it right away. ! 149: .PP ! 150: That completes the list of panic types you are likely to see. ! 151: Now for the crash dump procedure: ! 152: .PP ! 153: At the moment a dump can be taken only on magnetic tape. ! 154: Before you do anything, be sure that a clean tape is mounted with a ring-in ! 155: on the tape drive if you plan to make a dump. ! 156: .PP ! 157: Write the date and time on the console log. ! 158: Use the console commands to examine the registers, program status long word, ! 159: and the top several locations on the stack. ! 160: A suggested command sequence, which is executed by the \*(lq@DUMP\*(rq ! 161: console command script, is: ! 162: .DS ! 163: .nf ! 164: E PSL<return> ! 165: E R0/NE:F<return> ! 166: E SP<return> ! 167: E/V @ /NE:40<return> ! 168: .fi ! 169: .DE ! 170: If hardware problems dictate a special set of commands be executed when ! 171: the system crashes, a sequence of commands can be saved using the console ! 172: command \*(lqLINK\*(rq to be reexecuted with \*(lqPERFORM\*(rq (which can be ! 173: abbreviated \*(lqP\*(rq). ! 174: If a dump is to be taken on magnetic tape (this is a good idea ! 175: in most any case where the cause of the crash is not immediately obvious) ! 176: then the following commands will (should) be executed: ! 177: .DS ! 178: .nf ! 179: D PSL 0<return> ! 180: D PC 80000200<return> ! 181: C<return> ! 182: .fi ! 183: .DE ! 184: These commands are actually part of the standard \*(lq@DUMP\*(rq script. ! 185: This should write a copy of all of memory ! 186: on the tape, followed by two EOF marks. ! 187: Caution: ! 188: Any error is taken to mean the end of memory has been reached. ! 189: This means that you must be sure the ring is in, ! 190: the tape is ready, and the tape is clean and new. ! 191: .PP ! 192: If there are not 40(hex) locations active on the kernel stack when the ! 193: procedure is begun, then the console may begin to print error diagnostics. ! 194: You can stop this by hitting \*(lq^C\*(rq (control-C), and then give the ! 195: last three commands above. ! 196: .PP ! 197: If the dump fails, you can try again, ! 198: but some of the registers will be lost. ! 199: See below for what to do with the tape. ! 200: .PP ! 201: To restart after a crash, follow the directions in ! 202: .IR reboot (8); ! 203: if the virtual memory subsystem is suspected as the cause of the crash, ! 204: then a version of the system other than \*(lqvmunix\*(rq should be booted ! 205: which will leave the paging areas temporarily intact ! 206: for use by the post-mortem analysis program ! 207: .I analyze. ! 208: After checking your root file system consistency with ! 209: .IR fsck (8), ! 210: you can read the core dump tape into the file /vmcore with ! 211: .IP ! 212: dd if=/dev/rmt0 of=/vmcore bs=20b ! 213: .LP ! 214: It does not work to use just ! 215: .IR cp (1), ! 216: as the tape is blocked. ! 217: With the system still in single-user mode, run the analysis program ! 218: .I analyze, ! 219: e.g.: ! 220: .IP ! 221: analyze \-s /dev/drum /vmcore /vmunix ! 222: .LP ! 223: and save the output. ! 224: Then boot up ! 225: \*(lqvmunix\*(rq ! 226: and let it do the automatic reboot, i.e. to boot multi-user from ! 227: an RM03/RM05/RP06 on the MASSBUS ! 228: .IP ! 229: >>> BOOT RPM ! 230: .PP ! 231: After rebooting, to analyze a dump you should execute ! 232: .I "ps \-alxk" ! 233: to print the process table at the time of the crash. ! 234: Use ! 235: .IR adb (1) ! 236: to examine ! 237: .IR /vmcore . ! 238: The location ! 239: .I dumpstack\-80000000 ! 240: is the bottom of a stack onto which were pushed the stack pointer ! 241: .BR sp , ! 242: .B PCBB ! 243: (containing the physical address of a ! 244: .IR u_area ), ! 245: .BR MAPEN , ! 246: .BR IPL , ! 247: and registers ! 248: .BR r13 \- r0 ! 249: (in that order). ! 250: .BR r13 (fp) ! 251: is the system frame pointer and the stack is used in standard ! 252: .B calls ! 253: format. Use ! 254: .IR adb (1) ! 255: to get a reverse calling order. ! 256: In most cases this procedure will give ! 257: an idea of what is wrong. ! 258: A more complete discussion ! 259: of system debugging is impossible here. ! 260: See, however, ! 261: .IR analyze (8) ! 262: for some more hints. ! 263: .SH "SEE ALSO" ! 264: analyze(8), reboot(8) ! 265: .br ! 266: .I "VAX 11/780 System Maintenance Guide" ! 267: for more information about machine checks. ! 268: .SH BUGS
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.