From owner-freebsd-current Tue Apr 23 03:02:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA22134 for current-outgoing; Tue, 23 Apr 1996 03:02:00 -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 DAA22106 for ; Tue, 23 Apr 1996 03:01:24 -0700 (PDT) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id MAA20819 for current@freebsd.org; Tue, 23 Apr 1996 12:00:49 +0200 Message-Id: <199604231000.MAA20819@nixpbe.pdb.sni.de> Subject: Re: request for a new "feature" as regards DDB To: bde@zeta.org.au (Bruce Evans) Date: Tue, 23 Apr 96 12:00:43 MDT From: Greg Lehey Cc: lehey.pad@sni.de, smpatel@umiacs.UMD.EDU, current@freebsd.org, hackers@freebsd.org In-Reply-To: <199604230928.TAA12645@godzilla.zeta.org.au>; from "Bruce Evans" at Apr 23, 96 7:28 pm X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) 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 syscons, you can still change after entering DDB", or are you saying something else? >> Good idea. I'll add it to my list. For those who don't know, I had >> planned to make some major changes to ddb Real Soon Now. > >>> While we're talking about DDB, can't we have it timeout in 30s if you >>> don't hit a key (and then generate a core dump). > >> Also a good idea. > > 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. >>> What about making DDB a LKM also? Whenever I find myself using DDB, I > >> Yes, I had planned on that. Who can give me info on how to write >> LKMs? > > Begin with /usr/src/share/examples/lkm. Thanks. >> On the other subject, changing out of X into character mode: I believe >> that a debugger should have as little involvement with the subject >> being debugged (in this case, the kernel), as possible. I can't see > > Yes, it shouldn't touch anything that it doesn't fully understand or > can't restore. > >> why ddb shouldn't understand enough about generic VGA to be able to >> put it back in 25x80 mode. Somewhere I have a little program which I >> used to do this under BSD/386 0.3, where the X server wasn't always >> successful. It's only a few lines. I'm sure somebody's going to come >> up with "yes, but that's not completely generic", but I don't think >> this is an adequate argument. Make it a config option for ddb, and > > "yes, but that's not completely generic" :-). > >> it'll handle 98% of all hardware. If somebody with the other 2% >> wants, they can do it for that hardware as well. > > 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. Greg