Summary: | Procinfo #cpus bug | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Brandon Black <ph_317> |
Component: | Current packages | Assignee: | Martin Schlemmer (RETIRED) <azarah> |
Status: | RESOLVED FIXED | ||
Severity: | trivial | ||
Priority: | Lowest | ||
Version: | 1.2 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Brandon Black
2002-07-15 22:56:28 UTC
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 "procid". 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 ChangeLog: o 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. |