0x9490:0x1787:0x2003: HIS H467QSS1GP Radeon HD 4670 1GB
Hello, I have been using this unrecognized card for a week or so, initially with no 2D acceleration, and more recently I got the EXA acceleration working. However, after that, I started to notice some visual artifacts. When I first start xdm I see: http://sentinelchicken.org/data/images/p1010076.jpg While using Mythtv, I most often get small artifacts showing up on icons: http://sentinelchicken.org/data/images/p1010072.jpg http://sentinelchicken.org/data/images/p1010073.jpg http://sentinelchicken.org/data/images/p1010074.jpg Though sometimes also on specific font characters: http://sentinelchicken.org/data/images/p1010075.jpg The artifacts vary over time and are never the same, though they seem to get worse over time on a particular X session. I also see artifacts at the top of the screen while using MAME, but I'm not convinced it's an issue with the radeonhd driver. This issue isn't a critical one for me right now, but since my card isn't recognized, I thought I should submit my info. I should also draw your attention to a couple of items in my X log: (II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Using only 262144kB of the total 1048576kB. (--) RADEONHD(0): VideoRAM: 262144 kByte [...] (II) RADEONHD(0): Start of VRAM area used by Firmware: 0xfffec (II) RADEONHD(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEONHD(0): AtomBIOS VRAM scratch base: 0xfffec (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x104fec VRAM End: 0x10000000 (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory instead [...] (**) RADEONHD(0): Using AtomBIOS for Outputs (II) RADEONHD(0): FUNCTION: RHDAtomOutputInit (II) RADEONHD(0): FUNCTION: RHDHdmiInit (EE) RADEONHD(0): RHDHdmiInit: unknown HDMI output type [...] Anything I should be wary of in all of that? I may want to use HDMI in the future (through a DVI->HDMI adapter that came with the card), so will that error be a show stopper? Here's my system specs: dionysis:~# uname -a # Custom kernel's .config available upon request Linux dionysis 2.6.30 #1 SMP Wed Jul 22 21:46:29 PDT 2009 x86_64 GNU/Linux dionysis:~# dpkg -l | grep radeonhd ii xserver-xorg-video-radeonhd 1.2.5-1 X.Org X server -- AMD/ATI r5xx, r6xx display I'm running Debian sid (unstable). Please find attached my lspci output for this card, my X config and verbose log, and also the xrandr and xvinfo output. If there's anything else I can provide, or if I should post this info elsewhere, please let me know. Thanks, tim
Tim wrote:
Hello,
I have been using this unrecognized card for a week or so, initially with no 2D acceleration, and more recently I got the EXA acceleration working. However, after that, I started to notice some visual artifacts. When I first start xdm I see: http://sentinelchicken.org/data/images/p1010076.jpg
While using Mythtv, I most often get small artifacts showing up on icons: http://sentinelchicken.org/data/images/p1010072.jpg http://sentinelchicken.org/data/images/p1010073.jpg http://sentinelchicken.org/data/images/p1010074.jpg
Though sometimes also on specific font characters: http://sentinelchicken.org/data/images/p1010075.jpg
The artifacts vary over time and are never the same, though they seem to get worse over time on a particular X session. I also see artifacts at the top of the screen while using MAME, but I'm not convinced it's an issue with the radeonhd driver.
This issue isn't a critical one for me right now, but since my card isn't recognized, I thought I should submit my info. I should also draw your attention to a couple of items in my X log:
(II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Using only 262144kB of the total 1048576kB. (--) RADEONHD(0): VideoRAM: 262144 kByte [...] (II) RADEONHD(0): Start of VRAM area used by Firmware: 0xfffec (II) RADEONHD(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEONHD(0): AtomBIOS VRAM scratch base: 0xfffec (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x104fec VRAM End: 0x10000000 (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory instead [...] (**) RADEONHD(0): Using AtomBIOS for Outputs (II) RADEONHD(0): FUNCTION: RHDAtomOutputInit (II) RADEONHD(0): FUNCTION: RHDHdmiInit (EE) RADEONHD(0): RHDHdmiInit: unknown HDMI output type [...]
Anything I should be wary of in all of that? I may want to use HDMI in the future (through a DVI->HDMI adapter that came with the card), so will that error be a show stopper?
Here's my system specs:
dionysis:~# uname -a # Custom kernel's .config available upon request Linux dionysis 2.6.30 #1 SMP Wed Jul 22 21:46:29 PDT 2009 x86_64 GNU/Linux dionysis:~# dpkg -l | grep radeonhd ii xserver-xorg-video-radeonhd 1.2.5-1 X.Org X server -- AMD/ATI r5xx, r6xx display
I'm running Debian sid (unstable). Please find attached my lspci output for this card, my X config and verbose log, and also the xrandr and xvinfo output.
If there's anything else I can provide, or if I should post this info elsewhere, please let me know.
Thanks, tim
Sounds like overlapping memory issue. Main memory is being used in video memory space? Have you tried the *gasp* ATI Catalyst driver. Does it artifact as well? Gary -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Gary, Thanks for the quick reply.
Sounds like overlapping memory issue. Main memory is being used in video memory space?
Have you tried the *gasp* ATI Catalyst driver. Does it artifact as well?
Well, when I was having difficulty with 2D acceleration earlier, I did try fglrx a few times, but I never got it working at all. I didn't try very hard, because I much prefer radeon or radeonhd. I've fought with the proprietary nvidia module for a long time and fglrx has been even more painful in my experience, so I've been trying to avoid it. I can wrestle with it more if you think that would be helpful. thanks, tim -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Wed, Jul 29, 2009 at 7:39 PM, Tim
Hello,
I have been using this unrecognized card for a week or so, initially with no 2D acceleration, and more recently I got the EXA acceleration working. However, after that, I started to notice some visual artifacts. When I first start xdm I see: http://sentinelchicken.org/data/images/p1010076.jpg
While using Mythtv, I most often get small artifacts showing up on icons: http://sentinelchicken.org/data/images/p1010072.jpg http://sentinelchicken.org/data/images/p1010073.jpg http://sentinelchicken.org/data/images/p1010074.jpg
Though sometimes also on specific font characters: http://sentinelchicken.org/data/images/p1010075.jpg
The artifacts vary over time and are never the same, though they seem to get worse over time on a particular X session. I also see artifacts at the top of the screen while using MAME, but I'm not convinced it's an issue with the radeonhd driver.
Looks like a DFS related problem. does disabling it help? Option "EXANoDownloadFromScreen" Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Alex, Thanks for the quick reply.
Looks like a DFS related problem. does disabling it help? Option "EXANoDownloadFromScreen"
I added this to my Device section and I still get the corruption happening on the xdm login screen, but I have yet to see it in mythtv. I've tried opening/closing myth, playing video on multiple formats and opening/closing Mame as well, then returning to myth a number of times. So far so good on the font/icon artifacts. I'll post back here if I see them showing up again there. I should also mention that the xdm artifact clears up if I switch to the text console and then back again. Restarting xdm, or even just logging out of my X session causes it to come back again though. I've not tried clearing up the font/icon artifacts with the text console trick yet, but if they show up again, I'll test that. cheers, tim -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
Tim wrote:
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 [...]
Thanks much, tim
Are your mtrrs set correctly? cat /proc/mtrr You should see something like this for your video card. reg01: base=0x0d0000000 ( 3328MB), size= 256MB, count=1:write-combining and something like that for your main memory. reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (3)
-
Alex Deucher -
GS Hunt -
Tim