Messages in this thread | | | From | Andi Kleen <> | Subject | Re: AVX "Sandy Bridge" hardware issue? | Date | Tue, 12 Jul 2011 17:49:35 -0700 |
| |
MK <mk@cognitivedissonance.ca> writes: > > In which Andreas Schwab points out (rightly or wrongly) that according > to the /proc/cpuinfo from the slice, the processor actually does not > support AVX. However, the "model name", "Intel(R) Xeon(R) CPU > E31230", is according to this a Sandy Bridge processor with AVX:
If it's in a VM then the VM may not expose AVX to the guest (the VMs have to do that explicitely because AVX has additional state). If it's not in /proc/cpuinfo on the guest that's likely the case.
However glibc should of course not use AVX in this case.
> Does anyone have any idea why I would get this identical backtrace, and > a failed reproducer test, on hardware which supposedly supports AVX > (but not according to the kernel in /proc/cpuinfo)?
If there's a problem then it's likely in the VM. Maybe it leaks AVX partially through only.
For example I had a similar problem a long time ago on a system which had inconsistent CPU features for different CPUs. The kernel will chose the least common denominator, but an application directly calling CPUID can sometimes see different flags and then crash when it switches CPUs.
The symptoms would be consistent with that.
I would contact the VM vendor.
-Andi
-- ak@linux.intel.com -- Speaking for myself only
| |