You are not logged in.
Hello,
I have a strange bug since mesa has been upgraded to 11.0.x version and also since llvm and llvm-libs have been upgraded to the 3.7.0 version,
I use the mesa r600 driver ( /usr/lib/xorg/modules/dri/r600_dri.so ), I have a radeon HD4650 pcie, a pentium dual core E6800 ( 3.33 Ghz ), I use archlinux 64 bits,
the bug occurs when a program use the openGL function glRasterPos2i(), or when the 100% emulation software mode is used ( "export LIBGL_ALWAYS_SOFTWARE=1" ),
for example the crash will occur with the program "tunnel" ( from mesa-demos package ), it will crash with the error "illegal instruction",
I want to know if I am alone with this bug ?
I can also reproduce this in a virtual machine ( qemu i686 ),
I created a bugreport :
https://bugs.freedesktop.org/show_bug.cgi?id=92214
if I downgrade to llvm 3.6.2 and llvm-libs 3.6.2, and if I rebuild mesa packages ( in order to link them to llvm-libs 3.6.2 ) then there is no bug, all is ok
Last edited by Potomac (2015-10-13 20:15:09)
Offline
I made a discovery :
in qemu I can set a type of CPU ( pentium, pentium2, pentium2, core2duo, SandyBridge and many more ), you can see the CPUs list with the command "qemu-i386 -cpu ?",
until now I used the qemu option "-cpu host", which means that it's the CPU of the host who is emulated ( my pentium dual core E6800 ),
then I decided to set a different CPU name in my qemu script :
-cpu core2duo -enable-kvm -machine type=pc,accel=kvm -smp 2
with this setting the bug disapears, all is ok in my virtual machine, glxgears and all openGL programs can run without crash, the mesa driver llvmpipe doesn't crash,
after that I decided to do set again another CPU in qemu :
-cpu Penryn -enable-kvm -machine type=pc,accel=kvm -smp 2 \
with "Penryn" CPU the bug is back in my virtual machine, which means that the bug seems related to the type of CPU, llvm 3.7.0 lib may have a bug when he tries to generate binary code, it fails with some CPUs,
this problem doesn't exist with llvm 3.6.2 lib
Offline
Mesa was just updated to 11.0.3 , do the problems also occur with that version ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
yes the problem is still here with mesa 11.0.3
Offline
I did further tests,
I found that llvm 3.7.0 sees my CPU pentium dual core like a "Penryn" :
$ llc --version | grep CPU
Host CPU: penrynbut llvm 3.6.2 ( who doesn't have the bug ) sees my CPU pentium dual core like a "core2"
$ llc --version | grep CPU
Host CPU: core2why this different behaviour ?
it could explain this bug if llvm 3.7.0 generates binary code for a wrong cpu ( penryn instead of core 2 )
Last edited by Potomac (2015-10-13 21:33:11)
Offline
I found the cause of this bug,
it's llvm 3.7.0, the llvm git commit who has introduced this bug is :
cd83d5b5071f072882ad06cc4b904b2d27d1e54a
https://github.com/llvm-mirror/llvm/com … 2d27d1e54a
the problem is that llvm 3.7.0 treats my pentium dual core as a "penryn",
penryn supports SSE4, but not the pentium dual core series ( CPU family 6 model 23 ),
the faulty commit has deleted a test about SSE4 :
return HasSSE41 ? "penryn" : "core2";
the solution is simply to add this test for CPU family 6 model 23, I created a patch who solves this bug :
--- a/lib/Support/Host.cpp 2015-10-14 07:13:52.381374679 +0200
+++ b/lib/Support/Host.cpp 2015-10-14 07:13:28.224708323 +0200
@@ -332,6 +332,8 @@
// 17h. All processors are manufactured using the 45 nm process.
//
// 45nm: Penryn , Wolfdale, Yorkfield (XE)
+ // Not all Penryn processors support SSE 4.1 (such as the Pentium brand)
+ return HasSSE41 ? "penryn" : "core2";
case 29: // Intel Xeon processor MP. All processors are manufactured using
// the 45 nm process.
return "penryn";this patch has been sent to llvm's bugzilla, I hope they will accept it
Last edited by Potomac (2015-10-14 06:39:14)
Offline