misc/compat6x port no longer sufficient for DRI under head?

[Robert Noland]

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 at FreeBSD.org>
FreeBSD