willy tarreau <wtarreau@yahoo.fr> writes:
> > Out of 5 panic() tries, kmsgdump was able to do
> > something only once.
> > The four other times, kmsgdump either:
> > - Printed "disabling sumetric I/O mode. Last
> > chance for SysRQ" and
> > then got stuck.
> > or - Caused an oops (available).
> >
> > This was on a two-CPU box.
> >
> > Is kmsgdump SMP-safe ?
>
> It should try to, because in machine_dump(), the
> other CPUs are stopped, IIRC, although I'm not
> really sure about this since it's been a long time
> since I last looked at the code.
>
> Indeed, there are many cases where the kernel is under
> weird condition, and the oops isn't catchable.
Well, here I was trying to test kmsgdump with:
#include <linux/module.h>
void init_module()
{
panic("Forced panic");
}
void cleanup_modules()
{
}
which was insmod'ed.
> Even with a UP kernel I often get stuck. The reason
> is mainly because kmsgdump still has lots of work to
> do after the oops and sometimes this is not completely
> possible. I began to write a new version in which
> the system would be pre-initialized so that the CPU
> would just have to reset to enter kmsgdump (even a
> triple fault would work). But I don't have time to
> work on it, even if I really would like to finish it.
That's really bad, kmsg was the only way I know how to catch oopses
and lockups under X.
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:17 EST