Re: [Crash-utility] [PATCH] ppc64: fix 'bt' command for vmcore captured with fadump.
----- Original Message -----
... [cut] ...
>
> Also, the exception frame doesn't even show the [bracketed] type of exception
> that occurred -- it's just a register dump followed by the remainder of the
> backtrace. Upon a quick glance, it's not obvious that they are even active
> tasks. And traditionally, all of the other architectures have always dumped
> a full trace.
>
> I'm not sure what the mechanism is for shutting down the non-active
> FADUMP tasks, so that's why I asked if you could restrict this change
> to just those types of dumps. (For that matter, is it even possible to
> differentiate a real kdump from an FADUMP dumpfile -- aside from a
Hi Dave,
Differentiating a kdump and fadump dumpfile is not possible except that the
stack search would invariably fail and ptregs are guaranteed to be saved by
firmware in case of fadump. Posted v2 that doesn't change bt output for anything
but active tasks in case of fadump..
Ok, so let me get this straight. The only difference I see with the v2 patch
is that fadump non-panicking active tasks change from something like this:
PID: 0 TASK: c000000000e7f6d0 CPU: 0 COMMAND: "swapper"
#0 [c000000000f2ba30] (null) at 3aae291c67 (unreliable)
#1 [c000000000f2bae0] .tick_dev_program_event at c0000000000d16fc
#2 [c000000000f2bb90] .__hrtimer_start_range_ns at c0000000000c4bcc
#3 [c000000000f2bcb0] .tick_nohz_stop_sched_tick at c0000000000d2d30
#4 [c000000000f2bdc0] .cpu_idle at c000000000015bf0
#5 [c000000000f2be70] .rest_init at c000000000009de4
#6 [c000000000f2bef0] .start_kernel at c000000000850eb4
#7 [c000000000f2bf90] .start_here_common at c0000000000083d8
to this:
PID: 0 TASK: c000000000e7f6d0 CPU: 0 COMMAND: "swapper"
#0 [c000000000f2bd50] (null) at 0 (unreliable)
#1 [c000000000f2bdc0] .cpu_idle at c000000000015bf0
#2 [c000000000f2be70] .rest_init at c000000000009de4
#3 [c000000000f2bef0] .start_kernel at c000000000850eb4
#4 [c000000000f2bf90] .start_here_common at c0000000000083d8
But with your v1 patch, you also dumped the exception frame:
PID: 0 TASK: c000000000e7f6d0 CPU: 0 COMMAND: "swapper"
R0: 0000000000000000 R1: c000000000f2bd50 R2: c000000000f27628
R3: 0000000000000000 R4: 0000000000000000 R5: 8000000002144400
R6: 800000001314c4f8 R7: 0000000000000000 R8: 0000000000000000
R9: ffffffffffffffff R10: 0000000000000000 R11: 80003fbff901700c
R12: 0000000000000000 R13: c000000000ff2500 R14: 0000000001a3fa58
R15: 00000000002230a8 R16: 0000000000223150 R17: 0000000000223144
R18: 0000000000c8a098 R19: 0000000002b13a58 R20: 0000000000000000
R21: 0000000002b135d8 R22: 0000000002b13530 R23: 0000000002280000
R24: 0000000002b135f0 R25: c000000000fd5c48 R26: c0000000010942f0
R27: c0000000010942f0 R28: c0000000005fd168 R29: 0000000000000008
R30: c000000000eb1d68 R31: c000000000f28080
NIP: c000000000055730 MSR: 8000000000009032 OR3: 0000000000000000
CTR: 0000000000000000 LR: c000000000057350 XER: 0000000000000000
CCR: 0000000024000048 MQ: 0000000000000000 DAR: 000001000ad763b0
DSISR: 0000000000000000 Syscall Result: 0000000000000000
NIP [c000000000055730] .plpar_hcall_norets
LR [c000000000057350] .pseries_shared_idle_sleep
#0 [c000000000f2bd50] (null) at 0 (unreliable)
#1 [c000000000f2bdc0] .cpu_idle at c000000000015bf0
#2 [c000000000f2be70] .rest_init at c000000000009de4
#3 [c000000000f2bef0] .start_kernel at c000000000850eb4
#4 [c000000000f2bf90] .start_here_common at c0000000000083d8
Again, I don't understand how the non-panicking active tasks are stopped
by the fadump facility, but is it because you cannot differentiate kdumps
from fadumps that you don't show the exception frame with the v2 patch?
Would it be possible to also show the exception frame type in brackets and
the register dump for those fadump non-panicking active tasks?
Dave