Summary: | [965GM] Relocation beyond target object bounds | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | roberth <sarvatt> | ||||||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||
Status: | RESOLVED WORKSFORME | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||
Severity: | major | ||||||||||||
Priority: | medium | ||||||||||||
Version: | 7.5 (2009.10) | ||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Attachments: |
|
Description
roberth
2011-01-28 06:50:31 UTC
Created attachment 42649 [details]
Xorg.0.log
Created attachment 42650 [details]
Boot dmesg
Created attachment 42651 [details]
Current dmesg
Full of errors like these
[21754.275039] [drm:i915_gem_execbuffer_relocate_entry] *ERROR* Relocation beyond target object bounds: obj ffff88004bb8ac00 target 6 delta 43655680 size 4096.
valgrind compiz. Something is not very happy. Is mesa compiled with NDEBUG? (Since there is an assert to catch that error.) This is not a compiz display issue (or at least not entirely) because the problem actually looks worse without compiz running. You see the same errors reported in dmesg without compiz? (Not just the errors existing once compiz has exited.) I see similar update corruption in emacs and xchat-gnome. Reverting commit 1ba983034b3a70fb541dc359189c020ee497c634 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Dec 7 12:27:29 2010 +0000 uxa: Emit the damage after the render for the workaround in uxa_solid_rects Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes it. Travis Watkins also reports this revert fixing the corruption. I presume this was added for a reason; perhaps the damage changes in Xserver 1.10 have caused this to now be harmful? > I presume this was added for a reason; perhaps the damage changes in Xserver
> 1.10 have caused this to now be harmful?
Hm, testing against Xserver 1.8 reveals the same corruption.
commit da990536eca09c6de74627541cd56ecfad925eda Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 3 09:41:48 2011 +0000 uxa: Undo damage translation before appending The region is used to paint onto the backing pixmap (and thus translated) prior to being passed to the damage layer (wrt to the drawable). So the local translation needs to be undone first. Identified by Christopher James Halse Rogers. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33650 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Oops, thought I was looking at another bug (the compiz damage). Christopher, who was the culprit for the invalid relocations? I don't know. My logs did not contain any of those messages. The relocation failures appear to be independent of the damage corruption that was the motivation for this bug. It's not clear to me if the relocation failures have any symptoms other than the log messages. Travis: now that the damage corruption is gone, are there any symptoms for those relocation failures? Downgrading prior as the visual corruption was fixed in another bug, only the issue of the illegal relocations remain (for which we await dbg results). The assertion has gone and so has the error message. There is little we can do before we get a report of some actual corruption. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.