Bug 23382
| Summary: | Graphical glitches on GM965 since 2.6.37-rc1 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Brian Rogers (brian) |
| Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | chris, florian, maciej.rutecki, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/677770 | ||
| Kernel Version: | 2.6.37-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 21782 | ||
|
Description
Brian Rogers
2010-11-20 18:06:28 UTC
You probably forgot to post the link to the mentioned bugreport. This is likely fixed by 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> which is working its way upstream, and is currently available from drm-intel-fixes. Running a kernel with that, it looks good so far. I'll correct myself if I see a glitch pop up. The downstream report is here, BTW: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/677770 I have it in the URL field of this bug report, but I guess it isn't very obvious there. Ah, indeed you have. I overlooked it. Chris, I just wanted to add a link to the patch, but I don't seem to find it on intel-gfx or dri-devel. (I did look only superficial for the subject line and mails from Daniel.) Where do patches usually get posted? Patch: http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=de18a29e0fa3904894b4e02fae0e712cd43f740c Usually intel-gfx@. This particular regression was raised and debugged on irc and no patch made its way to the list. Hmm, I think I will try and enforce a cooling off period such that all patches must first be staged and to email all patches pushed to -staging to the list for review. I don't know what's the recommended workflow, but for tracking purposes a link to a mailinglist posted patch is more helpful then a link to a git repository. With a mailinglist posted patch, issues have a chance of being reported in that same thread and are then automatically visible from the bugreport. Whereas for patches where google does not find a post, you have very few ways to find issues or discussion about it,... *** Bug 22542 has been marked as a duplicate of this bug. *** Fixed by commit de18a29 drm/i915: fix regression due to ba3d8d749b01548b9 . |