![](https://seccdn.libravatar.org/avatar/237232642d1b6701c01629d00f14dc8e.jpg?s=120&d=mm&r=g)
Looks like a DFS related problem. does disabling it help? Option "EXANoDownloadFromScreen"
I had some time to do some more testing; here's what I found: Without the EXANoDownloadFromScreen option in MythTV: - Corruption occurs randomly on it's own. Usually difficult to predict. Leaving/reentering MythTV usually clears it up temporarily. - While in MythTV, switching to a text console and back again reliably creates corruption in the icons at the bottom of the screen. With the EXANoDownloadFromScreen option I still get xdm login screen brokeness, but I have yet to see a single artifact in MythTV, even when switching back and forth between text console and X repeatedly. So, I think this option is definitely helping. There's still the issue with xdm, but I'm not stressing over it. Now, I should also mention some kernel messages I'm getting... [ 227.050824] [drm] Initialized radeon 1.30.0 20080528 for 0000:03:00.0 on minor 0 [ 227.051632] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 227.171260] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 227.171310] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 227.171344] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 227.205172] [drm] Setting GART location based on new memory map [...] [17335.748010] [drm] Resetting GPU [17335.774315] mtrr: no MTRR for d0000000,10000000 found [17335.919519] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [17335.919556] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [17335.979233] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [17335.979261] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [17335.979281] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [17335.981313] [drm] Setting GART location based on new memory map (these repeat every few minutes) Should I be messing around with "fixes" like: http://ubuntuforums.org/showthread.php?t=115104 Or should I report the issue to the kernel folks? Perhaps bug my mobo manufacturer for a bios fix? Not sure who might be at fault... My early MTRR related kernel messages are: [ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) [ 0.000000] last_pfn = 0x1c0000 max_arch_pfn = 0x100000000 [ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF uncachable [ 0.000000] C0000-CFFFF write-protect [ 0.000000] D0000-DFFFF uncachable [ 0.000000] E0000-E3FFF write-protect [ 0.000000] E4000-EFFFF write-through [ 0.000000] F0000-FFFFF write-protect [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 1C0000000 mask FC0000000 uncachable [ 0.000000] 1 base 000000000 mask E00000000 write-back [ 0.000000] 2 base 0C0000000 mask FC0000000 uncachable [ 0.000000] 3 base 0BF800000 mask FFF800000 uncachable [ 0.000000] 4 disabled [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled Thanks much, tim -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org