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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:55 UTC