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] xorg.log
Created attachment 6148 [details] dmesg output
Created attachment 6149 [details] Kernel configuration
Created attachment 6150 [details] Verbose output from glxinfo
looks like tiling is screwed up. does: Option "ColorTiling" "false" fix it?
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 insmod .../radeon.ko
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.
Frank Kingswood, Do you still experience this issue with newer soft? Please check the status of your issue.
Hi, 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!
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.