Bug 433270 - irqbalance isn't launched correctly
Summary: irqbalance isn't launched correctly
Alias: None
Product: Fedora
Classification: Fedora
Component: irqbalance
Version: 9
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-02-18 08:59 UTC by austin
Modified: 2009-07-15 08:17 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-15 08:17:52 UTC
Type: ---

Attachments (Terms of Use)
patch to fix cpu parsing (4.01 KB, patch)
2008-03-17 11:10 UTC, Neil Horman
no flags Details | Diff

Description austin 2008-02-18 08:59:59 UTC
Description of problem:
The system had configurated irqbalance as 'on' in runlevel 3/4/5. But 
irqbalance didn't be launched yet. Run 'chkconfig --list irqbalance', it showes:
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
I am exactly in mode 3, but I can not find the irqbalance daemon by 'ps -ax'.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.boot system
3.ps -ax | grep irqbalance
Actual results:
ps -ax | grep irqbalance --> can not see the irqbalance daemon.

Expected results:
ps -ax | grep irqbalance --> can see the irqbalance is running.

Additional info:
The platform is Intel's stoakley.

Comment 1 Neil Horman 2008-03-14 11:27:18 UTC
You're likely using a single cpu system, or a multi core system which shares a
cache.  In these situations irqbalance will start, detect that balancing will
not have any effect, and exit.  This is working as designed.    Please let me
know if thats not the case, and send in your /proc/cpuinfo file as well as an
strace  from running irqbalance by hand please.  Thanks!

Comment 2 austin 2008-03-17 02:23:46 UTC
In fact, I got this result in Stoakley platform with harpertown processor (quad-
core, a pair cores shared L2 cache, so that means core1 and core2 shared 6M L2 
cache and core3 and core4 shared another 6M L2 cache.)

I will check again and give you feedback when I got F9 beta. Thanks.

Comment 3 Neil Horman 2008-03-17 11:10:49 UTC
Created attachment 298250 [details]
patch to fix cpu parsing

Ok, if its a multi cache system, than this may be a bug.    Since I don't have
the processor you describe on hand, if you could send me all the files that you
have on this system under /sys/devices/system/cpu, and can start looking at
this.  Also, I'm attaching the above patch.  It corrects a glitch in cpu
counting.  I have it in RHEL, but it slipped my mind to move it into fedora. 
If you would please, give it a try.  It may fix up your problem.  Thanks!

Comment 4 austin 2008-03-18 06:19:42 UTC
I thought the root-cause may be: In F9 irqbalnce.c, function parse_cpu_tree() 
is missing before decide the core number, so the app always exit just like 
there was only one cpu(core) in the system before we get the right core number.

In irqbalance-0.55-8.fc9.src.rpm, irqbalance has following lines in main():
	if (getenv("IRQBALANCE_DEBUG")) 

	/* On single core UP systems irqbalance obviously has no work to do */
	if (core_count<2) 

But seemed it should be:
	if (getenv("IRQBALANCE_DEBUG")) 

        parse_cpu_tree(); //missing this line in original source.

	/* On single core UP systems irqbalance obviously has no work to do */
	if (core_count<2) 

I modified code for adding this line, it works fine now in my stoakley (2 
physical cpu, 4 cores in each cpu, a pair cores share 6M L2 cache.) 

Comment 5 Neil Horman 2008-03-18 10:25:19 UTC
yeah, thats a good point, definately looks wrong.  I'll check that in.  Thanks!

Comment 6 Neil Horman 2008-03-18 10:40:34 UTC
committed/built in -9.fc9  Thanks!

Comment 7 Vaidyanathan Srinivasan 2008-04-25 14:06:49 UTC
Hi Neil,

I found the same problem and verified the above fix as well.

--- irqbalance-0.55.orig/irqbalance.c   2008-04-26 05:53:08.000000000 +0530
+++ irqbalance-0.55/irqbalance.c        2008-04-26 05:53:58.000000000 +0530
@@ -74,6 +74,7 @@
        if (getenv("IRQBALANCE_DEBUG")) 
+       parse_cpu_tree();
        /* On single core UP systems irqbalance obviously has no work to do */
        if (core_count<2) 

Adding parse_cpu_tree() made irqbalance work on my dual socket dual core system.

How do I get -9.fc9 to verify the fix.  I found that the problem exist on beta
of F9.


Comment 8 Neil Horman 2008-04-25 14:31:21 UTC
wierd.  Sorry about that.  It was in CVS, but not tagged and not built.  I must
have checked it in while the tree was locked for something.  Its building now,
and should be available in rawhide shortly.

Comment 9 Bug Zapper 2008-05-14 05:15:01 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 10 Bug Zapper 2009-06-09 23:34:34 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 11 Bug Zapper 2009-07-15 08:17:52 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.