i915 error hangcheck timer elapsed
Stefan Roas
sroas at roath.org
Sun Dec 2 07:34:05 PST 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121202/a0f60372/attachment.pgp>
More information about the dri-devel
mailing list