Date: Mon, 11 Jun 2012 21:12:41 +0300 From: Andrey Kosachenko <andrey.kosachenko@gmail.com> To: freebsd-x11@freebsd.org Subject: Re: intel GPU hangs Message-ID: <4FD63519.1090507@gmail.com> In-Reply-To: <4E8E02E8.9000402@gmail.com> References: <4E8DF3F9.3090201@gmail.com> <20111006184623.GS1511@deviant.kiev.zoral.com.ua> <4E8E02E8.9000402@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 --- 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've to say that the workaround above was removed from linux kernel somewhere around 3.0-3.1 (sorry, I can't recall the commit but I clearly remember the log message that stated that they don't need this workaround in the kernel anymore). I'm not sure if we need this too (if I'm not mistaken kib@ mentioned that he synced drm stuff with linux but I don't remember at which point). Anyway I just want to admit that this simple hack works and I'd like to ask: can it be considered (or possibly it's reworked version or..) for inclusion? Again, I'm not sure that all community requires mentioned hack but at least those guys who've got SB hardware may earn some bits on it. Thanks! -- WBR, Andrey Kosachenko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD63519.1090507>