[Intel-gfx] i915 error hangcheck timer elapsed

[Daniel Vetter]

Hi,

Can you please file a bug report for this at bugs.freedesktop.org
against DRI -> DRM (Intel). Then please rehang your machine on a fresh
boot and attach the i915_error_state from debugfs, it should contain a
nice gpu dump with useful information. Also, please provide the
version of your userspace driver stack (mesa, xf86-video-intel,
libdrm) and whether you're using the SNA accel backend.

Thanks, Daniel

On Sun, Dec 2, 2012 at 4:34 PM, Stefan Roas <sroas at roath.org> wrote:
> Hi there,
>
> I've been experiencing X.org hangups for a few month (cannot remember when exactly it started) that are related to the i915 driver.
>
> demsg output when the hangup occurs is always the following:
>
> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
> [drm:i915_reset] *ERROR* Failed to reset chip.
>
> System Information:
>
> Dell Latitude E5500
> Debian stable with vanilla 3.6.8 kernel
>
> lspci -vv output for the graphic card is:
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
>         Subsystem: Dell Device 0263
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Interrupt: pin A routed to IRQ 45
>         Region 0: Memory at f6c00000 (64-bit, non-prefetchable) [size=4M]
>         Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
>         Region 4: I/O ports at efe8 [size=8]
>         Expansion ROM at <unassigned> [disabled]
>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>                 Address: fee0300c  Data: 4122
>         Capabilities: [d0] Power Management version 3
>                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Kernel driver in use: i915
>
> During the time I lived with the hangup happening, I realized a rather reliable way of
> reproducing the problem. Which would be to boot up and log into a graphical
> session, then wait for a few minutes (could run pretty much every program
> except firefox or a movie player), finally firing up either firefox or mplayer
> and I got the hang.
>
> As I had some spare time on my hands this weekend and a pretty reliable
> way of reproducing the problem i gave git bisect a try nailing down the
> commit that broke i915 for me.
>
> It came up with
>
> commit dabdfe021ab1e985e6566009c774fb03f14b568e
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Mon Mar 26 10:10:27 2012 +0200
>
>     drm/i915: Avoid using mappable space for relocation processing through the CPU
>
>     We try to avoid writing the relocations through the uncached GTT, if the
>     buffer is currently in the CPU write domain and so will be flushed out to
>     main memory afterwards anyway. Also on SandyBridge we can safely write
>     to the pages in cacheable memory, so long as the buffer is LLC mapped.
>     In either of these cases, we therefore do not need to force the
>     reallocation of the buffer into the mappable region of the GTT, reducing
>     the aperture pressure.
>
>     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>     Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> as the culprit.
>
> I've undone that commit on 3.6.8 and couldn't reproduce the problem since then.
>
> Unfortunately I know close to nothing about graphic cards or drm, so I'm
> not sure that just undoing those changes is the right thing to do, but I
> hope it helps you to come up with the right(tm) solution.
>
> If you need any additional information or me testing some more suitable
> fix, let me now.
>
> Best regards,
>   Stefan
>
> --
> Stefan Roas                                         sroas at roath.org
> Joh.-Seb.-Bach-Str. 4                            D-91083 Baiersdorf
> -------------------------------------------------------------------
> Key fingerprint = 557C 99BE 865B 1463 2A44  7936 C662 8970 4DA5 50B8
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJQu3TsAAoJEMZiiXBNpVC4b/QP/1A9JxFqD5L6Gp665p98B65B
> SjYC/CD0jUQGcNyJdsF+r/LZCQiETzLVyPkGs3wEK7cccmrQxHHgmIijd+gZnp4I
> 051RKwl+idXjpasQkqL0Oi2hQsfNa7wV7woMV3n0/WlXF84uRzgQbyuvyXR1iu2A
> 8qYdJ2wKCd2PRUoSSq+cpf938AnCsHnqrDU66Af6Z7ZHf5if0eaqQZZVIbn5eA95
> uAjvzjh58peFcqtJUIm7kd7sxyt5DtkYg3TBBn8bx9wVuJ+QoOc5P9d+kGmgHCoQ
> 9ivuYm9CewPvauJ2/hRubXPhLXL2THMqJju2EjVO8Hy0oD8nzUQ2BNAyBjGTO+tV
> w85AF8qCO35sC4S2Hwi9QMlVG+ObfSqCvazT5hnp6sOpakh1M0PDzOrdbTMpS/6X
> gG2ROmKk5/vIrtD8/33x9+4M0W2LmUga+4qL2xUYys6j9ne7izP3UMETEfmCPC11
> frcALmAf5DKX1FrFyo4DtN2nOgEktJB8ylQu44Zme3JhgG5FuE5BvqTKGwj2aQz/
> qCi87Unl7H1/baFei1uqlIkqeo12ZfNIZmdGjnTApLA9OaBNTLZt9/LxWeSoLs6f
> soteZ0dUEYWhbQf9c8H0qj3X1z4oSuUfVEzxrssQe6PqlRwxstv8/IwrqLgKZ4+H
> IeAgZGWjAubAoLbevOfA
> =xd6P
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch