misc/compat6x port no longer sufficient for DRI under head?
julian at elischer.org
Thu Sep 17 20:31:08 UTC 2009
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<enter> should result
>> in some /var/log/messages entries at the very least and quite possible reboot,
> 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
> * 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
serial console is a lot more useful a diag than just serial port..
> * Power-cycle & recover.
More information about the freebsd-current