failed to set mtrr: invalid argument

[Chris H]

Hello Robert, and thank you for taking the time to respond.

Quoting Robert Noland <rnoland at freebsd.org>:

> On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote:
>> Quoting Dimitry Andric <dimitry at andric.com>:
>>
>> > On 2009-05-19 08:40, Chris H wrote:
>> >> I see. Well I'm specifically using the nv driver. Here's another
>> >> attempt to provide the relevant info:
>> >
>> > I could not find the error message from $subject in these logs.  Where
>> > is it? :)
>>
>> If I had found it, I would have better known what direction to travel
>> to overcome it. :)
>> Aparently Xorg wants to keep it a secret - I saw no "argument".
>
> This isn't actually Xorg per se... It is when we attempt to set an MTRR
> range via ioctl on /dev/mem.  The ultimate return value is EINVAL which
> just gets displayed as invalid argument.
>
>> The closest possible answer I can come up with, involves "write combining"
>> and provinding some information in /proc/mtrr
>> But I only have /proc and nothing in it. Thought about echo(1)ing
>> the information to mtrr. But don't understand the whole thing well
>> enough to /dare/ do it. I only know it involves something in this
>> area:
>>
>> 0xfd000000/16777216, 0xf0000000/134217728, 0xfa580000/524288
>>
>> out of the Xorg log. I'm also not sure if GENERIC knows how to handle
>> mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel
>> yet because there are also some issues on the ATA ports that need to be
>> resolved. I started a theread on this earlier.
>>
>> Thank you for taking the time to respond.
>
> You can do a "memcontrol list" which will display the memory regions and
> their caching method.  Likely what you will find is a "global" MTRR
> which is set to write-back.
I always set "write-back" in the BIOS, as it then gets marked "dirty",
and the CPU cache will get processed accordingly.
>  We don't have the ability to split regions
> and we aren't allowed to overlap write-combine on top of write-back, so
> any attempt to set MTRR will fail.  The specific failure is most likely
> when X tries to set write-combine on the framebuffer, which in your case
> looks like 0xf0000000/134217728.
>
> Again, this shouldn't prevent X from working...  It is just a
> performance issue.

My investigations on this have led me to believe that Linux can address
(allow) write-combining via their version of sysctl (so to speak).
The article I found this reference was here:
http://www.mplayerhq.hu/DOCS/HTML/en/mtrr.html

Do we (does FreeBSD) have this ability? Or will we?

I also found some good information on write combining here:
http://www.meduna.org/txt_mtrr_en.html

This box can be used as a "guinea pig" if you would like.

Thanks again Robert, for all your time and efforts.

--Chris H

>
> robert.
>
>> --Chris H
>>
>> >
>>
>>
>>
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> --
> Robert Noland <rnoland at FreeBSD.org>
> FreeBSD
>