LINUX GAZETTE

 [ Prev ][ Table of Contents ][ Front Page ][ Talkback ][ FAQ ][ Next ]

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

dmesg explained

By José Nazario and Natarajan Krishnaswami

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.

The manpage for dmesg is quite simple: 

DMESG(8)                                                 DMESG(8)


NAME
       dmesg - print or control the kernel ring buffer

SYNOPSIS
      dmesg [ -c ] [ -n level ] [ -s bufsize ]

DESCRIPTION
       dmesg is  used  to  examine  or  control  the kernel ring
       buffer.
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.

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

A standard PC console screen (15 inch monitor).

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

My memory statistics. My machine has 64MB of real memory.

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.

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.

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 support quotas (though I'm not using them).

A quick identification of the processor.

I seem to recall there being some Intel processor issues, which the kernel has to know about if it's to invoke corrections.

And we start the probing of the PCI bus for peripherals.

This kernel supports the Net4 networking codebase, which has a lot of features yet to be fully utilized.

My core IP protocols supported. While not needed, IGMP can be fun. Note that some networks do not support muticasting.

Should be quite obvious...

The information about my serial ports.

My motherboard supports the APM standard for sleeping.

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 IDE controllers.

My hard drive in the machine.

My CDROM drive.

Disk information.

Floppy drive information.

A bunch of RAID and MD (used in multiple device devices, like disk arrays) information, again not used.

While the kernel supports SCSI, I'm not using any on this host.

My disk partition information. The brackets indicate extended partitions.

Like I said above, I'm using not using any RAID arrays.

At this point we're almost done with the kernel and ready to start the system.

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

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.

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.

Again, total physical RAM available.

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.

Two PCI busses. OpenFirmware (OF) calls their controllers bandit and chaos.

Ahh... sweet BogoMIPS, which mean pretty much nothing.

After the initial bootstrap, about 68 MB of memory is left, having reserved some for the kernel and core system.

Let the PCI probing begin!

USB support is in the kernel, though I have no USB devices on the system.

ADB, or Apple Desktop Bus, has two devices, the keyboard and the mouse. We'll see them detected below.

Core networking protocols (NET4) built into the kernel. The IGMP comes from multicast support (see Stevens for more info).

Recall that bandit is the PCI controller (bus0). I use an IMS Twin Turbo 8 MB video chipset.

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.

fd0, or the floppy drive 0, on PowerMacs uses a controller called 'SWIM3'. Unfortunately, in this instance of the kernel, it's broken.

If I had RAID controllers, this would be neat. As such, it's just sucking up space in my kernel.

I have two SCSI controllers, both onboard, with one being internal (the MESH one) and one being external (the 53C94 controller).

Disk detection. I'm not a big fan of how Linux names its disks (in the order it finds them), but it found all of my devices.

Kernel PPP support. Compressed TCP headers in PPP is a great feature, by the way, in keeping message overhead low.

Good old eth0, the ethernet device. It's MACE on a PowerMac. If this had been a modular driver, it wouldn't have shown up here but only after the module had been inserted.

The partition check is useful for knowing what the disks are laid out as.

And we're done booting.

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.

Copyright © 2000, Jose Nazario and Natarajan Krishnaswami. Copying license http://www.linuxgazette.com/copying.html
Published in Issue 59 of Linux Gazette, November 2000

[ Prev ][ Table of Contents ][ Front Page ][ Talkback ][ FAQ ][ Next ]