Accepting request 32799 from X11:XOrg

Copy from X11:XOrg/libdrm based on submit request 32799 from user sndirsch

OBS-URL: https://build.opensuse.org/request/show/32799
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/libdrm?expand=0&rev=24
This commit is contained in:
OBS User autobuild 2010-02-18 14:49:01 +00:00 committed by Git OBS Bridge
parent c20f54c926
commit eaf7b933ed
4 changed files with 133 additions and 1 deletions

View File

@ -0,0 +1,49 @@
From fdcde592c2c48e143251672cf2e82debb07606bd Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue, 9 Feb 2010 08:32:54 +0000
Subject: [PATCH] intel: Account for potential pinned buffers hogging fences
As the kernel reports the total number of fences, we must guess how many
fences are likely to be pinned. In the typical system these will be only
used by the scanout buffers, of which there may be one per pipe, and any
number of manually pinned fenced buffers. So take a conservative guess
and reserve two fences for use by the system.
Note this reduces the number of fences to 3 for i915 and prior.
Reference:
http://bugs.freedesktop.org/show_bug.cgi?id=25911
The latest intel driver 2.10.0 causes kernel oops and system hangs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
intel/intel_bufmgr_gem.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 0d011a2..66d12bc 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1769,6 +1769,19 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
fprintf(stderr, "param: %d, val: %d\n", gp.param,
*gp.value);
bufmgr_gem->available_fences = 0;
+ } else {
+ /* XXX The kernel reports the total number of fences,
+ * including any that may be pinned.
+ *
+ * We presume that there will be at least one pinned
+ * fence for the scanout buffer, but there may be more
+ * than one scanout and the user may be manually
+ * pinning buffers. Let's move to execbuffer2 and
+ * thereby forget the insanity of using fences...
+ */
+ bufmgr_gem->available_fences -= 2;
+ if (bufmgr_gem->available_fences < 0)
+ bufmgr_gem->available_fences = 0;
}
}
--
1.6.4.2

View File

@ -0,0 +1,69 @@
From 4f0f871730b76730ca58209181d16725b0c40184 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed, 10 Feb 2010 09:45:13 +0000
Subject: [PATCH] intel: Handle resetting of input params after EINTR during SET_TILING
The SET_TILING is pernicious in that it overwrites the input arguments
following an error in order to report the current tiling state of the
buffer. This caught us by surprise as we then fed those arguments back
into to the ioctl unmodified following an EINTR and so the kernel then
reported success for the no-op. We interpreted this success as meaning
that the tiling on the buffer had changed so updated our state and
started using the buffer incorrectly in the new tiled/untiled manner.
This lead to all sorts of random corruption and GPU hangs, even though
the batch buffers would look sane (when the GPU had not wandered off
into forbidden territory).
References:
Bug 25475 - [i915] Xorg crash / Execbuf while wedged
http://bugs.freedesktop.org/show_bug.cgi?id=25475
Bug 25554 - i830_uxa_prepare_access: gtt bo map failed: Input/output error
http://bugs.freedesktop.org/show_bug.cgi?id=25554
(And probably every other weird bug in the last few months.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
intel/intel_bufmgr_gem.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 66d12bc..4e61cef 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1423,18 +1423,15 @@ drm_intel_gem_bo_set_tiling(drm_intel_bo *bo, uint32_t * tiling_mode,
memset(&set_tiling, 0, sizeof(set_tiling));
set_tiling.handle = bo_gem->gem_handle;
- set_tiling.tiling_mode = *tiling_mode;
- set_tiling.stride = stride;
do {
+ set_tiling.tiling_mode = *tiling_mode;
+ set_tiling.stride = stride;
+
ret = ioctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_SET_TILING,
&set_tiling);
} while (ret == -1 && errno == EINTR);
- if (ret != 0) {
- *tiling_mode = bo_gem->tiling_mode;
- return -errno;
- }
bo_gem->tiling_mode = set_tiling.tiling_mode;
bo_gem->swizzle_mode = set_tiling.swizzle_mode;
@@ -1445,7 +1442,7 @@ drm_intel_gem_bo_set_tiling(drm_intel_bo *bo, uint32_t * tiling_mode,
drm_intel_bo_gem_set_in_aperture_size(bufmgr_gem, bo_gem);
*tiling_mode = bo_gem->tiling_mode;
- return 0;
+ return ret == 0 ? 0 : -errno;
}
static int
--
1.6.4.2

View File

@ -1,3 +1,13 @@
-------------------------------------------------------------------
Wed Feb 17 16:25:36 CET 2010 - sndirsch@suse.de
- intel-Account-for-potential-pinned-buffers-hogging-f.patch
* intel: Account for potential pinned buffers hogging fences
(bfo #25911)
- intel-Handle-resetting-of-input-params-after-EINTR-d.patch
* intel: Handle resetting of input params after EINTR during
SET_TILING (bfo #25475, bfo #25554)
-------------------------------------------------------------------
Wed Jan 6 03:44:44 CET 2010 - sndirsch@suse.de

View File

@ -32,11 +32,13 @@ Obsoletes: libdrm-64bit
%endif
#
Version: 2.4.17
Release: 1
Release: 2
Summary: Userspace Interface for Kernel DRM Services
Source: %{name}-%{version}.tar.bz2
Source2: baselibs.conf
Patch: enable_test_tools.diff
Patch1: intel-Account-for-potential-pinned-buffers-hogging-f.patch
Patch2: intel-Handle-resetting-of-input-params-after-EINTR-d.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-build
%description
@ -117,6 +119,8 @@ Authors:
%prep
%setup -q
%patch
%patch1 -p1
%patch2 -p1
%build
autoreconf -fi