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.
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 /proc/cpuinfo.
*** Bug 147762 has been marked as a duplicate of this bug. ***
Please explain the following encountered with 2.4.9-e.59enterprise using hyperthreading. # 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
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.
The fix has been submitted today for inclusion in the next update.
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).
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. http://rhn.redhat.com/errata/RHSA-2005-283.html