Created attachment 71081 [details] dmesg When I compile xf86-video-intel with sna and using gnome shell it sometimes freezes the whole Xserver. This happens approx once a day of normal usage and so far I haven't found a reliable way to reproduce (just move windows between workspaces a lot, maybe with opengl apps it may freeze faster but not sure). I can't do anything, even switching to console doesn't work, however I can still ssh in. All my attempts to obtain a backtrace through ssh were unsuccessful. When i try to attach to X with gdb, it just freezes, the same happens when I'm already attached to it at the moment of incident. There is some interesting info in the dmesg. Also attaching Xorg log. (Logs are few days old, however the incident just happened toady with bleeding edge stack). BTW I was using UXA with no problems for a week. SNA lasts at most for 2 days. GPU: GM45 Kernel: 3.6.8-2.fc17.x86_64 xf86-video-intel: 626dd1324dd2c5b14ca4aff598b5eb1e45550e69 mesa: cff4c94 libdrm: 171666e4b8127c17c68ea0d44cf4e81ec342f2d0 X.org: 1.12.4
Created attachment 71082 [details] Xorg.0.log
Try https://patchwork.kernel.org/patch/1832631/
*** Bug 57961 has been marked as a duplicate of this bug. ***
Should be fixed in drm-intel-fixes: commit e7d841ca03b7ab668620045cd7b428eda9f41601 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Dec 3 11:36:30 2012 +0000 drm/i915: Close race between processing unpin task and queueing the flip Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc. To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected. v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks.
Confirming fixed on gzdoom. Thank you!
Should this have been RESOLVED -> VERIFIED instead of RESOLVED -> REOPENED?
Presuming the workaround is indeed holding the OOPS at bay...
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.