Message-Id: <20070319.123836.39155546.davem@davemloft.net>
Date:	Mon, 19 Mar 2007 12:38:36 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	zaitcev@...hat.com
Cc:	jg@...top.org, linux-kernel@...r.kernel.org
Subject: Re: BSOD

From: Pete Zaitcev <zaitcev@...hat.com>
Date: Mon, 19 Mar 2007 12:08:07 -0700

> On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys <jg@...top.org> wrote:
> 
> > Also more seriously, a somewhat hybrid approach is in order for mode
> > setting: simple mode setting isn't much code and is required for sane
> > behavior on crash (it is nice to get oopses onto a screen); but the full
> > blown mode setting/configuration problem is so large that on some
> > hardware, it is likely left best left to a helper process (not the X
> > server).
> 
> Jim, I doubt that a mode switch on oops is a good idea. Maybe I'm unlucky,
> but in my experience, it often is the case that systems fail to switch
> to text mode for shutdown. What is amazing, the very same systems switch
> to text mode on <Alt>F1 just fine, and then back to <Alt>F7!
> I would hazard a guess that this happens because nobody cares
> about shutdown modes to fix them. But then the same is true for
> crashes.
> 
> I understand that you have your own experience, but thought to note
> this all the same.
> 
> From the constructive angle, I think that a crash should render into
> existing mode, into the currently mapped frame buffer. This is the
> only way how it can be made to work reliably.

All of this talk makes me appreciate what happens on Sparc machines
even though it has more often than not been ridiculed.

There the firmware sets the resolution and that's basically what
the kernel and X uses, no mode changes are performed.

With that kind of setup even the system firmware (such as OFW) can
render error messages onto the console while X is active.

The disadvantage of course is that you're stuck with whatever video
mode you configured the firmware to use.  The advantage is that you
always get crash messages and neither X nor the kernel framebuffer
driver need to know how to switch modes.

Back to the main discussion, when we get an OOPS you can basically
assume that nothing works.  So I definitely agree with Peter.
There is no way we should try to execute something so non-trivial
as a mode switch when the kernel is on it's last legs.

There are four pieces of information the kernel needs from the X
server when it switches modes in order to do this:

1) pixel resolution
2) frame buffer base, should be specified in an extremely
   portable a manner (this means NOT using physical addresses
   or just PCI addresses), perhaps a PCI device specifier,
   BAR index, and offset from that BAR.
3) frame buffer w-skip (ie. how many bytes to get to the next
   scanline)
4) depth/bpp

This is also what the most minimal kernel framebuffer driver needs in
order to support a chip.

I understand that there are chips that can only be rendered into using
DMA or indirect accesses, that's a very real and tough problem to fix.
There is also the issue of making sure the graphics card accelerator
is not rendering anything (ie. it's pipeline FIFO has emptied) when
we try to render a panic message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists