> But you are assuming that kmsg_dump is perfect and it isn't, in which case > by putting kmsg_dump in the kdump path, you actually may be blocking kdump > from working.
I think the concern is that kdump isn't perfect, so sometimes we don't get a good dump from it. In those cases it would have been nice to have a pstore log of the original problem. But ... I don't see an answer to this problem. Adding more code just increases the number of possible places we can fail (especially as we are executing in a state where we know that things are all messed up ... the first kernel panic'd because something bad happened that we didn't know how to fix). A boot argument might help - so we can force use of pstore in cases where kdump is failing (or prevent use of pstore in cases where it seem to be preventing us getting to kdump ... I don't have a preference). BUT this would only be useful if we had a repeatable problem so that we could switch to the other mode ... and it seems likely that the kinds of problems that cause pstore or kdump to fail would be weird cases that are not very repeatable :-( -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/