Everything about DMESG.........

1.About dmesg

Print or control the kernel ring buffer. The program helps users to print out their bootup messages. Instead of copying the messages by hand and mail the boot.messages file to whoever can debug their problem.

Syntax

dmesg [ -c ] [ -n level ] [ -s bufsize ]
-c Clear the ring buffer contents after printing.
-sbufsize Use a buffer of size bufsize to query the kernel ring buffer. This is 16392 by default. (The default kernel syslog buffer size was 4096 at first, 8192 since 1.3.54, 16384 since 2.1.113.) If you have set the kernel buffer to be larger than the default then this option can be used to view the entire buffer.
-nlevel Set the level at which logging of messages is done to the console. For example, -n 1 prevents all messages, expect panic messages, from appearing on the console. All levels of messages are still written to /proc/kmsg, so syslogd(8) can still be used to control exactly where kernel messages appear. When the -n option is used, dmesg will not print or clear the kernel ring buffer.

When both options are used, only the last option on the command line will have an effect.



Examples

dmesg

Display the kernel ring buffer to the screen.

dmesg > boot.messages

Send the kernel ring buffer to the boot.messages file, which could then be sent to another person.



2.dmesg (for "display message") is a command on Unix-like operating systems that prints the message buffer of the kernel.

dmesg (for "display message") is a command on Unix-like operating systems that prints the message buffer of the kernel.

When the computer system is initially booted the kernel is loaded into memory. At this stage each device driver present in the kernel probes the system for the existence of relevant hardware. If the hardware is located, a diagnostic message is produced documenting precisely what was found. Other elements within the kernel may also produce similar output reporting both the presence of that particular module, and the values of any parameters adopted. This process typically happens at a speed where individual messages scroll off the top of the screen before they can be read. The dmesg command allows these messages to be reviewed in a controlled manner after the system has started.

Even after the system has fully booted, the kernel may occasionally produce further diagnostic messages. Common examples of when this might happen are when I/O devices encounter errors, or USB devices are hot-plugged. dmesg provides a mechanism to review these messages at a later time. When first produced they will be directed to the system console: if the console is in use then these messages may be confused with or quickly overwritten by the output of user programs.

The output of dmesg can amount to several complete screens. For this reason, this output is normally reviewed using standard text-manipulation tools such as more, tail, or grep. The output is often captured in a permanent system logfile via a logging daemon, such as syslog.

Many commercial operating systems display an animated splash screen during this stage of the boot process, so the user does not see these messages. However, there is frequently a mechanism to disable the splash screen and view the messages. This is an important diagnostic capability if the system fails to boot. There is also usually a method of reviewing these messages subsequent to start up in a manner equivalent to dmesg.




3.
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 will be confused, 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.

Linux version 2.2.14-5.0 (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 7 20:53:41 EST 2000

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.

Memory: 63008k/65536k available (1084k kernel code, 412k reserved, 968k data, 64k init, 0k bigmem)

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

Dentry hash table entries: 262144 (order 9, 2048k)

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).

VFS: Diskquotas version dquot_6.4.0 initialized

My kernel support quotas (though I'm not using them).

CPU: AMD AMD-K6(tm) 3D processor stepping 00

A quick identification of the processor.

Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.

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

POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb490

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

PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
Activating ISA DMA hang workarounds.
Linux NET4.0 for Linux 2.2

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

Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP

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

TCP: Hash tables configured (ehash 65536 bhash 65536)
Initializing RT netlink socket
Starting kswapd v 1.5
Detected PS/2 Mouse Port.

Should be quite obvious...

Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A

The information about my serial ports.

pty: 256 Unix98 ptys configured
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.9)

My motherboard supports the APM standard for sleeping.

Real Time Clock Driver v1.09
RAM disk driver initialized: 16 RAM disks of 4096K size

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).

VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA

My IDE controllers.

hda: Maxtor 51369U3, ATA DISK drive

My hard drive in the machine.

hdb: IDE/ATAPI CD-ROM 32X, ATAPI CDROM drive

My CDROM drive.

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: Maxtor 51369U3, 12949MB w/2048kB Cache, CHS=6577/64/63
hdb: ATAPI 16X CD-ROM drive, 128kB Cache

Disk information.

Uniform CDROM driver Revision: 2.56
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077

Floppy drive information.

md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
raid5: measuring checksumming speed
raid5: MMX detected, trying high-speed MMX checksum routines
pII_mmx : 761.238 MB/sec
p5_mmx : 726.567 MB/sec
8regs : 447.675 MB/sec
32regs : 308.610 MB/sec
using fastest function: pII_mmx (761.238 MB/sec)

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

scsi : 0 hosts.
scsi : detected total.

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

md.c: sizeof(mdp_super_t) = 4096
Partition check:
hda: hda1 hda2 < hda5 hda6 >

My disk partition information. The brackets indicate extended partitions.

autodetecting RAID arrays
autorun ...
... autorun DONE.

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

VFS: Mounted root (ext2 filesystem) readonly.

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

Freeing unused kernel memory: 64k freed
Adding Swap: 66488k swap-space (priority -1)
ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html
ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xe800, IRQ 11.
eth0: RealTek RTL-8029 found at 0xe800, IRQ 11, 00:80:AD:41:22:10.

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.

Total memory = 72MB; using 512kB for hash table (at c0280000)

Again, total physical RAM available.

Linux version 2.2.6-15apmac (root@video.linuxppc.org) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Mon May 31 03:54:09 EDT 1999

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.

PCI bus 0 controlled by bandit at f2000000
PCI bus 1 controlled by chaos at f0000000

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

System has 32 possible interrupts
via_calibrate_decr: decrementer_count = 100001 (600010 ticks)
Console: colour dummy device 80x25
Calibrating delay loop... 239.21 BogoMIPS

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

Memory: 69900k available (1532k kernel code, 2184k data, 112k init) [c0000000,c4800000]

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

VFS: Diskquotas version dquot_6.4.0 initialized
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware

Let the PCI probing begin!

USB: Universal USB Driver v$Revision: 1.2 $
USB-OHCI: USB Open Host Controller Interface Driver
USB-HUBD: UUSBD Hub Driver v$Revision: 1.2 $
USB-HIDD: USB Human Interface Devices Driver v$Revision: 1.2 $
USB-HIDBP: USB HID Boot Protocol Driver v$Revision: 1.2 $

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

adb devices: [2]: 2 2 [3]: 3 1

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

Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP

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

Starting kswapd v 1.5
MacOS display is /bandit/IMS,tt128mb8

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

Console: switching to colour frame buffer device 80x30
fb0: IMS TT (TVP) frame buffer; 8MB vram; chip version 2
Monitor sense value = 0x73f, using video mode 6 and color mode 0.
fb1: control display adapter

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).

ADB mouse at 3, handler set to 4
ADB keyboard at 2, handler set to 5
PowerMac Z8530 serial driver version 1.01
tty00 at 0xc900e020 (irq = 15) is a Z8530 ESCC, port = modem
tty01 at 0xc9011000 (irq = 16) is a Z8530 ESCC, port = printer

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.

pty: 256 Unix98 ptys configured
Macintosh ADB mouse driver installed.
DMA sound driver installed, using 4 buffers of 32k.
RAM disk driver initialized: 16 RAM disks of 4096K size
loop: registered device at major 7
fd0: SWIM3 floppy controller

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

md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
USB-HUBM: Starting kusbdd (pid 2)
USBD: No USB hosts found
linear personality registered
raid0 personality registered
raid1 personality registered
raid5: measuring checksumming speed

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

8regs : 140.970 MB/sec
32regs : 122.301 MB/sec
using fastest function: 8regs (140.970 MB/sec)
scsi0 : MESH
scsi1 : 53C94
scsi : 2 hosts.

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

mesh: target 0 synchronous at 10.0 MB/s
Vendor: IBM Model: DPES-31080 Rev: S31S
Type: Direct-Access ANSI SCSI revision: 01 CCS
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Vendor: QUANTUM Model: CTS80S Rev: 4.05
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0
mesh: target 3 synchronous at 5.0 MB/s
Vendor: MATSHITA Model: CD-ROM CR-8005A Rev: 4.0i
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
mesh: target 4 synchronous at 10.0 MB/s
Vendor: SEAGATE Model: ST31200N Rev: 8648
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdc at scsi0, channel 0, id 4, lun 0
Vendor: QUANTUM Model: FIREBALL_TM2110S Rev: 300X
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdd at scsi1, channel 0, id 2, lun 0
scsi : detected 1 SCSI cdrom 4 SCSI disks total.
Uniform CDROM driver Revision: 2.54
SCSI device sda: hdwr sector= 512 bytes. Sectors= 2118144 [1034 MB] [1.0 GB]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 166200 [81 MB] [0.1 GB]
SCSI device sdc: hdwr sector= 512 bytes. Sectors= 2061108 [1006 MB] [1.0 GB]
SCSI device sdd: hdwr sector= 512 bytes. Sectors= 4124736 [2014 MB] [2.0 GB]

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.

PPP: version 2.3.3 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.

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

eth0: MACE at 00:05:02:10:e6:6d, chip revision 9.64

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.

Partition check:
sda: sda1 sda2 sda3 sda4 sda5 sda6
sdb: sdb1
sdc: sdc1 sdc2 sdc3 sdc4
sdd: sdd1 sdd2 sdd3 sdd4

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

md.c: sizeof(mdp_super_t) = 4104
autodetecting RAID arrays
autorun ...
... autorun DONE.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 112k init 32k prep
Adding Swap: 131428k swap-space (priority -1)

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.