Bug 33929 - screen got garbled with latest ati driver 6.14 on open openoffice.org startup I [color tiling issue]
Summary: screen got garbled with latest ati driver 6.14 on open openoffice.org startup...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 33952 34013 34157 34441 34452 34521 35035 35075 42056 42058 42086 (view as bug list)
Depends on:
Blocks: xserver-1.10
  Show dependency treegraph
 
Reported: 2011-02-05 01:42 UTC by Thierry Vignaud
Modified: 2012-01-18 02:04 UTC (History)
18 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (39.28 KB, text/plain)
2011-02-07 03:40 UTC, Thierry Vignaud
no flags Details
Xorg.0.log (36.17 KB, text/plain)
2011-02-07 03:40 UTC, Thierry Vignaud
no flags Details
just opening previously opened .doc file (101.27 KB, image/jpeg)
2011-02-07 03:45 UTC, Thierry Vignaud
no flags Details
switching to another workspace then back: screen is now fully corrupted after redrawing (95.37 KB, image/jpeg)
2011-02-07 03:45 UTC, Thierry Vignaud
no flags Details
switching to last workspace (274.41 KB, image/jpeg)
2011-02-07 03:47 UTC, Thierry Vignaud
no flags Details
Update GPU copy pitch in exaModifyPixmapHeader_mixed (1.18 KB, patch)
2011-02-08 04:35 UTC, Michel Dänzer
no flags Details | Splinter Review
check for xserver 1.9.4.901 to enable tiling by default (1.21 KB, patch)
2011-11-02 12:16 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Thierry Vignaud 2011-02-05 01:42:18 UTC
I just updated to latest ati driver 6.14.
Since that, everytime I open openoffice.org, the screen got garbled (I suspect due to tiling).
xwd returns normal images though.
That doesn't happens once I return to the 2010-10-29 snapshot I was previously using, openoffice doesn't cause the screen to be garbaged

Hardware: RV530LE [Radeon X1600/X1650 PRO]
Comment 1 Alex Deucher 2011-02-05 10:11:48 UTC
What kernel are you using?  Please attach your xorg log and dmesg output.
Comment 2 Thierry Vignaud 2011-02-07 03:39:45 UTC
I'm using kernel-2.6.37 on x86_64
Comment 3 Thierry Vignaud 2011-02-07 03:40:27 UTC
Created attachment 43027 [details]
dmesg output
Comment 4 Thierry Vignaud 2011-02-07 03:40:56 UTC
Created attachment 43028 [details]
Xorg.0.log
Comment 5 Thierry Vignaud 2011-02-07 03:45:22 UTC
Created attachment 43029 [details]
just opening previously opened .doc file

screen start to slightly corrupt
Comment 6 Thierry Vignaud 2011-02-07 03:45:56 UTC
Created attachment 43030 [details]
switching to another workspace then back: screen is now fully corrupted after redrawing
Comment 7 Thierry Vignaud 2011-02-07 03:47:00 UTC
Created attachment 43031 [details]
switching to last workspace

note in red surrouned areas: some blue pixels moving along selected workspace both where desktops/workspaces are displayed in gnome bar and in middle of screen
Comment 8 Michel Dänzer 2011-02-07 23:53:13 UTC
*** Bug 34013 has been marked as a duplicate of this bug. ***
Comment 9 Thierry Vignaud 2011-02-08 00:30:19 UTC
I forgot to say there's no difference between october snapshot & 6.14 in Xorg.0.log beside the supported card list and one new line ("SwapBuffers wait for vsync: enabled" if I remember right)

There might be more dups according to https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&content=color%20tiling&product=&query_format=specific&order=bug_id%20DESC&query_based_on=
Comment 10 Thierry Vignaud 2011-02-08 03:55:31 UTC
Indeed using 'Option "ColorTiling" "false"' fixes this bug
Comment 11 Michel Dänzer 2011-02-08 04:35:15 UTC
Created attachment 43095 [details] [review]
Update GPU copy pitch in exaModifyPixmapHeader_mixed

Does this xserver patch help?
Comment 12 Alex Deucher 2011-02-08 10:27:19 UTC
I think the following bugs are probably related:
bug 33929
bug 33952
bug 33943
bug 33963
Comment 13 Michel Dänzer 2011-02-08 11:00:21 UTC
*** Bug 33943 has been marked as a duplicate of this bug. ***
Comment 14 Thierry Vignaud 2011-02-08 11:57:21 UTC
That fixes it indeed
Comment 15 Thierry Vignaud 2011-02-08 12:04:23 UTC
Except that now mplayer now misteriously die when going forward
Comment 16 Torsten Kaiser 2011-02-08 12:27:01 UTC
I think I'm seeing the same bug. After login via KDM the whole screen looks scrambled, similar to attachment 43031 [details] (switching to last workspace) in this bug.

It started after upgrading from xf86-video-ati-6.13.2 to 6.14.0 and can be fixed by adding "ColorTiling" "false".

I'm using kernel 2.6.38-rc3/4 with KMS on a RV370 (RV370 5B60 [Radeon X300 (PCIE)]), compositing in KDE is off, the X-Server is 1.9.3.902.

Should I try the GPU-copy-pitch patch against that version or would 1.9.99.901 be better?
Comment 17 Michel Dänzer 2011-02-09 00:58:33 UTC
(In reply to comment #15)
> Except that now mplayer now misteriously die when going forward

'going forward' as in fast forwarding the video, or what? Any evidence that this is directly related to this bug/patch at all, or at least any information about mplayer's death?


(In reply to comment #16)
> Should I try the GPU-copy-pitch patch against that version or would 1.9.99.901
> be better?

Shouldn't matter.
Comment 18 Thierry Vignaud 2011-02-09 01:17:24 UTC
well, the segfault only happens when using the patched xserver.

I was using "mplayer -vo gl" (which thus do invoke some EXA paths I think?) due to bug #32871 where colors got corrupted with XV after suspending/resuming.

mplayer -vo gl always segfaulted while using that server, segfault disappeared once downgrading to previous version.

The segfault happened when:
- using any key to move forward
- using -ss to move forward

I hadn't the debug package at the time and I hadn't the time to dig further but I'll today once back at home.
I'll check if other frontends (x11, xv, ...) have the same issue or not and get a debug trace
Comment 19 Thierry Vignaud 2011-02-09 04:41:24 UTC
First, while the bug doesn't happen anymore with oowriter, I've found a new way to reproduce it: start "links -g" (the CLI/GUI navigator), and just type o in order to open a new dialog and voila, screen is garbaged again :-(

As for mplayer, I had the segfault while running it from a older screen session with a different user, it would play a few frames then segfaults when I try to move forward.
I cannot reproduce anymore, either it just segfault after complaining about the bogus x11 cookie or it runs smoothly after running xhost in another termanal.
Anyway the "links -g" issue is more pressing :-(
Comment 20 Torsten Kaiser 2011-02-09 11:35:48 UTC
(In reply to comment #17)

I'm still seeing the problem after upgrading to vanilla xserver-1.9.4. After adding the GPU-copy-pitch patch to that server, KDE works normal again. So for me the patch seems to fix it. Thanks!

I also tried mplayer and had no problems after applying the patch. Both -vo xv and -vo gl worked, including seeking. But my setup is probably not directly comparable to Thierry's.
Comment 21 Thierry Vignaud 2011-02-10 02:05:42 UTC
(In reply to comment #20)
Torsten, could you try installing "links", it's a small package that is provided in most distro (at least in Debian, Fedora, Mandriva), then run "links -g" then type "g" in order to open the "go to URL" dialog ?
Does it result in your screen to be garbaged again?
Comment 22 Michel Dänzer 2011-02-10 02:50:52 UTC
(In reply to comment #19)
> First, while the bug doesn't happen anymore with oowriter, I've found a new way
> to reproduce it: start "links -g" (the CLI/GUI navigator), and just type o in
> order to open a new dialog and voila, screen is garbaged again :-(

I can't seem to reproduce any problem with links2 -g. Which graphics 'driver' is your links using, and which window/compositing manager(s) are you using when the problem occurs?
Comment 23 Thierry Vignaud 2011-02-10 03:46:04 UTC
I'm using:
- Mandriva Linux 2010.2 with backported xserver-1.9.4 + rebuild drivers
 (from Mandriva Linux Cooker (~~ Fedora Rawhide))
- kernel-2.6.37
- gnome-2.30
- no composite

both links & links-hacked garbage the screen, either when opening a dialog or when opening on the menu bar through F10
links offers x & fb drivers, thus it must be using the x one.
links-hacked offers x dreamcast fb DirectFB drivers. It must uses the x driver I guess.
Note that I must be the last links-hacked users since that fork is unmaintained for years.

For both, using 'Option "ColorTiling" "false"' fixes this bug
Without that, both links & links-hacked garbage the screen like oowriter uses to do, which implies there's maybe another code path that is hitten and shows the same bug as before. Any idea?

Here's the Mandriva spec files:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/links-hacked/current/SPECS/links-hacked.spec?revision=533273&view=markup
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/links/current/SPECS/links.spec?revision=533227&view=markup
Comment 24 Thierry Vignaud 2011-02-10 03:54:13 UTC
I just tested kernel-2.6.38-rc4.
Same garbaged screen.
Same fix with disabling colortiling
Comment 25 Thierry Vignaud 2011-02-10 04:17:26 UTC
Sorry I had downgrading xserver :-(
I confirm that both links & oowriter works fine with xserver-1.9.4+patch on kernel-2.6.38.
Sorry for the alarming noise :-(
/me putting the brown paper bag on my head :-(
Comment 26 Ernst Sjöstrand 2011-02-10 10:19:36 UTC
Dupe of bug 33497?
Comment 27 Thierry Vignaud 2011-02-10 11:06:51 UTC
I would do the reverse since:
- more people have commented here
- more info was provided here
- screenshots were provided here
- devs provided a fix here

Please try the patch
Comment 28 Torsten Kaiser 2011-02-10 12:29:20 UTC
(In reply to comment #21)

Not sure, if this is still relevant, but links -g works fine for me. (2.6.38-rc4, xserver-1.9.4 with the GPU-copy-pitch-patch, KDE with compositing disabled)
Comment 29 Alex Deucher 2011-02-10 13:12:23 UTC
*** Bug 33952 has been marked as a duplicate of this bug. ***
Comment 30 Alex Deucher 2011-02-10 22:32:20 UTC
*** Bug 34157 has been marked as a duplicate of this bug. ***
Comment 31 Thierry Vignaud 2011-02-12 03:07:46 UTC
Does the patch is still valid after all the pitch align fixes commits that landed in trunk?
Comment 32 Asbjørn Sannes 2011-02-12 05:09:24 UTC
Patch fixes it for me on:
xorg-server 1.9.4 + patch
xf86-video-ati from git master a9a59717d11af37a2dda5555f6a83c5b65449527.
Comment 33 Thierry Vignaud 2011-02-14 08:08:02 UTC
So can the fix be commited into git ?
Comment 34 Jonas Meurer 2011-02-18 09:51:47 UTC
*** Bug 34452 has been marked as a duplicate of this bug. ***
Comment 35 Arno Schuring 2011-02-20 04:23:19 UTC
*** Bug 34441 has been marked as a duplicate of this bug. ***
Comment 36 Michel Dänzer 2011-02-21 04:26:58 UTC
*** Bug 34521 has been marked as a duplicate of this bug. ***
Comment 37 Michel Dänzer 2011-02-24 03:21:39 UTC
Finally got around to double-checking that this shouldn't cause regressions elsewhere and submitting the fix to the xorg-devel mailing list for review.
Comment 38 Keith Packard 2011-02-24 19:48:28 UTC
Patch merged
Comment 39 Michel Dänzer 2011-03-07 02:27:19 UTC
*** Bug 35035 has been marked as a duplicate of this bug. ***
Comment 40 lenzenmi 2011-03-08 19:01:36 UTC
*** Bug 35075 has been marked as a duplicate of this bug. ***
Comment 41 Fabio Pedretti 2011-05-01 12:19:11 UTC
What about also patching -ati to disable Color Tiling by default when xorg-server < 1.9.4.901 (the first official release with the fix)?

This to workaround the issue when using an old xorg-server with newer -ati, e.g. under Ubuntu 10.10 (it has 1.9.0).
Comment 42 Alex Deucher 2011-11-02 12:16:47 UTC
Created attachment 53075 [details] [review]
check for xserver 1.9.4.901 to enable tiling by default

How about this?  As Michel suggested, a runtime check would probably be better, but I'm not sure how complicated that would be.
Comment 43 Lauri Kasanen 2011-11-03 06:20:23 UTC
*** Bug 42086 has been marked as a duplicate of this bug. ***
Comment 44 Michel Dänzer 2011-11-04 04:19:19 UTC
(In reply to comment #42)
> How about this?  As Michel suggested, a runtime check would probably be better,
> but I'm not sure how complicated that would be.

I pushed your patch and a followup patch to turn it into a runtime check.
Comment 45 Michel Dänzer 2012-01-18 02:04:02 UTC
*** Bug 42058 has been marked as a duplicate of this bug. ***
Comment 46 Michel Dänzer 2012-01-18 02:04:28 UTC
*** Bug 42056 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.