Ubuntu

ksoftirqd high CPU on 10.04-LTS Server

Reported by Ralph on 2010-05-04
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (CentOS)
Fix Released
Unknown
linux (Ubuntu)
Undecided
Unassigned

Bug Description

On an HP DL380G6 running a fresh install of 10.04 LTS Server 64-bit, I observed ksoftirqd hitting the CPU (up to 100%). Fortunately it limited itself to one core. I did not see this on 9.10 Server 64-bit on the same hardware. I installed the mainline kernel from today (2.6.34-999-generic) and the problem did correct itself.

WORKAROUND: 1. Edit /boot/config-{kernversion}-server (on mine right now this is 2.6.31-22); comment out any line with IPMI in it.
2. Get rid of /lib/modules/2.6.31-22-server/kernel/drivers/char/ipmi/ipmi_* (or whatever your kern version is). I moved these files to another location just in case I needed them.

Ralph (rforsythe) wrote :
tags: added: kj-triage
Shura (shurymury) wrote :

I see the very same behavior on MacBook 5.1.

Thomas Jarosch (thomas-jarosch) wrote :

Ralph, could you look for any "ipmi_*" module and try to unload it?

That worked for me on a HP Proliant DL320G6.

Ralph (rforsythe) wrote :

Late followup, but that did indeed work. I also went back 9.10 with a current patch level and saw the same thing, so this appears to be a kernel version thing and not just the version of Ubuntu.

For others, this is what I did to permanently disable ipmi and get my CPU back:
1. Edit /boot/config-{kernversion}-server (on mine right now this is 2.6.31-22); comment out any line with IPMI in it.
2. Get rid of /lib/modules/2.6.31-22-server/kernel/drivers/char/ipmi/ipmi_* (or whatever your kern version is). I moved these files to another location just in case I needed them.
3. Profit!!

After a reboot, ksoftirqd is back to being happy.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 575392

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Jimmy the shoe (jdshewey) wrote :

I too am experiencing this issue and it does appear to be an upstream problem. It sounds like the commonality is HP hardware and kernel version. I found this thread: http://forums.fedoraforum.org/archive/index.php/t-70926.html and this bug: http://bugs.centos.org/view.php?id=5813 for a similar issue. So who among us is running an HP server, what model and what is your RAID configuration?

I'm on an HP ProLiant DL380 G3 with RAID5. Running a 2.8Ghz Intel Chip. I am unable to run the apport-collect 575392 due to the lockup and am running ubuntu 12.10.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (CentOS):
status: Unknown → New
Changed in linux (CentOS):
status: New → Fix Released

Ralph, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

tags: added: lucid needs-kernel-logs needs-upstream-testing
removed: 10.04 cpu high ksoftirqd
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.