This section describes the various types of UNIX kernel messages displayed by the console. These messages may also appear in /var/adm/SYSLOG, where they are prefixed by "<systemname> unix:." Not all kernel messages appear in the SYSLOG file because a daemon must be running to transfer the error message from the kernel to the file. If the system panics, the kernel messages appear only on the console and in a system core dump.
There are three types of kernel messages:
Panic messages
Warning messages
Driver messages
The panic message syntax is PANIC CPU n: xxx, where n is the processor number and xxx is the string indicating the general area of the fault. The kernel panics when it cannot continue operation without the risk of corrupting user data. Common causes of kernel panics are:
problems in the kernel data structures
processor exceptions taken during kernel code, resulting from a software bug
processor exceptions taken during kernel code, resulting from a bus timeout when hardware doesn't respond to a PIO operation (such as a read/write to a control register)
The following message usually indicates a hardware problem:
WARNING: Kernel Bus Error Exception ... HARDWARE ERROR STATE: ... PANIC: CPU n: Kernel Bus Error Exception ... |
This kind of message also indicates a hardware problem:
WARNING: Bus Error Exception in User mode ... HARDWARE ERROR STATE: ... PANIC: CPU n: Bus Error Exception in User mode ... |
There are some cases in which this message displays because of software bugs. This is discussed in further detail below.
Note that it is not useful to report only the Bus Error Exception message when filing a bug report. The HARDWARE ERROR STATE messages are the most useful messages.
The following message means that a chip detected a problem and sent an interrupt to a CPU. This is probably a hardware problem.
Received interrupt at level 0x7a due to FCHIP ERROR HARDWARE ERROR STATE: ... |
The following kernel fault message indicates a software bug:
PANIC: CPU 1: KERNEL FAULT PC: 0x8012681c ep:ffffc888 EXC code:128, `Software detected SEGV ` (or) Read Address Error (or) Write Address Error Bad addr: 0x0, cause: 0x8<CE=0,EXC=RMISS> |
This message indicates the kernel read or wrote an out-of-range, or misaligned address. Despite the fact that the panic message lists a specific CPU, this message does not necessarily indicate a problem with that CPU.
In general, even if a panic message is followed by a CPU number, it does not automatically indicate a hardware problem (with the exception of the cases listed above).
The following message does not appear in production kernels. It should appear only in special engineering builds in which assertations are turned on:
assertion failed cpu n: <some C code> file: xxx.c, line: nn |
This message normally indicates a software bug.
The following message means that the R4400 detected a problem in its interface to the CC chip, or in the secondary cache SIMMs:
CPU 26: ECC PANIC: Uncorrectable HARDWARE ECC error... PANIC MSG: ... XXX: ... PANIC: CPU n: Uncorrectable ecc/parity error |
In this kind of message, XXX is any of:
| primary i-cache | an R4400 chip problem | |
| primary d-cache | an R4400 chip problem | |
| secondary i-cache | a likely IP19 Scache SIMM problem | |
| secondary d-cache | a likely IP19 Scache SIMM problem | |
| CPU SysAD bus | a likely problem on the IP19 board |
This is probably a hardware problem. Note that it does not refer to main memory. MC3 ECC errors are reported in HARDWARE ERROR STATE messages.
The HARDWARE ERROR STATE message sequence means that the CPU received a hardware Bus Error signal in response to a read operation, or that a CPU received an error interrupt from an error detecting chip. This message format is used to convey almost all error conditions detected by the hardware itself.
The CHALLENGE/Onyx hardware error state looks like:
HARDWARE ERROR STATE: + <board name> in slot 1 + <Error register name>: <value> + bit number: <meaning of the bit> |
For a detailed description of all possible HARDWARE ERROR STATE messages, refer to Section 2.4, "ASIC Error Detection." Important cases are described in the next section.
HARDWARE ERROR STATE Caused by Software
The following message can be caused by software that mistakenly generates a non-existent address:
A Chip ADDR_HERE not asserted |
A non-existent address on the EBus results in a display with the A Chip Error Register bit ADDR_HERE not asserted message. For example:
pb 8: <4>WARNING: CPU 3 Bus Error Exception in User mode... pb 9: HARDWARE ERROR STATE: pb 10: + IP19 in slot 7 pb 11: + A Chip Error Register: 0x8000 pb 12: + 15:CPU 3 ADDR_HERE not asserted pb 13: + CC in IP19 Slot 7, cpu 3 pb 14: + CC ERTOIP Register: 0x100 pb 15: + 8:Address Error on MyRequest on EBUS pb 16: + IP19 in slot 9 pb 17: + A Chip Error Register: 0x8000 pb 18: + 15:CPU 3 ADDR_HERE not asserted pb 20: <0>PANIC: CPU 3: Bus Error Exception in User mode... |
Although this can be a hardware error, such as a board failing to decode its address, usually this is a software problem.
IA ADDR_HERE not asserted
Software can cause an IA ADDR_HERE not asserted message by programming a device to do DMA to a non-existent address. An example message might be:
HARDWARE ERROR STATE: + IO4 board in slot 3 + IA EBUS Error Register: 0x24 + 2: ADDR_ERROR Detected + 5: ADDR_HERE not asserted or My ADDR_ERROR Received + IA Error EBus Address: 0xfffffff800 + 47..40: EBus Outgoing Command: 0x1 + 48: Originating IOA number = 5 + 54: DMA Read + 55: Address Map Match + Fchip in IO4 slot 3 adapter 5, FCI master: FCG – |
The warning message syntax is: WARNING: CPU n xxx, where "n" is the processor number and "xxx" is the string indicating the general area of the fault. Warnings often result from the kernel nearly running out of some resource, indicating that a kernel software configuration change is needed.
The driver message syntax is: dddn: xxxx, where "ddd" is a two- or three-character string indicating the driver name, "n" is a number indicating the controller, and "xxxx" is the string indicating the general area of the fault. These messages are sometimes embedded inside a warning message. Driver messages are generally hardware specific and will not directly cause a kernel panic.
An example of a message from the SCSI driver is: dks0d1s6: invalid partition. Where "dks" identifies the SCSI driver, "0" indicates which SCSI bus, and "d1s6" identifies which drive and partition.
The System Controller daemon (sysctrlrd) receives messages from the system controller and enters them in the file /var/adm/SYSLOG.
The following are error messages are caused by system contoller alarms and warnings, and appear in the SYSLOG file.
Table 7-1. System Controller Alarms and Warnings from SYSLOG
SYSLOG Message Type | Message | Meaning |
|---|---|---|
Alarm[a] | Overtemp alarm! | The system controller is shutting down the system because it has become too hot |
| Keyswitch off! | A user has switched off the keyswitch. |
| Blower failure! | The blower is not operating at the requested speed. |
Warning[b] | COP timer reset error!System controller crystal oscillator failed!Firmware detected illegal opcode!System controller firmware reset. | These messages are all System Controller internal errors which, if seen repeatedly, may indicate hardware failures. |
| Voltage out of tolerance! | The system controller has detected a voltage that is out of spec but is not yet bad enough to warrant shutting down the system. |
| Firmware compensating for blower RPM problem. | The system controller has set the blower speed to a higher speed than should be required to maintain adequate cooling. This usually indicates a blower problem. |
|
|
|
|
|
|
|
|
|
|
|
|
[a] All of these cause a controlled shutdown if the cleanpower flag is set to "on" using the chkconfig command. [b] These are logged, but no action is taken. | ||