Re: MTRR & NVTNT

Jeremy Fitzhardinge (jeremy@goop.org)
Sat, 13 Mar 1999 11:41:45 -0800 (PST)


On 12-Mar-99 Scott Lampert wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> informed me that I should ignore
> the 0xe4000000 range since its marked un-prefetchable and is likely IO
> registers.
>
> Before all this wealth of information I was using something like:
>
># echo "base=0xe6000000 size=0x1000000 type=write-combining" >! /proc/mtrr
># echo "base=0xe4000000 size=0x1000000 type=write-combining" >! /proc/mtrr
>
> and this messed my video. So I added:
>
># echo "base=0xe4000000 size=0x1000000 type=uncacheable" >! /proc/mtrr

It shouldn't be necessary to do this - the CPU will do the right thing with PCI
bus cycles on its own. I simply have

if [ -n "`/sbin/lspci -d 10de:0020`" ]; then
echo 'base=0xe6000000 size=0x1000000 type=write-combining' >/proc/mtrr
fi

in my /etc/rc.local, and its been working well for months. By "ignore
the memory at 0xe4000000", I mean exactly that - just don't put any mtrr
entry for it.

I think the Riva TNT cards *do* have a full 16MB of video memory.
Only some of it may be frame store, depending on the resolution etc, but
the rest is used for off-screen pixmaps. If VESA reports only 15MB of
video memory, it probably only means framebuffer and ignores the other
things you can do with the memory. The X server can make us of it all
(off-screen pixmaps, windows, font cache, etc).

> This seemed to fix the problem and everything seemed to work ok,
> but I'm pretty sure this is just plain wrong, especially since the
> card only has 16 megs, not 32 and looking at the /proc/<pid>/maps the
> e4000000 range seems to be broken up.

The stuff at 0xe4000000 is not RAM, its probably just memory-mapped control
registers. A card can take up 32MB of address space but only have 16MB of RAM.

> Then I got e-mail from you and Jeremy and I switched my settings
> to
> your suggestion as per the vesa fb results:
>
># echo "base=0xe6000000 size=0x1000000 type=write-combining" >! /proc/mtrr
># echo "base=0xe6ff0000 size=0x10000 type=uncachable" >! /proc/mtrr
>
> This also seems to work ok. I'm still confused as to the "right"
> setting for these and mostly for what the card is actually using as
> the frame buffer. It seems to map a lot of address spaces all over the
> place. And I'm no longer certain if its using one large frame buffer,
> or a chopped up one as Alan Cox suggested it might in a prior e-mail
> to me. The e6000000 seems to be contiguous so I'm assuming thats the
> actual frame buffer. Beats me what the other address is for then. I
> guess I'm getting in over my head now. ;)

It's probably all video memory, but the X server maps it in chunks depending on
what its using each chunk for. That will depend on your video modes and what
ever else you've been using the X server for.

X -probeonly will tell you where and how much video memory the X server found,
and you should just use that for your MTRR setting. I hope the X server will
set its own MTRR soon and avoid all this confusion.

J

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/