This bug really belongs to procinfo not Gentoo - but the listed maintainers
website doesn't seem to exist, and we could fix it with a quickie patch in the
procinfo detects the number of cpus by reading /proc/cpuinfo and (for x86
anyways) counting the number of times a line starts with "processor". The
problem is that each CPU in my PIII also has a line in cpuinfo that says
"processor id", so my 2 cpu system gets counted as 4 cpus, which then screws up
the idle/sys/user time percentages.
The one-liner fix is to change this:
if (!strncmp ("processor",9)) /* Intel */
if (!strncmp ("processor\t",10)) /* Intel */
at line 837 of procinfo.c
Hmm, apparently this practice is common. I noticed a similar problem (my dual
cpu machine detected as 4 cpus) with "top", which comes from the procps
package. I investigated the procps code, and found that it got the number of
processors from a glibc library call. As it turns out, buried deep down in
glibc is this exact same "bug" that procinfo has, which can be fixed the same
way (adding a tab to the end of the "processor" search string).
Perhaps if it's common between both procinfo and glibc to use a search for
"processor" on /proc/cpuinfo to determine #cpus, the fix should be in the
kernel? It could be trivially fixed there by changing the text for
/proc/cpuinfo for PIII processor ids from "processor id" to something like
This is fixed on the kernel side in Alan's tree from 2.4.19-rc5-ac1 and onwards.
It hasn't whoever been merged to the mainline tree. The comment from Alan's
Switch 'processor id' to 'physical id' (me)
| Keeps glibc happy until we sort out cpu numbers longer term
gentoo-sources is still based on 2.4.19-pre7-ac2, but I assume gentoo-sources
will catch up with this patch in due course on it's, so no need for this bug
anymore, moving it to resolved.