>>>> Has anyone had similar trouble? >>> No. But it sounds like the AVX disaster. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=801650 >> 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 /lib64/libpython2.7.so.1.0 >> #3 0x00007ffff7b00b2f in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 >> #4 0x00007ffff7b00c02 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0 >> #5 0x00007ffff7b1017d in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0 >> [...] >> >> 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: ketuzsezr@xxxxxxxxxx The issue in glibc has been fixed by Jeff Law. Please see: https://admin.fedoraproject.org/updates/glibc-2.15-51.fc17 Python works fine with this update, pushed today. -- Mike :wq -- xen mailing list xen@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/xen
