[PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

Ahmed S. Darwish darwish.07 at gmail.com
Wed Jan 26 07:49:54 EST 2011


On Wed, Jan 26, 2011 at 06:25:19AM +1000, Linus Torvalds wrote:
> On Tue, Jan 25, 2011 at 11:47 PM, Ahmed S. Darwish <darwish.07 at gmail.com> wrote:
> >
> > As a possible solution, below patches prototypes the idea of persistently
> > storing the kernel log ring to a hard disk partition using the enhanced BIOS
> > 0x13 services.
> >
> Quite frankly, I'm not likely to _ever_ merge anything like this.
> Over the years, many people have tried to write things to disk on
> oops. I refuse to take it. No way in hell do I want the situation of
> "the system is screwed, so let's overwrite the disk" to be something
> the kernel I release might do. It's crazy. That disk is a lot more
> important than the kernel, and overwriting it when we might have
> serious memory corruption issues or something is not a thing I feel is
> appropriate.

OK, I've carefully read all the criticism posted here and in the other
replies. A short summary:

- It will be _too_ much to restore the PIC, IO-APIC, PCI configuration,
  and disk controllers to the BIOS Power-on self-test (POST) state. The
  solution will not be guaranteed to work on all machines.

- The write path of the BIOS INT 0x13 services is not tested enough by
  contemporary x86 kernels (Windows and Linux). Thus, that part of the
  BIOS is probably not as stable as I originally claimed.

Possible solutions:

- Having a minimal "fail-safe" disk controller driver to access the
  disk. This can't be made "perfect" enough to work on all combinations
  of machines (Though it can work on a small subset, e.g. the usual lot
  of x86 laptops with Intel chipsets). Linus is not OK with the _whole_
  idea of doing _any_ disk write on panic.

- Use kexec/kdump. I wonder though, can kexec work on early panics? The
  kind where the disk itself might not yet be initialized?

  If not, can kexec be modified to do so? That possibly needs the help
  of a a bootloader extension.

- The latest approach (proposed by Linus) is to forget the disk: jump to
  real-mode, but display the kernel log in a fancy format (with scroll
  ups and downs) instead.

  Will re-initializing the VGA registers to their POST state be possible?
  If not, what about a "fail-safe" VGA driver?

I'm most likely going to implement either the second or the third point,
so I'd really appreciate some input.


> If you want to do the BIOS services thing, do it for video: copy the
> oops to low RAM, return to real mode, re-run the graphics card POST
> routines to initialize text-mode, and use the BIOS to print out the
> oops.  That is WAY less scary than writing to disk.
>                               Linus


More information about the kexec mailing list