From owner-freebsd-current@FreeBSD.ORG Thu Sep 17 20:31:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E966C1065676 for ; Thu, 17 Sep 2009 20:31:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outb.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id CB8118FC14 for ; Thu, 17 Sep 2009 20:31:07 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3803A736CF; Thu, 17 Sep 2009 13:31:11 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BDEFC2D6012; Thu, 17 Sep 2009 13:31:06 -0700 (PDT) Message-ID: <4AB29C88.7030809@elischer.org> Date: Thu, 17 Sep 2009 13:31:04 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: David Wolfskill References: <20090917134924.GZ1212@albert.catwhisker.org> <1253208550.49704.4014.camel@balrog.2hip.net> <200909172010.22513.mel.flynn+fbsd.current@mailing.thruhere.net> <20090917194822.GF1212@albert.catwhisker.org> In-Reply-To: <20090917194822.GF1212@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mel Flynn , freebsd-current@freebsd.org Subject: Re: misc/compat6x port no longer sufficient for DRI under head? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 20:31:08 -0000 David Wolfskill wrote: > On Thu, Sep 17, 2009 at 08:10:22PM +0200, Mel Flynn wrote: >> ... >>> 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 should result >> in some /var/log/messages entries at the very least and quite possible reboot, >> right? > > Now that it's lunch time, I had a chance to try an experiment: > > * Connect serial to another system vai crossover cable. > > * Boot head (slice 4, in my case) in to normal multi-user mode. > Neither dbus nor hald is enable in /etc/rc.conf, and Xorg is not > started automatically (unlike the way I have stable/6 configured, > in that respect). > > * On vty1 (I don't usually login to vty0, as I prefer to keep that for > seeing logged messages or whatever), login as root. > > * Mount all disk-resident file systems (vs. swap-backed /tmp, for > example) other than /var as read-only. This is to reduce the time for > recovery later. > > * From another system, "ssh -xvvv" -- partly as a record of what to > expect when it works; partly to demonstrate that doing that does > normally work. Exit the connection. > > * sh /usr/local/etc/rc.d/dbus forcestart; uptime > Note system responses: > Starting dbus. > 12:32PM up 2 mins, 1 user, load averages: 0.26, 0.30, 0.14 > > * sh /usr/local/etc/rc.d/hald forcestart; uptime > Note system responses: > Starting hald. > 12:32PM up 2 mins, 1 user, load averages: 0.22, 0.29, 0.14 > > Also note that disk I/O light flickers quite a bit for about 5 > seconds. > > * Type "uptime" at shell prompt. Note lack of response: no echo; no > output; no disk I/O. > > * Re-try the "ssh -xvvv" from the other system. Last couple of lines > shown are: > debug3: key_read: missing keytype > debug1: identity file /homes/dwolf/.ssh/id_dsa type 2 > > In the "successful" case, the above were followed by: > > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2p1 FreeBSD-20090522 > debug1: match: OpenSSH_5.2p1 FreeBSD-20090522 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > > > * Hit "Enter" on serial connection. Note lack of response. > > * On vty1 (where I last tried "uptime"), hit Enter a time or two, then > type "halt -p" (blind, as there's no echo). Note lack of response. set flags for console to be serial, when frozen, try CTL_ALT_ESC on keyboard to try drop to debugger CR ~ ^B (I think that is the serial break to debugger, check the options..) serial console is a lot more useful a diag than just serial port.. > > * Power-cycle & recover. > > Peace, > david