lkml.org 
[lkml]   [2005]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: -mm -> 2.6.13 merge status
Date

On Tue, 21 Jun 2005 14:04:41 PDT, Andrew Morton wrote:
> Gerrit Huizenga <gh@us.ibm.com> wrote:
> >
> > Kexec/kdump has a chance of working reliably.
>
> IOW: Kexec/kdump has a chance of not working reliably.
>
> Worried.

No worries. Machine locks up hard, hardware failures, etc., there
is a possibility that nothing but a hard reset can unlock a machine.
But that is rare and outside the scope of the simple locking problems
that today prevent crash dumps. There are still some rough edges in
PCI shutdown code, reinitialization, etc. that will need to be shaken
out over time with more experience, but those at least can be addressed
in the fundamental architecture of kexec/kdump.

About the only possible solution that *might* be fail proof (and even
that case I doubt) would be an external dump program under control
of the firmware (assuming the firmware can still run) which does a
copy of memory off to some device without any assistance from the
kernel.

Kexec/kdump needs much wider exposure at this point and there will
a few bumps along the way. They should be isolated to cases where
the machine is already crashing and the only thing that doesn't work
is the crash dump/restart. And those we will fix like any other bugs.

gerrit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-21 23:38    [from the cache]
©2003-2011 Jasper Spaans