Currently dump_stack is printed once a spin_bug is detected for rwlock.
So provide an options to trigger a panic or watchdog bite for debugging
rwlock magic corruptions and lockups.
Change-Id: I20807e8eceb8b81635e58701d1f9f9bd36ab5877
[abhimany: replace msm with qcom]
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
Currently we cause a BUG_ON once a spin_bug is detected, but
that causes a whole lot of processing and the other CPUs would
have proceeded to perform other actions and the state of the system
is moved by the time we can analyze it.
Provide an option to trigger a watchdog bite instead so that we
can get the traces as close to the issue as possible.
Change-Id: Ic8d692ebd02c6940a3b4e5798463744db20b0026
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Once a spinlock lockup is detected on a CPU, we invoke a Kernel Panic.
During the panic handling, we might see more instances of spinlock
lockup from other CPUs. This causes the dmesg to be cluttered and makes
it cumbersome to detect what exactly happened.
Call spin_bug instead of calling spin_dump directly.
Change-Id: I57857a991345a8dac3cd952463d05129145867a8
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Data corruptions in the kernel often end up in system crashes that
are easier to debug closer to the time of detection. Specifically,
if we do not panic immediately after lock or list corruptions have been
detected, the problem context is lost in the ensuing system mayhem.
Add support for allowing system crash immediately after such corruptions
are detected. The CONFIG option controls the enabling/disabling of the
feature.
Change-Id: I9b2eb62da506a13007acff63e85e9515145909ff
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
[abhimany: minor merge conflict resolution]
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
