From owner-freebsd-current  Tue Apr 23 04:34:05 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id EAA26045
          for current-outgoing; Tue, 23 Apr 1996 04:34:05 -0700 (PDT)
Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA25977
          for <current@FreeBSD.ORG>; Tue, 23 Apr 1996 04:33:50 -0700 (PDT)
Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id NAA26211 for current@FreeBSD.ORG; Tue, 23 Apr 1996 13:33:35 +0200
Message-Id: <199604231133.NAA26211@nixpbe.pdb.sni.de>
Subject: Re: request for a new "feature" as regards DDB
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Tue, 23 Apr 96 13:33:29 MDT
From: Greg Lehey <lehey.pad@sni.de>
Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG (FreeBSD hackers)
In-Reply-To: <4674.830258923@time.cdrom.com>; from "Jordan K. Hubbard" at Apr 23, 96 4:28 am
X-Mailer: xmail 2.4 (based on ELM 2.2 PL16)
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> I disagree completely.  If my machine dies in the middle of the night,
>> I want to come in the next morning and be able to debug the live
>> hardware, not a dump.  YMMV, but we should have the option.
>
> However, there's a corrolary:
>
> If your machine dies in the middle of the night (or when you're in
> front of it, for that matter) and *you're sitting in the X server*
> then you should be given a dump if you're not configured for a serial
> console because we know that there's no way in hell you're going to be
> debugging any live hardware.  

We haven't done that one to death yet :-)

> A dump is the best you can ask for under those circumstances.

If a dump is the best you can hope for, then you shouldn't have to
even ask.  Even if we can only change back to character mode 98% of
the time, the other 2% (at least) should give you a dump.  Of course,
if there's a timeout, that would handle it.

> Assuming that the same interface which the VT_GETACTIVE ioctl()
> uses is available for determining if "curvty = vty0", it seems you
> should be able to avoid going into DDB interaction mode if it's
> not possible to do anything else.  You can simply call panic.

Sounds reasonable.  I'll take a look at it.

Greg