I am having display corruption when using (any) OpenGL application with
hardware rendering on a Radeon 9250 card and an AMD64 CPU.
Somehow, horizontal lines of 64 pixels get scattered accross the screen, instead
of placed in columns neatly side by side.
In glxgears, the first (64-border_width) pixels are in the right place. The next
128 pixels to the right are not drawn. Then there are 64 more pixels that belong
under the first 64. Another 128 undrawn pixels and then there are more drawn.
For your convenience and enjoyment I have captured an image that shows the top
400 pixels of a 1600x1200 screen with glxgears running.
This problem occurs only when running the x86_64 kernel, the system is
fine with the i386 kernel. This issue is not a (recent) regression but
has been present in all recent versions of xorg+kernels that I have tried.
Created attachment 6146 [details]
Image showing display corruption
Created attachment 6147 [details]
Created attachment 6148 [details]
Created attachment 6149 [details]
Created attachment 6150 [details]
Verbose output from glxinfo
looks like tiling is screwed up. does:
Option "ColorTiling" "false"
Yes, that fixes it, thanks!
If this is a known or indeed unknown bug in the radeon/dri driver, is there
something I can do to help debug it?
this is odd, it's almost as if the dri driver never gets told that tiling is
enabled. You could try loading drm with debug parameter to maybe see a bit more
what's going on. At first sight it looks like a 64bit kernel / 32bit userspace
problem but afaik all of these problems got fixed. But there is another oddity
in your logs, in xorg log it tells it's using the new memory map param but in
kernel it's saying it's not using it (Setting GART location based on old memory
map) - this should be impossible to happen...
Cheered too soon :-(
Of course glxgears is fine as far as it goes, but is not really part of my
normal work flow.
My machine now completely locks up the kernel when I try to run googleearth.
Yes, perhaps not an ideal application, but it was nearby.
I'll recompile my kernel with drm as a module, load it with debug=1 and post logs.
Created attachment 6159 [details]
dmesg output with agp+drm as module
Recompiled the kernel with agp, drm, and radeon as modules.
Same kernel config as #6149 above except for these modules.
Created attachment 6160 [details]
syslog on loading drm and radeon modules
This section of /var/log/syslog is from loading DRM through starting X, running
glxgeards to closing down X again (long).
Modules loaded as:
insmod .../drm.ko debug=1
Created attachment 6161 [details]
xorg.log with drm and radeon as modules and drm debug
(In reply to comment #8)
It can happen with Option "UseFBDev", but that doesn't seem the case here.
Really smells like a 32 on 64 bit issue. You could try booting a 32 bit kernel
to confirm that.
(In reply to comment #13)
> Really smells like a 32 on 64 bit issue. You could try booting a 32 bit kernel
> to confirm that.
Yes, it is fine when I'm running a 32-bit kernel.
Do you still experience this issue with newer soft?
Please check the status of your issue.
Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated to http://gitlab.freedesktop.org.
To avoid migrating out of date bugs, I am now closing all the bugs that did not see any activity in the past year. If the issue is still happening, please create a new bug in the relevant project at https://gitlab.freedesktop.org/drm (use misc by default).
Sorry about the noise!