>>>> Has anyone had similar trouble?
>>> No. But it sounds like the AVX disaster.
>> It seems to be.
>> I booted bare metal and used yum to install gdb and the debug symbols
>> for Python and glibc.
>> Then I rebooted in Xen. I found that gdb itself crashed when the debug
>> symbols were installed, so I removed them. I ran gdb again and obtained
>> a partial backtrace on "import random":
>> (gdb) ba
>> #0 0x00007ffff71474ec in __ieee754_exp_fma4 () from /lib64/libm.so.6
>> #1 0x00007ffff009e415 in ?? () from /usr/lib64/python2.7/lib-dynload/math.so
>> #2 0x00007ffff7b00053 in PyEval_EvalFrameEx () from
>> #3 0x00007ffff7b00b2f in PyEval_EvalCodeEx () from
>> #4 0x00007ffff7b00c02 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
>> #5 0x00007ffff7b1017d in PyImport_ExecCodeModuleEx () from
>> After looking a little closer, it seems that __ieee754_exp_fma4 is
>> executing "vmovsd %xmm0,-0x20(%rsp)".
>> I thought booting Xen with xsave=1 might help, but this causes Xen to
>> crash on this hardware. As mentioned above, it looks like there has been
> Right. That is b/c of Fedora's incorrect extra patch that neuters xsave.
>> work in glibc to properly detect AVX (my understanding is that you have
>> to check that both the processor and OS supports it). Is it possible
>> that this glibc work missed something?
> Very likely. There was another fix to it that got added in Debian (or Ubuntu)
> that checked for FMA4 on AMD (which had a different CPUID).
> Can you open a Red Hat bugzilla please? And CC me on it: ketuzs...@darnok.org
The issue in glibc has been fixed by Jeff Law. Please see:
Python works fine with this update, pushed today.
xen mailing list