From owner-freebsd-stable@FreeBSD.ORG Tue May 19 20:15:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00CCD106567C for ; Tue, 19 May 2009 20:14:59 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (dsl081-172-045.sea1.dsl.speakeasy.net [64.81.172.45]) by mx1.freebsd.org (Postfix) with ESMTP id A7A7C8FC15 for ; Tue, 19 May 2009 20:14:59 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id n4JKEqEq025161 for ; Tue, 19 May 2009 13:14:58 -0700 (PDT) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id n4JKEqmM025160 for freebsd-stable@freebsd.org; Tue, 19 May 2009 13:14:52 -0700 (PDT) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [64.81.172.194]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Tue, 19 May 2009 13:14:52 -0700 Message-ID: <20090519131452.yq6e2t2puswko44o@webmail.1command.com> X-Priority: 3 (Normal) Date: Tue, 19 May 2009 13:14:52 -0700 From: Chris H To: freebsd-stable@freebsd.org 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> In-Reply-To: <1242761335.1752.28.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / UNIX Subject: Re: failed to set mtrr: invalid argument X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:15:00 -0000 Hello Robert, and thank you for taking the time to respond. Quoting Robert Noland : > On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: >> Quoting Dimitry Andric : >> >> > 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 > FreeBSD >