Created attachment 69450 [details] dmesg output With the update to Mesa 9.0 my machine completely locks up as soon as I start a 3D application like XBMC or glxgears. Mouse and keyboard don't react and the machine is not reachable via network anymore either. Downgrading to 8.0.4 fixes the problem. I also compiled from git with "--enable-debug" (I assume this is enough to enable debugging?!). When I export MESA_DEBUG=1 and start glxgears the window opens with completely black content and I get the following output before the machine locks up: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. Strange thing I noticed: If I update the system to 9.0 and then restart my display manager, everything works fine. It is only after a reboot that the machine locks up as soon as I start a 3D application. dmesg and lspci attached. Arch Linux x64 Kernel 3.6.4 Xorg 1.13.0 xf86-video-intel 2.20.12 Intel Core i5 2500 (Sandy Bridge) Asus P8H77-I (Ivy Bridge)
Created attachment 69451 [details] lspci
Corrected the subject to mention the hardware you're using, not i915. Are you using some unusual window manager or something maybe? Naturally, we aren't seeing hangs on starting GL applications. When you said one variant worked with a specific update pattern, was that window manager using 9.0 and everything else using 8.0, or window manager using 8.0 and everything else 9.0?
This is actually an HTPC where I usually run XBMC standalone, so no window manager. To make sure this was not an XBMC problem I installed the i3 window manager which works fine on its own, but as soon as I start glxgears or XBMC from there, the machine locks up. I am not mixing versions between WM/Applications. After updating to 9.0 I completely kill X and start XBMC standalone, meaning no window manager or other GL application running. XBMC then works fine and even reports Mesa 9.0 in the system information. After a reboot however I get the lockup without really having changed anything on the system. Same thing happens with i3 and glxgears. I know this doesn't seem to make any sense, but I reproduced this behaviour multiple times.
I was able to confirm the same problem with different hardware: Intel H67CF Intel Pentium G620T After about 150 reboots while trying to narrow down the problem I actually found something interesting. The problem is that is doesn't make any sense whatsoever to me. The machine only locks up under the following conditions: - I'm running Mesa 9.0 - I start X for the first time - My Display Manager is configured to autologin my user I was even able to confirm this with 3 difference DMs: slim, lxdm and gdm. If the DM is set to autologin, the machine locks up as soon as I start glxgears, XBMC or whatever. If I disable autologin and log in manually, everything works fine. Even more confusing: once I logged in manually, I can kill X and use autologin on any DM just fine. I hope you can make any kind of sense of this because I seriously can't.
Seems like I'm not alone, another Arch Linux user has the same weird problem: https://bbs.archlinux.org/viewtopic.php?pid=1193362 I told him about this bug report but he is gone for 2 weeks now, I'm sure he will report here after that.
Hello, I have a similar problem. When I start xbmc via .xinitrc the pc freeze. When I remove the .xinitrc from home. X Starts and I can start xbmc from xterm. When xbmc was started once I can close X and start xbmc via .xinitrc. my System Archlinux x64 Kernel 3.6.6 X.org 1.13.0 xf86-video-intel 2.20.12 core i3-2100T
Her is another one with this problem http://forum.xbmc.org/showthread.php?tid=144211
That's my post on the xbmc forum in the previous comment. I since changed to the LTS kernel, and that fixed the issue for me.
So it's gone with an updated kernel? If so, we may have just been tickling one of the many pieces of hardware that require workarounds from the kernel, and I'd say you can make this resolved fixed.
no, this still happens with kernel 3.6.7 and mesa 9.0.1. I haven't tried the LTS kernel yet (which is 3.0.52 in Arch Linux currently) because it can't be booted from Gummiboot-efi. But I'm gonna set up another bootloader and try to confirm that the LTS kernel doesn't have this problem. Then I'm gonna try to narrow this down to a specific kernel version. I already tested kernel 3.5 before so if the LTS kernel indeed doesn't have this problem, whatever is causing this must have been introduced between 3.1 and 3.5 and for some reason is only triggered with Mesa >= 9.0.
Kernel 3.3.8 works fine, 3.4.0 is the first to cause the lockup, meaning that the problem only occurs with: - Mesa >= 9.0 - Kernel >= 3.4.0 Maybe someone can confirm this (whoever uses Arch can use the "downgrade" package from the AUR).
I can also confirm the same problem as the original reporter. I am also running XBMC on Intel Sandybridge hardware. The machine completely locks up during XBMC startup.
I've also the same problem on my Intel Celeron G550, with INTEL HD 2000. As the workaround in that moment I've start DM (like gdm) first, and then i've start xbmc. Problem occure with mesa in version > 8.0.4 and intel-dri > 8.0.4. Info about my architecture: ArchLinux Kernel: 3.7.9 Xorg-server: 1.13.2.901 Mesa/Intel-dri: 9.1
Hi, same problem for me here. Pentium G860, Z77 arch 64 Kernel 3.7.10 xorg-server 1.13.3 mesa 9.1 thx
isn't this bug related to that one ? https://bugs.freedesktop.org/show_bug.cgi?id=54964
looks like it, but according to the comments the patches were merged into 3.8-rc2. I am however running 3.8.2 and the problem is still there...
I'm also an effected user, see my comments on issue 2 posts above. The mentioned merged patches doesn't work me too. I tried the Ubuntu mainline 3.8 final kernel. I think, this issue is still not fixed or at least not fixed by only updating the kernel alone.
I think this was the fix: commit 1dfea559c3f188a7a82a4abc09765ba09e939522 Author: Eric Anholt <eric@anholt.net> Date: Wed May 1 16:08:12 2013 -0700 i965: Fix SNB GPU hangs when a blorp batch is the first thing to execute.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.