I have received a new work laptop with a corei7 sandybridge chipset (and then rebuilt world with -march=native) and now I get an illegal opcode fault in glibc when starting under xen (no problems booting the same kernel and initrd and system without xen). I've seen several threads that report this to be an upstream problem with glibc's runtime detection or some such involving some of the avr operations (e.g. XSTOR or something like that). Is this going to be addressed in gentoo?
Forgot to mention/set this is an AMD64 ARCH (64 bit multilib) problem.
1) Please post your `emerge --info' output in a comment. 2) Please provide the command command line, command output and gdb backtrace of the program causing the SIGILL.
seems to be the same as in bug #402753?
Created attachment 317165 [details] emerge --info as requested I have attached emerge --info as requested. I suspect the program running at the time is /bin/bash (non statically linked). The kernel is reporting the program as "/init" which is the boot script from the initramfs image. The initramfs image I am using is the one generated by http://underdog.sourceforge.com which is (my soruceforge project, so I know that this is) the bash script in prototype/init from that project. I know this is non-statically linked because that is part of the point of underdog. 8-). I am trying to figure out how to get a core dump from early user context into any rational place where I can gdb it. (Any ideas there?)
er... http://underdog.sourceforge.net (doh, typing too fast. 8-)
(In reply to comment #3) > seems to be the same as in bug #402753? That Summary seems to say it's about a kernel panic, and this is about a segmentation fault in glibc...
Comment on attachment 317165 [details] emerge --info as requested this isn't `emerge --info` ...
post /proc/cpuinfo and the output of running: gcc -march=native - -E -dD -P - </dev/null do this inside & outside of the xen system
(In reply to comment #6) > (In reply to comment #3) > > seems to be the same as in bug #402753? > > That Summary seems to say it's about a kernel panic, and this is about a > segmentation fault in glibc... Please have a look at the screenshots attached in this bug...
there are no screenshots attached to this bug. guess you meant bug 402753.
may be the CFLAG -mno-avx help, but this problem is fixed in unstable upstream.
*** This bug has been marked as a duplicate of bug 433884 ***
