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

On Thu, 2009-09-17 at 21:28 +0300, Kostik Belousov wrote:
> On Thu, Sep 17, 2009 at 01:20:13PM -0500, Robert Noland wrote:
> > On Thu, 2009-09-17 at 20:10 +0200, Mel Flynn wrote:
> > > On Thursday 17 September 2009 19:29:10 Robert Noland wrote:
> > > > On Thu, 2009-09-17 at 08:32 -0700, Freddie Cash wrote:
> > > > > On Thu, Sep 17, 2009 at 8:29 AM, David Wolfskill 
> > > <david_at_catwhisker.org>wrote:
> > > > > > On Thu, Sep 17, 2009 at 05:04:31PM +0200, Gary Jennejohn wrote:
> > > > > > > ...
> > > > > > > Maybe you need to install misc/compat7x also for things to work with
> > > > > > > head?  Don't forget options COMPAT_FREEBSD7 in your kernconf for
> > > > > > > head.
> > > > > > >
> > > > > > :-)  As I was writing the previous message, that thought occurred, so I
> > > > > >
> > > > > > did install it, re-tried, and the symptoms persisted: with DRI enabled,
> > > > > > the keyboard & mouse were non-functional; with DRI disabled, Xorg
> > > > > > worked.
> > > > > >
> > > > > > (I had intended to install misc/compat7x under head as soon as it had
> > > > > > been committed, but it slipped what passes for my mind.  And the file
> > > > > > system where /usr/ports lives is not one I normally even mount when
> > > > > > running head....)
> > > > > >
> > > > > > But thanks for the thought!
> > > > >
> > > > > Have you tried re-enabling hald and dbus and configuring X to use those?
> > > > 
> > > > So, the DRI option has absolutely nothing to do with kbd/mouse.  I
> > > > expect that what you are actually seeing is a hard lockup, quite
> > > > possibly a gpu crash.
> > > 
> > > If that's the case, having a root vty open before starting X and upon gpu 
> > > crash, blind type (no cookies for typos!) shutdown -r NOW<enter> should result 
> > > in some /var/log/messages entries at the very least and quite possible reboot, 
> > > right?
> > 
> > Maybe... It really depends on exactly what state X has left things in
> > when it crashed/hung.  If X crashes and catches the signals, it should
> > try to restore the console to a usable state.  If it is a gpu crash then
> > X may still be functioning, but hung on a lock.  In this case, you can
> > generally ssh in or get serial console.  It is also possible for
> > something entirely more evil to occur, such that things get hung with
> > interrupts disabled which results in a case where nothing but the power
> > button will remedy it.  In any case, if X isn't able to cleanly exit and
> > call LeaveVT, then your console is likely hosed.
> 
> 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
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.

> It seems that after some time, X starts sleeping in select(2).
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD