Date: Tue, 19 May 2009 14:28:55 -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: <1242761335.1752.28.camel@balrog.2hip.net> In-Reply-To: <20090519095739.5o53vu0gcg4owkww@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-KDBiKcBNB87NquIeaG+t Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: > Quoting Dimitry Andric <dimitry@andric.com>: >=20 > > 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? :) >=20 > 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: >=20 > 0xfd000000/16777216, 0xf0000000/134217728, 0xfa580000/524288 >=20 > 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=20 > resolved. I started a theread on this earlier. >=20 > 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. 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. robert. > --Chris H >=20 > > >=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 --=-KDBiKcBNB87NquIeaG+t 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) iEYEABECAAYFAkoTCHcACgkQM4TrQ4qfRONnuwCfaKEGMwWLz7ffkemktWtc2BxA 26kAn281hz9CCaBFH2moJntzCytf+0IP =/t1N -----END PGP SIGNATURE----- --=-KDBiKcBNB87NquIeaG+t--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1242761335.1752.28.camel>