1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Whoops, Intel SNB Is Borked At The Last Minute In Linux 2.6.39

Michael Larabel

Published on 18 May 2011
Written by Michael Larabel
Page 1 of 1 - 15 Comments

This morning after writing Intel Sandy Bridge On Ubuntu 11.04 Is Still Troubling, I proceeded to build the latest Mesa / Linux kernel / libdrm / DDX Git stack to see where the latest Intel SNB code is at and how it's running for the popular Core i5 2500K processor. Before leaving three weeks ago, everything was running great, but to much surprise, this morning it was a broken mess. Intel just regressed hard in their Sandy Bridge support for the about-to-be-released Linux 2.6.39 kernel. Whoops!

The problems experienced on the Git stack as of this morning were similar to what was encountered under a clean Ubuntu 11.04 installation with the Linux 2.6.38 kernel... When running any OpenGL test, the frame-rate was extremely choppy due to the GPU stalling. The dmesg filled up with i915_hangcheck_ring_idle errors from the Intel DRM driver. This at least signaled it being a kernel problem and also a definite regression since this i915_hangcheck_ring_idle problem was corrected earlier on in the Linux 2.6.39 cycle.

Checking the mailing lists revealed that this was also not isolated but a definite regression and one that occurred in the past two weeks while I was away. There was the PROBLEM: i915 regression between 2.6.39-rc6 and 2.6.39-rc7 message saying the i915_hangcheck_ring_idle regression took place between 2.6.39-rc6 and 2.6.39-rc7. Separately, another e-mail entitled Sandy Bridge GPU hang reproducer... indicated Sandy Bridge being hung with the latest Linux 2.6.39-rc7 kernel.

This hurts a lot seeing this regression introduced late in the Linux 2.6.39 kernel cycle. The Linux 2.6.39-rc7 release came a week ago and it has expected to be the last release candidate before going gold. In fact, the Linux 2.6.39 kernel is likely just hours away from release and this Sandy Bridge support is borked.

None of the mailing list messages received an official response from Intel yet nor was the regression tracked down. Fortunately, however, the Phoronix Test Suite stack in conjunction with OpenBenchmarking.org and Phoromatic can systematically bisect the entire Linux kernel (among other Git-controlled code-bases) to find this problem. I initiated the automatic bisection and soon enough this regression was tracked down to the particular commit. What is borking the Intel SNB code in the Linux kernel Git is this commit:

commit 087fbc9962e10a65fb0b542ecfc116ebf6cf1735
Author: Andy Lutomirski <luto@mit.edu>
Date: Fri May 13 12:14:54 2011 -0400

drm/i915: Revert i915.semaphore=1 default from i915 merge

My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs instantly when GNOME loads and it hangs so hard the reset button does not work. Setting i915.semaphore=0 fixes it.

Semaphores were disabled in a1656b9090f7 ("drm/i915: Disable GPU semaphores by default") in 2.6.38 but were then re-enabled (by mistake?) by the merge 47ae63e0c2e5 ("Merge branch 'drm-intel-fixes' into drm-intel-next").

(It's worth noting that the offending change is i915_drv.c, which was not marked as a conflict - although a 'git show --cc' on the merge does show that neither parent had it set to 1)

Signed-off-by: Andy Lutomirski <luto@mit.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

A semantic change on Friday the 13th caused the Sandy Bridge support to break. This commit disables Intel driver semaphores by default, which was the case in the Linux 2.6.38 kernel, but then later re-enabled. This was done because evidently a user (also of SNB graphics) experienced a hang on loading when semaphores were enabled. However, for other Sandy Bridge users, disabling semaphores will cause the graphics processor to still hang, but later on. Fortunately, the semaphores can be controlled by a kernel module parameter (i915.semaphores=[0,1]). When reverting this commit, sure enough, the i915_hangcheck_ring_idle regression went away. Alternatively, when simply pulling the latest kernel Git, setting i915.semaphores=1 corrects the situation on this test machine as well without needing to rebuild the kernel.

It may be too late though for this to be corrected in the Linux 2.6.39 kernel with its release likely just hours away (it's been more than a week since the last -rc and commit activity has settled down signaling a possible imminent release). This semaphores might not also be reverted yet again if the opposite behavior is affecting other Sandy Bridge hardware differently. Some other solution may be needed elsewhere to properly correct this problem for all Intel Sandy Bridge customers. Regardless, if you are an Intel user affected by these hangs, try setting i915.semaphores=1 as a temporary fix from the kernel command-line. Update: under some select workloads with semaphores enabled, I can still manage to lockup the GPU, but it's less frequent than with it disabled. It's too bad though this regression has been living in the Linux kernel so late in the cycle for five days now without being properly addressed, especially when it could have been spotted immediately with our automated per-commit driver testing had that tracker and hardware been setup. At least it's not as bad as the months-old and wide-scale Linux kernel power regression.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Intel Pentium G3258 On Linux
  2. SilverStone Precision PS10
  3. ASRock Z97 Extreme6
  4. Nouveau Re-Clocking Is Way Faster, Shows Much Progress For Open-Source NVIDIA
Latest Linux Articles
  1. KVM Benchmarks On Ubuntu 14.10
  2. X.Org Server 1.16 Officially Released With Terrific Features
  3. Ubuntu With Linux 3.16 Smashes OS X 10.9.4 On The MacBook Air
  4. Preview: Benchmarking CentOS 7.0 & Scientific Linux 7.0
Latest Linux News
  1. Unigine Develops City Traffic System, A Driving Simulator
  2. Intel 3.0 X.Org Driver Still Baking, New Development Release
  3. Eric Anholt Makes Progress With Broadcom VC4 Graphics Driver
  4. Intel Is Getting Very Close To OpenGL 4.0/4.1/4.2 Mesa Support
  5. Valve Is Still Hiring For SteamOS, Linux Work
  6. Users Warned About Possible Regressions With DRI3
  7. GNOME Shell Gets Wayland HiDPI Fonts, Mutter Gets Touch Gestures
  8. BPTC Texture Compression Comes To Nouveau After Intel's Work
  9. Development Continues For Supporting EXT4 On NVDIMMs
  10. Libinput 0.5 Improves Pointer Acceleration, Adds A Configuration API
Latest Forum Discussions
  1. Next-Gen OpenGL To Be Announced Next Month
  2. Open-Source Radeon Performance Boosted By Linux 3.16
  3. Remote gui not accessible in Phoronix Test Suite 5.2
  4. AMD "Hawaii" Open-Source GPU Acceleration Still Not Working Right
  5. Updated and Optimized Ubuntu Free Graphics Drivers
  6. In Road To Qt, Audacious Switches From GTK3 Back To GTK2
  7. Debian + Steam + r600
  8. Ubuntu With Linux 3.16 Smashes OS X 10.9.4 On The MacBook Air