Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

We have CentOS 6.4 and the kipmi0 is showing as 99.8%cpu and 0.0% memory and load average is 1.00. What should we do to rectify on this?

share|improve this question
you should start by reading this www-01.ibm.com/support/… –  Shutupsquare May 6 '13 at 19:31
@I have read it before so it just says ignore should I just ignore but my other machines are not having this issue? –  biz14 May 6 '13 at 19:40
Are the other systems identical to this system? You're going to have to determine that they are. There has to be something that's fundamentally different between them. Firmware? Same RPM versions? –  slm May 7 '13 at 1:08
@Yes there is two same machines with same centos 6.4 what should I look for now? –  biz14 May 7 '13 at 3:44
Compare the outputs from lshw and dmidecode would be my next areas to look into. –  slm May 7 '13 at 18:00
show 3 more comments

4 Answers

up vote 2 down vote accepted

Debugging the issue

Are the other systems identical to this system? You're going to have to determine that they are. There has to be something that's fundamentally different between them. Firmware? Same RPM versions?

You can use tools such as lshw, dmidecode, and looking at the dmesg log for clues as to what's different and what's the root cause.

I'd get a good baseline of the RPMs installed by running this command on one of the systems that's not exhibiting this issue and the one that is and compare the package lists to make sure they're all at the same versions.

 # machine #1
 $ rpm -aq | sort -rn > machine1_rpms.txt

 # machine #2
 $ rpm -aq | sort -rn > machine2_rpms.txt     

Then get the files on the same machine and do an sdiff of the 2 files:

 sdiff machine1_rpms.txt machine2_rpms.txt

Potential cause #1

The IBM website had this technote titled: Kipmi0 May Show Increased CPU Utilization on Linux, regarding this issue. According to this issue you can essentially ignore the problem.

description of issue

The kipmi0 process may show increased CPU utilization in Linux. The utilization may increase up to 100% when the IPMI (Intelligent Platform Management Interface) device, such as a BMC (Baseboard Management Controller) or IMM (Integrated Management Controller) is busy or non-responsive.


No fix required. You should ignore increased CPU utilization as it has no impact on actual system performance.


  1. If using an IPMI device, reset the BMC or reboot the system.
  2. If not using an IPMI device, stop the IPMI service by issuing the following command:

    service ipmi stop

Potential solution #2

I found this post on someones blog simply titled: kipmi0 problem. This problem sounded identical to yours. The issue was traced to an issue with 2 kernel modules that were getting loaded as part of the lm_sensors package.

These were the 2 kernel modules:

  • ipmi_si
  • ipmi_msghandler


You can manually remove these with the following commands:

rmmod ipmi_msghandler
rmmod ipmi_si

To make this fix permanent, you'lll need to disable the loading of these particular kernel modules within one of the lm_sensors configuration files, by commenting them out like so:

# /etc/sysconfig/lm_sensors
# MODULE_0=ipmi-si
# MODULE_1=ipmisensors
# MODULE_2=coretemp

Restart lm_sensors after making these changes:

share|improve this answer
I have been to both the website and in my system I dont find this file /etc/sysconfig/lm_sensors. Something funny when I do the sort on the first file is Asc but the second file is desc? Secondly how to output the difference into a file. Yes I can see quite a number of difference too. –  biz14 May 7 '13 at 4:07
yes now I did the second time it is sorted accordingly descending. I dont get you how to use the grep "|". What else should I do to rectify this problem? –  biz14 May 7 '13 at 12:05
All I was saying was to do this: sdiff machine1_rpms.txt machine2_rpms.txt | grep "|" will pull out all the differences b/w the 2 .txt files. There are other ways to do it but that's one way. –  slm May 7 '13 at 14:00
I ran this command and here is the output sdiff 12_rpms.txt 11_rpms.txt | grep "|" perl-DBI-1.609-4.el6.x86_64 | perl-Digest-SHA-5.47-131.el6_4.x86_64 . The 12_rpms is the problem machine and the other one is without the issue. But when I manually look 12_rpms have 247 lines and 11_rpms have 263 but the sdiff is just one? So what should be my next step now based on this difference? –  biz14 May 7 '13 at 17:56
Please post these files as well on pastebin.com. –  slm May 7 '13 at 19:41
show 4 more comments

According to the IPMI Document:

this thread can use a lot of CPU depending on the interface's performance. This can waste a lot of CPU and cause various issues with detecting idle CPU and using extra power. To avoid this, the kipmid_max_busy_us sets the maximum amount of time, in microseconds, that kipmid will spin before sleeping for a tick. This value sets a balance between performance and CPU waste and needs to be tuned to your needs. Maybe, someday, auto-tuning will be added, but that's not a simple thing and even the auto-tuning would need to be tuned to the user's desired performance.

So,we can execute this command to set the kipmid_max_busy_us parameter:

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

In our system,after set this parameter,the cpu of kipmi0 decreased to 15%.

You can try this.

To make the changes persistent you can configure the options for the ipmi_si kernel module.
Create a file in /etc/modprobe.d/, i.e./etc/modprobe.d/ipmi.conf, and add the following content:
# Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100

Now everytime the ipmi_si kernel module is loaded into the kernel the paramter should be automatically and correctly set.

share|improve this answer
Although this may be the correct answer, it is considered best practice on SE sites to detail the reasoning as part of your answer, as well as quoting any external links. That way, if the external link becomes defunct, the logic and reasoning is still viewable here. –  Drav Sloan Sep 16 '13 at 14:32
Thank you,I have rewrited my answer. –  d0ngw Sep 17 '13 at 2:56
Is there a standard way of making that take effect permanently? –  tgharold Sep 17 '13 at 13:27
On CentOS/RHEL, that command can be made permanent by adding it to /etc/rc.d/rc.local. The rc.local runs after all of the other init scripts. –  tgharold Sep 17 '13 at 13:33
Thanks @tgharold ,I will add it to our server. –  d0ngw Sep 18 '13 at 2:33
add comment

kipmi0 can be disabled on CentOS 6 entirely by adding ipmi_si.force_kipmid=0 as a kernel parameter

Test at the GRUB boot screen by highlighting the kernel you want to boot, hit 'a' to modify parameters and appending ipmi_si.force_kipmid=0

Make permanent by appending ipmi_si.force_kipmid=0 to the relevant kernel lines in /boot/grub/grub.conf

NOTE: In distros that have ipmi_si as a separate kernel module, using a modprobe.d conf file is more appropriate. In CentOS ipmi_si is built in to the kernel image, so modprobe configs do not work.

share|improve this answer
add comment

CentOS 6 have ipmi driver compiled in kernel. If you do not need ipmi support then just disable it grub.conf

ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0
share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.