lkml.org 
[lkml]   [2011]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

    * Ahmed S. Darwish <darwish.07@gmail.com> wrote:

    > Hi,
    >
    > I've faced some very early panics in latest kernel. Being a run of the mill
    > x86 laptop, the machine is void of debugging aids like serial ports or
    > network boot.
    >
    > 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.
    >
    > The used BIOS INT 0x13 functions are the same ones originally used by all
    > contemporary bootloaders to load the Linux kernel. If the kernel code is
    > already loaded to RAM and being executed, such parts of the BIOS should be
    > stable enough.
    >
    > The basic idea is to switch from 64-bit long mode all the way down to 16-bit
    > real-mode. Once in real-mode, we reset the disk controller and write the log
    > buffer to disk using a user-supplied absolute disk block address (LBA).
    >
    > Doing so, we can capture very early panics (along with earlier log messages)
    > reliably since the writing mechanism has minimal dependency on any Linux code.
    >
    > Unfortunately, there are problems on some machines.
    >
    > In my laptop, when calling the BIOS with the "Reset Disk Controllers" command
    > or even issuing a direct "Extend Write" without a controller reset, the BIOS
    > hangs for around __5 minutes__. Afterwards, it returns with a 'Timeout' error
    > code.
    >
    > The main problem, it seems, is that the BIOS "Reset controller" command is not
    > enough to restore disk hardware to a state understandable by the BIOS code.
    >
    > So:
    >
    > - Is it possible to re-initialize the disk hardware to its POST state (thus
    > make the BIOS services work reliably) while keeping system RAM unmodified?
    > - If not, can we do it manually by reprogramming the controllers?
    >
    > The first patch (#1) implements the longMode -> realMode switch and invokes
    > the BIOS. The second reserves needed low-memory areas for such code and
    > registers a panic logger using the kmsg_dump interface.
    >
    > Both patches are on '-next' and include XXX marks where further help is also
    > appreciated. Please remember that these patches, while tested, are now for
    > prototyping the technical feasibility of the idea.
    >
    > Diffstat:
    >
    > arch/x86/kernel/saveoops-rmode.S | 483 ++++++++++++++++++++++++++++++++++++++
    > arch/x86/include/asm/saveoops.h | 15 ++
    > arch/x86/kernel/saveoops.c | 219 +++++++++++++++++
    > arch/x86/kernel/setup.c | 9 +
    > arch/x86/kernel/Makefile | 3 +
    > lib/Kconfig.debug | 15 ++
    > 6 files changed, 744 insertions(+), 0 deletions(-)

    Ok, i have to admit that while i'm a rabid BIOS-hater i find this debug feature very
    very interesting, for the plain reason that if it's implemented in a robust and
    clever way then this has a chance to improve debuggability of pretty much any Linux
    laptop quite enormously!

    While we generally thoroughly hate BIOSes from beginning to end, one thing can be
    said, a BIOS bootstraps very early during bootup, and it's relatively simple to
    trigger as well.

    Also, since latest kernels do not stomp on BIOS data structures anymore (low RAM),
    there's some good chance it's still functional at the point of crash - be that an
    early crash or a later crash.

    I think the biggest areas of practical concern would be:

    - Can this mechanism ever, under any circumstance corrupt any real data, destroy
    the MBR or do other nasties. Can you think of any additional fail-safe measures
    where you could _further robustify the BIOS calls_ to make sure it can never go
    to the wrong sector(s)? I really do not want to think of trusting a BIOS to
    _write to my disk_.

    - Is there some hidden disk area somewhere on PCs, or somewhere on a real partition
    on typical Linux distributions, which we could use without having to reinstall
    the box? This would increase utility and availability enormously. I'm thinking of
    partition _ends_ which sometimes get rounded in an awkward way and which are
    potentially skipped by most Linux filesystems. Even a very small, 512 bytes of
    area would be extremely useful for debugging weird suspend hangs ...

    - Could we automate the recovery of the dump, and just put it into the regular
    kernel log on the next (successful) bootup (on a feature-enabled kernel)? That
    would make the log of the 'previous crash' very conveniently available in dmesg
    and the syslog. Tools like kerneloops could make use of it immediately.

    All in one, a very intriguing idea IMO, and the hardest bits (lowlevel x86
    transition) is all implemented already.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2011-01-25 15:15    [W:0.026 / U:90.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site