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


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 Articles & Reviews
  1. Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V
  2. Samsung 850 EVO SSD Linux Benchmarks
  3. Kubuntu 15.04 Is Turning Out Quite Nice, Good Way To Try Out The Latest KDE
  4. 5-Way Linux Distribution Comparison On The Core i3 NUC
  5. OCZ ARC 100 Linux SSD Benchmarks
  6. Lenovo ThinkPad X1 Carbon Works Great As A Linux Ultrabook
Latest Linux News
  1. PC-BSD 10.1.2 To Add Tor Mode, LibreSSL & Other Features
  2. Valve Launches SteamOS Sale, Confirms A Lot Of New Linux Games
  3. Ubuntu Cloud Switches Over To Using Systemd By Default
  4. System76 Introduces The Broadwell-Powered, Ubuntu-Loaded "Meerkat"
  5. Xfce 4.12 Might Make It For Fedora 22
  6. Pictures Of The Near Production Ready Ubuntu Tablet
  7. OpenVG Support Stripped From Gallium3D
  8. Mozilla Is Getting Excited About WebGL 2
  9. ZOTAC Announces Steam Machine SN970, Powered By SteamOS
  10. Allwinner Continues Violating The LGPL
Most Viewed News This Week
  1. More Proof That Allwinner Is Violating The GPL
  2. The Tremendous Features Of Fedora 22
  3. Krita 2.9 Released, Their Biggest Release Ever
  4. Confirmed: Vulkan Is The Next-Gen Graphics API
  5. A Single UEFI Executable With The Linux Kernel, Initrd & Command Line
  6. Xfce 4.12 Released After Nearly Three Years Of Work
  7. 8cc: A Small C11 Compiler
  8. LLVM 3.6 & Clang 3.6 Deliver More Features, Complete C++14 Support