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 _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
