System Environment: -------------------------- Arch: i386 Platform: Sandybridge Libdrm: (master)2.4.31-4-g9b3ad51ae5fd9654df8ef75de845a519015150bb Mesa: (master)78734e375a0e3ea87abd6d5b2f85946e78e96015 Xserver: (master)xorg-server-1.11.99.903-1-gd53235af85d50774c68347720ce132daf9a5bc49 Libva_intel_driver: (vaapi-ext)d0cf73ad1dc66a8fa5911acb837c08604cc51940 Kernel: (drm-intel-next-queued)7c26e5c6edaec70f12984f7a3020864cc21e6fec Bug detailed description: ----------------------------- It occurs on Sandybridge with kernel drm-intel-next-queued branch while running some piglit glean cases(glean_clipFlat,glean_pointAtten, glean_polygonOffset). It does not happen on Ivybridge. It does not occur with kernel 3.2.4 on Sandybridge. Reproduce steps: ---------------------------- 1. start X 2. start gnome-session 3. run : ./glean -r /tmp/results/glean/pointAtten -o -v -v -v -t +pointAtten
So I guess this is just the missing merge from -fixes?
The -queued sha1 you've tested on does not yet contain the voodoo stuff for snb. Please retest with an updated -queued and ensure that you have commit 99ffa1629d737295e569267cf5940758139f9ddb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 25 14:04:00 2012 +0100 drm/i915: enable forcewake voodoo also for gen6 in your kernel.
Tested with the latest -queued branch kernel(de67cba65944f26c0f147035bd62e), Missing IRQ still hanppens.
Created attachment 57200 [details] [review] reinstate the hwstam magic Please try the attached patch. Also, this 'missed IRQ' issue showed up before I've applied the voodoo patch for snb (which reverted the hwstam w/a), so something else changed. Can you please bisect where this issue got introduced so that we have a chance to find out what went wrong? Please do the bisect even when the attached patch works, it's _very_ important for us to get a handle on these 'missed IRQ' issues.
Put the patch with the attachment 57200 [details] [review]. This issue does not happen. Bisect is in progress. Select good commint d8e70a254d8f2da141006e496a51502b79115e80, and bad commint 7c26e5c6edaec70f12984f7a3020864cc21e6fec.
Another patch to try: https://bugs.freedesktop.org/attachment.cgi?id=57315 Please also check whether this patch works to get rid of this missed IRQ issue.
This issue does not happen with that you provided new patch.
Bisect shows 8a8ed1f5143b3df312e436ab15290e4a7ca6a559 is the first bad commit. commit 8a8ed1f5143b3df312e436ab15290e4a7ca6a559 Author: Yufeng Shen <miletus@chromium.org> AuthorDate: Mon Feb 13 17:36:54 2012 -0500 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Tue Feb 14 10:39:53 2012 +0100 drm/i915: Fix race condition in accessing GMBUS GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). v2: Moved gmbus_mutex below intel_gmbus and added comments. Rebased to drm-intel-next-queued. Signed-off-by: Yufeng Shen <miletus@chromium.org> [danvet: Shortened the gmbus_mutex comment a bit and add the patch revision comment to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This bisect result is pretty astonishing ... Can you confirm this by reverting the offending commit on top of latest -testing?
This issue does not hanppen on the latest -testing branch, also not happen while revert commit 8a8ed1f5143b3df312e436ab15290e4a7ca6a559. Retest this issue on the branch(commit 8a8ed1f5143b3df312e436ab15290e4a7ca6a559), can not duplicate it. So the bisect result needs reconfirmation.
Hm, this sounds like a Heisenbug that shows up and disappears again. Closing as 'worksforme' for now, please reopen if this shows up again somewhere.
Enable compiz, This issue happens again.
System Environment: -------------------------- Platform: Sandybridge Kernel: (drm-intel-next-queued)fa37d39e4c6622d80bd8061d600701bcea1d6870 Bug detailed description: ----------------------------- running gem_dummy_reloc_loop of the Intel-gpu-tools,the dmesg shows like this: [ 111.853298] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 7769971, at 7769971], missed IRQ? [ 113.692050] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 7823757, at 7823757], missed IRQ? [ 118.119401] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 8285985, at 8285985], missed IRQ?
I hate this bug :( Can you please check whether the patch at: https://bugs.freedesktop.org/attachment.cgi?id=57315 still works around this issues?
I ran into this bug with my HW context work, and the patch from https://bugs.freedesktop.org/attachment.cgi?id=57315 seems to make the problem go away.
Running on the lastest queued branch(121d527a32) and patch https://bugs.freedesktop.org/attachment.cgi?id=57315. Disable compiz,Issue doesn't happen. Enable compiz, Issue still exists. dmesg shows: [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 28554476, at 28554476], missed IRQ? [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 31826421, at 31826421], missed IRQ? [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 32373088, at 32373088], missed IRQ? [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 35318264, at 35318264], missed IRQ? [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 35418763, at 35418763], missed IRQ?
Created attachment 58909 [details] [review] enable CS reg readback w/a for snb Please apply this patch and check whether the issue goes away (in both configurations, i.e. compiz enabled and disabled).
Running on the lastest queued branch(1d83f44) and patch (attachment 58909 [details] [review]) Disable compiz,Issue doesn't happen. Enable compiz, Issue still exists. dmesg shows: [ 263.391270] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 762923, at 762923], missed IRQ? [ 390.382665] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 5576121, at 5576121], missed IRQ?
Hm, I have a gut feeling that this is just an issue with the blt ring. Ben, do you still have patches around to use pipe notify irq and MI_FLUSH_DW writes for the seqno+irq generation on blt?
Yes. My branch here has both workarounds. It's missing the readback though, and the last revert commit should be removed. http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=irq_fix
A patch referencing this bug report has been merged in Linux v3.4-rc2: commit 1c7eaac737e4cca24703531ebcb566afc3ed285f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 27 09:31:24 2012 +0200 drm/i915: apply CS reg readback trick against missed IRQ on snb
Verified. It doesn't happen on drm-intel-next-queued with commit b98e5240b362e702355ffedba05aeb589dfbcbe2.
Reopen, following piglit cases have this issue on -queued kernel with commit 74d2c584c37c4fd7ab0f40d2fb546559992c4f9b. glx_GLX_ARB_create_context_default_minor_version shaders_glsl-vs-user-varying-ff spec_OpenGL_1.1_texwrap-2D-GL_LUMINANCE4 spec_glsl-1.10_compiler_special-characters_digraph-open-bracket.frag spec_glsl-1.10_execution_built-in-functions_fs-op-mult-ivec2-ivec2 spec_glsl-1.20_compiler_built-in-functions_op-mult-ivec3-int.vert
Can you retest please retest with latest -queued, specifically this patch: commit 63c02a10149080afc8fd616b5e1aa6a1e72352fb Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 24 21:48:47 2012 +0100 drm/i915: Use a global lock for modifying global irq flags
It doesn't happen on -queued kernel commit b57aa4007a558be50955f9b58f5da98fcb78aa85.
Verified.It fixed on -queued kernel commit b57aa4007a558.
Closing old verified.
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.