Bug#584748: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' on AMD cpu
On Mon, Jun 07, 2010 at 08:47:23AM +0200, Aurelien Jarno wrote:
> Aurelien Jarno a écrit :
> > On Sun, Jun 06, 2010 at 10:27:12PM +0200, Gianluigi Tiesi wrote:
> >> On 06/06/2010 14.55, Aurelien Jarno wrote:
> >>> On Sun, Jun 06, 2010 at 02:17:29PM +0200, Gianluigi Tiesi wrote:
> >>>> On 06/06/2010 13.21, Aurelien Jarno wrote:
> >>>>>> Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/8 CPU cores)
> >>>>> This part is not consistent. Are you running reportbug on a different
> >>>>> machine?
> >>>> yes
> >>>>
> >>>> the problem is on a old amd 800mhz box, but I use a different box
> >>>> for submitting
> >>>>
> >>>> do you need some additional infos about the amd installation?
> >>>>
> >>> Yes, which libc6 packages are actually installed? I have fixed a bug
> >>> that my cause the problem you are observing in version 2.11.1-2, so if
> >>> you are running version 2.11.1-1, please try to upgrade.
> >>>
> >>> Also which kernel are you running?
> >> libc is 2.11.1-2
> >> kernel: Linux attila 2.6.32-5-686 #1 SMP Tue Jun 1 04:59:47 UTC 2010 i686 GNU/Linux
> >>
> >> I known the problem with libc6-i686 and intel i7 I've reported some info too :)
> >
> > It's not the problem with core i7, but a different one that has also
> > been corrected. One that breaks reading model and family in some
> > conditions.
> >
> >> this look different
> >>
> >
> > Unfortunately I am not able to reproduce it. Tried on an Athlon and on
> > Opteron CPU.
> >
>
> For your information, I have been able to find a machine with a CPU
> identical to yours, and I am now able to reproduce the issue. I'll debug
> it later today.
>
Ok, here we go, it's a bit tricky.
First of all, newer versions of the glibc tries to optimise the string
function by using cache information, which are stored in cpuid level 2
and later on an Intel CPU.
Secondly, valgrind does not use the real CPU, but always emulates an
Intel one, trying to match the characteristics of the host CPU,
especially in term of instruction set. When the CPU has no SSE support
it emulates an old Pentium CPU, which have a max a cpuid level of 1.
This is what happens when the host CPU is an Athlon one.
The Pentium CPU is an i586 CPU, which does not support the CMOV
instruction, so the libc from the libc6 package is used. On the other
hand, the Athlon CPU is an i686 CPU, which does support the CMOV
instruction, so the libc from libc6-i686 is used.
Everything works well as long as you don't use valgrind. When you use
it, it loads all the libraries using the host CPUID, that is it loads
the libc from libc6-i686. It latter emulates a Pentium CPU, which has
a cpuid level of 1 only. The glibc code recognizes an Intel CPU (as
valgrind emulates it), and given it is the i686 version of the libc, it
assumes it is at minimum a Pentium Pro (which is the first i686 Intel
CPU), which means it assumes that the cpuid level is at 2. This is
where all the cache information is stored.
The bug really seems to be on the valgrind side, which should not load
an i686 library while emulating an i586 CPU. OTOH, if it is difficult
to fix, we can maybe remove assumptions that are correct, but wrong when
using valgrind.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: