On Tue, Dec 4, 2012 at 11:09 PM, Lekensteyn <lekensteyn@xxxxxxxxx> wrote: > On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote: >> Ok, but in comment 11 in the same thread you mention that reverting >> this patch didn't fix the issue for you: >> >> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue." > The bisected commit was from between rc2 and rc3: > $ git describe 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 > v3.6-rc2-88-g504c726 This just means that after -rc2 there are 88 patches until 504c72. This doesn't mean at all that this patch is included in -rc3 - git history is non-linear! In fact this commit is only part of the 3.7-rc1 release, so if you just update Linus' tree it will have shown up somewhere between the 3.6 and 3.7-rc1 tag being pushed out. > The fact that reverting that commit does not help implies that some commits > thereafter also expose the bug. Well, enabling rc6 was merge before the offending commit but still works around at least a class of bugs. So it's very likely that we're just hunting down different strawmens ... >> > i915.i915_enable_rc6=0 worked for me, if it does not work for you, then >> > you probably hit another bug. >> >> I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE >> compositor. Now I'm trying to hit the bug again... > Do you have a reliable reproduce method? As you can see in the linked bug it > was caused by relatively low memory pressure combined with high I/O (caching? > delays? Who knows). Nope, we could only reproduce quickly with rc6 enabled :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
