| Summary: | AMD64+Radeon display corruption | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Frank Kingswood <frank> | ||||||||||||||||||
| Component: | General | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||
| Priority: | high | CC: | airlied | ||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||||
| URL: | http://www.kingswood-consulting.co.uk/frank/dri/ | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
|
Description
Frank Kingswood
2006-07-06 11:47:19 UTC
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.