Russell King wrote:
On Sun, Apr 11, 2010 at 11:06:09PM -0700, David VomLehn wrote:
This patch makes panic() and die() registers available to, for example,
panic notifier functions. Panic notifier functions are quite useful
for recording crash information, but they don't get passed the register
values. This makes it hard to print register contents, do stack
backtraces, etc. The changes in this patch save the register state when
panic() is called and introduce a function for die() to call that allows
it to pass in the registers it was passed.
Can you explain why you want this?
I'm wondering about the value of saving the registers; normally when a panic
occurs, it's because of a well defined reason, and not because something
went wrong in some CPU register; to put it another way, a panic() is a
more controlled exception than a BUG() or a bad pointer dereference.
More context probably helps, starting with noting that the platform is
an embedded
one. (I'm at the Eembedded Linux Conference, which is why my reply is so
tardy).
In embedded systems we frequently (probably?) don't have the resources
to create or
store a crash dump. A very common approach is to record a subset of the
system
state that is likely to help diagnose the failure. The state information
is then stored\
on the system or sent upstream to some network-connected node. When I
gave a talk
about this at the ELC, I polled the audience and got at least half a
dozen other
companies using the same approach. This is the first set of patches to
allow this
common embedded community requirement to be met. My expectation that
register
values will be wanted by everyone doing this kind of targeted state
reporting.
I should also note that I regard this is more the beginning of a
conversation on how
to diagnose kernel (and, possibly, application) failures on crash
dump-less systems.
I would expect to see some number of patches, some of which will
ultimately be
dropped in favor of other approaches.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
