> > Doh! You're right of course. Setting it to size (0x1000000) worked
> > fine. That leads me to another two questions if you have the time:
> >
> > My X server has this line for video ram:
> >
> > (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xe4000000, 0xe6000000
> >
> > Does this mean I should have two 8 meg MTRR entries at those base
> > addresses or just ignore the first one?
>
> The part you want a write-combining region for is the frame-buffer. If
> it's not clear from the X server output, there is another way. With X
> running, find the pid of the X server and cat /proc/<pid>/maps. One of
> the entries will be the mmap of the framebuffer, and you can find its
> physical address and exact size.
Looking at the output from cat /proc/<pid>/maps I get this:
08048000-082ed000 r-xp 00000000 16:02 862324 /usr/X11R6/bin/XF86_SVGA
082ed000-08325000 rw-p 002a4000 16:02 862324 /usr/X11R6/bin/XF86_SVGA
08325000-087ae000 rwxp 00000000 00:00 0
40000000-4000a000 r-xp 00000000 16:02 540709 /lib/ld-2.0.7.so
4000a000-4000b000 rw-p 00009000 16:02 540709 /lib/ld-2.0.7.so
4000b000-4000c000 rw-s e4600000 16:02 440787 /dev/mem
4000c000-4000d000 rw-s e4680000 16:02 440787 /dev/mem
4000d000-4000e000 rw-s e4100000 16:02 440787 /dev/mem
4000e000-40010000 rw-s e4002000 16:02 440787 /dev/mem
40010000-40012000 rw-s e4400000 16:02 440787 /dev/mem
40012000-4002a000 r-xp 00000000 16:02 540736 /lib/libm-2.0.7.so
4002a000-4002b000 rw-p 00017000 16:02 540736 /lib/libm-2.0.7.so
4002b000-4002d000 r-xp 00000000 16:02 540733 /lib/libdl-2.0.7.so
4002d000-4002e000 rw-p 00001000 16:02 540733 /lib/libdl-2.0.7.so
4002e000-400bf000 r-xp 00000000 16:02 540724 /lib/libc-2.0.7.so
400bf000-400c7000 rw-p 00090000 16:02 540724 /lib/libc-2.0.7.so
400c7000-400d3000 rw-p 00000000 00:00 0
400d3000-400e3000 rw-s e4710000 16:02 440787 /dev/mem
400e3000-400e4000 rw-s e4101000 16:02 440787 /dev/mem
400e4000-400e5000 rw-s e4009000 16:02 440787 /dev/mem
400e5000-400e6000 rw-s e4000000 16:02 440787 /dev/mem
400e6000-400f6000 rw-s e4800000 16:02 440787 /dev/mem
400f6000-40106000 rw-s 000a0000 16:02 440787 /dev/mem
40106000-41106000 rw-s e6000000 16:02 440787 /dev/mem
41106000-41212000 rw-p 00000000 00:00 0
41224000-41602000 rw-p 0011e000 00:00 0
41606000-42033000 rw-p 00000000 00:00 0
421b4000-42360000 rw-p 00bae000 00:00 0
4247e000-42604000 rw-p 00e78000 00:00 0
4262a000-427d6000 rw-p 01024000 00:00 0
bfff3000-c0000000 rwxp ffff4000 00:00 0
I assume the /dev/mem entries are the mmap of the frame buffer(s)? The
lspci entry for the TNT card is:
01:00.0 VGA compatible controller: Nvidia Corporation: Unknown device 0020 (rev 04)
Subsystem: Unknown device 10b4:273d
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
Memory at e4000000 (32-bit, non-prefetchable)
Memory at e6000000 (32-bit, prefetchable)
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
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. 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. ;)
-Scott
-- Scott Lampert | Home Page: http://www.heavymetal.org <fortunato@heavymetal.org> | PGP Key: finger fortunato@heavymetal.org "Singe the Hare Hare, +----------------------------------------- dance the Hoochie Koo!"
- 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/