Please cc: any responses to my email address <[email protected]>
My setup
-A standard install of RedHat 7.0 with the 2.2.16smp w/ hand compiled X
4.0.1 to support xinerama
-Tyan tiger 133 s1834 motherboard (VIA Apollo Pro133A Chipset)
-256mb PC133 RAM
-Two 800 Mhz PIII eb Slot-1 CPU's
-Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver
from matrox
My problem
from /var/log/message at startup:
mtrr: v1.35a (19990819) Richard Gooch ([email protected])
<snip>
CPU0: Intel Pentium III (Coppermine) stepping 03
<snip>
CPU1: Intel Pentium III (Coppermine) stepping 03
Total of 2 processors activated (3194.88 BogoMIPS).
<snip>
checking TSC synchronization across CPUs: passed.
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs
and immediately after starting X:
kernel: mtrr: base(0xd4000000) is not aligned on a size(0x1800000) boundary
last message repeated 2 times
and finally:
%cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 64MB: write-combining, count=1
reg02: base=0xd5800000 (3416MB), size= 8MB: write-combining, count=1
I would like to know what, if anything, is wrong and what I can do about it.
Cheers!
/paul
> kernel: mtrr: base(0xd4000000) is not aligned on a size(0x1800000) boundary
> last message repeated 2 times
>
> and finally:
>
> %cat /proc/mtrr
> reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1
> reg01: base=0xd0000000 (3328MB), size= 64MB: write-combining, count=1
> reg02: base=0xd5800000 (3416MB), size= 8MB: write-combining, count=1
I'm seeing the same thing with the Matrox G400.
John
See my answers inline below. /paul
Mark Hahn ([email protected]) said:
> > kernel: mtrr: base(0xd4000000) is not aligned on a size(0x1800000) boundary
>
> X is trying to set an mtrr for the framebuffer. the odd thing
> is that its trying to set a 24M mtrr, which is pretty strange.
> what does /proc/pci look like for the G450?
>
% cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies Unknown device (rev 196).
Vendor id=1106. Device id=691.
Medium devsel. Master Capable. No bursts.
Prefetchable 32 bit memory at 0xd0000000 [0xd0000008].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0).
Medium devsel. Master Capable. No bursts. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies VT 82C596 Apollo Pro (rev 35).
Medium devsel. Master Capable. No bursts.
Bus 0, device 7, function 1:
IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16).
Medium devsel. Fast back-to-back capable. Master Capable. Latency=32.
I/O at 0xe000 [0xe001].
Bus 0, device 7, function 2:
USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 17).
Medium devsel. IRQ 9. Master Capable. Latency=32.
I/O at 0xe400 [0xe401].
Bus 0, device 7, function 3:
Host bridge: VIA Technologies Unknown device (rev 48).
Vendor id=1106. Device id=3050.
Medium devsel. Fast back-to-back capable.
Bus 0, device 17, function 0:
Multimedia audio controller: Ensoniq AudioPCI (rev 0).
Slow devsel. IRQ 9. Master Capable. Latency=32. Min Gnt=12.Max Lat=128.
I/O at 0xe800 [0xe801].
Bus 0, device 18, function 0:
Ethernet controller: Intel 82557 (rev 8).
Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xda100000 [0xda100000].
I/O at 0xec00 [0xec01].
Non-prefetchable 32 bit memory at 0xda000000 [0xda000000].
Bus 1, device 0, function 0:
VGA compatible controller: Matrox Unknown device (rev 130).
Vendor id=102b. Device id=525.
Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=16.Max Lat=32.
Prefetchable 32 bit memory at 0xd4000000 [0xd4000008].
Non-prefetchable 32 bit memory at 0xd6000000 [0xd6000000].
Non-prefetchable 32 bit memory at 0xd7000000 [0xd7000000].
> also, how do you like the G450?
My first impressions of the g450 are spectacular. I know it's not supposed
to be as fast as the dual Nvidia offerings, but I don't play games and Matrox
has always been tops when it comes to text appearance. It's fast as can be
driving two monitors at 1600x1200 and not too expensive to boot. I like it.
> > I would like to know what, if anything, is wrong and what I can do about it.
>
> worst case is that X doesn't get to set the mtrr it wants.
> this may have some performance effect, but no functionality effect.
That's good enough for me!
> regards, mark hahn.
>
On 11 Dec 00 at 14:00, Paul C. Nendick wrote:
> -Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver
> from matrox
Make sure you do not use either matroxfb or XFree's driver... Same chip
ID, but different ramdac :-(
> and immediately after starting X:
>
> kernel: mtrr: base(0xd4000000) is not aligned on a size(0x1800000) boundary
> last message repeated 2 times
For some strange reason X thinks that you have 24MB of memory on the G450.
You can either create 32MB write-combining region at 0xd4000000, or
teach X that your device occupies 32MB and not 24 (you should do it anyway,
region size can be only power of two)...
> and finally:
>
> %cat /proc/mtrr
> reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1
> reg01: base=0xd0000000 (3328MB), size= 64MB: write-combining, count=1
> reg02: base=0xd5800000 (3416MB), size= 8MB: write-combining, count=1
+ reg03: base=0xd4000000 (????MB), size= 32MB: write-combining, count=1
Petr Vandrovec
[email protected]
Petr Vandrovec wrote:
> > kernel: mtrr: base(0xd4000000) is not aligned on a size(0x1800000) boundary
> > last message repeated 2 times
>
> For some strange reason X thinks that you have 24MB of memory on the G450.
> You can either create 32MB write-combining region at 0xd4000000, or
> teach X that your device occupies 32MB and not 24 (you should do it anyway,
> region size can be only power of two)...
Petr, the Matrox card splits the memory between the two video screens
when running in a multi-head configuration and "pretends" that it is two
distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
for 8mb seperately when in this mode.
At line 1190 in arch/i386/kernel/mtrr.c the switch on Intel falls
through hitting the error message for Centaur. I know the comment says
to fall through, but is this correct? I've inserted a break at the end
of the Intel switch before and have not had problems, but I left it out
in the latest couple of kernels because of all the mtrr work being done,
waiting to see if there was resolution.
John
On 12 Dec 00 at 16:07, John Cavan wrote:
> Petr Vandrovec wrote:
> > > kernel: mtrr: base(0xd4000000) is not aligned on a size(0x1800000) boundary
> > > last message repeated 2 times
> >
> > For some strange reason X thinks that you have 24MB of memory on the G450.
> > You can either create 32MB write-combining region at 0xd4000000, or
> > teach X that your device occupies 32MB and not 24 (you should do it anyway,
> > region size can be only power of two)...
>
> Petr, the Matrox card splits the memory between the two video screens
> when running in a multi-head configuration and "pretends" that it is two
> distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> for 8mb seperately when in this mode.
That's wrong. They must first register MTRR and then split it to
24+8, as they cannot register 24MB range. They can split it
16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries -
and there is very limited number of possible MTRRs.
Matroxfb also splits Matrox memory in 24:8, but it registers only one
region in mtrr. Of course, in X, as mtrr registration is done by map
videomemory, you must tell this function to not register mtrr...
Best regards,
Petr Vandrovec
[email protected]
> Petr, the Matrox card splits the memory between the two video screens
> when running in a multi-head configuration and "pretends" that it is two
> distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> for 8mb seperately when in this mode.
That is a driver bug. The intel processors only support MTRR's on certain
power boundaries/sizes. The fall through is intended.
> to fall through, but is this correct? I've inserted a break at the end
> of the Intel switch before and have not had problems, but I left it out
Lucky
> in the latest couple of kernels because of all the mtrr work being done,
> waiting to see if there was resolution.
The Matrox driver needs to register a single 32Mb MTRR
Alan Cox wrote:
> > to fall through, but is this correct? I've inserted a break at the end
> > of the Intel switch before and have not had problems, but I left it out
>
> Lucky
Wouldn't be the first time...
Shall I submit this to Matrox as a bug then?
/paul
Alan Cox ([email protected]) said:
> > Petr, the Matrox card splits the memory between the two video screens
> > when running in a multi-head configuration and "pretends" that it is two
> > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> > for 8mb seperately when in this mode.
>
> That is a driver bug. The intel processors only support MTRR's on certain
> power boundaries/sizes. The fall through is intended.
>
> > to fall through, but is this correct? I've inserted a break at the end
> > of the Intel switch before and have not had problems, but I left it out
>
> Lucky
>
> > in the latest couple of kernels because of all the mtrr work being done,
> > waiting to see if there was resolution.
>
> The Matrox driver needs to register a single 32Mb MTRR
>
--
Paul C. Nendick
" Paul C. Nendick " <[email protected]> writes:
> Shall I submit this to Matrox as a bug then?
The "bug" is in the XFree86 core, so telling Matrox might not do a lot
of good.
The driver code just says "I want to map a framebuffer of this size at
this physical address" (or actually "with these PCI details"), and the
core code arranges the mapping, doing the MTRR stuff while it's at it.
David Wragg
On Tue, 12 Dec 2000, Petr Vandrovec wrote:
> That's wrong. They must first register MTRR and then split it to
> 24+8, as they cannot register 24MB range. They can split it
> 16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries -
> and there is very limited number of possible MTRRs.
>
> Matroxfb also splits Matrox memory in 24:8, but it registers only one
> region in mtrr. Of course, in X, as mtrr registration is done by map
> videomemory, you must tell this function to not register mtrr...
>
> Best regards,
> Petr Vandrovec
> [email protected]
NOW, I am really convinced that we need PAT support on top
of the crappy MTRR driver. :-) I already started working on it...
Regards,
Zoltan Boszormenyi
Alan Cox wrote:
> > Petr, the Matrox card splits the memory between the two video screens
> > when running in a multi-head configuration and "pretends" that it is two
> > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and
> > for 8mb seperately when in this mode.
>
> That is a driver bug. The intel processors only support MTRR's on certain
> power boundaries/sizes. The fall through is intended.
> > in the latest couple of kernels because of all the mtrr work being done,
> > waiting to see if there was resolution.
>
> The Matrox driver needs to register a single 32Mb MTRR
The kernel VESA framebuffer has exactly the same problem. Sometimes
VESA reports 2.5Mb video memory, and vesafb's attempt to register an
MTRR fails.
But should vesafb know about Intel-specific MTRR limitations, given that
those limitations may change?
-- Jamie