Random ocassional graphics freeze on Intel chipset

[Chris Wilson]

On Wed, Oct 02, 2013 at 09:22:18AM -0500, Alex Villací­s Lasso wrote:
> El 02/10/13 05:19, Chris Wilson escribió:
> >On Tue, Oct 01, 2013 at 06:15:00PM -0500, Alex Villací­s Lasso wrote:
> >>I have seen this graphics freeze under stock 3.10.x from the Fedora
> >>18 x86_64 distro, and also with vanilla compiled 3.11 and 3.12-rc3.
> >>After a few hours of working, the screen stops updating. The mouse
> >>pointer moves around and changes if moved over different parts of
> >>the screen, but the display itself does not change anymore. If I
> >>check /sys/kernel/debug/dri/0/i915_error_state right then (via a
> >>remote ssh), there is no error captured. However, if I do "echo 1 >
> >>/sys/kernel/debug/dri/0/i915_wedged", after a few moments an error
> >>is captured, as well as messages in the kernel log, both of which
> >>are attached. If I try to restart the gnome-shell session, I get the
> >>KMS console, and then the start of the graphic login, but then the
> >>graphic login itself freezes again.
> >>
> >>Is the attached information enough to diagnose the issue?
> >Afaict it was a userspace hang, the GPU was rightfully idle. Only on the
> >reset did it actually die.
> If I do "echo 1 > /sys/kernel/debug/dri/0/i915_wedged" when the display is not frozen, I only get the following in dmesg, and the system keeps working normally:
> [  323.441616] [drm] Manually setting wedged to 1
> [  323.441622] [drm] capturing error event; look for more information in /sys/class/drm/card0/error
> [  348.955655] [drm] Manually setting wedged to 0
> 
> Is it to be expected that an "userspace hang" will escalate into a failed reset when setting i915_wedged to 1, without anything being actually wrong at the kernel side, at least at first?

Yes, your chipset is notorious for not being able to restart the rings.
We've added a few attempts to workaround the issue, but I'm not
surprised if it still occasionally fails.

> >I'd suggest looking at the stacktraces of the usual suspects and see who
> >is waiting upon whom, or if there is a more obvious lockup. Then begin
> >the painful process of tracing the interoperation of those two processes
> >to try and catch the breakdown.
> >-Chris
> >
> I think Xorg is one of the "usual suspects". Should gnome-shell be one too? This is a Fedora 18 desktop with gnome-shell as installed from the DVD.

X and gnome-shell are the two responsible for working together and
presenting your desktop, so would definitely be the first to check for
an error.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre