Bug 15327
| Summary: | [855GM] random freezes | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Vasyl Demin (vasyl.demin) |
| Component: | Video(DRI - Intel) | Assignee: | Jesse Barnes (jbarnes) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | chris, jbarnes, maciej.rutecki, rjw, vasyl.demin |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32.8 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 14885 | ||
|
Description
Vasyl Demin
2010-02-16 18:31:49 UTC
Can you test the drm-intel-next branch from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git? Ok, I'll try it BTW, what was the last working kernel? 2.6.32.7 Well, it should be pretty straightforward to carry out bisection of commits between 2.6.32.7 and 2.6.32.8. Can you please try that? Interaction with userspace would muddle the bisection. This bug should be fixed by: commit 99fcb766a3a50466fe31d743260a3400c1aee855 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Feb 7 16:20:18 2010 +0100 drm/i915: Update write_domains on active list after flush. 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=26101 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Adam Lantos <hege@playma.org> Cc: stable@kernel.org Signed-off-by: Eric Anholt <eric@anholt.net> Ok closing per Chris's add. |