Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 May 2009 17:58:05 -0500
From:      Robert Noland <rnoland@FreeBSD.org>
To:        Chris H <chris#@1command.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: failed to set mtrr: invalid argument
Message-ID:  <1242773885.1752.43.camel@balrog.2hip.net>
In-Reply-To: <20090519131452.yq6e2t2puswko44o@webmail.1command.com>
References:  <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com> <20090518224246.0qrzye1z40w4ws8g@webmail.1command.com> <20090518232019.36g94wxl7zeo088g@webmail.1command.com> <3a142e750905182328m60439dfcgadd4c28ba037400e@mail.gmail.com> <20090518234011.k55bmqq3488kko8c@webmail.1command.com> <4A126DBA.9080701@andric.com> <20090519095739.5o53vu0gcg4owkww@webmail.1command.com> <1242761335.1752.28.camel@balrog.2hip.net> <20090519131452.yq6e2t2puswko44o@webmail.1command.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-oecuDmi2DTpWWz/vhiYr
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2009-05-19 at 13:14 -0700, Chris H wrote:
> Hello Robert, and thank you for taking the time to respond.
>=20
> Quoting Robert Noland <rnoland@freebsd.org>:
>=20
> > On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote:
> >> Quoting Dimitry Andric <dimitry@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.  Whe=
re
> >> > 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 combin=
ing"
> >> 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/kerne=
l
> >> yet because there are also some issues on the ATA ports that need to b=
e
> >> 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 an=
d
> > 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 cas=
e
> > looks like 0xf0000000/134217728.
> >
> > Again, this shouldn't prevent X from working...  It is just a
> > performance issue.
>=20
> 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
>=20
> Do we (does FreeBSD) have this ability? Or will we?
>=20
> I also found some good information on write combining here:
> http://www.meduna.org/txt_mtrr_en.html
>=20
> This box can be used as a "guinea pig" if you would like.
>=20
> 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
>=20
> >
> > robert.
> >
> >> --Chris H
> >>
> >> >
> >>
> >>
> >>
> >> _______________________________________________
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.o=
rg"
> > --
> > Robert Noland <rnoland@FreeBSD.org>
> > FreeBSD
> >
>=20
>=20
>=20
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
--=20
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

--=-oecuDmi2DTpWWz/vhiYr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEABECAAYFAkoTOX0ACgkQM4TrQ4qfRONn5ACfSdG28gS9lq9TKlHSXW0s2xf8
kcMAmwQfLRtxuOBkgwqo4hbe0Wc03mWf
=bRGp
-----END PGP SIGNATURE-----

--=-oecuDmi2DTpWWz/vhiYr--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1242773885.1752.43.camel>