From owner-freebsd-x11@FreeBSD.ORG Tue Jun 12 11:07:48 2012 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BEA11065670 for ; Tue, 12 Jun 2012 11:07:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 06DA78FC0A for ; Tue, 12 Jun 2012 11:07:47 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5CB797V085612; Tue, 12 Jun 2012 14:07:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5CB74se088317; Tue, 12 Jun 2012 14:07:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5CB74vo088316; Tue, 12 Jun 2012 14:07:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jun 2012 14:07:04 +0300 From: Konstantin Belousov To: Andrey Kosachenko Message-ID: <20120612110704.GM2337@deviant.kiev.zoral.com.ua> References: <4E8DF3F9.3090201@gmail.com> <20111006184623.GS1511@deviant.kiev.zoral.com.ua> <4E8E02E8.9000402@gmail.com> <4FD63519.1090507@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g6DVDhPhk1bqxDrC" Content-Disposition: inline In-Reply-To: <4FD63519.1090507@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-x11@freebsd.org Subject: Re: intel GPU hangs X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:07:48 -0000 --g6DVDhPhk1bqxDrC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 > http://lists.freebsd.org/pipermail/freebsd-x11/2011-October/011210.html) >=20 > Briefly: > I've experienced sporadic GPU hangs (using 10-Current and trying=20 > different kms patches starting from the very beginning up to the latest= =20 > all.15.*.patch). It has happened on my "workhorse" ThinkPad T410 (intel= =20 > integrated graphics, chipset "Arrandale"). GPU hungs were not tied to=20 > usage of heavy 3D apps or whatever. Indeed I've never managed to=20 > identify what was wrong and I don't remember that smb. reported the=20 > same. Moreover somewhere around all.12.x.patch issue occurrence=20 > decreased almost to zero (once or twice per month) and so I abandoned to= =20 > report it (recompiled kernel w/o debug stuff and forgot about it). >=20 > Several weeks ago I had to use software for my private needs that is not= =20 > working under BSD (I'm talking about Google Sketchup actually, free=20 > software (basic version) that allows to make 3D sketches easily). So I=20 > employed a VM for this (VirtualBox). So far so good. But as the=20 > complexity of models grew I started to catch more GPU hangups. It made=20 > me crazy. At last point it was enough to load model + perform 2-3=20 > 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. >=20 > I googled for a while and found several pretty similar reports in linux= =20 > world. They experienced the same issue with SandyBridge hardware. I=20 > tried various patches (at least those I could apply) and it appeared=20 > that the following patch eliminates GPU hangs in my case: >=20 >=20 > Index: sys/dev/drm2/i915/i915_irq.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- 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); >=20 > 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,=20 > ~GEN6_BLITTER_USER_INTERRUPT); > + I915_WRITE(GEN6_BSD_HWSTAM, ~GEN6_BSD_USER_INTERRUPT); > + } >=20 > + > /* XXX hotplug from PCH */ >=20 > 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@. --g6DVDhPhk1bqxDrC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/XItgACgkQC3+MBN1Mb4jaQgCg76gr/w73QI6DVimMKVdvuVf7 /UYAoN81xahx8JSIsx5cNEYFj8ZIVyP1 =kZ8X -----END PGP SIGNATURE----- --g6DVDhPhk1bqxDrC--