Not exactly the error message that you were hoping to see when you were checking you dmesg logs.  Don’t panic, this is easily remedied.  If you are wondering how to check your own Linux system for this error you can look by using this command:

dmesg | grep -i cpu

This error occurs on a multiple logical processor system when a uniprocessor kernel is loaded.  What the error indicates is that one CPU is being used and that more have been found but are being ignored.  The system should come online correctly but with only a single logical CPU.  (For a detailed discussion on logical processors see CPUs, Cores and Threads.)

In today’s market full of multi-core CPU products and hyperthreading this error message has moved from the exclusive realm of multi-socket servers to the home desktop and laptop.  It is now a potentially common site for many casual Linux users.

To correct this issue on a Red Hat, CentOS or Fedora Linux system all you will need to do is make a simple change to your GRUB configuration to tell it to point to a symmetrical multiprocessor (smp) kernel rather than the uniprocessor kernel. The file that you will need to edit is /etc/grub.conf.  After some header comments the beginning of your file should look something like this:

default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.9-67.0.7.plus.c4smp)
     root (hd0,0)
     kernel /vmlinuz-2.6.9-67.0.7.plus.c4smp ro root=/dev/VG0/LV0
     initrd /initrd-2.6.9-67.0.7.plus.c4smp.img
title CentOS (2.6.9-67.0.7.plus.c4)
     root (hd0,0)
     kernel /vmlinuz-2.6.9-67.0.7.plus.c4 ro root=/dev/VG0/LV0
     initrd /initrd-2.6.9-67.0.7.plus.c4.img

The GRUB configuration file can appear daunting at first but, in reality, it is quite simple to deal with.  The only line with which we are concerned with making modifications is the “default” line value.  In this case it is set to 1.  The grub.conf file contains a list of available kernels for us to use.  We may have just one or possible several, maybe even dozens.  In this case we see two.  You can see here that we have a CentOS 2.6.9 c4smp and a CentOS 2.6.9 c4 kernel.  You only need to be concerned with the “title” lines.  These are your kernel titles.  Normally the kernels of most interest will be at the top of the file.

You can check the name of the kernel that you are currently running by issuing:

uname -a

The first title line is kernel “0”, the second is kernel “1”, the next “2” and so forth.  Right now our “default” value is pointing to “1” which is the second kernel from the top and, as you will notice, not an smp kernel (therefore it is a uniprocessor kernel.)  In this case all we need to do is change the “default” value from “1” to “0” so that it now points to the first kernel option which for us is the smp kernel.

After your grub.conf file has been saved you make reboot the Linux system.  If all goes well it will return to you with additional logical processors enabled.  You can verify the name of the loaded kernel with the command given above.

In my examples I will be working from Red Hat Enterprise Linux 4 running on an HP DL585 G2 using dual-core CPUs. This model uses AMD Opteron processors which are natively 64bit and based on the AMD64 architecture (a.k.a. x86-64 or x64.)

We will begin by looking at the output of dmidecode. Dmidecode is the most standard method for retrieving this type of information. We know that all four of our processors will be identical due to SMP limitations so we will not bother to look at all four of them – one will be sufficient. Using dmidecode we can retrieve both the Max Speed of the board as well as the Current Speed of the installed processors.

dmidecode | grep "Current Speed" | head -n 1
Current Speed: 2400 MHz

dmidecode | grep "Max Speed" | head -n 1
Max Speed: 2400 MHz

In this case we can see that we are dealing with processors of 2.4GHz which, according to dmidecode, is the fastest processor available for this revision of the motherboard. Often maximum speeds can be changed by the BIOS so do not be surprised if a firmware update changes this number. The “head -n 1” is simply for clarity to remove the extra processors – they all show identical information. Dmidecode pulls its information directly from the system firmware.

Cpuinfo in the proc filesystem is full of very useful CPU information and should be a primary source of discovery. In should be noted, however, that /proc/cpuinfo can be misleading if used incorrectly but that it contains some of the most important information to our system. Again we will only look at a single CPU instance in this example.

grep MHz /proc/cpuinfo | head -n 1
cpu MHz : 1004.694

In this case we see that cpuinfo is reporting to us that the processors are running at just 1GHz. This is a very different number than what we saw with dmidecode. The reason for the difference in the reported speed is that dmidecode is showing the processor’s rated speed – more or less its model number. This is why the speed is an even number. Cpuinfo, on the other hand, is reading the current speed directly from the CPU clock. Normally we would expect these numbers to be very close to each other with an acceptable degree of rounding. This dramatic difference in speeds is because the server is mostly idle and the CPU has been stepped down by the kernel to save power while it is not needed. This is an important power saving characteristic of newer processors and needs to be taken into account when using CPU speed reporting tools.

We can find additional information, as detected during the boot process, from dmesg. Dmesg will give us the maximum detected speed of our process as well as some very useful information if we just know where to look.

dmesg | grep "MHz processor"
time.c: Detected 2411.266 MHz processor.

dmesg | grep "powernow" | head -n 6
powernow-k8: Found 8 Dual-Core AMD Opteron(tm) Processor 8216 processors (version 2.00.00-rhel4)
powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0xa
powernow-k8: 1 : fid 0xe (2200 MHz), vid 0xc
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xe
powernow-k8: 3 : fid 0xa (1800 MHz), vid 0x10
powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12

As you can see from the first command output, dmesg tested the processors and determined that they are approximately 2.4GHz which corresponds to the rated speed as shown by dmidecode. We can see here that dmesg believes that this server has eight CPUs which is technically correct as each Opteron in this configuration is truly two processors. This is confusing, though, because it reports eight dual-core processors which is not correct. There are four dual-core processors here. Each dual-core is two discrete processors for eight total with just four sockets (semantic difference between the die configuration of Intel and AMD chips.)

What we are really interested in, in the above output, is the five PowerNow K8 levels – zero through four. These are the five speed steps available to our processors. When viewing the output of /proc/cpuinfo we should see the processor to be at one of the speeds indicated here as being available to us. This can be extremely useful information.

We can also discover some simple CPU count information through our first two tools. Each tool views the system differently so we need to be aware of what we are looking at. Dmidecode views the system from a socket perspective and cpuinfo views the system from a core perspective (which can be either an independent CPU or cores within a single CPU – AMD versus Intel ideology.)

dmidecode | grep "Central Processor" | wc -l
4

grep processor /proc/cpuinfo | wc -l
8

As you can see, it is important to know which view of the processor you are speaking about. This will become ever more important as CPUs continue to increase in cores per CPU, CPUs per socket and threads per core!

To gain more insight into the CPU discovery process I will now run through the same examples but on an HP DL380 G5 server using two quad-core Intel XEON processors based on its Core 2 architecture.

dmidecode | grep "Current Speed" | head -n 1
Current Speed: 2333 MHz

dmidecode | grep "Max Speed" | head -n 1
Max Speed: 4800 MHz

grep MHz /proc/cpuinfo | head -n 1
cpu MHz : 2333.337

dmesg | grep "MHz processor"
time.c: Detected 2333.337 MHz processor.

dmidecode | grep "Central Processor" | wc -l
2

grep processor /proc/cpuinfo | wc -l
8

Unfortunately the trick used on the AMD Opteron to display the steppings of the PowerNow architecture does not work with the Intel processors. But we can see here how the discrepancy between processor reporting methods varies even more dramatically as we move towards more multi-core processors.