- 27 5月, 2010 2 次提交
-
-
由 Eric Anholt 提交于
With the advent of the BSD ring, be clear about which ring this is. The docs are pretty consistent with calling this the Render engine at this point.
-
由 Eric Anholt 提交于
This is preparation for supporting multiple ringbuffers on Ironlake. The non-copy-and-paste changes are: - de-staticing functions - I915_GEM_GPU_DOMAINS moving to i915_drv.h to be used by both files. - i915_gem_add_request had only half its implementation copy-and-pasted out of the middle of it.
-
- 11 5月, 2010 1 次提交
-
-
由 Daniel Vetter 提交于
This lru tracks fences, not objects, so move it to where it belongs. As a side effect, this nicely shrinks drm_i915_gem_object by two pointers. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 08 5月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
By idling the GPU and discarding everything we can when under extreme memory pressure, the number of OOM-killer events is dramatically reduced. For instance, this makes it possible to run firefox-planet-gnome.trace again on my swapless 512MiB i915. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 24 4月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
My PIPE_CONTROL fix (just sent via Eric's tree) was buggy; I was testing a whole set of patches together and missed a conversion to the new HAS_PIPE_CONTROL macro, which will cause breakage on non-Ironlake 965 class chips. Fortunately, the fix is trivial and has been tested. Be sure to use the HAS_PIPE_CONTROL macro in i915_get_gem_seqno, or we'll end up reading the wrong graphics memory, likely causing hangs, crashes, or worse. Reported-by: NZdenek Kabelac <zdenek.kabelac@gmail.com> Reported-by: NToralf Förster <toralf.foerster@gmx.de> Tested-by: NToralf Förster <toralf.foerster@gmx.de> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 4月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
Since 965, the hardware has supported the PIPE_CONTROL command, which provides fine grained GPU cache flushing control. On recent chipsets, this instruction is required for reliable interrupt and sequence number reporting in the driver. So add support for this instruction, including workarounds, on Ironlake and Sandy Bridge hardware. https://bugs.freedesktop.org/show_bug.cgi?id=27108Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 20 4月, 2010 5 次提交
-
-
由 Daniel Vetter 提交于
Luckily the change is quite a little bit less invasive than I've feared. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
Thanks to the to_intel_bo helper, this change is rather trivial. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
Just embed it and adjust the pointers, No other changes (that's for later patches). Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
Just preparation, no functional change. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Daniel Vetter 提交于
When drivers embed the core gem object into their own structures, they'll have to do this. Temporarily this results in an ugly kfree(gem_obj); in every gem driver. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 4月, 2010 1 次提交
-
-
由 Daniel Vetter 提交于
Current code is definitely crap: Largest pitch allowed spills into the TILING_Y bit of the fence registers ... :( I've rewritten the limits check under the assumption that 3rd gen hw has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an otherwise totally misleading XXX comment. This bug mostly resulted in tiling-corrupted pixmaps because the kernel allowed too wide buffers to be tiled. Bug brought to the light by the xf86-video-intel 2.11 release because that unconditionally enabled tiling for pixmaps, relying on the kernel to check things. Tiling for the framebuffer was not affected because the ddx does some additional checks there ensure the buffer is within hw-limits. v2: Instead of computing the value that would be written into the hw fence registers and then checking the limits simply check whether the stride is above the 8kb limit. To better document the hw, add some WARN_ONs in i915_write_fence_reg like I've done for the i830 case (using the right limits). Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449Tested-by: NAlexander Lam <lambchop468@gmail.com> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 26 3月, 2010 1 次提交
-
-
由 Daniel Vetter 提交于
This is a purely cosmetic change to make changes in this area easier. And hey, it's not only clearer and typechecked, but actually shorter, too! [anholt: To clarify, this is a change to let us later make drm_i915_gem_object subclass drm_gem_object, instead of having drm_gem_object have a pointer to i915's private data] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 18 3月, 2010 3 次提交
-
-
由 Chris Wilson 提交于
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=15527 NULL pointer dereference in i915_gem_object_save_bit_17_swizzle BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f82b5d2b>] i915_gem_object_save_bit_17_swizzle+0x5b/0xc0 [i915] Call Trace: [<f82aea55>] ? i915_gem_object_put_pages+0x125/0x150 [i915] [<f82aeb71>] ? i915_gem_object_get_pages+0xf1/0x110 [i915] [<f82b0de8>] ? i915_gem_object_bind_to_gtt+0xb8/0x2a0 [i915] [<c02db74d>] ? drm_mm_get_block_generic+0x4d/0x180 [<f82b11cd>] ? i915_gem_mmap_gtt_ioctl+0x16d/0x240 [i915] [<f82ae786>] ? i915_gem_madvise_ioctl+0x86/0x120 [i915] Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reported-by: maciej.rutecki@gmail.com Cc: stable@kernel.org Reviewed-by: NEric Anholt <eric@anholt.net> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
This could resolve HW deadlocks where a unit downstream of the VS is waiting for more input, the VS has one vertex queued up but not dispatched because it hopes to get one more vertex for 2x4 dispatch, and software isn't handing more vertices down because it's waiting for rendering to complete. The B-Spec says you should always have this bit set. Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Owain G. Ainsworth 提交于
The continue just after this call with loop around and wait for the request just added just fine. This leads to slightly more compact code. Signed-Off-by: NOwain G. Ainsworth <oga@openbsd.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 27 2月, 2010 10 次提交
-
-
由 Daniel Vetter 提交于
The assumption that an object has only ever one write domain is deeply threaded into gem (it's even encoded the the singular of the variable name). Don't let userspace screw us over. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
Now that we have an exact gpu write domain tracking, we don't need to move objects to the active list ourself. i915_add_request will take care of that under all circumstances. Idea stolen from a patch by Chris Wilson <chris@chris-wilson.co.uk>. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
We have it, so use it. This required moving the function to avoid a forward declaration. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
The fence_list should be lru ordered for otherwise we might try to steal a fence reg from an active object even though there are fences from inactive objects available. lru ordering was obeyed for gpu access everywhere save when moving dirty objects from flushing_list to active_list. Fixing this cause the code to indent way to much, so I've extracted the flushing_list processing logic into its on function. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
The spaghetti logic in there tripped up my brain's code parser for a few secs. Prevent this from happening again by extracting the fence stealing code into a seperate functions. IMHO this slightly clears up the code flow. v2: Beautified according to ickle's comments. v3: ickle forgot to flush his comment queue ... Now there's also a we-are-paranoid BUG_ON in there. v4: I've forgotten to switch on my brain when doing v3. Now the BUG_ON actually checks something useful. v5: Clean up a stale comment as noted by Eric Anholt. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
All other accesses take this spinlock, so do this here, too. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
This has a few functional changes against the old code: * a few more unnecessary loads and stores to the drm_i915_fence_reg objects. Also an unnecessary store to the hw fence register. * zaps any userspace mappings before doing other flushes. Only changes anything when userspace does racy stuff against itself. * also flush GTT domain. This is a noop, but still try to keep the bookkeeping correct. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
The register's moved to the same location as the one for the BCS, it seems. Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 23 2月, 2010 3 次提交
-
-
由 Owain Ainsworth 提交于
i915_gem_object_fenceable was mostly just a repeat of the i915_gem_object_fence_offset_ok, but also checking the size (which was checkecd when we allowed that BO to be tiled in the first place). So instead, export the latter function and use it in place. Signed-Off-By: NOwain G. Ainsworth <oga@openbsd.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
This aligns it with the other user of i915_gem_clear_fence_reg, which blows away the mapping before changing the fence reg. Only affects userspace if it races against itself when changing tiling parameters, i.e. behaviour is undefined, anyway. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
No functional change, because gtt flushing is a no-op. Still, try to keep the bookkeeping accurate. The if is still slightly wrong for with execbuf2 even i915-class hw doesn't always need a fence reg for gpu access. But that's for somewhen lateron. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 17 2月, 2010 2 次提交
-
-
由 Eric Anholt 提交于
The fence start is for compatibility with UMS X Servers before fence management. KMS X Servers only started doing tiling after fence management appeared. Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
With the introduction of the hang-check, we can safely expect that i915_wait_request() will always return even when the GPU hangs, and so do not need to open code the wait in order to manually check for the hang. Also we do not need to always evict all buffers, so only flush the GPU (and wait for it to idle) for KMS, but continue to evict for UMS. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 11 2月, 2010 3 次提交
-
-
由 Luca Barbieri 提交于
Mostly obvious simplifications. The i915 pread/pwrite ioctls, intel_overlay_put_image and nouveau_gem_new were incorrectly using the locked versions without locking: this is also fixed in this patch. Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Owain Ainsworth 提交于
Signed-off-by: NOwain G. Ainsworth <oga@openbsd.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
Before changing the status of a buffer with a pending write we will await upon a new flush for that buffer. So we can take advantage of any flushes posted whilst the buffer is active and pending processing by the GPU, by clearing its write_domain and updating its last_rendering_seqno -- thus saving a potential flush in deep queues and improves flushing behaviour upon eviction for both GTT space and fences. In order to reduce the time spent searching the active list for matching write_domains, we move those to a separate list whose elements are the buffers belong to the active/flushing list with pending writes. Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported by me. In addition to better performance, this also fixes a real bug. Before this changes, i915_gem_evict_everything didn't work as advertised. When the gpu was actually busy and processing request, the flush and subsequent wait would not move active and dirty buffers to the inactive list, but just to the flushing list. Which triggered the BUG_ON at the end of this function. With the more tight dirty buffer tracking, all currently busy and dirty buffers get moved to the inactive list by one i915_gem_flush operation. I've left the BUG_ON I've used to prove this in there. References: Bug 25911 - 2.10.0 causes kernel oops and system hangs http://bugs.freedesktop.org/show_bug.cgi?id=25911 Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops within seconds after login http://bugs.freedesktop.org/show_bug.cgi?id=26101Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Tested-by: NAdam Lantos <hege@playma.org> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 05 2月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
Following a gpu hang, we would leak the relocation buffer. So simply earrange the error path to always free the relocation buffer. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 28 1月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
Having missed the ENOMEM return via i915_gem_fault(), there are probably other paths that I also missed. By not enabling NORETRY by default these paths can run the shrinker and take memory from the system (but not from our own inactive lists because our shrinker can not run whilst we hold the struct mutex) and this may allow the system to survive a little longer whilst our drivers consume all available memory. References: OOM killer unexpectedly called with kernel 2.6.32 http://bugzilla.kernel.org/show_bug.cgi?id=14933 v2: Pass gfp into page mapping. v3: Use new read_cache_page_gfp() instead of open-coding. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 1月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
X.org hang with [drm:i915_gem_do_execbuffer] *ERROR* in dmesg http://bugzilla.kernel.org/show_bug.cgi?id=15114 Matej found he was hitting an error path within i915_gem_do_execbuffer() that led to the attempt to dereference an uninitialised pointer during cleanup. This path used to be safe as we used to calloc the object lists, but this was changed in c8e0f93a. Daniel Vetter had also spotted this error and proposed a similar patch. [ 6379.732892] [drm:i915_gem_do_execbuffer] *ERROR* Object ffff880098cd6540 appears more than once in object list [ 6379.740976] [drm:i915_gem_do_execbuffer] *ERROR* Object ffff880098cd6540 appears more than once in object list [ 6379.740995] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 [ 6379.740998] IP: [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260 [ 6379.741006] PGD babab067 PUD bb435067 PMD 0 [ 6379.741010] Oops: 0002 [#1] PREEMPT SMP [ 6379.741014] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:06:00.0/ieee80211/phy0/rfkill0/state [ 6379.741017] CPU 1 [ 6379.741021] Pid: 2186, comm: X Not tainted 2.6.33-rc4-00399-g24bc7347 #142 M11D/ESPRIMO Mobile M9400 [ 6379.741023] RIP: 0010:[<ffffffff8122ddb5>] [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260 [ 6379.741027] RSP: 0018:ffff8800b9047b78 EFLAGS: 00213206 [ 6379.741029] RAX: 0000000000000000 RBX: 000000000000004f RCX: ffff880098cac800 [ 6379.741032] RDX: ffff880098caca78 RSI: ffff8800b9047c98 RDI: ffff880098cd6540 [ 6379.741034] RBP: ffff8800b9047c78 R08: ffffffff814b96b5 R09: 0000000000000006 [ 6379.741036] R10: 0000000000000000 R11: 0000000000000003 R12: 000000000000004e [ 6379.741038] R13: 00000000fffffff7 R14: 0000000000000000 R15: 0000000000000001 [ 6379.741041] FS: 0000000000000000(0000) GS:ffff880001900000(0063) knlGS:00000000f72636c0 [ 6379.741043] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 6379.741041] FS: 0000000000000000(0000) GS:ffff880001900000(0063) knlGS:00000000f72636c0 [ 6379.741043] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 6379.741045] CR2: 00000000000000a0 CR3: 00000000b9000000 CR4: 00000000000006e0 [ 6379.741048] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6379.741050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 6379.741052] Process X (pid: 2186, threadinfo ffff8800b9046000, task ffff8800bb5d8000) [ 6379.741054] Stack: [ 6379.741055] ffffc90023f57000 ffffc90023f56fff ffffc90023f56fff ffffc90023f55000 [ 6379.741059] <0> ffff8800b9047c98 ffff8800bb43c840 ffff8800bf1de800 ffff8800bf1de820 [ 6379.741063] <0> ffff8800b9047bd8 ffff880098cac800 0000000000000000 0000000000000002 [ 6379.741068] Call Trace: [ 6379.741072] [<ffffffff8122e6cb>] ? i915_gem_execbuffer+0x6b/0x370 [ 6379.741077] [<ffffffff810a5f52>] ? __vmalloc_node+0xa2/0xb0 [ 6379.741080] [<ffffffff8122e6cb>] ? i915_gem_execbuffer+0x6b/0x370 [ 6379.741083] [<ffffffff8122e816>] i915_gem_execbuffer+0x1b6/0x370 [ 6379.741086] [<ffffffff8120cd55>] drm_ioctl+0x1d5/0x460 [ 6379.741089] [<ffffffff8122e660>] ? i915_gem_execbuffer+0x0/0x370 [ 6379.741093] [<ffffffff81248c35>] i915_compat_ioctl+0x45/0x50 [ 6379.741097] [<ffffffff810f1659>] compat_sys_ioctl+0xa9/0x1570 [ 6379.741102] [<ffffffff810b1d5c>] ? vfs_read+0x13c/0x1a0 [ 6379.741106] [<ffffffff81028424>] sysenter_dispatch+0x7/0x2b [ 6379.741108] Code: 08 85 c0 74 52 31 db 0f 1f 80 00 00 00 00 48 63 c3 48 8b 8d 68 ff ff ff 48 8d 14 c1 48 8b 02 48 85 c0 74 25 48 8b 80 80 00 00 00 <c7> 80 a0 00 00 00 00 00 00 00 48 8b 3a 48 85 ff 74 0c 48 c7 c6 [ 6379.741142] RIP [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260 [ 6379.741145] RSP <ffff8800b9047b78> [ 6379.741147] CR2: 00000000000000a0 [ 6379.741159] ---[ end trace 0598809afa4c31db ]--- Reported-by: NMatej Laitl <strohel@gmail.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 16 1月, 2010 1 次提交
-
-
由 Eric Anholt 提交于
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> (in principle) Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 13 1月, 2010 1 次提交
-
-
由 Zhenyu Wang 提交于
When we setup buffer for display plane, we'll check any pending required GPU flush and possible make interruptible wait for flush complete. But that wait would be most possibly to fail in case of signals received for X process, which will then fail modeset process and put display engine in unconsistent state. The result could be blank screen or CPU hang, and DDX driver would always turn on outputs DPMS after whatever modeset fails or not. So this one creates new helper for setup display plane buffer, and when needing flush using uninterruptible wait for that. This one should fix bug like https://bugs.freedesktop.org/show_bug.cgi?id=24009. Also fixing mode switch stress test on Ironlake. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-