Bug 768584 - intel[GM45] Gnome-shell crashes after resume or after screen unlock (GPU hangup)
intel[GM45] Gnome-shell crashes after resume or after screen unlock (GPU hangup)
: 770246 (view as bug list)
Classification: openSUSE
Product: openSUSE 12.2
Classification: openSUSE
Component: X.Org
Beta 2
x86-64 openSUSE 12.2
: P3 - Medium : Critical (vote)
: ---
Assigned To: E-mail List
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2012-06-25 02:04 UTC by Atri Bhattacharya
Modified: 2012-07-21 17:15 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
badshah400: SHIP_STOPPER?

cat .xession-errors (5.61 KB, text/plain)
2012-06-25 02:04 UTC, Atri Bhattacharya
cat .xession-errors.old (25.33 KB, text/plain)
2012-06-25 02:05 UTC, Atri Bhattacharya
cat /var/log/Xorg.0.log (29.34 KB, text/plain)
2012-06-28 06:29 UTC, Atri Bhattacharya
/var/log/messages (3.84 MB, text/plain)
2012-06-30 12:46 UTC, Atri Bhattacharya
cat .xsession-errors.old (34.38 KB, text/plain)
2012-07-01 07:16 UTC, Atri Bhattacharya
tail -n 500 /var/log/messages immediately after restarting after crash (61.53 KB, text/plain)
2012-07-06 06:16 UTC, Atri Bhattacharya
i915_error_state (1.40 MB, text/plain)
2012-07-06 07:31 UTC, Atri Bhattacharya

Note You need to log in before you can comment on or make changes to this bug.
Description Atri Bhattacharya 2012-06-25 02:04:16 UTC
Created attachment 496140 [details]
cat .xession-errors

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1

Not always, but fairly frequently to be a major enough problem, gnome-shell crashes after screen unlocking or resuming from suspended state (even when lock screen is disabled this happens). The entire shell disappears and if there were applications running, they would appear without the window-titlebars. The only way forward is to kill the xserver by hitting Ctrl+Alt+Backspace twice, killing every running application and leading to loss of unsaved data. I attach the .xsession-errors(.old) file after a recent such occurrence.

Reproducible: Sometimes

Steps to Reproduce:
Comment 1 Atri Bhattacharya 2012-06-25 02:05:06 UTC
Created attachment 496141 [details]
cat .xession-errors.old
Comment 2 Dominique Leuenberger 2012-06-25 20:40:52 UTC
Whay does

rpm -q --whatprovides "typelib(GnomeDesktop)"

(Just wondering about all the typelib errors seen in the log)
Comment 3 Atri Bhattacharya 2012-06-25 21:24:18 UTC
(In reply to comment #2)
> Whay does
> rpm -q --whatprovides "typelib(GnomeDesktop)"
> return?

No package provides typelib(GnomeDesktop).

The package that provides the typelib component is available but not installed, so I have now installed it. Will report back if I see the problem reproduced despite this package being installed.
Comment 4 Atri Bhattacharya 2012-06-25 21:44:12 UTC
No success :(
The problem just struck again, and typelib(GnomeDesktop) was in the system this time
Comment 5 Atri Bhattacharya 2012-06-28 06:29:30 UTC
Created attachment 496701 [details]
cat /var/log/Xorg.0.log

This happens fairly frequently nowadays. One line from the .xsession-errors file I find to be always present is this:
intel_do_flush_locked failed: Input/output error

May be this points to some driver issue?

I have attached my Xorg.0.log file now
Comment 6 Atri Bhattacharya 2012-06-30 10:44:47 UTC
I don't know if this is relevant, but I used to notice that immediately after unlocking the screen gnome-shell would disappear and come back on, as if it were restarting (like what it does when you type 'r' and hit enter on the Alt+F2 prompt) on openSUSE 12.1 as well (on both a radeon and an intel machine). I did not think much of it then, because gnome-shell invariable restarted and everything got back together. On 12.2, gnome-shell still disappears similarly after unlocking/suspension, but it never does restart.
Comment 7 Dominique Leuenberger 2012-06-30 11:43:23 UTC

Do you happen to see anything logged in /var/log/messages?

Maybe you can configure your system to keep crash dumps in a location on the disk. This could help identify 'what crashes' and it would even write a core dump

(See for example http://www.randombugs.com/linux/core-dumps-linux.html for info on how to specify where to save core dumps)
Comment 8 Atri Bhattacharya 2012-06-30 12:46:13 UTC
Created attachment 497018 [details]

Attached /var/log/messages hoping it provides some hint
Comment 9 Atri Bhattacharya 2012-06-30 12:55:33 UTC
I think the above comment provides the needed info, for now. I have also set up my system to save core dumps in a specific location, so we will see if that gives any new hints.
Comment 10 Atri Bhattacharya 2012-07-01 07:16:08 UTC
Created attachment 497023 [details]
cat .xsession-errors.old

This is the latest log from .xsession-errors.old immediately after restarting x after the crash of gnome-shell. The last few lines might be useful? Unfortunately despite setting up coredumps to be logged as suggested by Dominique, I see nothing in the specific directory for dumps. Perhaps I am doing something wrong?
Comment 11 Atri Bhattacharya 2012-07-02 11:18:58 UTC
When running gnome-shell under gdb, the last few lines when the crash is reproduced is (note the intel_do_flush_locked failed almost at the end):

[Thread 0x7fffbb971700 (LWP 3624) exited]
[Thread 0x7fffbb170700 (LWP 3625) exited]
[Thread 0x7fffcefff700 (LWP 3618) exited]
[New Thread 0x7fffcefff700 (LWP 3632)]
[New Thread 0x7fffbb170700 (LWP 3633)]
[New Thread 0x7fffbb971700 (LWP 3634)]
[New Thread 0x7fffab9e1700 (LWP 3635)]
[New Thread 0x7fffab1e0700 (LWP 3636)]
[New Thread 0x7fffaa9df700 (LWP 3637)]
[New Thread 0x7fffaa1de700 (LWP 3638)]
[New Thread 0x7fffa99dd700 (LWP 3639)]
[New Thread 0x7fffa91dc700 (LWP 3640)]
[Thread 0x7fffaa1de700 (LWP 3638) exited]
[Thread 0x7fffaa9df700 (LWP 3637) exited]
[Thread 0x7fffbb971700 (LWP 3634) exited]
[Thread 0x7fffab1e0700 (LWP 3636) exited]
[Thread 0x7fffa91dc700 (LWP 3640) exited]
[Thread 0x7fffa99dd700 (LWP 3639) exited]
[Thread 0x7fffcefff700 (LWP 3632) exited]
[Thread 0x7fffab9e1700 (LWP 3635) exited]
[Thread 0x7fffba96f700 (LWP 3626) exited]
[Thread 0x7fffbb170700 (LWP 3633) exited]
[New Thread 0x7fffbb170700 (LWP 3641)]
[New Thread 0x7fffba96f700 (LWP 3642)]
[New Thread 0x7fffab9e1700 (LWP 3643)]
[New Thread 0x7fffcefff700 (LWP 3644)]
[Thread 0x7fffbb170700 (LWP 3641) exited]
[Thread 0x7fffba96f700 (LWP 3642) exited]
[Thread 0x7fffcefff700 (LWP 3644) exited]
[Thread 0x7fffab9e1700 (LWP 3643) exited]
intel_do_flush_locked failed: Input/output error
[Thread 0x7fffe297e700 (LWP 3614) exited]
[Thread 0x7fffe318f700 (LWP 3613) exited]
[Thread 0x7fffe3b97700 (LWP 3612) exited]
[Thread 0x7fffe45ca700 (LWP 3611) exited]
[Inferior 1 (process 3608) exited with code 01]

Stefan, would be great if you could take a look at this, it seems like an intel driver issue (logs are all attached). Thanks a lot!
Comment 12 Atri Bhattacharya 2012-07-06 06:16:53 UTC
Created attachment 497585 [details]
tail -n 500 /var/log/messages immediately after restarting after crash

Immediately after the crash, I hit Ctrl+Alt+Backspace to kill X and go back to the Gdm screen, and then login. After log in, I notice that gnome-shell starts using Gallium on llvmpipe, where it had been using "Mobile Intel GM45 Graphics Chipset" prior to crash. If I restart the computer, it starts to use the Intel GM45 graphics again.

I have attached the last 500 lines of log from /var/log/messages immediately after the crash. What  happens at "Jul  6 11:21:08" as documented in the log might be interesting. It starts to report problems like:

Jul  6 11:21:08 linux-qd8c kernel: [ 1678.008027] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Jul  6 11:21:08 linux-qd8c kernel: [ 1678.008032] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
Jul  6 11:21:08 linux-qd8c kernel: [ 1678.510033] [drm:i915_reset] *ERROR* Failed to reset chip.
Jul  6 11:21:25 linux-qd8c polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session4 (system bus name :1.145, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jul  6 11:21:50 linux-qd8c bluetoothd[788]: Endpoint unregistered: sender=:1.130 path=/MediaEndpoint/HFPAG
Jul  6 11:21:50 linux-qd8c bluetoothd[788]: Endpoint unregistered: sender=:1.130 path=/MediaEndpoint/A2DPSource
Jul  6 11:21:50 linux-qd8c gnome-session[2223]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198814] ------------[ cut here ]------------
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198850] WARNING: at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.4.2/linux-3.4/drivers/gpu/drm/i915/i915_gem.c:2421 i915_gem_object_put_fence+0xac/0xd0 [i915]()
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198853] Hardware name: HCL Notebook
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198855] Modules linked in: af_packet rfcomm bnep xt_LOG xt_limit xt_tcpudp xt_pkttype nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT ipt_REJECT ip6table_raw xt_NOTRACK vmsync(O) iptable_raw vmblock(O) iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables fuse snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep btusb snd_pcm_oss arc4 iwlwifi snd_pcm snd_seq mac80211 snd_timer snd_seq_device snd_mixer_oss snd cfg80211 uvcvideo bluetooth i2c_i801 sr_mod soundcore rfkill videobuf2_core videodev snd_page_alloc acpi_cpufreq iTCO_wdt videobuf2_vmalloc cdrom pcspkr iTCO_vendor_support ums_realtek r8169 videobuf2_memops mperf usb_storage uas joydev coretemp battery wmi ac microcode autofs4 i915 thermal drm_kms_helper drm processor i2c_algo_bit button video thermal_sys scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198908] Pid: 2109, comm: Xorg Tainted: G           O 3.4.2-2.1-desktop #1
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198910] Call Trace:
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198923]  [<ffffffff81004648>] dump_trace+0x88/0x300
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198930]  [<ffffffff8157f747>] dump_stack+0x69/0x6f
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198935]  [<ffffffff8103fdb9>] warn_slowpath_common+0x79/0xc0
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198947]  [<ffffffffa00f741c>] i915_gem_object_put_fence+0xac/0xd0 [i915]
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198974]  [<ffffffffa00f8ce4>] i915_gem_object_unbind+0x84/0x260 [i915]
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.198997]  [<ffffffffa00f8ed7>] i915_gem_free_object_tail+0x17/0x130 [i915]
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199046]  [<ffffffffa005e080>] drm_gem_object_release_handle+0xb0/0xd0 [drm]
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199057]  [<ffffffff812cb756>] idr_for_each+0x86/0xe0
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199067]  [<ffffffffa005e487>] drm_gem_release+0x17/0x30 [drm]
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199081]  [<ffffffffa005ccd3>] drm_release+0x663/0x730 [drm]
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199089]  [<ffffffff8115eba0>] fput+0x100/0x260
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199095]  [<ffffffff8115ad9f>] filp_close+0x5f/0x90
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199100]  [<ffffffff81043adb>] put_files_struct+0xbb/0x130
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199104]  [<ffffffff81044101>] do_exit+0x191/0x950
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199109]  [<ffffffff81044bf8>] do_group_exit+0x38/0xa0
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199112]  [<ffffffff81044c72>] sys_exit_group+0x12/0x20
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199117]  [<ffffffff8159247d>] system_call_fastpath+0x1a/0x1f
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199123]  [<00007f389cd30039>] 0x7f389cd30038
Jul  6 11:21:50 linux-qd8c kernel: [ 1720.199257] ---[ end trace 280f0fc7f307fe13 ]---
Jul  6 11:21:50 linux-qd8c gdm-simple-slave[2107]: WARNING: Child process 2109 was already dead.
Jul  6 11:21:50 linux-qd8c gdm-simple-slave[2107]: WARNING: Child process 2109 was already dead.
Jul  6 11:21:50 linux-qd8c acpid: 1 client rule loaded
Jul  6 11:21:51 linux-qd8c systemd-logind[550]: New session 7 of user gdm.
Comment 13 Stefan Dirsch 2012-07-06 06:23:55 UTC
> Jul  6 11:21:08 linux-qd8c kernel: [ 1678.510033] [drm:i915_reset] *ERROR*
> Failed to reset chip.

And that's the issue here. Unfortunately GPU resetting didn't work reliably before Sandybridge. :-( GM45 is much older ...
Comment 14 Dominique Leuenberger 2012-07-06 06:25:51 UTC
Moving to X.Org : keeping the session alive while the underlying graphic driver 'disappears' is tough.
Comment 15 Atri Bhattacharya 2012-07-06 06:36:41 UTC
There are probably useful comments here
and here (this one says updating to kernel 3.5.0 solves the user's problem)
Comment 16 Stefan Dirsch 2012-07-06 06:47:46 UTC
What you've found are workarounds for Sandybridge. And a GPU hangup is only a sympton and can have a lot of different reasons. :-(
Comment 17 Atri Bhattacharya 2012-07-06 07:08:34 UTC
there's a fairly recent i915 (GM45) commit that might be relevant:-

Comment 18 Atri Bhattacharya 2012-07-06 07:31:55 UTC
Created attachment 497598 [details]
Comment 19 Stefan Dirsch 2012-07-06 07:55:49 UTC
Ok. Looks kind of promising. Easiest would be to update the kernel to 3.5-rc4, which already contains this patch.


Please let me know, whether this fixes this issue.
Comment 20 Atri Bhattacharya 2012-07-06 08:35:27 UTC
Updating to Kernel 3.5-rc4 does not fix the issue unfortunately, so I guess we can safely rule that patch out :(

I could reproduce the same problem as I did earlier. It seems letting the screen lock itself after 5 mins of idle time is enough to cause this crash.
Comment 21 Stefan Dirsch 2012-07-06 08:56:58 UTC
Ok. Thanks for testing nevertheless.
Comment 22 Atri Bhattacharya 2012-07-06 13:38:06 UTC
I am back to the 12.2 Kernel. I also tried the X packages from X11:Xorg, but that didn't help either. It seems now that instead of trying too hard to reproduce it, just letting the screen lock after 5 mins of idle time is enough to reliable trigger the crash, or suspending it a couple of times hit is as well. I can't use 12.2 unless this is fixed unfortunately :(

Requesting a stopper status for this bug
Comment 23 Atri Bhattacharya 2012-07-07 01:22:06 UTC
Just tried an older version: openSUSE 12.2 Beta 1 (Build 398, from around May 30). This problem does not happen there at all (for the duration of my testing for about ~24 hours), neither during resume, nor during screen unlocking.

From this Beta 1 system:
uname -r

If indeed this is a kernel issue, it must have been introduced somewhere between 3.4.0 and 3.4.2 (kernel in Beta 2).
Comment 24 Stefan Dirsch 2012-07-07 01:41:37 UTC
First obvious thing to verify that it is a kernel issue. Replace the kernel on Beta1 with the one of Beta2.

Also possible would be that the issue just isn't triggered on Beta1 - for whatever reasons.
Comment 25 Atri Bhattacharya 2012-07-07 08:08:15 UTC
So far on my tests:
Beta 1 + kernel-desktop 3.4.2 = No issues
Beta 1 + kernel-desktop 3.4.4 = No issues

Beta 1 + kernel-desktop 3.4.2 + upgrade of X stack from oss (Beta 2) = CRASH!!!

These are the additional packages installed/upgraded, that reproduce the crash on Beta 1:-

diff -u openSUSE_12.2_Beta-1_installed_packages.txt openSUSE_12.2_upgraded_X_installed_packages.txt 
--- openSUSE_12.2_Beta-1_installed_packages.txt	2012-07-07 07:14:08.923490932 +0530
+++ openSUSE_12.2_upgraded_X_installed_packages.txt	2012-07-07 13:28:10.228572036 +0530
@@ -1530,3 +1530,42 @@
 	upgrade kernel-desktop 3.4.4
 	upgrade kernel-firmware 20120521git
 	install plymouth-plugin-label 0.8.4
+	downgrade kernel-desktop 3.4.2
+	downgrade kernel-firmware 20120521git
+	upgrade xorg-x11 7.6_1
+	upgrade Mesa 8.0.3
+	install libgbm1 0.0.0
+	install libxcb-util1 0.3.9
+	install libxcb-xfixes0 1.8.1
+	install vaapi-dummy-driver 1.1.0
+	install yast2-x11 2.22.1
+	upgrade xorg-x11-Xvnc 7.6_1.12.2
+	upgrade xorg-x11-server-extra 7.6_1.12.2
+	upgrade xorg-x11-server 7.6_1.12.2
+	install Mesa-libEGL1 8.0.3
+	upgrade xorg-x11-driver-video-nouveau 0.0.16_20120321_ab7291d
+	upgrade xf86-video-trident 1.3.5
+	upgrade xf86-video-sis 0.10.4
+	upgrade xf86-video-savage 2.3.4
+	upgrade xf86-video-neomagic 1.2.6
+	upgrade xf86-video-mga 1.5.0
+	upgrade xf86-video-cirrus 1.4.0
+	upgrade xf86-video-ati 6.14.4
+	upgrade xf86-video-ark 0.7.4
+	upgrade xf86-input-vmmouse 12.9.0
+	upgrade xf86-input-synaptics 1.6.2
+	install xf86-video-geode 2.11.13
+	install libva1 1.1.0
+	install glamor 0.4.1
+	upgrade xorg-x11-driver-input 7.6_1
+	install vaapi-intel-driver 1.0.18
+	upgrade xf86-video-intel 2.19.0_20120601_8eed569
+	upgrade xorg-x11-driver-video 7.6_1
+	upgrade libX11-data 1.5.0
+	upgrade libX11-xcb1 1.5.0
+	upgrade libX11-6 1.5.0
+	upgrade libXft2 2.3.1
+	upgrade Mesa-libglapi0 8.0.3
+	upgrade Mesa-libGL1 8.0.3
+	upgrade Mesa-libGLU1 8.0.3

So, it might be the X-stack that is causing the problem and not the kernel after all, specifically, changes between the X stack in Beta 1 and Beta 2?
Also checked that Kernel 3.4.4 + upgraded X stack also has the crashing issue.
Comment 26 Dominique Leuenberger 2012-07-07 08:21:53 UTC
(In reply to comment #25)

> +    install libva1 1.1.0
> +    install vaapi-intel-driver 1.0.18

That strikes like entering a completely different execution path (offloading to the gpu). I could imaging this triggering such things, if Beta1 worked fine.

Can you remove vaapi-intel-driver ? (there are no 'requires' on it.. the vaapi is setup to 'load when available' IIRC.. )
Comment 27 Atri Bhattacharya 2012-07-07 10:57:10 UTC
Thanks Dominique,
Removing the vaapi-intel-driver seems to have done the trick. No more crashes on my system of Beta 1 + Updated X-stack. Am going back to try the same trick on a Beta 2 system now.
Comment 28 Atri Bhattacharya 2012-07-07 13:54:59 UTC
I guess there is such a thing called "spoke too soon" :(

The problem happens on my Beta 2 system even after uninstalling the vaapi intel (and dummy) driver and libva1. Any ideas for further checks? Should I just keep the intel-vide driver from Beta 1 and upgrade the remaining X stack to Beta 2 versions?
Comment 29 Atri Bhattacharya 2012-07-07 17:01:30 UTC
Finally here is a configuration that seems to work:-

zypper se -s xf86-video-intel
Loading repository data...
Reading installed packages...

S | Name                   | Type    | Version                     | Arch   | Repository       
v | xf86-video-intel       | package | 2.19.0_20120601_8eed569-2.1 | x86_64 | openSUSE-12.2-Oss
i | xf86-video-intel       | package | 2.18.0-1.1                  | x86_64 | (System Packages)
  | xf86-video-intel-32bit | package | 2.19.0_20120601_8eed569-2.1 | x86_64 | openSUSE-12.2-Oss

So I have locked xf86-video-intel to the version from Beta 1 (which is 2.18.0-1.1; the version available from Beta 2 is 2.19.0_20120601_8eed569-2.1) while upgrading everything else (including the kernel, X stack and GNOME) to Beta 2 status, and tried everything that would reproduce the crash on a vanilla Beta 2 system; yet no crashes so far. I think I will take a day or two to test this further, but I am hopeful this is it.
Comment 30 Atri Bhattacharya 2012-07-08 17:38:39 UTC
I can confirm now, that having the intel video driver locked to version 2.18.0 indeed solves the problem (with any kernel, tried 3.4.2, 3.4.4 and no problems at all). Version 2.19.0 appears to be the culprit as far as I see.
Comment 31 Stefan Dirsch 2012-07-09 15:38:18 UTC
(In reply to comment #30)
> I can confirm now, that having the intel video driver locked to version 2.18.0
> indeed solves the problem (with any kernel, tried 3.4.2, 3.4.4 and no problems
> at all). Version 2.19.0 appears to be the culprit as far as I see.

Sounds good. So we could "git bisect" the driver regression now.
Comment 32 Atri Bhattacharya 2012-07-09 18:13:52 UTC
Hi Stefan,
I didn't properly understand your above comment, I think. Please let me know if you want me to do the bisecting. I am willing to try, but have never done this before, so the results might be ... :)
Comment 33 Stefan Dirsch 2012-07-10 06:46:30 UTC
Yes, you would need to do the git bisecting, since you have the hardware and can reproduce the issue.

You would need to checkout the xf86-video-intel git tree and do the git bisect, i.e. build and install the driver until you find the culprit git commit. See 
"git bisect --help".
Comment 34 Atri Bhattacharya 2012-07-10 10:55:33 UTC
I have been trying to do the bisect routine now, but I see that I don't hit the problem at all with the bisection almost entirely done. After building and installing the driver, do I have to do something special? Like mkinitrd or something?
Comment 35 Stefan Dirsch 2012-07-10 12:38:10 UTC
I should have mentioned before. After installing the driver (replacing the previously used one in /usr/lib64/xorg/modules/drivers) the Xserver needs to be restarted.
Comment 36 Atri Bhattacharya 2012-07-10 19:31:10 UTC
Hi Stefan!
Commit 3f3bde4f0c72f6f31aae322bcdc20b95eade6631 looks like the problem from my bisection results.


Does this look like it could be the source of the problem?

Off-topic: thanks a ton for the help and guidance. It was fun learning to git bisect for the frist time!
Comment 37 Atri Bhattacharya 2012-07-10 20:51:22 UTC
Hi Stefan!
I can confirm that this is the commit that causes the problem. Just tested that the immediately previous commit worked fine for me. And it also looks now, that this upstream commit (which was made on Jun 5, i.e. after the tarball for openSUSE 12.2 was frozen on Jun 1) fixes the issue for me:


Accordingly I have built [1] an xf86-video-intel package with this upstream patch applied and could submit it to X11:XOrg if you think this is accetable. I am of course continuing with testing if this patch really does it over the next couple of hours or so.

Hope that helps.

[1] https://build.opensuse.org/package/show?package=xf86-video-intel&project=home%3Abadshah400%3Abranches%3AX11%3AXOrg
Comment 38 Atri Bhattacharya 2012-07-11 09:31:07 UTC
Hi Stefan!
I have verified that this patch against the xf86-video-intel package in openSUSE:12.2 works (problem gone now), and accordingly I have submitted it to X11:XOrg; please review https://build.opensuse.org/request/show/127596

Comment 39 Stefan Dirsch 2012-07-11 10:33:16 UTC
Accepted and forwarded to openSUSE:Factory. Thanks a lot!
Comment 40 Egbert Eich 2012-07-11 10:33:22 UTC
*** Bug 770246 has been marked as a duplicate of this bug. ***
Comment 41 Bernhard Wiedemann 2012-07-11 11:00:10 UTC
This is an autogenerated message for OBS integration:
This bug (768584) was mentioned in
https://build.opensuse.org/request/show/127632 Factory / xf86-video-intel
Comment 42 Bruno Friedmann 2012-07-21 16:10:13 UTC
@Stefan shouldn't that one be pushed to 12.2 also. It would save the life of several users ...
Comment 43 Atri Bhattacharya 2012-07-21 17:15:34 UTC
(In reply to comment #42)
> @Stefan shouldn't that one be pushed to 12.2 also. It would save the life of
> several users ...

Hi! As far as I understand, xf86-video-intel 2.20.0 was pushed out as a maintenance update for 12.2 and this already contains the fix for this issue.

zypper se -si xf86-video-intel
S | Name                   | Type       | Version                       | Arch   | Repository          
i | xf86-video-intel       | package    | 2.20.0-3.9.1                  | x86_64 | openSUSE-12.2-Update