Bug 147674 - physical_id field of /proc/cpuinfo contains arbitrary values that change
physical_id field of /proc/cpuinfo contains arbitrary values that change
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jim Paradis
Brian Brock
: 147762 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-02-10 09:39 EST by Ward Fenton
Modified: 2013-08-05 21:12 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-28 11:05:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 81396 None None None Never

  None (edit)
Description Ward Fenton 2005-02-10 09:39:45 EST
We have application which uses a license key which depends on /proc/cpuinfo
remaining consistent. We have been told by Ab Initio support that there appears
to be a bug in kernel code that causes the physical_id field to be set from
uninitialized memory. We have this ETL software running on several dozen servers
and the set of servers which were updated recently to the kernel
2.4.9-e.59enterprise started to encounter this changing /proc/cpuinfo output
after a week of use and now changes occur once or more per day.

[root@etl9op-e15 root]# grep -i "physical id" /proc/cpuinfo
physical id     : -233324544
physical id     : 1
physical id     : -1070399256
physical id     : -1070399256

The physical id field doesn't seem to exist on our 2.4.9-e.40 installs.

Our "control nodes" in an Ab Initio "cluster" are very busy servers. After a
week of use the issue started appearing daily. The eight "processing nodes"
running this same kernel still show a physical id for each cpu of 0.
Comment 1 Michael J. Saletnik 2005-02-10 10:32:15 EST
This bug, in 2.1AS as of 2.4.9-e.57, is the same bug reported in #81396.

In introducing hyperthreaded cpu support to the kernel, the code in
arch/i386/kernel/setup.c initializes phys_proc_id[] only if the cpu is
hyperthreaded (num_smp_siblings > 1), whereas the code that then prints
phys_proc_id[] into /proc/cpuinfo will run for all CONFIG_SMP kernels.

Thus an SMP kernel on a machine with hyperthreading disabled (or unavailable)
will end up printing out the uninitialized values from phys_proc_id[] to

Comment 2 Suzanne Hillman 2005-02-11 16:46:02 EST
*** Bug 147762 has been marked as a duplicate of this bug. ***
Comment 3 Ward Fenton 2005-02-14 04:52:54 EST
Please explain the following encountered with 2.4.9-e.59enterprise using

# grep -E "processor|physical id" /proc/cpuinfo
processor       : 0
physical id     : 661944436
processor       : 1
physical id     : 538970668
processor       : 2
physical id     : 538976288
processor       : 3
physical id     : 538976288
processor       : 4
physical id     : 538976288
processor       : 5
physical id     : 538976288
processor       : 6
physical id     : 538976288
processor       : 7
physical id     : 538976288
Comment 5 Neil Horman 2005-02-14 16:31:31 EST
Just so its written down, I believe that if they disable HT in the BIOS, that
should prevent this problem from occuring until such time as it can be fixed.
Comment 8 Jim Paradis 2005-02-15 16:07:14 EST
The fix has been submitted today for inclusion in the next update.
Comment 16 Jim Paradis 2005-03-02 23:13:54 EST
A fix for this problem has just been committed to the RHEL2.1 U7
patch pool this evening (in kernel version 2.4.9-61).
Comment 17 John Flanagan 2005-04-28 11:05:14 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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