[gentoo-amd64] mtrr: base is not aligned

[gentoo-amd64] mtrr: base is not aligned

[Mark Knecht]

Hi,
   Is anyone else seeign these troubling messages from tie to time?

mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining

   Is there somethign I should be doing to fix this?

Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: mtrr: base is not aligned

[Duncan]

Mark Knecht posted
<5bdc1c8b0510151118p447b72a9la959017a0de1dd08@mail.gmail.com>, excerpted
below,  on Sat, 15 Oct 2005 11:18:12 -0700:

>    Is anyone else seeign these troubling messages from tie to time?
> 
> mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining 
> mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> 
>    Is there somethign I should be doing to fix this?

You may well know more about this than I do, but on the off chance this
may be new to you and for others... (and because I'm googling and learning
a bit in the process myself... =8^)

mtrr=memory type range (or region) register.  This is definitely kernel
domain we are talking about here, often video drivers (so xorg related as
well).

Here's a link to an old but decently "Engish" explanation of what MTRRs
are that doesn't get too technical, but gives you some idea of not only
what the theory does, but the effects on real-world performance. (It's
talking PentiumPro/PII CPUs and kernel 2.2.0 or later... I /said/ it was
old! =8^)

http://www.meduna.org/txt_mtrr_en.html

Paraphrasing from the above link...

Basically, the MTRRs determine the behavior of cache vs regular memory on
memory-write, for various memory regions/ranges.

* Write-thru means the write is to cache and main memory together, slower
than Write-back or Write-combining below but most reliable as any DMAs
from main memory are guaranteed to be up-to-date.

* Write-back is far faster, allowing the CPU to write to cache only then
go about its business, with the update to main memory happening as memory
bandwidth permits.  The catch is that cache (play on words there! <g>) and
main memory can be out of sync momentarily, which could mean either longer
waits for the update to happen when it /has/ to happen (if everything is
working right and the out-of-date-data is caught and a wait forced until
it's updated to valid data when needed), or in the worst-case scenario, if
something's not quite working right, glitches, instability and crashes
because old and invalid data was used where updated data was expected.

* Write-combining is sort of in-between the two above choices.  The data
is allowed to sit in cache without updating main memory only a
comparatively short period, in ordered to allow the possibility of
combining several smaller writes into a larger, single, more efficient
write.  (More efficient because each write has a set amount of overhead in
setup and take-down time and data.  Thus, combining 8 128-byte
transactions into a single 1KB transaction means 1/8 the overhead, thus
more effective payload bandwidth, at a cost of more latency, due to
waiting for several transactions to accumulate, provided of course they
come in before the expiry time forces what's there to be written even if
it's not yet a full size transfer.)

* There's also uncachable, which turns off caching for reads as well as
writes.  This will be /very/ slow.

Where graphics gets involved is that these MTRRs are often used to program
access to video memory over the AGP or whatever bus.  The link above lists
some of the (then) xfree86 operations that MTRR settings affect and by how
much.

Another link with some interesting info on the kernel config option
(CONFIG_MTRR) and the userland interface to MTRRs (/proc/mtrr) once
enabled.  The two paragraphs below are excerpted:

http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/mtrr.txt

The CONFIG_MTRR option creates a /proc/mtrr file which may be used to
manipulate your MTRRs. Typically the X server should use this. This should
have a reasonably generic interface so that similar control registers on
other processors can be easily supported.

There are two interfaces to /proc/mtrr: one is an ASCII interface which
allows you to read and write. The other is an ioctl() interface. The ASCII
interface is meant for administration. The ioctl() interface is meant for
C programs (i.e. the X server). The interfaces are described below, with
sample commands and C code.

</quote>

Finally, this, on the mtrr_add command from kernelnewbies:

http://kernelnewbies.org/documents/kdoc/kernel-api/r7666.html

Memory type region registers control the caching on newer Intel and non
Intel processors. This function allows drivers to request an MTRR is
added. The details and hardware specifics of each processor's
implementation are hidden from the caller, but nevertheless the caller
should expect to need to provide a power of two size on an equivalent
power of two boundary.

If the region cannot be added either because all regions are in use or
the CPU cannot support it a negative value is returned. On success the
register number for this entry is returned, but should be treated as a
cookie only. On a multiprocessor machine the changes are made to all
processors. This is required on x86 by the Intel processors. The
available types are

MTRR_TYPE_UNCACHABLE - No caching

MTRR_TYPE_WRBACK - Write data back in bursts whenever

MTRR_TYPE_WRCOMB - Write data back soon but allow bursts

MTRR_TYPE_WRTHROUGH - Cache reads but not writes

</quote>

That last contains a mention of boundaries ("power of two size on an
equivalent power of two boundary") that appears to pertain to your
problem.

So... now we know a bit about what MTRRs actually do (control the
interaction between cache and a specified portion of memory for write
transactions), what they are most often adjusted for (to increase graphics
performance, by changing the way writes to graphics memory are cached),
and can make a bit of sense out of the messages (the size doesn't match
the required base address for the MTRR, something's trying to change the
caching method, but using the wrong address and the adjustment is
therefore getting a type mismatch).

How does that translate into something you can do to fix it?

Well, first, you can actually go take a look at /proc/mtrr (don't try to
write anything to it, unless you are sure you know what you are doing, but
reading it should be fine), and see if you can figure out which entry it's
supposed to be changing, if there's one close to that address at all, or
if not, what needs created.

Beyond that, it depends on what is actually using the MTRR.  It's probably
your video card driver, but it could be something else.  You don't say
which card you have, but from the googling I did to find the above, I see
that ATI's proprietary drivers at least, have posts about changing MTRRs
to increase performance.  Whatever your video card driver is, that's
probably (but not for certain) what's causing the log messages. 
Therefore, take a look at /var/log/Xorg.0.log, and see if you can match up
any possible MTRR messages listed there.

Next, take a look at the driver documentation and your xorg.conf file
and boot loader config, and see what sort of adjustments you might need to
make.

Of course, if it's /not/ video driver related, you'll likely have to
figure out what else is accessing the MTRRs and how to reconfigure it
correctly.  Taking a wild guess, I'd say check anything that's likely to
be using  DMA, thus, stuff like NICs or storage devices, and their drivers.

Oh, MTRRs are also used in connection with mapping around the PCI device
memory hole just below 4GB, if you have 4G or more of memory.

Hmm...  Now I'm beginning to integrate what I just learned here, with some
other stuff I just read, with stuff I knew before, and a real-time look
at /proc/mtrr on my system... and things are beginning to "click".  You
get to see my understanding developing as I write this!  <g>

>From an Opteron BIOS integrator's pdf @ amd... they recommend one of the
variable MTRRs (there are some fixed ones covering the memory space from
640k to 1 MB as well, that must be what those common settings in BIOS must
be for) be set to cover the entire physical memory range... And so I
see... I have a gig of memory and see a 1024 MB MTRR set @ base-address
0x 0000 0000 (0 MB), type write-back (so read/write cacheable). That makes
sense as it's telling the CPU(s, 2 in my case) that all of my main memory
is fully cacheable, no special restrictions needed!

Apparently, some CPUs only have two variable MTRRs, and if one is used to
cover all of physical main-memory, that leaves only one available, which
would be used by the video driver, so that's how Linux is normally setup. 
Again apparently, modern x86 (and presumably x86_64 as well) CPUs from
both AMD and Intel have eight such MTRRs, so more ranges can be programed
as needed.

Now this is just a guess based on the fixed MTRs (memory type ranges, I'm
using MTRR to reference the register, MTR to reference the range in
memory it controls, here referring to the previously mentioned fixed range
MTRRs/MTRs between 640k and 1M) being included in the main-mem variable
range, and variable MTRs within other variable MTRs might not work quite
the same (tho I expect they do), but going on that... smaller ones in
larger ones can act as exceptions.

That would explain the BIOS MTRR setting in many AMD64 systems for > 3.5
GB physical memory -- continuous or explicit hole for the 3.5 - 4 GB
(0x e000 0000 - 0x ffff ffff) top-of-32-bit-memory-space PCI hole.  The
continuous option will map the entire X GB of memory as a single MTR,
presumably (presumably since I've never run > 4 GB myself, and I'm making
connections faster than I could look them up to verify them) with
additional MTRs such as the video memory one overlaid on top of it, in the
3.5-4.0 GB PCI device space. Non-contiguous or explicit-hole would map an
explicit hole to the 3.5-4 GB area.  Note that this would map additional
memory up above the 4 GB 32-bit barrier, out of reach of most 32-bit
systems, explaining some comments on forums.amd.com I was reading.  If
this isn't handled correctly, even 64-bit systems won't see all their
memory if it's more than 3.5 GB, since part of it will be hidden by the
PCI device overlay 3.5 - 4.0 GB.

Note that at least here (Tyan s2885 dual Opteron board), the BIOS actually
has two related settings controlling the way > 3.5 GB of physical memory
is mapped.  One apparently controls the actual memory addresses, whether
they skip the 3.5-4 GB range or not, the other controls the MTRRs,
continuous or not.  If the two don't match, it could mean all of memory is
seen but not all of it is marked as cacheable, slowing access to the
uncached memory range.

...  Another leap of understanding...  Remember those ranges need to be in
power-of-2 sizes and on matching power-of-2 boundaries?  I happen to have
a gig of memory, an even power of two, so one MTR covers it exactly. 
That wouldn't work for those with 3/4 gig or 1.5 or 3 gig or some such. 
OTOH, I noticed a count=1 at the end of the two ranges I have mapped in my
/proc/mtrr, so it would appear that could be remedied by using say 3
half-gig MTRs (count=3) stacked end-to-end, or a 1 gig and a half gig
(thus two), to map that 1.5 gig area.  I'm not sure if the count= would
mean it's using additional MTRRs or not, tho I'd expect it would indeed
mean that.  Thus, non-power-of-two memory layouts will probably mean more
MTRRs used to map the full memory MTR.

(If there's anyone with an odd amount of memory that could verify, it'd be
nice...)

My second MTRR is set to cover the 128 MB range dedicated to my video card
(it's got 256 MB but on 128 MB is being used, it would appear, but it's no
big deal since I don't do much 3D anyway because I'm running dual head
video @ 2048x1536 each).  Here, it's the 128 MB beginning at exactly 3.5
MB base address (0x e000 0000), write combining.

OK...  0x e000 0000 is the 3.5 GB boundary, so your 0x e802 0000 is indeed
in the PCI device area... 0x 800 0000 is 128 MB, 0x 2 0000 is 8 KB, so the
base address it's attempting to use is 3.5 GB + 128 MB + 8 KB.  The
requested size is 0x 40 0000 or 4 MB, so the closest boundary would be the
0x e800 0000 you see it trying for and getting the type mismatch.

Note also that the AMD docs say disable caching (which would mean flush
all pending writes) before making other MTRR changes, also.  

What I'd guess is happening here, then, is that these errors are occurring
when you start X, and the graphics video driver tries to overlay a
write-combining MTRR over top of (part of) the previously mapped
write-back MTRR covering all of main-memory (which would appear to be 4GB
or better, thus overlapping the 3.5-4.0 GB PCI device area).  They will
mean problems with the video rendering, either glitches or not as fast as
it could be.  (Write-back being less strict than write-combining, I'm
thinking it could mean glitches, whenever the video card tries to draw
memory that's not current with that in cache.  However, it may not appear
except under heavy 3D use, such as in games.)

If that's the case, in addition to the MTRR remapping you may do either
from your boot scripts or by reconfiguring your graphics card driver in
xorg.conf, you may have to reset your BIOS' MTRR settings to specifically
map out the pci-area hole.

That's about all I have ATM...  Hope this is as informative for others as
it just was for me!  <g>  (And, if anyone's an expert on this stuff and I
got it wrong, please inform me where!  Better to correct any mistakes I
have now while it's new than after I build a bunch more suppositions on a
faulty foundation!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: mtrr: base is not aligned

[Mark Knecht]

On 10/16/05, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted
> <5bdc1c8b0510151118p447b72a9la959017a0de1dd08@mail.gmail.com>, excerpted
> below,  on Sat, 15 Oct 2005 11:18:12 -0700:
>
> >    Is anyone else seeign these troubling messages from tie to time?
> >
> > mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> > mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> > mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> > mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> > mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> > mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> > mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> > mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> > mtrr: base(0xe8020000) is not aligned on a size(0x400000) boundary
> > mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
> >
> >    Is there somethign I should be doing to fix this?
>
> You may well know more about this than I do, but on the off chance this
> may be new to you and for others... (and because I'm googling and learning
> a bit in the process myself... =8^)

Duncan,
   Great post. I'm getting some really good stuff out of it.

   Time to fess up. Based on reading this and looking again this
morning I'm embarrassed to say that the machine that is failing is
actually an Intel P4HT machine, not an AMD64 machine. I do have an
AMD64 machine and I guess I blanked out at the moment I sent the
email. None the less I think the topic is valuable on either list and
I cannot imagine getting a more detailed and comprehensive response
from anyone. Thanks!
>
> mtrr=memory type range (or region) register.  This is definitely kernel
> domain we are talking about here, often video drivers (so xorg related as
> well).

Yes, this I knew. Until reading you post I thought it was only used
for video memory, and from my hardware background (PC chipset/AGP
stuff some years ago) specifically with write-combining. I see that it
really can have more wide ranging uses.
<SNIP>
>
> http://www.meduna.org/txt_mtrr_en.html
>
> Paraphrasing from the above link...
>
> Basically, the MTRRs determine the behavior of cache vs regular memory on
> memory-write, for various memory regions/ranges.
>
<SNIP>
>
> * Write-combining is sort of in-between the two above choices.  The data
> is allowed to sit in cache without updating main memory only a
> comparatively short period, in ordered to allow the possibility of
> combining several smaller writes into a larger, single, more efficient
> write.  (More efficient because each write has a set amount of overhead in
> setup and take-down time and data.  Thus, combining 8 128-byte
> transactions into a single 1KB transaction means 1/8 the overhead, thus
> more effective payload bandwidth, at a cost of more latency, due to
> waiting for several transactions to accumulate, provided of course they
> come in before the expiry time forces what's there to be written even if
> it's not yet a full size transfer.)

There was a totally related, but slightly additional use for write
combining at the hardware level. It was introduced by Intel when they
first wrote the AGP 1.0 spec. The idea at the time was that game
software doing 3D work does not naturally output memory chunks that
are the same width as the AGP bus. Typically they are smaller blocks,
like 2 bytes, 4 bytes, etc. For this reason, to keep transfers on the
AGP bus more efficient, write combining could be set up so that the
processor would hold a number of small writes in a single cache line
and only flush this cache line over the AGP bus to the video display
when the software moved off the cache line or over-wrote some dirty
part of the cache line. The idea was that there was no reason to send
a bunch of bytes in separate writes, using more AGP bus bandwidth,
when these writes could be sent as a group using less bandwidth. The
description above supports this but it's not specifically graphics
oriented.
>
> * There's also uncachable, which turns off caching for reads as well as
> writes.  This will be /very/ slow.
>
> Where graphics gets involved is that these MTRRs are often used to program
> access to video memory over the AGP or whatever bus.  The link above lists
> some of the (then) xfree86 operations that MTRR settings affect and by how
> much.

Yep.

>
> Another link with some interesting info on the kernel config option
> (CONFIG_MTRR) and the userland interface to MTRRs (/proc/mtrr) once
> enabled.  The two paragraphs below are excerpted:
>
> http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/mtrr.txt

This one is interesting in that it opens my eyes to the possibility of
defining more MTRRs, a concept that I hadn't considered before.

<SNIP>

> Memory type region registers control the caching on newer Intel and non
> Intel processors. This function allows drivers to request an MTRR is
> added. The details and hardware specifics of each processor's
> implementation are hidden from the caller, but nevertheless the caller
> should expect to need to provide a power of two size on an equivalent
> power of two boundary.

The 'power of two' comments are interesting.
<SNIP>
>
> That last contains a mention of boundaries ("power of two size on an
> equivalent power of two boundary") that appears to pertain to your
> problem.

Seems to...

>
> So... now we know a bit about what MTRRs actually do (control the
> interaction between cache and a specified portion of memory for write
> transactions), what they are most often adjusted for (to increase graphics
> performance, by changing the way writes to graphics memory are cached),
> and can make a bit of sense out of the messages (the size doesn't match
> the required base address for the MTRR, something's trying to change the
> caching method, but using the wrong address and the adjustment is
> therefore getting a type mismatch).

OK.

>
> How does that translate into something you can do to fix it?
>
> Well, first, you can actually go take a look at /proc/mtrr (don't try to
> write anything to it, unless you are sure you know what you are doing, but
> reading it should be fine), and see if you can figure out which entry it's
> supposed to be changing, if there's one close to that address at all, or
> if not, what needs created.

Yes, on the IA32 machine that actually has the problem I see strange
results. It's a machine with 512MB, but possibly with shared memory?
Not sure. Anyway, look at this:

mark@dragonfly ~ $ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=983552MB: write-back, count=1
reg01: base=0x1f000000 ( 496MB), size=983056MB: uncachable, count=1
mark@dragonfly ~ $

where as my AMD64 machine has a single MTRR operating and shows this:

mark@lightning ~/.wine/drive_c/VST $ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
mark@lightning ~/.wine/drive_c/VST $

It seems that the IA32 machine is having some trouble with these
registers. The size numbers look strange to me.

<SNIP>

>Whatever your video card driver is, that's
> probably (but not for certain) what's causing the log messages.

I agree. It's a built in Intel device. Part of the chipset I think:

dragonfly ~ # lspci
0000:00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM
Controller/Host-Hub Interface (rev 02)
0000:00:02.0 VGA compatible controller: Intel Corporation 82865G
Integrated Graphics Controller (rev 02)

> Therefore, take a look at /var/log/Xorg.0.log, and see if you can match up
> any possible MTRR messages listed there.

No MTRR messages in Xorg.0.log....

>
> Next, take a look at the driver documentation and your xorg.conf file
> and boot loader config, and see what sort of adjustments you might need to
> make.
>
> Of course, if it's /not/ video driver related, you'll likely have to
> figure out what else is accessing the MTRRs and how to reconfigure it
> correctly.  Taking a wild guess, I'd say check anything that's likely to
> be using  DMA, thus, stuff like NICs or storage devices, and their drivers.

I'm thinking that the strange sizes on the first MTRR are what caused
the messages and possibly relate to something not really happy at boot
time. The first one shows up in this set of operations:

agpgart: Detected an Intel 865 Chipset.
agpgart: Detected 16252K stolen memory.
agpgart: AGP aperture is 128M @ 0xe8000000
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 19
mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining
[drm] Initialized i915 1.1.0 20040405 on minor 0: Intel Corporation
82865G Integrated Graphics Controller

Not sure if it's ACPI related or graphics related. I'm guessing the latter...

<SNIP>
>
> From an Opteron BIOS integrator's pdf @ amd... they recommend one of the
> variable MTRRs (there are some fixed ones covering the memory space from
> 640k to 1 MB as well, that must be what those common settings in BIOS must
> be for) be set to cover the entire physical memory range... And so I
> see... I have a gig of memory and see a 1024 MB MTRR set @ base-address
> 0x 0000 0000 (0 MB), type write-back (so read/write cacheable). That makes
> sense as it's telling the CPU(s, 2 in my case) that all of my main memory
> is fully cacheable, no special restrictions needed!
>
> Apparently, some CPUs only have two variable MTRRs, and if one is used to
> cover all of physical main-memory, that leaves only one available, which
> would be used by the video driver, so that's how Linux is normally setup.
> Again apparently, modern x86 (and presumably x86_64 as well) CPUs from
> both AMD and Intel have eight such MTRRs, so more ranges can be programed
> as needed.

Intel P4 with Hyper-threading here. I would assume it has a reasonable
set of these things.

<SNIP>
>
> Note that at least here (Tyan s2885 dual Opteron board), the BIOS actually
> has two related settings controlling the way > 3.5 GB of physical memory
> is mapped.  One apparently controls the actual memory addresses, whether
> they skip the 3.5-4 GB range or not, the other controls the MTRRs,
> continuous or not.  If the two don't match, it could mean all of memory is
> seen but not all of it is marked as cacheable, slowing access to the
> uncached memory range.

I have not investigated BIOS on this machine. Good point.

>
> ...  Another leap of understanding...  Remember those ranges need to be in
> power-of-2 sizes and on matching power-of-2 boundaries?  I happen to have
> a gig of memory, an even power of two, so one MTR covers it exactly.
> That wouldn't work for those with 3/4 gig or 1.5 or 3 gig or some such.
> OTOH, I noticed a count=1 at the end of the two ranges I have mapped in my
> /proc/mtrr, so it would appear that could be remedied by using say 3
> half-gig MTRs (count=3) stacked end-to-end, or a 1 gig and a half gig
> (thus two), to map that 1.5 gig area.  I'm not sure if the count= would
> mean it's using additional MTRRs or not, tho I'd expect it would indeed
> mean that.  Thus, non-power-of-two memory layouts will probably mean more
> MTRRs used to map the full memory MTR.
>
> (If there's anyone with an odd amount of memory that could verify, it'd be
> nice...)

I have an older Athlon XP 1600+ machine with 756MB. I don't pretend to
understand this exactly but here's the results:

gigastudio ~ # cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x20000000 ( 512MB), size= 256MB: write-back, count=1
reg02: base=0xe8000000 (3712MB), size= 128MB: write-combining, count=1
reg07: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1
gigastudio ~ #

It looks like reg00 and reg01 make up the 756MB of main memory. The
video card is an NVidia with 128MB (I think....I'll have to go check)
so I assume that this is reg02. I do not understand reg07.

Somewhat disappointing, from this conversation, is my AMD64 machine:

mark@lightning ~/.wine/drive_c/VST $ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
mark@lightning ~/.wine/drive_c/VST $

Why no mtrr for the video adapter? Note that this machine is running
2.6.14-rc4-rt6. That's new today. There are no advanced drivers for
this kernel so possibly this gets turned on when the VGA driver is
loaded?
>
> My second MTRR is set to cover the 128 MB range dedicated to my video card
> (it's got 256 MB but on 128 MB is being used, it would appear, but it's no
> big deal since I don't do much 3D anyway because I'm running dual head
> video @ 2048x1536 each).  Here, it's the 128 MB beginning at exactly 3.5
> MB base address (0x e000 0000), write combining.
>
> OK...  0x e000 0000 is the 3.5 GB boundary, so your 0x e802 0000 is indeed
> in the PCI device area... 0x 800 0000 is 128 MB, 0x 2 0000 is 8 KB, so the
> base address it's attempting to use is 3.5 GB + 128 MB + 8 KB.  The
> requested size is 0x 40 0000 or 4 MB, so the closest boundary would be the
> 0x e800 0000 you see it trying for and getting the type mismatch.

And this is the address that my Via machine with 768MB shows.
<SNIP>
>
> That's about all I have ATM...  Hope this is as informative for others as
> it just was for me!  <g>  (And, if anyone's an expert on this stuff and I
> got it wrong, please inform me where!  Better to correct any mistakes I
> have now while it's new than after I build a bunch more suppositions on a
> faulty foundation!)
>

That was a huge contribution to my knowledge and I appreciate it
greatly. I think it's more than likely that there is something here
that should be reported to the LKML but I want to understand it just a
bit more first.

Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: mtrr: base is not aligned

[Marco Matthies]

Hi,

i'm not an expert on this subject myself but i found it nonetheless 
interesting, here's what i found mostly by grepping and googling:

Here's someone who is also getting these huge reported memory sizes:
http://lkml.org/lkml/2005/9/12/35
Found it by googling for 983552MB, there's more there.

There's is some info on mtrr's with vesafb here:
/usr/src/linux-2.6.13-gentoo-r3/Documentation/fb/vesafb.txt, line 176
Seems to suggest trying video=vesafb:nomtrr if you're using vesafb.

Also some other reports seem to hint at Xorg as the culprit:
https://bugs.freedesktop.org/show_bug.cgi?id=4310
and others found by googling "mtrr: type mismatch for".

You might want to also grep Xorg.log for the addresses provided by
'cat /proc/mtrr' or just the prefix such as
'grep -in 0xd /var/log/Xorg.0.log' in my case, that should some results 
(Xorg.log doesn't seem to mention mtrr literally, as far as i can see).

I'm sorry that I don't have an answer to the actual problem, but I'm 
very thankful for the interesting explanations about mtrr from both of 
you (Duncan and Mark).

Cheers,
Marco
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: mtrr: base is not aligned

[Duncan]

Marco Matthies posted <4352EDBE.7030503@gmx.net>, excerpted below,  on
Mon, 17 Oct 2005 02:18:06 +0200:

> Here's someone who is also getting these huge reported memory sizes:
> http://lkml.org/lkml/2005/9/12/35
> Found it by googling for 983552MB, there's more there.
> 
> There's is some info on mtrr's with vesafb here:
> /usr/src/linux-2.6.13-gentoo-r3/Documentation/fb/vesafb.txt, line 176
> Seems to suggest trying video=vesafb:nomtrr if you're using vesafb.
> 
> Also some other reports seem to hint at Xorg as the culprit:
> https://bugs.freedesktop.org/show_bug.cgi?id=4310
> and others found by googling "mtrr: type mismatch for".
> 
> You might want to also grep Xorg.log for the addresses provided by
> 'cat /proc/mtrr' or just the prefix such as
> 'grep -in 0xd /var/log/Xorg.0.log' in my case, that should some results 
> (Xorg.log doesn't seem to mention mtrr literally, as far as i can see).

Same here.  The address range corresponds, but mtrr isn't mentioned by
name in xorg.conf.

You can check video memory (and a couple other items) by running lspci -v.
Look for the line that has a size in megs, under the correct video device,
of course...  <g>

This is all great fun and I sure learned a lot yesterday researching, then
putting it into words therefore anchoring it in my memory as well as
forcing myself to contemplate angles for the purpose of writing that I
wouldn't necessarily see, otherwise.  However, Saturday nite is my Monday,
and I spent all of my Monday nite researching and writing this and a
couple other technical replies... and  got only an hour or so of sleep! 
<g>  So... tonite I'm going to try to avoid getting too deeply involved in
this and ignore the additional research I now want to do given the above
links!  <g>  Maybe that way I can get some sleep today (day=nite for me,
nite=day)!

...  One of the things that is making this interesting for me, is that
I've been trying to run dual Radeons for some time, one AGP one PCI, each
with two outputs so I can run FOUR 21" monitors instead of only TWO, like
I used to run an NVidia (Twinview) with the closed drivers and an old
cheap S3 Virge (giving me three monitors, then a 19" and two 17"), a
couple years ago. However, I keep getting conflicting resources when I
try.  I've always wanted to take the time to see if I could grok things
well enough to try and reconfigure around the issue, and this is giving me
the motivation (and additional brain power) to grasp at least one angle of
it.  I'm not sure that's actually what's conflicting, as I haven't tried
running it that way for awhile, but I'm at least developing enough
understanding now to make a bit of sense of things and figure out from the
errors where the problem actually is, now, when I get a chance to get back
to it.  That's /miles/ farther than I was, previously!

In addition, few enough folks actually grok this stuff that if I can get
it, I'm sure the knowledge will be of help to quite a few others, as well.

Oh...  Previously I was trying to run a separate "screen" config for each
monitor, thus, two per card since each card has two outputs.  I'm now
running xorg's merged framebuffer for Radeons, so it's actually possible
the problem will have disappeared when I actually try it again...

So anyway, that's why I'm spending so much time on this myself...  The
knowledge gained at this point can be of help to at least two, and later
others, so it's not just me gaining immediate benefit, nor is it just you.
However, the research will work better when I'm rested, so tomorrow or
later this week...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Merged Framebuffer

[Sebastian Redl]

Duncan wrote:

>Oh...  Previously I was trying to run a separate "screen" config for each
>monitor, thus, two per card since each card has two outputs.  I'm now
>running xorg's merged framebuffer for Radeons, so it's actually possible
>the problem will have disappeared when I actually try it again...
>  
>
What exactly are the effects of this, and how do I do it? I have a 
Radeon 9800 Pro with two monitors, and right now they're rather 
disjointed. I'd like them to act as one, but I don't want maximized 
windows being spread over both screens.

Sebastian Redl
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Merged Framebuffer

[Duncan]

Sebastian Redl posted <43539567.9080803@getdesigned.at>, excerpted below, 
on Mon, 17 Oct 2005 14:13:27 +0200:

>>Oh...  Previously I was trying to run a separate "screen" config for each
>>monitor, thus, two per card since each card has two outputs.  I'm now
>>running xorg's merged framebuffer for Radeons, so it's actually possible
>>the problem will have disappeared when I actually try it again...
>>  
>>
> What exactly are the effects of this, and how do I do it? I have a 
> Radeon 9800 Pro with two monitors, and right now they're rather 
> disjointed. I'd like them to act as one, but I don't want maximized 
> windows being spread over both screens.

First, I know nothing at all about the closed ATI drivers, except that
they're closed so I won't run them, and that from what I read, they aren't
as easy to work with as Nvidia's closed drivers, which I used to use back
when I first switched from MSWormOS, because I had an NVidia card that
only ran Twinview mode with the non-free drivers.  (I had the foresight to
check whether the card had Linux drivers, and that they worked with
Twinview, since I was thinking about switching, when I bought it, but
didn't yet know that there was such as thing as proprietary Linux drivers,
so naturally didn't/couldn't check whether the /free/ drivers supported
twinview, since I didn't know there was a distinction.)

Therefore, what I know is the xorg "freedomware" Radeon drivers, which
unfortunately in current versions don't support beyond 9200s in 3D
accelerated mode.  Not that such would work all that well at 2048x3072
total resolution (2048x1536 x2, stacked) anyway, but...

Post 9200 has /experimental/ 3D support in the latest masked for testing
xorg-x11-6.8.99.x series, however, so you could see how that works.  Note
that the 6.8.99.15-rX snapshot is the last non-modular series.  The latest
snapshots are xorg-modular, which I tried installing but apparently
didn't get something merged correctly, so I went back to the 15 snapshots.
(I like testing so am running them even tho I have 9200s, which have full
support in current stable xorg.)

Anyway...  I believe the 9800 is supported by the free drivers in 2D mode,
which is all that works well with multi-monitor anyway, so if that's what
you are after, you should be fine.

Here's how it works.  There are multiple levels of integration choices
available to you.

>From your question, it appears you are currently running both monitors as
separate xorg "screens", without xinerama (regular or pseudo) activated. 
This effectively runs two xorg mini-sessions, each on its own screen.  You
can't move stuff (other than the mouse, and keyboard focus, of course)
directly between them.  Each has it's own session widgets, taskbar and the
like, if whatever environment you are running uses such things.

What you want is Xinerama mode (either real or pseudo).  How well it fits
what you want, in terms of controlling where windows maximize and the
like, depends on the windowing environment you run and its support for
xinerama.  KDE, my X environment of choice, supports xinerama rather well,
and has options for whether applications maximize to one screen or all,
and such things as window placement (on the mouse-focused screen or
either), window movement snap-to support, etc, with each feature
individually configurable to single monitor or entire desktop area.  (In
KDE 3.5 at least, yes, I'm running the betas of that too, these settings
are in the control panel under Peripherals/Display, not under
Desktop/Window-behavior, where one might otherwise look.)

Since you already have both screens running in non-xinerama mode, you've
already done the heavy work in xorg, configuring each monitor's separate
resolutions and the like. To activate xinerama (real X xinerama), simply
add the appropriate 

	Option "Xinerama"

line to your ServerFlags section.  That should be all you need to do for
X.  Other reconfiguration will be done in your window manager and X
environment of choice.  If you want to discuss KDE settings, I'm up for
that, otherwise, you'll need to look elsewhere for help with that, if you
need any.

The free Radeon driver also supports merged framebuffer mode, as I
mentioned earlier.  This will require a bit of additional reconfiguration
to your xorg.conf file, but you already have the data you need in your
current config, you just have to redo it a bit.

Basically, merged framebuffer uses a single instance of the driver (with
or without "PseudoXinerama" enabled) to manage the monitors connected to
both outputs of your video card, rather than using a separate instance of
the driver for each output.  This means there's less overhead and things
operate a bit more efficiently.  If 3D is supported by the driver on your
hardware (as I said, experimental support for post Radeon 9200s is in the
latest masked for testing xorg snapshots), you may even get full
accelerated 3D support, as long as the total resolution doesn't get too
high (I believe the maximum bounded area for merged framebuffer
accelerated 3D support is 2048x2048, so I can't run it anyway, since I run
2048x3072).

There are, however, a few drawbacks to merged framebuffer, as well. 
First, merged framebuffer operates as a single screen, so regardless of
whether xinerama is on or not, you get only the one session with one set
of windowing environment widgets, etc.  No dual independent mini-sessions!
Second, where xinerama isn't supported by your windowing environment,
flexibility on where things go will be limited, and windows will maximize
to the total screen (across monitors).  If xinerama is supported by your
windowing environment, of course, this isn't an issue to the degree you
can configure it  not to be, with the xinerama support.  Third, and the
thing I personally found most irritating at first, you lose the ability to
set each monitor's resolution independently.  Yes, the monitors CAN still
run at different resolutions, but rather than moving your mouse to the one
you want to set and hitting ALT-CTRL-NUMPLUS (or NUMMINUS) to cycle thru
each configured resolution on each screen independently, you have a single
set of configured resolutions for the merged framebuffer to cycle thru. 
If like me you have a whole series of resolutions configured for each
monitor, listing the permutations in a single combined list very quickly
becomes unwieldly!  So... with the exception of one special purpose (a
specific game) mode that's full size 2048x1536 on the top monitor and
640x400 on the bottom one, I settled for a series of equivalent
resolutions on each screen.  I'll list an example below so you can see
what I mean...  Combined with a variable strength image magnifier (KView),
that serves my purposes well enough, and I'm now running merged
framebuffer.

Xorg.conf changes for merged framebuffer:

The xorg.conf changes for merged framebuffer, compared to running two
separate instances of the driver, one for each output, all have to do with
the fact that instead of two separate screen configurations, one for each
monitor/graphics-card-output combo, you have only one, that has to contain
all the information from what was two different screen configs.  

The way the "primary" monitor and output are configured remains exactly
the same, with the exception of the previously mentioned single
resolutions sequence, and the single-instance version of that is ignored
in merged framebuffer mode, so you don't need to comment out anything from
your current  primary screen/device config.  All the new settings are
additional entries.

The original secondary screen/device config info is entirely ignored in
merged framebuffer mode, since all the necessary info is added as new
entries into the primary screen config.  Therefore, it too can remain.

Further, if merged framebuffer is deactivated, all the merged framebuffer
entries (save for the single activate/deactivate option) are ignored, so
can remain uncommented in the primary config.

This makes it very easy to switch between the two modes, merged
framebuffer vs separate screen configs, by switching a single "merged
framebuffer" activator entry.  Here, I actually comment a few additional
entries to make clear which ones are operational and which ones aren't,
but that's not necessary.  A single change is all that's needed to switch
merged framebuffer on or off and activate the appropriate entries.

Example time!  Keep in mind that the documentation for all these settings
are in the radeon manpage, if they're not xorg generic in the first place,
so that's where to look if you need to figure out what a setting does or
what other options are available.

Actually, all the changes are in the primary device section.  No screen
section changes necessary either!

Section "Device"
    Identifier "DevAgp.0"
    Driver "radeon"
    Screen 0
    BusID "PCI:5:0:0"
    Option "BusType" "AGP"
    Option "AGPMode" "4"
    Option "AGPFastWrite"
    Option "EnablePageFlip"
    Option "MonitorLayout" "CRT, CRT"

# The above are all standard xorg device section or radeon settings,
# nothing special there!  The below settings activate merged
# framebuffer and configure the second monitor

# This one's the activator switch.  Without an "on" or "off"
# after the option, it's  "on".
    Option "MergedFB"

# Position of the second monitor.  Self-evident.
    Option "CRT2Position" "Above"

# These are the hardware settings for the second monitor.
# Note again that the primary monitor settings are taken
# from the normal place, the monitor section specified
# in the screen section that also specifies this device
# section.
    Option "CRT2HSync" "30-110"
    Option "CRT2VRefresh" "50-180"

# This is that confounded resolutions line!  It's all one line, wrapped
# here for posting.  See what I mean about the permutations quickly
# becoming unmanageable!  If I listed each resolution against each
# resolution...  Note that as listed, the resolutions on each monitor
# are equal, save for the last one.  Also note the "-" connectors.  A "+"
# may also be used, but has a special meaning (clone mode, IRC).  Or
# a single resolution by itself may be listed.  See the radeon
# manpage for more.
    Option "MetaModes" "2048x1536-2048x1536 1792x1344-1792x1344
    1600x1200-1600x1200 1280x960-1280x960 1152x864-1152x864
    1024x768-1024x768 800x600-800x600 640x480-640x480 512x384-512x384
    400x300-400x300 640x400-2048x1536"

# Since xorg will otherwise have difficulty calculating the dot-per-inch
# settings, and the fonts will likely be way big or way small, if this
# setting isn't specified...  Note that this is another disadvantage of
# merged framebuffer.  If your monitors are physcally different sizes or
# "normal" operating resolution is different on each, with separate
# screens, you can specify separate DPIs.  Here, there's only one setting,
# so if the monitors use different ones, you gotta pick a compromise.
    Option "MergedDPI" "120 120"

# This one is a specific accel deactivator, here because of the
# comment in the ebuild...  I don't think it's used as I'm configured,
# because 3d accel is deactivated here anyway, due to 2048x3072, but
# I put it here anyway.  The radeon manpage says what it does...
    # ColorTiling off due to bug mentioned in xorg-6.8.99.15 ebuilds
    Option "ColorTiling" "off"
EndSection

A couple more notes...

In the serverlayout section, I comment the second screen section
reference.  I don't believe I have to do that because the Option MergedFB
should take care of it, but I've never tried it with both activated to see
which takes precedence, for sure.

PseudoXinerama...  is activated automatically with mergedFB, unless turned
off either because regular xinerama is on, or specifically set off.
PseudoXinerama works almost like regular xinerama would with separate
framebuffers.  Your windowing environment configurations and hooks should
apply just as they would to normal xinerama.

Thus, I have my xinerama activator line in the serverflags section
commented out, for use with mergedFB, because if it were on,
PseudoXinerama would deactivate itself.

Hope that's what you needed!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list