Date: Tue, 23 Apr 96 13:37:28 MDT From: Greg Lehey <lehey.pad@sni.de> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org (FreeBSD hackers) Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604231137.NAA26445@nixpbe.pdb.sni.de> In-Reply-To: <199604231045.UAA15838@godzilla.zeta.org.au>; from "Bruce Evans" at Apr 23, 96 8:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
This is not really a -current theme, so I'm just copying hackers. >>> 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. OK, if that's all it takes. >>> 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. This looks like the wrong solution. The correct one would be either 1: Make it easier to return from ddb out of kdb_trap. Lowbug doesn't have any problems there, so it must be possible. 2: Make the panic exit tidy up the stack first, so you see what you want to see. >>> 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. Oh well. If it's really that bad, I suppose I would have to give in, but I'll check it out first. BSDI seem to bear you out: in 2.1, if you go into the kernel debugger in X, it plays pretty patterns in the keyboards LEDs. Any opinions on whether this is a good idea or not? Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604231137.NAA26445>