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: always. Steps to Reproduce: 1.boot system 2.login 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.
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!
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.
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!
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")) debug_mode=1; /* On single core UP systems irqbalance obviously has no work to do */ if (core_count<2) exit(EXIT_SUCCESS); But seemed it should be: if (getenv("IRQBALANCE_DEBUG")) debug_mode=1; 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) exit(EXIT_SUCCESS); 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.)
yeah, thats a good point, definately looks wrong. I'll check that in. Thanks!
committed/built in -9.fc9 Thanks!
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")) debug_mode=1; + parse_cpu_tree(); /* On single core UP systems irqbalance obviously has no work to do */ if (core_count<2) exit(EXIT_SUCCESS); 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. --Vaidy
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.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.