https://bugzilla.novell.com/show_bug.cgi?id=823702 https://bugzilla.novell.com/show_bug.cgi?id=823702#c1 --- Comment #1 from Dinar Valeev 2013-06-06 17:00:20 UTC --- Created an attachment (id=543121) --> (http://bugzilla.novell.com/attachment.cgi?id=543121) full build log Please find full build log attached. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=823702 https://bugzilla.novell.com/show_bug.cgi?id=823702#c2 --- Comment #2 from LTC BugProxy 2013-06-12 13:01:21 UTC --- Towards the end of the build, it reports segfaiults. Were there any core files generated? Did they show anything in common? Also, does the output of dmesg show any new kernel messages during the build? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=823702 https://bugzilla.novell.com/show_bug.cgi?id=823702#c4 Paul Mackerras changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paulus@au1.ibm.com --- Comment #4 from Paul Mackerras 2013-06-14 00:45:19 UTC --- I have looked into this a bit. The first test I looked at, align, falls over with a SIGSEGV when run in a KVM guest on a POWER7, but gets a SIGILL when run in the host. It turns out that there is a bug in the liboil code resulting in a pointer value getting truncated to 32 bits. This is in liboil/motovec/vec_memcpy.S line 655: rlwinm DBK,DBK,0,0,27 The intent is to clear the bottom 5 bits of the address, which it will do, but it also clears the top 32 bits. As a result, when run in a 64-bit process with a heap that is up high (past the 4GB point), subsequent accesses using this pointer cause a segfault. There are several other instances of this pattern in both vec_memcpy.S and vec_memset.S. Basically this code was written a long time ago for a 32-bit processor and is not 64-bit safe. Interestingly, this test passes when run under gdb. This is because gdb disables address space randomization and that causes the heap to be located at low addresses (just after the executable). The same effect can be obtained using setarch ppc64 -R. Running "setarch ppc64 -R make check" in the KVM guest reports that 1 of 19 tests failed. Now as far as the SIGILL when running on the host is concerned, this is because we have a kernel bug in handling the emulation assist interrupt (0xe40) in the host. We're calling program_check_exception() to handle it without setting the SRR1 bit that normally says "illegal instruction" for a program interrupt. That causes instructions that we normally emulate (specifically dcba, in this case) not to get emulated. I'll fix that. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=823702 Dinar Valeev changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Dinar Valeev --- Package no longer exists. Closing. -- You are receiving this mail because: You are on the CC list for the bug.