[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
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.
- 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.
More information about the kexec