From owner-freebsd-current Tue Feb 24 02:34:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14745 for freebsd-current-outgoing; Tue, 24 Feb 1998 02:34:53 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rah.star-gate.com ([209.133.7.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14724 for ; Tue, 24 Feb 1998 02:34:50 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id CAA23367; Tue, 24 Feb 1998 02:34:19 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199802241034.CAA23367@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Andrzej Bialecki cc: Kazutaka YOKOTA , freebsd-current@FreeBSD.ORG Subject: Re: Proposed addition to panic() behaviour In-reply-to: Your message of "Tue, 24 Feb 1998 11:13:16 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Feb 1998 02:34:19 -0800 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 24 Feb 1998, Kazutaka YOKOTA wrote: > > > >> > Many people (including me) suffered from panic while their console was in > > >> > graphic mode (e.g. X Window). I don't know if this would be proper place > > >> > to do this, but in case of panic (where everything is lost anyway) just > > >> > add there the code to forcefully reset the video card to set it in > > >> > known (and useful) mode... > > >> > > >> See the numerous "DDX in the kernel" discussions in the -current list > > >> archives to see why "just add there the code to forcefully reset the > > >> video card" requires knowing how the video card got in the mode it's > > >> in, and specific knowledge of the card (hint: write-only hardware > > >> registers not shadoewed in RAM). > > > > > > >But I also vaguely recall something like dump of VGA registers > > >when booted with -v, so they are stored somewhere, right? > > > > The video BIOS ROM contains the table of STANDARD register values only. > > We cannot know which additional registers should be set to what value. > > Ok. Call me stubborn, but why can't we just write the STANDARD register > values corresponding to the initial state of the card, and if the screen > is still garbled, well - at least we tried... But, my point is (or > maybe I'm still wrong), that *most of the time* this will restore the card > to some usable state... > Look I worked on low level graphic support for S3 cards as well as other graphic cards and is not an easy thing to do at least in a clean fashion. You can however write a simple shell program that monitors the X server and restart it if you need to or use xdm which is supposed to re-start an X server if it dies -- usually it just pops you back to a login screen if the X server dies. However... if you think you can do it go ahead thats the attitute which allow me to port X to 386bsd 0.0 8) Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message