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 ?
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkqzO/QACgkQC3+MBN1Mb4j/YgCg0TMwK/of4MDa9JzbJkAHZOlL
zjoAn1xlQAdxWS/pDqHOdEggnA478jK7
=8YXo
-----END PGP SIGNATURE-----