You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the panic_on_oops is disabled, when getting a BUG hit in the code,
the system continues and does not panic. However, a short time later, a
hard lockup is hit and the system does panic. Even though the system
panicked at hard lockup, the panic string is still the first BUG hit.
For example:
Without the patch:
crash> sys | grep PANIC
PANIC: "BUG: unable to handle kernel paging request at ffffab835d7f9d50"
With the patch:
crash> sys | grep PANIC
PANIC: "Kernel panic - not syncing: Hard LOCKUP"
Let's search for the panic string based on the severity of the panic
event, and also refactor the get_panicmsg() a little bit to improve
readability.
Reported-by: John Pittman <[email protected]>
Signed-off-by: Lianbo Jiang <[email protected]>
0 commit comments