Messages in this thread | | | Date | Sat, 13 Mar 1999 11:41:45 -0800 (PST) | From | Jeremy Fitzhardinge <> | Subject | Re: MTRR & NVTNT |
| |
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/
| |