intel GPU hangs

[Konstantin Belousov]

On Mon, Jun 11, 2012 at 09:12:41PM +0300, Andrey Kosachenko wrote:
> I'd like to revive this topic.
> (It was started pretty much ago 
> http://lists.freebsd.org/pipermail/freebsd-x11/2011-October/011210.html)
> 
> Briefly:
> I've experienced sporadic GPU hangs (using 10-Current and trying 
> different kms patches starting from the very beginning up to the latest 
> all.15.*.patch). It has happened on my "workhorse" ThinkPad T410 (intel 
> integrated graphics, chipset "Arrandale"). GPU hungs were not tied to 
> usage of heavy 3D apps or whatever. Indeed I've never managed to 
> identify what was wrong and I don't remember that smb. reported the 
> same. Moreover somewhere around all.12.x.patch issue occurrence 
> decreased almost to zero (once or twice per month) and so I abandoned to 
> report it (recompiled kernel w/o debug stuff and forgot about it).
> 
> Several weeks ago I had to use software for my private needs that is not 
> working under BSD (I'm talking about Google Sketchup actually, free 
> software (basic version) that allows to make 3D sketches easily). So I 
> employed a VM for this (VirtualBox). So far so good. But as the 
> complexity of models grew I started to catch more GPU hangups. It made 
> me crazy. At last point it was enough to load model + perform 2-3 
> rotates and GPU reliably hanged
> --- smth. like below was in dmesg output
> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
> ---
This part of the report is meaningless, since almost all GPU problems
are reported as hung GPU with hangcheck timer report. The real information
about problem should be obtained after the hang. The procedure is
described on Intel_GPU wiki page.

> 
> I googled for a while and found several pretty similar reports in linux 
> world. They experienced the same issue with SandyBridge hardware. I 
> tried various patches (at least those I could apply) and it appeared 
> that the following patch eliminates GPU hangs in my case:
> 
> 
> Index: sys/dev/drm2/i915/i915_irq.c
> ===================================================================
> --- sys/dev/drm2/i915/i915_irq.c        (revision 236796)
> +++ sys/dev/drm2/i915/i915_irq.c        (working copy)
> @@ -1524,7 +1524,19 @@
>             dev->dev_private);
> 
>         I915_WRITE(HWSTAM, 0xeffe);
> +       if (IS_GEN6(dev)) {
> +               /* Workaround stalls observed on Sandy Bridge GPUs by
> +               * making the blitter command streamer generate a
> +               * write to the Hardware Status Page for
> +               * MI_USER_INTERRUPT.  This appears to serialize the
> +               * previous seqno write out before the interrupt
> +               * happens.
> +               */
> +               I915_WRITE(GEN6_BLITTER_HWSTAM, 
> ~GEN6_BLITTER_USER_INTERRUPT);
> +               I915_WRITE(GEN6_BSD_HWSTAM, ~GEN6_BSD_USER_INTERRUPT);
> +       }
> 
> +
>         /* XXX hotplug from PCH */
> 
>         I915_WRITE(DEIMR, 0xffffffff);
I remember this workaround and its removal. I am not in the position to
actually have access to any erratas to the chip. I think the only route
forward there is to try to reproduce your hang on recent Linux kernel
with same version of usermode and then ask on intel-gfx at .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20120612/a2b3f1e1/attachment.pgp