"Linux Gazette...making Linux just a little more fun!"

dmesg explained

Abstract

Often someone will write to a Linux help list asking for help with a
particular device they want to get working under Linux, and a standard
reply is "check the output of the dmesg command". This leaves a lot of new
users befuddled, and this document is here to hopefully help them navigate
this powerful debugging tool. Two sets of kernel boot messages are
presented and annotated, from an i386 system and a Linux-Pmac system.

Introduction

The Linux kernel is the central interface between the user and the
hardware. As such, it has to incorporate support for hardware if you are
to use it. Often, though, cryptic device names are used by the system,
making it difficult at first inspection to determine if some particular
hardware is supported. The command 'dmesg', which is used to print kernel
messages, is very useful in determining if a piece of hardware has been
found, and if so, what the system is referring to it as.

This artcle, including the title and format of the dmesg comments, were
directly inspired and copied from the OpenBSD Explained article by the
same name. I felt one on Linux would be useful for people.

Upon boot, the dmesg output is from the kernel booting, showing the
devices it has found and if it has been able to configure them at all
(aside from userland configuration). This log is also available in the
file /var/log/dmesg.

Kernel output on an i386 system

Shown below is a dmesg from an x86 system immediately after boot. The
output is indented by several space, and comments and descriptions are
left justified.

First up is the kernel version (2.2.14) and build (5), along with who built it, with what compile it was built, and when it wass built. This can be some inportant information, as some kernel versions and the GCC project don't interact correctly.

Detected 300683434 Hz processor.

My K6/2-300 processor running at 300 MHz.

Console: colour VGA+ 80x25

A standard PC console screen (15 inch monitor).

Calibrating delay loop... 599.65 BogoMIPS

The useless benchmark of BogoMIPS. They're bogus (hence the name), but are often used as a relative processor speed indicator.

The dentry cache (dcache) represents the kernel's view of the namespace of
mounted filesystems. There's pretty good documentation of it in
Documentation/filesystems/vfs.txt in the kernel source tree.

Buffer cache hash table entries: 65536 (order 6, 256k)

In 2.2, the buffer cache is used for caching and aggregating data for
writes to block devices. After 2.3.6, it is used for caching fs metadata,
such as inode information.

Page cache hash table entries: 16384 (order 4, 64k)

In 2.2, the page (VM) cache is used for caching swap, read and mmap data
(which was bad, because shared writable mappings were ugly). After 2.3.6,
it also is used for write data (i.e., the buffer and page caches are
mostly unified), and all became happiness and light (sorta like BSD).

My kernel supports RAM disks. While I'm not using any most days, sometimes I do use them; if you have the memory, they make a real fast filesystem (like /tmp or, for a webserver, the main pages loaded).

My ethernet device is a PCI NE2000 based device. (A real cheap NIC, but almost every OS supports it.)

VFS: Disk change detected on device fd(2,0)

At this point, the kernel is done booting and we're ready to start /sbin/init (unless we supplied some information about init upon boot). The system then starts rc.sysinit and begins normal boot operations. The kernel has finished booting.

Kernel output on a Linux-Pmac system

And, for comparison's sake, this is the output of Linux 2.2 on a PowerPC
system. Again, the dmesg output is indented and the description and
comments are left justified. For this system I was using BootX, which loads
the kernel into memory from within the MacOS, then completes bootstrapping
it after ditching the MacOS. Options can be passed to the kernel, as you
would with LILO on an Intel based PC, from within the app.

device tree used 17860 bytes

PowerPC systems use what is known as OpenFirmware, rather than a PC like
BIOS, and it has a 'device tree', which is arranged a bit like a UNIX
filesystem. This one uses about 16kb.

Kernel version (2.2.6 build 15 on a Pmac), who built it
(root@video.linuxppc.org), what version of gcc (or egcs), and when it was
built. This can be diagnostic as some versions of the Linux kernel don't
play well with some versions of GCC.

Some video settings. On PowerMac hardware, sometimes this can be important
if you've loaded a kernel level video driver, which can cause havoc on
some systems. This is useful stuff to check on a PPC that has some video
problems (ie in X).

It found the ADB devices and also the two serial ports. It's useful to know
which ones are which. Recall that Macintosh machines have one labeled modem
and one labeled printer, so this is useful info to know.

Concluding remarks

Like I noted above at the end of the i386 dmesg output, the kernel, once
finished, then moves on to /sbin/init unless an argument poiting it elsewhere
has been passed to the kernel at boot time. An example would be telling the
kernel "init=/bin/sh", such that it would execute a shell upon boot, rather
than /sbin/init (and what follows). Note that the kernel only mounts the
root filesystem read-only, so if all you do is boot the kernel you have
to mount your disks read-write in order to affect changes on them (ie
editing /etc/passwd to rescue root's password).

While this isn't the most thorough of jobs, I hope that this little tour
has been enjoyable for everyone, and educational.