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

[Kostik Belousov]

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().

It seems that after some time, X starts sleeping in select(2).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090917/1f8e7b40/attachment.pgp