Defective or Incompatible RAM
Incomplete,obsolete (or) corrupted kernel extensions
Incompatible , obsolete or corrupted drivers
Hard sisk corruption
Insfufficient hard disk sparc
Incompatibel hardware
Temporarly installed hardware or software
After recompiling a kernel binary image from source code, a kernel panic while booting the resulting kernel is a common problem if the kernel was not correctly configured, compiled or installed.[9] Add-on hardware or malfunctioning RAM could also be sources of fatal kernel errors during start up, due to incompatibility with the OS or a missing device driver.[10] A kernel may also go into panic() if it is unable to locate a root file system.[11] During the final stages of kernel userspace initialization, a panic is typically triggered if the spawning of init fails, as the system would then be unusable
Kernel panics appear in Linux like in other Unix-like
systems, but they can also generate another kind of error condition, known as a
kernel oops.[14] In this case, the kernel normally continues to run after
killing the offending process. As an oops could cause some subsystems or
resources to become unavailable, they can later lead to a full kernel panic.
In Linux kernel, a kernel panic causes keyboard LEDs
to blink as a visual indication of a critical condition
KDUMP
32.2.3. Configuring kdump on the Command Line
Configuring the Memory Usage
Memory reserved for the kdump kernel is always
reserved during system boot, which means that the amount of memory is specified
in the system's boot loader configuration. This section will explain how to
change the amount of reserved memory on AMD64 and Intel 64 systems and IBM
Power Systems servers using the GRUB boot loader, and on IBM System z using
zipl. To configure the amount of memory to be reserved for the kdump kernel,
edit the /boot/grub/grub.conf file and add crashkernel=<size>M or
crashkernel=auto to the list of kernel options as shown in Example 32.1, “A
sample /boot/grub/grub.conf file”. Note that the crashkernel=auto option only
reserves the memory if the physical memory of the system is equal to or greater
than:
2 GB on 32-bit and 64-bit x86 architectures;
2 GB on PowerPC if the page size is 4 KB, or 8 GB
otherwise;
4 GB on IBM S/390.
Example 32.1. A sample /boot/grub/grub.conf file
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making
changes to this file
# NOTICE: You
have a /boot partition. This means that
# all
kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro
root=/dev/sda3
#
initrd /initrd
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server
(2.6.32-220.el6.x86_64)
root
(hd0,0)
kernel /vmlinuz-2.6.32-220.el6.x86_64
ro root=/dev/sda3 crashkernel=128M
initrd /initramfs-2.6.32-220.el6.x86_64.img
Make sure the system has enough memory
This section is available only if the system has
enough memory. To learn about minimum memory requirements of the Red Hat Enterprise
Linux 6 system, read the Required minimums section of the Red Hat Enterprise
Linux Technology Capabilities and Limits comparison chart. When the kdump crash
recovery is enabled, the minimum memory requirements increase by the amount of
memory reserved for it. This value is determined by the user, and defaults to
128 MB plus 64 MB for each TB of physical memory (that is, a total of 192 MB
for a system with 1 TB of physical memory). The memory can be attempted up to
the maximum of 896 MB if required. This is recommended especially in large
environments, for example in systems with a large number of Logical Unit
Numbers (LUNs).
Configuring the Target Type
When a kernel crash is captured, the core dump can be
either stored as a file in a local file system, written directly to a device,
or sent over a network using the NFS (Network File System) or SSH (Secure
Shell) protocol. Only one of these options can be set at the moment, and the
default option is to store the vmcore file in the /var/crash/ directory of the
local file system. To change this, as root, open the /etc/kdump.conf
configuration file in a text editor and edit the options as described below.
To change the local directory in which the core dump
is to be saved, remove the hash sign (“#”) from the beginning of the #path
/var/crash line, and replace the value with a desired directory path.
Optionally, if you want to write the file to a different partition, follow the
same procedure with the #ext4 /dev/sda3 line as well, and change both the file
system type and the device (a device name, a file system label, and UUID are
all supported) accordingly. For example:
ext3 /dev/sda4
path /usr/local/cores
To write the dump directly to a device, remove the
hash sign (“#”) from the beginning of the #raw /dev/sda5 line, and replace the
value with a desired device name. For example:
raw /dev/sdb1
To store the dump to a remote machine using the NFS
protocol, remove the hash sign (“#”) from the beginning of the #net
my.server.com:/export/tmp line, and replace the value with a valid host name
and directory path. For example:
net penguin.example.com:/export/cores
To store the dump to a remote machine using the SSH
protocol, remove the hash sign (“#”) from the beginning of the #net
user@my.server.com line, and replace the value with a valid user name and host
name. For example:
net john@penguin.example.com
See Chapter 14, OpenSSH for information on how to
configure an SSH server, and how to set up a key-based authentication.
For a complete list of currently supported targets,
see Table 32.1, “Supported kdump targets”.
Note
When using Direct-Access Storage Devices (DASDs) as
the kdump target, the devices must be specified in the /etc/dasd.conf file with
other DASDs, for example:
0.0.2098
0.0.2198
0.0.2298
0.0.2398
Where 0.0.2298 and 0.0.2398 are the DASDs used as the
kdump target.
Similarly, when using FCP-attached Small Computer
System Interface (SCSI) disks as the kdump target, the disks must be specified
in the /etc/zfcp.conf file with other FCP-Attached SCSI disks, for example:
0.0.3d0c 0x500507630508c1ae 0x402424aa00000000
0.0.3d0c 0x500507630508c1ae 0x402424ab00000000
0.0.3d0c 0x500507630508c1ae 0x402424ac00000000
Where 0.0.3d0c 0x500507630508c1ae 0x402424ab00000000
and 0.0.3d0c 0x500507630508c1ae 0x402424ac00000000 are the FCP-attached SCSI
disks used as the kdump target.
See the Adding DASDs and Adding FCP-Attached Logical
Units (LUNs) chapters in the Installation Guide for Red Hat Enterprise Linux 6
for detailed information about configuring DASDs and FCP-attached SCSI disks.
The vmcore.flat file must be converted
When transferring a core file to a remote target over
SSH, the core file needs to be serialized for the transfer. This creates a
vmcore.flat file in the /var/crash/ directory on the target system, which is
unreadable by the crash utility. To convert vmcore.flat to a dump file that is
readable by crash, run the following command as root on the target system:
~]# /usr/sbin/makedumpfile -R */tmp/vmcore-rearranged*
< *vmcore.flat*
Configuring the Core Collector
To reduce the size of the vmcore dump file, kdump
allows you to specify an external application (that is, a core collector) to
compress the data, and optionally leave out all irrelevant information.
Currently, the only fully supported core collector is makedumpfile.
To enable the core collector, as root, open the
/etc/kdump.conf configuration file in a text editor, remove the hash sign (“#”)
from the beginning of the #core_collector makedumpfile -c --message-level 1 -d
31 line, and edit the command-line options as described below.
To enable the dump file compression, add the -c
parameter. For example:
core_collector makedumpfile -c
To remove certain pages from the dump, add the -d
value parameter, where value is a sum of values of pages you want to omit as
described in Table 32.2, “Supported filtering levels”. For example, to remove
both zero and free pages, use the following:
core_collector makedumpfile -d 17 -c
See the manual page for makedumpfile for a complete
list of available options.
Table 32.2. Supported filtering levels
Option Description
1 Zero
pages
2 Cache
pages
4 Cache
private
8 User
pages
16 Free
pages
Changing the Default Action
By default, when kdump fails to create a core dump,
the root file system is mounted and /sbin/init is run. To change this behavior,
as root, open the /etc/kdump.conf configuration file in a text editor, remove
the hash sign (“#”) from the beginning of the #default shell line, and replace
the value with a desired action as described in Table 32.3, “Supported
actions”.
Table 32.3. Supported actions
Option Description
reboot Reboot the
system, losing the core in the process.
halt Halt the
system.
poweroff Power
off the system.
shell Run the
msh session from within the initramfs, allowing a user to record the core
manually.
For example:
default halt
Enabling the Service
To start the kdump daemon at boot time, type the
following at a shell prompt as root:
chkconfig kdump on
This will enable the service for runlevels 2, 3, 4,
and 5. Similarly, typing chkconfig kdump off will disable it for all runlevels.
To start the service in the current session, use the following command as root:
service kdump start
