From owner-freebsd-current  Tue Apr 23 03:59:50 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id DAA24209
          for current-outgoing; Tue, 23 Apr 1996 03:59:50 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA24061
          Tue, 23 Apr 1996 03:56:44 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA15838; Tue, 23 Apr 1996 20:45:26 +1000
Date: Tue, 23 Apr 1996 20:45:26 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604231045.UAA15838@godzilla.zeta.org.au>
To: bde@zeta.org.au, lehey.pad@sni.de
Subject: Re: request for a new "feature" as regards DDB
Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG, smpatel@umiacs.UMD.EDU
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>>>> 	So...any way of having an auto-switch to vt0 if the system
>>>>> crashes with DDB enabled?
>>
>> Use syscons.

>I don't understand.  Are you saying "syscons auto-switches to vt0 if
>the system crashes with DDB enabled", or are you saying "if you use

I meant that syscons auto-switches from ttyvn to ttyv0 when DDB is
entered.  It actually stays on the same ttyvn, just like pcvt, and
you have to hit Alt-F1 to switch to it, not quite like in pcvt, where
you have to hit Ctr-Alt-F1.  Switching from graphics mode of course
doesn't work for either syscons or pcvt.

>> Bad idea.  You should make sure that ddb is never entered if you're not
>> around to watch it.

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

OK, you should makesure that ddb is never entered if you don't want it to
wait.  Entering ddb decreases the chance of getting a clean dump and
reboot.  There is currently no simple way of returning from ddb to continue
as if ddb wasn't configured except when ddb was entered via Debugger()
(if it was entered via kdb_trap(), then you have to modify some ddb code
or variables to get it to return 0).  The normal way to quit ddb after a
fatal trap is to use the builtin panic, but this complicates the trap
frames.

>> It'll only handle 98% of all hardware that is running in a VGA compatible
>> mode.  I guess most X modes aren't VGA compatible.

>Hmmm.  I'd have to check that.  We're not interested in the
>non-compatible modes, we're just interested in whether we can set a
>VGA compatible mode when we need it.  My program ran on an ET4000, and
>it worked OK, but I suppose it's possible that more modern hardware
>might not have a simple way to set it back to character mode.  I'll
>enquire.

I'm most familiar with the ET400.  It has locks to prevent inadvertent
access to the special Tseng registers.  Some of these locks must be
opened to change the bits to enable fairly standard graphics features.
E.g., there's one for interlace mode.  To work on an ET400, you would
have to use the keys for these locks or maybe depend on the X server
leaving everything unlocked.  I think there are no standards for the
keys, and more modern graphics cards have more things to lock, so
simply stuffing the VGA registers with standard values is unlikely
to work.  I've never had any success with using vidcontrol to fix up
the state on Et4000/W32 or S3 cards after the X server has crashed.

Bruce