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

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.

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