# uname -a
Linux foo 4.4.0-rc7-default-pciehp #1 SMP Mon Dec 28 18:30:44 CET 2015 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux
#

This is Dell Vostro 3550 laptop with no additional graphics chip. BIOS A12.

Created attachment 121026 [details]
dmesg.txt

Note to self: the wait is referencing an active pipe, with a range within the plane. DERRMR seems set correctly.

Hmm, the vsync region is right up to the last scanline (give or take the granularity). Do you see the error if you move the window off the bottom of the screen?

Also the error state is reporting GPU page faults from the context and VT'd. A recent drm-intel-nightly kernel should fix the context fault, and can you try intel_iommu=off?

Do you see the same error on older kernels?

(In reply to Chris Wilson from comment #3)

> Hmm, the vsync region is right up to the last scanline (give or take the
> granularity). Do you see the error if you move the window off the bottom of
> the screen?

I do not understand. I have just one screen, via HDMI to an external display. The internal LVDS display of the laptop is disabled. I can only add that when I leave my computer and turn off the external LCD, then after returning back and turning on the external LCD power it has no signal and the laptop's LCD is enabled. I have to use arandr to swap the outputs. I don't remember having to use arandr for a while. Maybe some code is too eager to disable the HDMI output? I would dare to guess that this (need to use arandr to re-enable HDMI output) is a consequence of the GPU HANG, because I realized this only after the GPU HANG.

> 
> Also the error state is reporting GPU page faults from the context and VT'd.
> A recent drm-intel-nightly kernel should fix the context fault, and can you
> try intel_iommu=off?

I can after I reboot after some days.

> 
> Do you see the same error on older kernels?

You can search bugzilla for my previous reports with GPU HANGs, I have no idea which have the same traces. But with 4.3.0, 4.3.3, 3.18.xx I did not see it.

(In reply to Martin Mokrejs from comment #4)
> (In reply to Chris Wilson from comment #3)
> 
> > Hmm, the vsync region is right up to the last scanline (give or take the
> > granularity). Do you see the error if you move the window off the bottom of
> > the screen?
> 
> I do not understand. I have just one screen, via HDMI to an external
> display. The internal LVDS display of the laptop is disabled. I can only add
> that when I leave my computer and turn off the external LCD, then after
> returning back and turning on the external LCD power it has no signal and
> the laptop's LCD is enabled. I have to use arandr to swap the outputs. I
> don't remember having to use arandr for a while. Maybe some code is too
> eager to disable the HDMI output? I would dare to guess that this (need to
> use arandr to re-enable HDMI output) is a consequence of the GPU HANG,
> because I realized this only after the GPU HANG.

The need to use arandr/xrandr to re-enable external HDMI and to disable internal LVDS is not related to the GPU hang. After a few other bootups with the same kernel and runtime options I conclude this is some new issue with the kernel elsewhere. It happens whenever I power off my external LCD (not if it just falls asleep and get woken up).


> > Also the error state is reporting GPU page faults from the context and VT'd.
> > A recent drm-intel-nightly kernel should fix the context fault, and can you
> > try intel_iommu=off?
> 
> I can after I reboot after some days.

I booted up several times but so far I never hit the GPU HANG. Therefore, I don't think even trying intel_iommu=off would help us getting any conclusion. It just does not manifest often enough.

Created attachment 121172 [details]
/sys/class/drm/card0/error

Another case but with the settings so IOMMU still turned on.

[195975.826841] [drm] GPU HANG: ecode 6:-1:0x00000000, reason: Kicking stuck wait on render ring, action: continue
[195975.826906] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[195975.826907] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[195975.826908] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[195975.826909] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[195975.826910] [drm] GPU crash dump saved to /sys/class/drm/card0/error

With the same kernel and intel_iommu=off I did not hit this issue (yet).

(In reply to Martin Mokrejs from comment #7)
> With the same kernel and intel_iommu=off I did not hit this issue (yet).

We seem to have neglected the bug a bit, apologies.

Martin Mokrejs, since There were improvements pushed in kernel that will benefit to your system, so please re-test with latest kernel and mark as REOPENED if you can reproduce (and attach fresh gpu error dump & kernel log) and RESOLVED/* if you cannot reproduce.

(In reply to yann from comment #8)
> (In reply to Martin Mokrejs from comment #7)
> > With the same kernel and intel_iommu=off I did not hit this issue (yet).
> 
> We seem to have neglected the bug a bit, apologies.
> 
> Martin Mokrejs, since There were improvements pushed in kernel that will
> benefit to your system, so please re-test with latest kernel and mark as
> REOPENED if you can reproduce (and attach fresh gpu error dump & kernel log)
> and RESOLVED/* if you cannot reproduce.

Timeout - assuming resolved+fixed.

If problem still persist with the latest kernels (preferable drm-tip from git://anongit.freedesktop.org/git/drm-tip), reopen this bug with latest logs as attachments.

I was just trying to connect to bugzilla now. After I baked my CPU for a day or so (seemed to be associated with high CPU load) and I did not hit this issue anymore, I conclude 4.10.8 is fixed.

(In reply to Martin Mokrejs from comment #10)
> I was just trying to connect to bugzilla now. After I baked my CPU for a day
> or so (seemed to be associated with high CPU load) and I did not hit this
> issue anymore, I conclude 4.10.8 is fixed.

Thanks Martin for this confirmation