Date: Tue, 19 Nov 2013 18:18:28 -0800 From: "Eric L. Camachat" <eric.camachat@gmail.com> To: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= <olivier@cochard.me>, freebsd-x11@freebsd.org Subject: Re: i915: Detected a hung GPU, disabling acceleration Message-ID: <528C1BF4.8040205@gmail.com> In-Reply-To: <CA%2Bq%2BTcrL%2BDBgTiybqq%2BFoaD=Q4d1__ioz6brPYq9=ZzKCFckRg@mail.gmail.com> References: <CA%2Bq%2BTcrL%2BDBgTiybqq%2BFoaD=Q4d1__ioz6brPYq9=ZzKCFckRg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DJhnpLt9OnIFhRVjTalFSARfqhLcsrM4q
Content-Type: multipart/mixed;
boundary="------------050508000107000903000905"
This is a multi-part message in MIME format.
--------------050508000107000903000905
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 01/19/2013 06:49, Olivier Cochard-Labb=E9 wrote:
> On my new HP laptop with FreeBSD 9.1-Release (amd64) I've got this
> message after few hours of xorg usage:
> (EE) intel(0): Detected a hung GPU, disabling acceleration.
My i915 hang was fixed by the patch.
Eric
--------------050508000107000903000905
Content-Type: text/x-patch;
name="i915_drm_hang.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="i915_drm_hang.patch"
=46rom 262b6d363fcff16359c93bd58c297f961f6e6273 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue, 15 Jan 2013 16:17:54 +0000
Subject: drm/i915: Invalidate the relocation presumed_offsets along the s=
low path
In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.
Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Nov 21 22:07:12 2010 +0000
drm/i915: Handle pagefaults in execbuffer user relocations
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=3D55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@fwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
Index: sys/dev/drm2/i915/i915_gem_execbuffer.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
diff --git a/stable/10/sys/dev/drm2/i915/i915_gem_execbuffer.c b/stable/1=
0/sys/dev/drm2/i915/i915_gem_execbuffer.c
--- a/stable/10/sys/dev/drm2/i915/i915_gem_execbuffer.c (revision 258349)=
+++ b/stable/10/sys/dev/drm2/i915/i915_gem_execbuffer.c (working copy)
@@ -724,6 +724,8 @@
total =3D 0;
for (i =3D 0; i < count; i++) {
struct drm_i915_gem_relocation_entry *user_relocs;
+ u64 invalid_offset =3D (u64)-1;
+ int j;
=20
user_relocs =3D (void *)(uintptr_t)exec[i].relocs_ptr;
ret =3D -copyin(user_relocs, reloc + total,
@@ -733,6 +735,25 @@
goto err;
}
=20
+ /* As we do not update the known relocation offsets after
+ * relocating (due to the complexities in lock handling),
+ * we need to mark them as invalid now so that we force the
+ * relocation processing next time. Just in case the target
+ * object is evicted and then rebound into its old
+ * presumed_offset before the next execbuffer - if that
+ * happened we would make the mistake of assuming that the
+ * relocations were valid.
+ */
+ for (j =3D 0; j < exec[i].relocation_count; j++) {
+ if (copyout(&invalid_offset,
+ &user_relocs[j].presumed_offset,
+ sizeof(invalid_offset))) {
+ ret =3D -EFAULT;
+ DRM_LOCK(dev);
+ goto err;
+ }
+ }
+
reloc_offset[i] =3D total;
total +=3D exec[i].relocation_count;
}
--------------050508000107000903000905--
--DJhnpLt9OnIFhRVjTalFSARfqhLcsrM4q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlKMG/QACgkQSfBQu3oOwYzXAQEAhO9uKHRQK/4vB3kJzB40kpk+
vNa068G4+iUa7ussxGAA/2f+KL3S1sIkDdxgl9mgkMDKTPc1rVixmy//1hfm8Ebt
=nIk2
-----END PGP SIGNATURE-----
--DJhnpLt9OnIFhRVjTalFSARfqhLcsrM4q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528C1BF4.8040205>