Bug 7445 - AMD64+Radeon display corruption
Summary: AMD64+Radeon display corruption
Status: RESOLVED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Default DRI bug account
QA Contact:
URL: http://www.kingswood-consulting.co.uk...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-06 11:47 UTC by Frank Kingswood
Modified: 2019-10-14 13:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Image showing display corruption (21.33 KB, image/png)
2006-07-06 11:48 UTC, Frank Kingswood
no flags Details
xorg.log (56.29 KB, text/plain)
2006-07-06 11:49 UTC, Frank Kingswood
no flags Details
dmesg output (14.33 KB, text/plain)
2006-07-06 11:49 UTC, Frank Kingswood
no flags Details
Kernel configuration (32.42 KB, text/plain)
2006-07-06 11:50 UTC, Frank Kingswood
no flags Details
Verbose output from glxinfo (4.99 KB, text/plain)
2006-07-06 11:50 UTC, Frank Kingswood
no flags Details
dmesg output with agp+drm as module (15.39 KB, text/plain)
2006-07-07 13:45 UTC, Frank Kingswood
no flags Details
syslog on loading drm and radeon modules (4.18 MB, text/plain)
2006-07-07 13:50 UTC, Frank Kingswood
no flags Details
xorg.log with drm and radeon as modules and drm debug (64.98 KB, text/plain)
2006-07-07 13:52 UTC, Frank Kingswood
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Kingswood 2006-07-06 11:47:19 UTC
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.
Comment 1 Frank Kingswood 2006-07-06 11:48:51 UTC
Created attachment 6146 [details]
Image showing display corruption
Comment 2 Frank Kingswood 2006-07-06 11:49:18 UTC
Created attachment 6147 [details]
xorg.log
Comment 3 Frank Kingswood 2006-07-06 11:49:43 UTC
Created attachment 6148 [details]
dmesg output
Comment 4 Frank Kingswood 2006-07-06 11:50:05 UTC
Created attachment 6149 [details]
Kernel configuration
Comment 5 Frank Kingswood 2006-07-06 11:50:30 UTC
Created attachment 6150 [details]
Verbose output from glxinfo
Comment 6 Alex Deucher 2006-07-06 12:06:34 UTC
looks like tiling is screwed up.  does:
Option "ColorTiling" "false"
fix it?
Comment 7 Frank Kingswood 2006-07-07 01:25:35 UTC
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?
Comment 8 Roland Scheidegger 2006-07-07 01:56:43 UTC
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...
Comment 9 Frank Kingswood 2006-07-07 05:48:48 UTC
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.
Comment 10 Frank Kingswood 2006-07-07 13:45:34 UTC
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.
Comment 11 Frank Kingswood 2006-07-07 13:50:32 UTC
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
Comment 12 Frank Kingswood 2006-07-07 13:52:52 UTC
Created attachment 6161 [details]
xorg.log with drm and radeon as modules and drm debug
Comment 13 Michel Dänzer 2006-07-17 03:21:42 UTC
(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.
Comment 14 Frank Kingswood 2006-07-17 03:25:47 UTC
(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.
Comment 15 chemtech 2013-03-15 08:10:50 UTC
Frank Kingswood,
Do you still experience this issue with newer soft?
Please check the status of your issue.
Comment 16 Martin Peres 2019-10-14 13:20:20 UTC
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.