Created attachment 39009 [details] Backtrace of frozen Xserver On a SandyBridge [8086:0106] (internal reference at SuSE: NUE837) running - kernel 2.6.36-rc5 - xorg server 1.9.0 - intel driver git 55b5fe8 - libdrm git 7ec9a1e - Mesa 7.9-RC1 glxinfo shows me direct rendering: Yes OpenGL renderer string: Mesa DRI Unknown Intel Chipset GEM 20100330 DEVELOPMENT x86/MMX/SSE2 /var/log/Xorg.0.log shows that DRI2 is initialized successfully. glxgears just shows a black window, and X is frozen (ssh does work, though). I'm seeing exactly ZERO messages in /var/log/messages or /var/log/Xorg.0.log, there's nothing logged there. X seems to hang in drm_intel_gem_bo_map_gtt(), and glxgears in a poll (probably waiting for the Xserver). Attaching backtraces for both the Xserver and glxgears.
Created attachment 39010 [details] Backtrace of glxgears Missing the symbols of glxgears itself, though.
cat /sys/kernel/dri/0/i915/i915_gem_interrupts would presumably show X waiting on the rendering to the buffer to be complete before it could transfer it to the GTT domain. intel_gpu_dump would be useful to confirm if the ring was still processing or was idle.
I assume you mean /sys/kernel/debug/dri/0/i915_gem_interrupt ;-) North Display Interrupt enable: 8c248080 North Display Interrupt identity: 00000000 North Display Interrupt mask: 73dbffff South Display Interrupt enable: 00000f00 South Display Interrupt identity: 00000000 South Display Interrupt mask: fffff0ff Graphics Interrupt enable: 00000010 Graphics Interrupt identity: 00000000 Graphics Interrupt mask: ffffffef Interrupts received: 914 Current sequence: 0 Waiter sequence: 0 IRQ sequence: 0 Sorry, but I don't speak i965 fluent enough to make anything out of this... Will attach the output of intel_gpu_dump.
Created attachment 39021 [details] gzipped output of intel_gpu_dump
Could you test with current mesa master? We've not been able to make sandybridge into 7.9 release.
Will do. But note that the driver drop we received from Intel *specifically* for Sandybridge support is based on the 7.9 branch...
yeah, we've been late for 7.9, and also for master, sorry for that. I'm not sure if Ian would pick up more sandybridge fixes for 7.9, but we'll have a release note for sandybridge support in Q3 release if it requires anything not in stable releases.
This should have been fixed in 7.9-rc2. Ian cherry-picked >20 zhenyu's snb patches from mesa master to 7.9 branch about 24 hours ago then made it as 7.9-rc2. So 7.9-rc2 has all sandybridge code on master except this one (which was committed to master after that time, and shouldn't matter much): Commit: 73dab75b4165f7d2214a68d4ba8e3cb7aab9b4ac URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=73dab75b4165f7d2214a68d4ba8e3cb7aab9b4ac Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Sun Sep 26 13:15:39 2010 +0800 i965: fallback lineloop on sandybridge for now Until we fixed GS hang issue. With mesa 7.9-rc2, glxgears runs fine on my side, and running all mesa demo shows only 2 fbo cases hang (bug#30445).
Yes, 7.9-RC2 works. It's still pretty slow (glxgears fullscreen 30fps), presumably because the back-to-front buffer copy is still not accelerated.
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.