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?

  • you should start by reading this www-01.ibm.com/support/…
    – squareborg
    Commented May 6, 2013 at 19:31
  • 2
    @I have read it before so it just says ignore should I just ignore but my other machines are not having this issue?
    – biz14
    Commented May 6, 2013 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
    Commented May 7, 2013 at 1:08
  • @Yes there is two same machines with same centos 6.4 what should I look for now?
    – biz14
    Commented May 7, 2013 at 3:44
  • Compare the outputs from lshw and dmidecode would be my next areas to look into.
    – slm
    Commented May 7, 2013 at 18:00

6 Answers 6


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 setting 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 every time the ipmi_si kernel module is loaded into the kernel, the parameter should be automatically and correctly set.

  • 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
    Commented Sep 16, 2013 at 14:32
  • Is there a standard way of making that take effect permanently?
    – tgharold
    Commented Sep 17, 2013 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
    Commented Sep 17, 2013 at 13:33

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:

  • 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
    Commented May 7, 2013 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
    Commented May 7, 2013 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
    Commented May 7, 2013 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
    Commented May 7, 2013 at 17:56
  • Please post these files as well on pastebin.com.
    – slm
    Commented May 7, 2013 at 19:41

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.


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

I found the following helps with this issue:

ipmitool bmc info

This seems to wake up IPMI and then it stops using 100% of a core.

I also found the following helpful:

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

Also in the past I have been able on some servers to resolve the 100% CPU usage by:

ipmitool lan print


ipmitool bmc reset cold

but in my most recent experience the above options would just cause ipmitool to be non-responsive and sit there, causing me to Ctrl+C it.

Hopefully this helps someone.

  • Is there any problem to do echo 1 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us?
    – Qian Chen
    Commented Apr 20, 2016 at 12:41

I found this running CentOS 7 and trying to figure out what was taking it up.

For me, it was Supermicro's "ipmicfg" running from a script I wrote or something. I just pkilled it and the kipmi0 usage went away.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .