On Sat, 10 Jan 2009, Andi Kleen wrote:
>
> I think that's mostly because kexec from arbitary context is a
> somewhat unstable concept.
I think that's the understatement of the year.
We have tons of problems with standard suspend-to-ram, and that's when the
suspend sequence has done its best to make everything quiescent. Expecting
that we can reinitialize all the hardware at some random point when things
are going haywire is "optimistic" at best.
So of course it will work on some hardware and not others.
I think we've been fairly successful at keeping a running system for
_most_ of our bugs. Even when things go bad with X running, it's quite
often possible to ssh in over the network (although it's often better if
you were already connected) and see the dump.
Not always, obviously. Many dumps really are painful. I'm hoping that
kernel-mode-setting will at least give us the oops message _more_ of the
time.
As far as I'm concerned, digital cameras have been more useful than kernel
dumps to kernel debugging.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
