Created attachment 488814 [details] Variation of the patch posted upstream to use cpuid 4 rather than cpuid 2 when possible Description of problem: The mechanism that sysconf(3) uses to get the various CACHE parameters fails on the Xen 5670 Version-Release number of selected component (if applicable): 2.12-1.7.el6_0.4 How reproducible: Every time Steps to Reproduce: 1. Find a machine whose /proc/cpuinfo starts something like this: vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU X5670 @ 2.93GHz stepping : 2 2. run "getconf -a | grep CACHE" 3. Observe values printed Actual results: All the cache parameter values are zero. Expected results: Non-zero values for all but the level 4 cache Additional info: Recent CPUs no longer have useful cpuid leaf 2 cache descriptors. For this particular machine, cpuid 2 returns 0x55035a01 0xf0b2ff 0x0 0xca0000 in eax, ebx, ecx and edx respectively. The 0xff in the least significant byte of ebx indicates that you need to use cpuid leaf 4. Actually, for all but somewhat old CPUs you're better off using cpuid leaf 4 anyway (the only machines I have access to that have a cpuid level less than four are a "Intel(R) Pentium(R) 4 CPU 1.70GHz" and "Intel(R) Pentium(R) 4 CPU 2.40GHz" both of which are long past their use-by date).
Sorry, of course the glibc version should be 2.5-58
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Note for QE, this was fixed for RHEL 6 (692177). There is a testcase, but it's not attached to be BZ. The testcase ID is 87285.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The glibc sysconf() function provides a way for the application to determine values for system limits or options at runtime. The mechanism that sysconf(3) uses to get the various CACHE parameters was incorrectly returning all zeroes on the Xeon X5670. sysconf() was modified to handle this CPU type correctly and return the information requested.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0022.html