fglrx lagging - mtrr table looks bad

mcover · 2008-09-11 22:22:12

Hi,

since a recent upgrade (sorry, I can't tell which one exactly) whenever I try to run an application with 3d-acceleration the video-ouput lags like crazy. Sometimes I even think my system froze, but then after 20 seconds it continues.

After searching for solutions to the problem, I came across a lot of people experiencing similar issues, but with 4GB ram and more and on 64bit systems.

I'm running on an Asus M51SE Laptop with Ati/Amd Radeon HD 3470, 3GB Ram on 32bit Arch. Shouldn't be an issue, however, this is where the trouble started. I had to set a kernel-parameter, in order to be able to start X at all. Using mem=2900M I've been quite happy until I noticed the lags.

dmesg|tail shows me this right after starting X

[fglrx] Reserved FB block: Shared offset:0, size:1000000 
[fglrx] Reserved FB block: Unshared offset:ff7b000, size:80000 
[fglrx] Reserved FB block: Unshared offset:fffc000, size:4000

Which, after pasting some lines of it, lead me to sites suggesting that the mtrr should be fixed.

My mtrr looks like this right now:

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1

lspci -v (Radeon section)

01:00.0 VGA compatible controller: ATI Technologies Inc Mobilitiy Radeon HD 3400 Series (prog-if 00 [VGA controll
er])
        Subsystem: ASUSTeK Computer Inc. Device 19d3
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at a000 [size=256]
        Memory at fdef0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fdec0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: fglrx_pci
        Kernel modules: fglrx

From which I concluded that I should try adding my 256MB Video Ram to mtrr:

echo "base=0xC0000000 size=0x10000000 type=write-back" >| /proc/mtrr

After trying that and testing if the lags were still there, I came to conclusion that it didn't help. Lags are still there, no idea if there are more or less lags, but what I can say is that movies are still unwatchable.

If anyone has some ideas, I'd be glad to hear them.

Thanks!

ras0ir · 2008-09-12 03:44:53

you can try adding nopat to kernel line in grub's menu.lst:

Here's an example:

# (1) Arch Linux
title  Archlinux Ice Kernel
root   (hd0,1)
kernel /boot/vmlinuz26-ice root=/dev/sda2 ro resume=/dev/sda3 quiet splash nopat
initrd /boot/kernel26-ice.img

I dont know what exactly it does, however, it works.

Cosay · 2008-09-12 12:34:38

Agreed. It fixed issues that I was having with my HD3450.

mcover · 2008-09-12 20:52:11

Neat. It seems to work. Thank you.

Still wondering why the Vid-Mem doesn't show up in mtrr. Hope its normal.

beissemj · 2008-09-12 23:41:17

Glad you got the problem fixed, that's what the forums are for.

It looks like you probably updated your kernel and your laptop is not liking the recent work done to implement PATs.

PAT (Page Attribute Table) is a feature found in x86 processors that allows for setting the memory attribute at the page level granularity. PAT is complementary to the MTRR settings which allows for setting of memory types over physical address ranges. However, PAT is more flexible than MTRR due to its capability to set attributes at page level and also due to the fact that there are no hardware limitations on number of such attribute settings allowed. It's not a very new feature: the Linux support for this has been in the works for a long time: the current patches are evolved from ones started in 2006, and there're traces of preliminary patches in 2001. Probably because it's not a critical feature and MTRRs did the job.

In other words the lag you are experiencing is actually a CPU caching problem, the -nopat (early) kernel parameter says to ignore PAT and just mtrr, which is why it fixes your problem.

Aside: I find it strange that you are having this problem, as it is typically a 64bit problem...

Cosay · 2008-09-13 14:52:55

beissemj wrote:

Glad you got the problem fixed, that's what the forums are for.
It looks like you probably updated your kernel and your laptop is not liking the recent work done to implement PATs.
PAT (Page Attribute Table) is a feature found in x86 processors that allows for setting the memory attribute at the page level granularity. PAT is complementary to the MTRR settings which allows for setting of memory types over physical address ranges. However, PAT is more flexible than MTRR due to its capability to set attributes at page level and also due to the fact that there are no hardware limitations on number of such attribute settings allowed. It's not a very new feature: the Linux support for this has been in the works for a long time: the current patches are evolved from ones started in 2006, and there're traces of preliminary patches in 2001. Probably because it's not a critical feature and MTRRs did the job.
In other words the lag you are experiencing is actually a CPU caching problem, the -nopat (early) kernel parameter says to ignore PAT and just mtrr, which is why it fixes your problem.
Aside: I find it strange that you are having this problem, as it is typically a 64bit problem...

I believe this issue started when Catalyst 8.8 was released, as I did not have this issue with 8.7. I was lucky in that someone else on these forums knew how to fix my problem.

pedepy · 2008-09-21 23:23:11

yep .. nopat fixed it here too.

and indeed, the problem seems to stem from catalyst rather than just the kernel itself, as using any other driver doesnt produce the hiccups. Ive checked my processes and, here anyway, X would hog 50-75% of the CPU for a couple seconds, causing the halts. It wasnt just during video playback either, althought that was when it was more noticeable.

Also it seemed to get worse with time, video playback provoking the fastest 'rise' in the frequency of the hangs. Maybe a memory leak issue or something, who knows..

Anyway, seems like 8.8 does not play well with 2.6.26. Problem is, it won't seem to compile with any other kernel either.

arsenist · 2008-10-01 20:21:32

Hey !

I had the same problem after a full system update, and "nopat" did the trick !
You guys are awesome ! Thanks.

Arch Linux

#1 2008-09-11 22:22:12

fglrx lagging - mtrr table looks bad

#2 2008-09-12 03:44:53

Re: fglrx lagging - mtrr table looks bad

#3 2008-09-12 12:34:38

Re: fglrx lagging - mtrr table looks bad

#4 2008-09-12 20:52:11

Re: fglrx lagging - mtrr table looks bad

#5 2008-09-12 23:41:17

Re: fglrx lagging - mtrr table looks bad

#6 2008-09-13 14:52:55

Re: fglrx lagging - mtrr table looks bad

#7 2008-09-21 23:23:11

Re: fglrx lagging - mtrr table looks bad

#8 2008-10-01 20:21:32

Re: fglrx lagging - mtrr table looks bad

Board footer