Bug 23102
| Summary: | [bisected] i915 regression in post 2.6.36 kernels | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Maciej Rutecki (maciej.rutecki) |
| Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | andreas.eckstein, brian, chris, florian, johannes.hirte, maciej.rutecki, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.37-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 21782 | ||
|
Description
Maciej Rutecki
2010-11-17 18:16:09 UTC
commit de18a29e0fa3904894b4e02fae0e712cd43f740c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Nov 27 22:30:41 2010 +0100 drm/i915: fix regression due to ba3d8d749b01548b9 We don't track gpu flush request in any special way. So even with obj->write_domain == 0, a gpu flush might be outstanding but no yet executed. Even worse, the latest request might use the object only for reading. So and unconditional call to object_wait_rendering is needed for !pipelined. Hence revert that patch fully and untangle the flushing from the synchronization again. Reported-by: Keith Packard <keithp@keithp.com> Tested-by: Keith Packard <keithp@keithp.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Sorry, but this didn't fixed it for me. The regression still exists, so please reopen. Chris, Johannes said in the thread referenced above:
> I've found it. 5c12a07e8073295ce8b57a822f811ac34e4f8420 contains
>
> static void
> @@ -1945,11 +1933,6 @@ i915_gem_flush_ring(struct drm_device *dev,
> {
> ring->flush(dev, ring, invalidate_domains, flush_domains);
> i915_gem_process_flushing_list(dev, flush_domains, ring);
> -
> - if (ring->outstanding_lazy_request) {
> - (void)i915_add_request(dev, file_priv, NULL, ring);
> - ring->outstanding_lazy_request = false;
> - }
> }
>
> which wasn't redone by a56ba56c275b1c2b982c8901ab92bf5a0fd0b757. After adding
> those five lines it works for me.
>
> regards,
> Johannes
Can you make anything out of that?
That would be a bug in the kernel that caused the emission of two requests for each batchbuffer. Hence it was removed. Ok, but without this I get the regression, I've reported. Any idea what's going wrong there? The system is unusable with KDE for me. I've tested with gdm instead kdm now and this works. All windows are displayed, in gdm and the started KDE session. With kdm still only the background is showed. There are also problems when logging in via gdm. After some time the screen got completely frozen. Only the mouse was updated but no windows/background. Can you observe theses misbehaviours also in the final 2.6.37 kernel? yes it's still present in 2.6.37 I was bitten by this bug too (actually it happened _sometimes_ with 2.6.36.x), but it went away once I upgraded to xf86-video-intel-2.13.903. I cannot guarantee that it won't happen again sometimes though. Will report back if it does. Yes, I can confirm that 2.6.37 works with the latest git of xf86-video-intel. So >xf86-video-intel-2.13 is necessary for 2.6.37 and later. Just one of the many userspace flushing issues. |