Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Sep 2009 08:53:41 -0500
From:      Robert Noland <rnoland@FreeBSD.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        Mel Flynn <mel.flynn+fbsd.current@mailing.thruhere.net>, freebsd-current@freebsd.org
Subject:   Re: misc/compat6x port no longer sufficient for DRI under head?
Message-ID:  <1253282021.2038.1168.camel@balrog.2hip.net>
In-Reply-To: <1253280980.2038.1148.camel@balrog.2hip.net>
References:  <20090917134924.GZ1212@albert.catwhisker.org> <b269bc570909170832u792f851fk4ace6bfa4c9a7321@mail.gmail.com> <1253208550.49704.4014.camel@balrog.2hip.net> <200909172010.22513.mel.flynn%2Bfbsd.current@mailing.thruhere.net> <1253211613.49704.4073.camel@balrog.2hip.net> <20090917182810.GG47688@deviant.kiev.zoral.com.ua> <1253214222.2038.18.camel@balrog.2hip.net> <20090918075117.GK47688@deviant.kiev.zoral.com.ua> <1253280980.2038.1148.camel@balrog.2hip.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2009-09-18 at 08:36 -0500, Robert Noland wrote:
> On Fri, 2009-09-18 at 10:51 +0300, Kostik Belousov wrote:
> > On Thu, Sep 17, 2009 at 02:03:42PM -0500, Robert Noland wrote:
> > > On Thu, 2009-09-17 at 21:28 +0300, Kostik Belousov wrote:
> > > > I spent some time with David looking at the debugging information.
> > > > In particular, David has access to the serial console on the machine.
> > > > 
> > > > I was unable to decide with some certainity what happens, in particular,
> > > > whether the machine was locked, only X was locked, or just keyboard and
> > > > mouse input not working.
> > > > 
> > > > But, the reliable state of the system where it spent quite a time
> > > > during X startup was mtrr setup. Xorg was sitting in kernel, in
> > > > i686_mrstore().
> > > 
> > > I'm not certain what to suggest here.  MTRR is fail on almost every
> > > newer board that I have, due to the fact that the BIOS sets a global WB
> > > MTRR, which we don't have the ability to split or overlap.  In any case
> > Could you, please, give me some more details ?
> > 
> > On the machine I am writing this from, default MTRR settings for uncovered
> > region are UC. Also, there is a variable MTRR covering whole region
> > of RAM from 1M to the end of physical RAM as WB. Is this what you mean ?
> 
> Yes, on my boards I have something like the following:
> 
> 0x0/0x100000000 BIOS write-back set-by-firmware active 
> 
> The specs state that we cannot overlap WC on this, so without being able
> to split the above variable MTRR, setting WC always fails.  It is
> further complicated by the fact that we only have 7 variable MTRR
> registers to work with.  It is valid to set WB using PAT though.
                                               ^WC

robert.
> robert.
> 
> > > every MTRR attempt by X/drm is to set WC.  I have easily produced hard
> > > system lockups by attempting to manually manipulate MTRRs via
> > > memcontrol, even to states that should be valid.  This is one of the
> > > many reasons that I'm trying to move to using PAT for everything.  If
> > > the attempt to set MTRR is not failing and returning an appropriate
> > > error, that could very well be the source of the lockup.
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD




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