failed to set mtrr: invalid argument

[Robert Noland]

On Tue, 2009-05-19 at 13:14 -0700, Chris H wrote:
> 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.

Linux may have the ability to split regions, I'm really not sure.  We
can manipulate memory ranges using memcontrol, but if you have a global
set to write-back like both of my newer bios's do, then you would have
to remove that and then manually split the regions to allow a
non-overlapping write-combined region.  I generally lock up the machine
when I have tried that though.

robert.

> --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
> >
> 
> 
> 
> _______________________________________________
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090519/ef9a7b01/attachment.pgp