Date: Sun, 30 Oct 2005 11:45:14 -0500 From: Sergey Babkin <babkin@verizon.net> To: Kris Kennaway <kris@obsecurity.org> Cc: gbergling@0xfce3.net, babkin@users.sourceforge.net, phk@phk.freebsd.dk, freebsd-arch@freebsd.org Subject: Re: wscons for FreeBSD? Message-ID: <4364F89A.29B607B4@verizon.net> References: <12768156.1130520253107.JavaMail.root@vms073.mailsrvcs.net> <200510281435.41700.jhb@freebsd.org> <4362B611.B4A12AF8@verizon.net> <20051028.215049.102576958.imp@bsdimp.com> <20051030104814.GA32477@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > On Fri, Oct 28, 2005 at 09:50:49PM -0600, M. Warner Losh wrote: > > In message: <4362B611.B4A12AF8@verizon.net> > > Sergey Babkin <babkin@verizon.net> writes: > > : John Baldwin wrote: > > : > > > : > On Friday 28 October 2005 01:24 pm, Sergey Babkin wrote: > > : > > >From: John Baldwin <jhb@freebsd.org> > > : > > > > > : > > : > > * When entering panic/debugger mode the console > > : > > should reset its video mode to the one where > > : > > the panic information is visible. > > : > > > : > I think this might be kind of hard since you really don't know what X has done > > : > to the hardware unless you make X talk to the console driver to do > > : > everything. > > : > > : Can you re-initialize the device from scratch? My knowledge > > : about the video hardware dates to SVGA times and even that > > : is not too deep. > > : > > : Maybe provide a basic SVGA re-initialization routine on x86 and have > > : an interface for the third-party in-kernel drivers that > > : would contain the re-initialization routine. > > > > When this has come up in the past, those in the know say that it takes > > card specific registers and knowledge to reset these cards' video > > modes. > > Even if it doesn't work on all cards, if there's some method that will > at least work for a subset of configurations it may be worth > investigating: by that point the machine has panicked anyway, so > what's the worst that can happen? I think that if there are no endless busy waits, nothing should make the situation any worse. I guess for VESA-compatible cards the VESA BIOS couls be used too, but that's much more complicated to do and much more prone to things going wrong during resets. But I guess in any case providing an interface for the in-kernel reset drivers would solve the problem as long as there are those drivers. Their implementation can probably be extracted from XF86, though of course it would need extra work. -SB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4364F89A.29B607B4>