Date: Tue, 19 May 2009 13:14:52 -0700 From: Chris H <chris#@1command.com> To: freebsd-stable@freebsd.org Subject: Re: failed to set mtrr: invalid argument Message-ID: <20090519131452.yq6e2t2puswko44o@webmail.1command.com> In-Reply-To: <1242761335.1752.28.camel@balrog.2hip.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Robert, and thank you for taking the time to respond. Quoting Robert Noland <rnoland@freebsd.org>: > 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. 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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- > Robert Noland <rnoland@FreeBSD.org> > FreeBSD >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090519131452.yq6e2t2puswko44o>