Re: [Crash-utility] [PATCH v5 0/4] arm64: more improvement of bt -f
On Wed, Jun 29, 2016 at 05:25:27PM -0400, Dave Anderson wrote: > > > Hi Takahiro, > > Here is another thing that I would prefer not to change/omit. > > In the current code, the raw exception frame data is dumped as > part of the "bt -[fF]" output, just prior to it being translated > as an exception frame: > > crash> bt -F > PID: 1223 TASK: 800020ef5780 CPU: 3 COMMAND: "sh" >... [ cut ] ... >#5 [800020b0bb70] do_mem_abort at 0808128c > 800020b0bb70: 800020b0bd40 el1_da+24 > 800020b0bb80: cpu_cgrp_subsys+152 0063 > 800020b0bb90: 800020b0bd40 sysrq_handle_crash+32 > 800020b0bba0: 0002 textbuf.34610 > 800020b0bbb0: 800020b0bbd0 kallsyms_token_index+43128 > 800020b0bbc0: 000f 0001 > 800020b0bbd0: 800020b0bc70 vprintk_default+56 > 800020b0bbe0: cpu_cgrp_subsys+152 0063 > 800020b0bbf0: sysrq_crash_op 0009 > 800020b0bc00: 0015 > 800020b0bc10: 0120 0040 > 800020b0bc20: 0001 > 800020b0bc30: log_wait+8 > 800020b0bc40: 47d4 > 800020b0bc50: 800022f337a4 > 800020b0bc60: 0106 0001 > 800020b0bc70: 0002 0106 > 800020b0bc80: log_buf_len cont > 800020b0bc90: 83cc28f0 text.34829+13 > 800020b0bca0: sys_write83d266c0 > 800020b0bcb0: 0006 cpu_cgrp_subsys+152 > 800020b0bcc0: 0063 sysrq_crash_op > 800020b0bcd0: 0009 > 800020b0bce0: 0015 0120 > 800020b0bcf0: 0040 sys_call_table > 800020b0bd00: 800020b08000 800020b0bd40 > 800020b0bd10: sysrq_handle_crash+12 800020b0bd40 > 800020b0bd20: sysrq_handle_crash+32 60400149 > 800020b0bd30: cpu_cgrp_subsys+152 [kmalloc-1024] >#6 [800020b0bd40] el1_da at 08084568 >PC: 08457fc8 [sysrq_handle_crash+32] >LR: 08457fb4 [sysrq_handle_crash+12] >SP: 800020b0bd40 PSTATE: 60400149 > X29: 800020b0bd40 X28: 800020b08000 X27: 087e2000 > X26: 0040 X25: 0120 X24: 0015 > X23: X22: 0009 X21: 08e071b0 > X20: 0063 X19: 08dda000 X18: 0006 > X17: 83d266c0 X16: 081c68b8 X15: 08e6cc95 > X14: 83cc28f0 X13: 08e6c758 X12: 08dda7a0 > X11: 0106 X10: 0002 X9: 0001 >X8: 0106 X7: X6: 800022f337a4 >X5: 47d4 X4: X3: >X2: 08dda7b8 X1: X0: 0001 > ORIG_X0: 08dda000 SYSCALLNO: 80002104d418 > ... > > whereas with the v5 patchset, the exception frame only gets translated, > but the actual raw memory never gets dumped: I surely remember that you said that would not be an issue when I submitted older version, maybe v1 or v2. > crash> bt -F > PID: 1223 TASK: 800020ef5780 CPU: 3 COMMAND: "sh" > ... [ cut ] ... >#5 [800020b0bb70] do_mem_abort at 08081288 > 800020b0bb70: 800020b0bd40 el1_da+24 > 800020b0bb80: cpu_cgrp_subsys+152 0063 > 800020b0bb90: 800020b0bd40 sysrq_handle_crash+32 > 800020b0bba0: 0002 textbuf.34610 > 800020b0bbb0: 800020b0bbd0 kallsyms_token_index+43128 > 800020b0bbc0: 000f 0001 > 800020b0bbd0: 800020b0bc70 vprintk_default+56 > 800020b0bbe0: cpu_cgrp_subsys+152 0063 > 800020b0bbf0: sysrq_crash_op 0009 > 800020b0bc00: 0015 > 800020b0bc10: 0120 0040 >#6 [800020b0bc20] el1_da at 08084564 Do you think that those symbolic display are still useful though it is not quite easy to recognize which register has what value? Even more, is *not* a stack for do_mem_abort(). It is just wrong and will confuse people. So this is another example of improvement on my patches. > --- --- >PC: 08457fc8 [sysrq_handle_crash+32] >LR: 08457fb4 [sysrq_handle_crash+12] >SP: 800020b0bd40 PSTATE: 60400149 > X29: 800020b0bd40 X28: 800020b08000 X27: 087e20
Re: [Crash-utility] [PATCH v5 0/4] arm64: more improvement of bt -f
On Wed, Jun 29, 2016 at 04:44:41PM -0400, Dave Anderson wrote: > > > Hi Takahiro, > > > > I applied patches 1/2 and 2/2 from the v5 patchset. But I can't > > believe the results are what you intended? > > Obviously I meant 1/4 and 2/4 above. > > However, I was under the impression that the 3/4 patch was a standalone > patch that only served to change the text address displayed, Right. I might have made some mistake when I squashed up the changes. > and that > "adding this patch was a discussion topic": ??? > > > On arm64, the link register (LR) holds a return address, which is the one > > just after a branch instruction. So using a saved lr as PC for backtracing > > might cause some confusion. > > For example, in kernel/entry.S, > > work_resched: > > ... > > bl schedule > > > > ret_to_user: > > ... > > > > The current code shows "ret_o_user", instead of "work_resched", > > as a caller of schedule(). > > > > This patch corrects a PC by decrementing it by 4. > > But please note that this change may also make people a bit confused > > because a value of LR in the stack dump of "bt -f" doesn't match with > > an address in one-line summary. > > > > #2 [cc7511407eb0] schedule at d628aee0 > > cc7511407eb0: cc6d22f23080 d5b44d6c <= LR > > cc7511407ec0: cc7511407ed0 > > #3 [cc7511407ed0] work_resched at d5b44d68 <= correcrted PC > > > > Signed-off-by: AKASHI Takahiro > > ...and as you subsequently mentioned, "adding this patch was a discussion > topic". > > But anyway, for the hell of it, I subsequently applied 3/4, and now I at > least see > the IPI exception frames: Sure that I did make this change recently. I mean, it is intentional but it should not have gone with patch#3 but patch#1. > > crash> bt -a > PID: 0 TASK: 08dcd900 CPU: 0 COMMAND: "swapper/0" > PC: 080857c0 [arch_cpu_idle+16] > LR: 080857bc [arch_cpu_idle+12] > SP: 08dc3f10 PSTATE: 60400149 > X29: 08dc3f10 X28: 08dc X27: > X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 > X23: 08dc X22: 08bd0270 X21: 08dc > X20: 08dc5b88 X19: X18: a632f641 > X17: 7da57880 X16: 081d9838 X15: 383a0a79 > X14: b2b0b162 X13: 5f2cbeec X12: 00045a9e > X11: 8000213bd800 X10: 0850 X9: 08dc > X8: 0001aa07 X7: 003d X6: 0015752a > X5: 0100 X4: 01c0 X3: > X2: 0001 X1: X0: > > #0 [08dc3f10] arch_cpu_idle at 080857bc > #1 [08dc3f20] cpu_startup_entry at 080f26c8 > #2 [08dc3f80] rest_init at 087c792c > #3 [08dc3fa0] start_kernel at 08b10b6c > > PID: 0 TASK: 8000218c0c80 CPU: 1 COMMAND: "swapper/1" > PC: 080857c0 [arch_cpu_idle+16] > LR: 080857bc [arch_cpu_idle+12] > SP: 8000218cff60 PSTATE: 6349 > X29: 8000218cff60 X28: 8000218cc000 X27: > X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 > X23: 8000218cc000 X22: 08bd0270 X21: 8000218cc000 > X20: 08dc5b88 X19: X18: 016d > X17: 007f8b122780 X16: ffc0001adf68 X15: 0005 > X14: 000c80096000 X13: 8000212b6600 X12: 00047ae2 > X11: 800021089980 X10: 0850 X9: 8000218cc000 > X8: 0001aa07 X7: 0243 X6: 0015752a > X5: 0100 X4: 03c0 X3: > X2: 0001 X1: X0: > > #0 [8000218cff60] arch_cpu_idle at 080857bc > #1 [8000218cff70] cpu_startup_entry at 080f26c8 > #2 [8000218cffd0] secondary_start_kernel at 0808e1e8 > > PID: 1324 TASK: 80002018be80 CPU: 2 COMMAND: "dhry" > PC: 004016a4 LR: 004016a4 SP: c10c40a0 > X29: c10c40a0 X28: X27: > X26: X25: 00402138 X24: 004021f0 > X23: X22: X21: 004001a0 > X20: X19: X18: > X17: 0001 X16: X15: 00493000 > X14: 00498000 X13: X12: 0005 > X11: 001e X10: 0101010101010101 X9: f59a9190 > X8: 7f7f7f7f7f7f7f7f X7: 1f535226301f2b4c X6: 0003001d1000 > X5: 00101d000300 X4: X3: 4952545320454d4f
Re: [Crash-utility] [PATCH v5 0/4] arm64: more improvement of bt -f
Dave, If you don't like my patches, that is OK. Applying them or not is totally up to you. I will *never* submit my patches again. Having said so, I think I would better explain my intentions on the code. On Wed, Jun 29, 2016 at 04:09:01PM -0400, Dave Anderson wrote: > > > Hi Takahiro, > > I applied patches 1/2 and 2/2 from the v5 patchset. But I can't > believe the results are what you intended? > > For example, taking the 4.6 vmcore that you gave to me, here is the > current crash utility's output of "bt -a", where the crashing task > entered crash_kexec() via the sysrq-c page fault exception, and the > tasks on the other cpus have all entered crash_save_cpu() on their > IRQ stack as a result of the shutdown IPI, one from user-space and > the others from the kernel: > > crash> bt -a > PID: 0 TASK: 08dcd900 CPU: 0 COMMAND: "swapper/0" >#0 [800022f42e50] crash_save_cpu at 0812ae44 >#1 [800022f43010] handle_IPI at 0808e718 >#2 [800022f43040] gic_handle_irq at 080815f8 >#3 [800022f43080] el1_irq at 08084720 > --- --- This part of dump shown above is the result of "kdump" mechanisms, and is *not* useful for you to understand what was happening on this CPU when a crash occurred on the other CPU, #3 in this case. >PC: 080857c0 [arch_cpu_idle+16] >LR: 080857bc [arch_cpu_idle+12] >SP: 08dc3f10 PSTATE: 60400149 > X29: 08dc3f10 X28: 08dc X27: > X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 > X23: 08dc X22: 08bd0270 X21: 08dc > X20: 08dc5b88 X19: X18: a632f641 > X17: 7da57880 X16: 081d9838 X15: 383a0a79 > X14: b2b0b162 X13: 5f2cbeec X12: 00045a9e > X11: 8000213bd800 X10: 0850 X9: 08dc >X8: 0001aa07 X7: 003d X6: 0015752a >X5: 0100 X4: 01c0 X3: >X2: 0001 X1: X0: > ORIG_X0: SYSCALLNO: 7fff >#4 [08dc3f10] arch_cpu_idle at 080857c0 >#5 [08dc3f20] cpu_startup_entry at 080f26cc >#6 [08dc3f80] rest_init at 087c7930 >#7 [08dc3fa0] start_kernel at 08b10b70 All you need to know is that CPU#0 was idle at the crash point. Whatever else do you want to know? -Takahiro AKASHI > PID: 0 TASK: 8000218c0c80 CPU: 1 COMMAND: "swapper/1" >#0 [800022f56e50] crash_save_cpu at 0812ae44 >#1 [800022f57010] handle_IPI at 0808e718 >#2 [800022f57040] gic_handle_irq at 080815f8 >#3 [800022f57080] el1_irq at 08084720 > --- --- >PC: 080857c0 [arch_cpu_idle+16] >LR: 080857bc [arch_cpu_idle+12] >SP: 8000218cff60 PSTATE: 6349 > X29: 8000218cff60 X28: 8000218cc000 X27: > X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 > X23: 8000218cc000 X22: 08bd0270 X21: 8000218cc000 > X20: 08dc5b88 X19: X18: 016d > X17: 007f8b122780 X16: ffc0001adf68 X15: 0005 > X14: 000c80096000 X13: 8000212b6600 X12: 00047ae2 > X11: 800021089980 X10: 0850 X9: 8000218cc000 >X8: 0001aa07 X7: 0243 X6: 0015752a >X5: 0100 X4: 03c0 X3: >X2: 0001 X1: X0: > ORIG_X0: SYSCALLNO: 7fff >#4 [8000218cff60] arch_cpu_idle at 080857c0 >#5 [8000218cff70] cpu_startup_entry at 080f26cc >#6 [8000218cffd0] secondary_start_kernel at 0808e1ec > > PID: 1324 TASK: 80002018be80 CPU: 2 COMMAND: "dhry" >#0 [800022f6ae50] crash_save_cpu at 0812ae44 >#1 [800022f6b010] handle_IPI at 0808e718 >#2 [800022f6b040] gic_handle_irq at 080815f8 >#3 [800022f6b080] el0_irq_naked at 08084c4c > --- --- >PC: 004016a4 LR: 004016a4 SP: c10c40a0 > X29: c10c40a0 X28: X27: > X26: X25: 00402138 X24: 004021f0 > X23: X22: X21: 004001a0 > X20: X19: X18: > X17: 0001 X16: X15: 00493000 > X14: 00498000 X13: X12: 00
Re: [Crash-utility] [PATCH v5 0/4] arm64: more improvement of bt -f
Hi Takahiro, Here is another thing that I would prefer not to change/omit. In the current code, the raw exception frame data is dumped as part of the "bt -[fF]" output, just prior to it being translated as an exception frame: crash> bt -F PID: 1223 TASK: 800020ef5780 CPU: 3 COMMAND: "sh" ... [ cut ] ... #5 [800020b0bb70] do_mem_abort at 0808128c 800020b0bb70: 800020b0bd40 el1_da+24 800020b0bb80: cpu_cgrp_subsys+152 0063 800020b0bb90: 800020b0bd40 sysrq_handle_crash+32 800020b0bba0: 0002 textbuf.34610 800020b0bbb0: 800020b0bbd0 kallsyms_token_index+43128 800020b0bbc0: 000f 0001 800020b0bbd0: 800020b0bc70 vprintk_default+56 800020b0bbe0: cpu_cgrp_subsys+152 0063 800020b0bbf0: sysrq_crash_op 0009 800020b0bc00: 0015 800020b0bc10: 0120 0040 800020b0bc20: 0001 800020b0bc30: log_wait+8 800020b0bc40: 47d4 800020b0bc50: 800022f337a4 800020b0bc60: 0106 0001 800020b0bc70: 0002 0106 800020b0bc80: log_buf_len cont 800020b0bc90: 83cc28f0 text.34829+13 800020b0bca0: sys_write83d266c0 800020b0bcb0: 0006 cpu_cgrp_subsys+152 800020b0bcc0: 0063 sysrq_crash_op 800020b0bcd0: 0009 800020b0bce0: 0015 0120 800020b0bcf0: 0040 sys_call_table 800020b0bd00: 800020b08000 800020b0bd40 800020b0bd10: sysrq_handle_crash+12 800020b0bd40 800020b0bd20: sysrq_handle_crash+32 60400149 800020b0bd30: cpu_cgrp_subsys+152 [kmalloc-1024] #6 [800020b0bd40] el1_da at 08084568 PC: 08457fc8 [sysrq_handle_crash+32] LR: 08457fb4 [sysrq_handle_crash+12] SP: 800020b0bd40 PSTATE: 60400149 X29: 800020b0bd40 X28: 800020b08000 X27: 087e2000 X26: 0040 X25: 0120 X24: 0015 X23: X22: 0009 X21: 08e071b0 X20: 0063 X19: 08dda000 X18: 0006 X17: 83d266c0 X16: 081c68b8 X15: 08e6cc95 X14: 83cc28f0 X13: 08e6c758 X12: 08dda7a0 X11: 0106 X10: 0002 X9: 0001 X8: 0106 X7: X6: 800022f337a4 X5: 47d4 X4: X3: X2: 08dda7b8 X1: X0: 0001 ORIG_X0: 08dda000 SYSCALLNO: 80002104d418 ... whereas with the v5 patchset, the exception frame only gets translated, but the actual raw memory never gets dumped: crash> bt -F PID: 1223 TASK: 800020ef5780 CPU: 3 COMMAND: "sh" ... [ cut ] ... #5 [800020b0bb70] do_mem_abort at 08081288 800020b0bb70: 800020b0bd40 el1_da+24 800020b0bb80: cpu_cgrp_subsys+152 0063 800020b0bb90: 800020b0bd40 sysrq_handle_crash+32 800020b0bba0: 0002 textbuf.34610 800020b0bbb0: 800020b0bbd0 kallsyms_token_index+43128 800020b0bbc0: 000f 0001 800020b0bbd0: 800020b0bc70 vprintk_default+56 800020b0bbe0: cpu_cgrp_subsys+152 0063 800020b0bbf0: sysrq_crash_op 0009 800020b0bc00: 0015 800020b0bc10: 0120 0040 #6 [800020b0bc20] el1_da at 08084564 --- --- PC: 08457fc8 [sysrq_handle_crash+32] LR: 08457fb4 [sysrq_handle_crash+12] SP: 800020b0bd40 PSTATE: 60400149 X29: 800020b0bd40 X28: 800020b08000 X27: 087e2000 X26: 0040 X25: 0120 X24: 0015 X23: X22: 0009 X21: 08e071b0 X20: 0063 X19: 08dda000 X18: 0006 X17: 83d266c0 X16: 081c68b8 X15: 08e6cc95 X14: 83cc28f0 X13: 08e6c758 X12: 08dda7a0 X11: 0106 X10: 0002 X9: 0001 X8: 0106 X7: X6: 800022f337a4 X5: 47d4 X4: X3: X2: 08dda
Re: [Crash-utility] [PATCH v5 0/4] arm64: more improvement of bt -f
- Original Message - > > > Hi Takahiro, > > I applied patches 1/2 and 2/2 from the v5 patchset. But I can't > believe the results are what you intended? Obviously I meant 1/4 and 2/4 above. However, I was under the impression that the 3/4 patch was a standalone patch that only served to change the text address displayed, and that "adding this patch was a discussion topic": > On arm64, the link register (LR) holds a return address, which is the one > just after a branch instruction. So using a saved lr as PC for backtracing > might cause some confusion. > For example, in kernel/entry.S, > work_resched: > ... > bl schedule > > ret_to_user: > ... > > The current code shows "ret_o_user", instead of "work_resched", > as a caller of schedule(). > > This patch corrects a PC by decrementing it by 4. > But please note that this change may also make people a bit confused > because a value of LR in the stack dump of "bt -f" doesn't match with > an address in one-line summary. > > #2 [cc7511407eb0] schedule at d628aee0 > cc7511407eb0: cc6d22f23080 d5b44d6c <= LR > cc7511407ec0: cc7511407ed0 > #3 [cc7511407ed0] work_resched at d5b44d68 <= correcrted PC > > Signed-off-by: AKASHI Takahiro ...and as you subsequently mentioned, "adding this patch was a discussion topic". But anyway, for the hell of it, I subsequently applied 3/4, and now I at least see the IPI exception frames: crash> bt -a PID: 0 TASK: 08dcd900 CPU: 0 COMMAND: "swapper/0" PC: 080857c0 [arch_cpu_idle+16] LR: 080857bc [arch_cpu_idle+12] SP: 08dc3f10 PSTATE: 60400149 X29: 08dc3f10 X28: 08dc X27: X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 X23: 08dc X22: 08bd0270 X21: 08dc X20: 08dc5b88 X19: X18: a632f641 X17: 7da57880 X16: 081d9838 X15: 383a0a79 X14: b2b0b162 X13: 5f2cbeec X12: 00045a9e X11: 8000213bd800 X10: 0850 X9: 08dc X8: 0001aa07 X7: 003d X6: 0015752a X5: 0100 X4: 01c0 X3: X2: 0001 X1: X0: #0 [08dc3f10] arch_cpu_idle at 080857bc #1 [08dc3f20] cpu_startup_entry at 080f26c8 #2 [08dc3f80] rest_init at 087c792c #3 [08dc3fa0] start_kernel at 08b10b6c PID: 0 TASK: 8000218c0c80 CPU: 1 COMMAND: "swapper/1" PC: 080857c0 [arch_cpu_idle+16] LR: 080857bc [arch_cpu_idle+12] SP: 8000218cff60 PSTATE: 6349 X29: 8000218cff60 X28: 8000218cc000 X27: X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 X23: 8000218cc000 X22: 08bd0270 X21: 8000218cc000 X20: 08dc5b88 X19: X18: 016d X17: 007f8b122780 X16: ffc0001adf68 X15: 0005 X14: 000c80096000 X13: 8000212b6600 X12: 00047ae2 X11: 800021089980 X10: 0850 X9: 8000218cc000 X8: 0001aa07 X7: 0243 X6: 0015752a X5: 0100 X4: 03c0 X3: X2: 0001 X1: X0: #0 [8000218cff60] arch_cpu_idle at 080857bc #1 [8000218cff70] cpu_startup_entry at 080f26c8 #2 [8000218cffd0] secondary_start_kernel at 0808e1e8 PID: 1324 TASK: 80002018be80 CPU: 2 COMMAND: "dhry" PC: 004016a4 LR: 004016a4 SP: c10c40a0 X29: c10c40a0 X28: X27: X26: X25: 00402138 X24: 004021f0 X23: X22: X21: 004001a0 X20: X19: X18: X17: 0001 X16: X15: 00493000 X14: 00498000 X13: X12: 0005 X11: 001e X10: 0101010101010101 X9: f59a9190 X8: 7f7f7f7f7f7f7f7f X7: 1f535226301f2b4c X6: 0003001d1000 X5: 00101d000300 X4: X3: 4952545320454d4f X2: 10c35b40 X1: 0011 X0: 10c35b40 ORIG_X0: 00498700 SYSCALLNO: PSTATE: 2000 #0 [user space] PID: 1223 TASK: 800020ef5780 CPU: 3 COMMAND: "sh" #0 [800020b0ba70] crash_kexec at 0812b0a8 #1 [800020b0ba90] die at 08088ce4 #2 [800020b0bad0] __do_kernel_fault at 08098fa8 #3 [800020b0bb00] do_p
Re: [Crash-utility] [PATCH v5 0/4] arm64: more improvement of bt -f
Hi Takahiro, I applied patches 1/2 and 2/2 from the v5 patchset. But I can't believe the results are what you intended? For example, taking the 4.6 vmcore that you gave to me, here is the current crash utility's output of "bt -a", where the crashing task entered crash_kexec() via the sysrq-c page fault exception, and the tasks on the other cpus have all entered crash_save_cpu() on their IRQ stack as a result of the shutdown IPI, one from user-space and the others from the kernel: crash> bt -a PID: 0 TASK: 08dcd900 CPU: 0 COMMAND: "swapper/0" #0 [800022f42e50] crash_save_cpu at 0812ae44 #1 [800022f43010] handle_IPI at 0808e718 #2 [800022f43040] gic_handle_irq at 080815f8 #3 [800022f43080] el1_irq at 08084720 --- --- PC: 080857c0 [arch_cpu_idle+16] LR: 080857bc [arch_cpu_idle+12] SP: 08dc3f10 PSTATE: 60400149 X29: 08dc3f10 X28: 08dc X27: X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 X23: 08dc X22: 08bd0270 X21: 08dc X20: 08dc5b88 X19: X18: a632f641 X17: 7da57880 X16: 081d9838 X15: 383a0a79 X14: b2b0b162 X13: 5f2cbeec X12: 00045a9e X11: 8000213bd800 X10: 0850 X9: 08dc X8: 0001aa07 X7: 003d X6: 0015752a X5: 0100 X4: 01c0 X3: X2: 0001 X1: X0: ORIG_X0: SYSCALLNO: 7fff #4 [08dc3f10] arch_cpu_idle at 080857c0 #5 [08dc3f20] cpu_startup_entry at 080f26cc #6 [08dc3f80] rest_init at 087c7930 #7 [08dc3fa0] start_kernel at 08b10b70 PID: 0 TASK: 8000218c0c80 CPU: 1 COMMAND: "swapper/1" #0 [800022f56e50] crash_save_cpu at 0812ae44 #1 [800022f57010] handle_IPI at 0808e718 #2 [800022f57040] gic_handle_irq at 080815f8 #3 [800022f57080] el1_irq at 08084720 --- --- PC: 080857c0 [arch_cpu_idle+16] LR: 080857bc [arch_cpu_idle+12] SP: 8000218cff60 PSTATE: 6349 X29: 8000218cff60 X28: 8000218cc000 X27: X26: 08dc5000 X25: 08dc5c1c X24: 08dc5000 X23: 8000218cc000 X22: 08bd0270 X21: 8000218cc000 X20: 08dc5b88 X19: X18: 016d X17: 007f8b122780 X16: ffc0001adf68 X15: 0005 X14: 000c80096000 X13: 8000212b6600 X12: 00047ae2 X11: 800021089980 X10: 0850 X9: 8000218cc000 X8: 0001aa07 X7: 0243 X6: 0015752a X5: 0100 X4: 03c0 X3: X2: 0001 X1: X0: ORIG_X0: SYSCALLNO: 7fff #4 [8000218cff60] arch_cpu_idle at 080857c0 #5 [8000218cff70] cpu_startup_entry at 080f26cc #6 [8000218cffd0] secondary_start_kernel at 0808e1ec PID: 1324 TASK: 80002018be80 CPU: 2 COMMAND: "dhry" #0 [800022f6ae50] crash_save_cpu at 0812ae44 #1 [800022f6b010] handle_IPI at 0808e718 #2 [800022f6b040] gic_handle_irq at 080815f8 #3 [800022f6b080] el0_irq_naked at 08084c4c --- --- PC: 004016a4 LR: 004016a4 SP: c10c40a0 X29: c10c40a0 X28: X27: X26: X25: 00402138 X24: 004021f0 X23: X22: X21: 004001a0 X20: X19: X18: X17: 0001 X16: X15: 00493000 X14: 00498000 X13: X12: 0005 X11: 001e X10: 0101010101010101 X9: f59a9190 X8: 7f7f7f7f7f7f7f7f X7: 1f535226301f2b4c X6: 0003001d1000 X5: 00101d000300 X4: X3: 4952545320454d4f X2: 10c35b40 X1: 0011 X0: 10c35b40 ORIG_X0: 00498700 SYSCALLNO: PSTATE: 2000 PID: 1223 TASK: 800020ef5780 CPU: 3 COMMAND: "sh" #0 [800020b0ba70] crash_kexec at 0812b0ac #1 [800020b0ba90] die at 08088ce8 #2 [800020b0bad0] __do_kernel_fault at 08098fac #3 [800020b0bb00] do_page_fault at 08096814 #4 [800020b0bb60] do_translation_fault at 080
