[Novalug] Does the Linux Kernel need a BSOD?

[Chris Sykes]

I assume that a fine upstanding recycling of old hardware man such as
yourself compiles his own kernels to have the bare minimum they need
to boot and run your hardware. As such you would simply compile your
kernels with the mode-setting feature disabled.

For those of us that do want that BSOD info we will have it when our
machine locks up in an X session and ctrl-alt-backspace (let alone
del) just doesn't seem to do it for ya. I like a stable machine as
much as the next man but when I have no info to troubleshoot why it
isn't stable I can't really get there from here now can I?

It's a new feature (mainline in 2.6.27) to improve performance that I
welcome. My personal feelings are to move more of the graphics
subsystem into the kernel but not ala the MS route. There are better
ways of implementing it (KGI?).

This sums it up nice :
http://linux.slashdot.org/comments.pl?sid=528366&cid=23132574

My only concern is if X.org decides to drop mode-setting in userspace
as a result. That I would feel would inconvenience too many of the old
guard with their headless servers.

Course if you are one of those guys why are you running X at all? ;)


-Chris



On Wed, Apr 23, 2008 at 11:44 PM, Don E. Groves, Jr.
<dgrovesjr at gmail.com> wrote:
> >  A SOD (be it B or otherwise) is always a good idea.
>
>  Lets look at the "always a good idea" to use code-space/memory for this feature.
>  I have six plus computers running....
>  Only three even have a "monitor" attached and only two of those are active.
>  If a SOD condition occorred I'd only see any output on the two with
>  there monitors  active.
>  The third after figuring out something happened and plugging the TEXT
>  mode only monitor in might I see something.
>
>   So for these three the SOD code might be useful if it got activated.
>
>  The fourth is in a cubby-hole and most likely come unplugged and lose
>  power long before I attached a monitor to it. {it's a FIREWALL/router}
>    On this one the code would most likely be a wasted of limited resources.
>      {it only has 62924 KB of memory total, so every bit counts.}
>      {Also if the BIOS would let it boot without a video card I'd remove it.}
>
>  The Fifth a "Desktop" class machine with currently a busted video card
>  that I access by "vnc" {any more mostly because it's fun to do it that
>  way}
>   (Plus I currently have it's monitor connected to another machine.)
>  So and SOD code would never be seen.
>   Would such code be a waste of resources?
>   No because I will get around to fixing the video card problem real soon now.
>
>  The Sixth machine (also running Linux) is SPECIAL as it doesn't even
>  have a video card or a place to connect one to it.   {well maybe by a
>  USB port}
>   It's a Asus WL-700gE MWSR {ie a Wireless router with a few extra features.}
>   Any SOD ('b'lue or otherwise) code be a waste.
>
>  So out of six real machines running Linux (a few are running Virtual
>  machines) here only three or (maybe) four could ever possible see any
>  bennift{sp} from any standised SOD code that only outputted to a VIDEO
>  card.
>
>  As for the framebuffer (the Linux penguin generating) code.
>  The following from the kernel docs shows where the problem starts:
>
>  |  GOTCHA: A common bug report is enabling the framebuffer without enabling
>  | the framebuffer console.  Depending on the driver, you may get a
>  blanked or
>  | garbled display, but the system still boots to completion.  If you are
>  | fortunate to have a driver that does not alter the graphics chip, then you
>  | will still get a VGA console.
>
>  BUT full the "GOTCHA" with the "framebuffer" code is while for
>  supported cards the kernel has the code to go into Graphic Mode it in
>  all most all cases requires an external support program to go back to
>  some sort of TEXT mode.
>   So unless code is/was also added to enable a Graphic type error
>  message there is no place for the kernel to write the Error Message
>  to, since Text and Graphic modes are incompatable with each other.
>
>  The "Text mode like XTERM" is an emulation (or faked text mode).
>
>  --
>   DonJr
>
>
>  On Wed, Apr 23, 2008 at 6:59 PM, Nick Danger <nick at hackermonkey.com> wrote:
>  > Don E. Groves, Jr. wrote:
>  >  > So your saying that you think that BSOD support in the Kernel is a good idea?
>  >  > Even though it may require moving driver code {the Video Graphic
>  >  > handler(s) in this case} back inside the kernel.
>  >
>  >  A SOD (be it B or otherwise) is always a good idea. Maybe it doesnt need
>  >  to be graphical but there should be some trail to follow when something
>  >  goes awry.
>
>  > Last night I had a CentOS box go down, and come back. Nothing
>  >  on console, nothing in logs, it was almost as if we had a power blink
>  >  but nothing else did it nor did anything else register (and its on two
>  >  UPSs) VERY weird. Not that I want a machine to 'hang', but I was on top
>  >  of the 'failed ping' report within a few minutes so had I been witness
>  >  do something on the console like a BSOD "failed XXXX ; rebooting in 300
>  >  seconds", it might have been useful.
>  >
>  >  Dont we already have video support in the kernel anyway? I get a lovely
>  >  linux penguin in the corner of my screen when I boot the kernel,
>  >  assuming I give it the right 'mode' line on startup. Maybe thats not the
>  >  same thing.
>  >
>  >  Nick
>
>
> --
>  --
>  Don E. Groves, Jr.
>
>  Tag it's your turn now... ... ....
>  _______________________________________________
>
>
> Novalug mailing list
>  Novalug at calypso.tux.org
>  http://calypso.tux.org/cgi-bin/mailman/listinfo/novalug
>