[KernelCrash] panic due to voltage droop in the specific device

Kernel panic log

2107.232713 / 01-01 11:11:03.809][7] init: cannot find '/system/bin/qrngp' (No such file or directory), disabling 'qrngp' [ 2107.239317 / 01-01 11:11:03.809][5] Unable to handle kernel NULL pointer dereference at virtual address 00000028 [ 2107.239351 / 01-01 11:11:03.809][5] pgd = e37ec000 [ 2107.239366 / 01-01 11:11:03.809][0] [00000028] *pgd=00000000 [ 2107.239388 / 01-01 11:11:03.809][5] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 2107.239405 / 01-01 11:11:03.809][0] Modules linked in: texfat(PO) [ 2107.239433 / 01-01 11:11:03.809][5] CPU: 5 PID: 2803 Comm: sensorservice Tainted: P        W  O   3.18.31-perf-gd069b48-00001-g8a6d6e5 #1 [ 2107.239452 / 01-01 11:11:03.809][5] task: e3ffb700 ti: e37f4000 task.ti: e37f4000 [ 2107.239479 / 01-01 11:11:03.809][5] PC is at find_vma_links+0x1c/0x78 [ 2107.239499 / 01-01 11:11:03.809][5] LR is at vma_adjust+0x3a0/0x574

Equivalent callstacks can be restored using the following command.

crash>  bt -I C01002D8 -S  E37F5DD0 0xE3FFB700 PID: 2803   TASK: e3ffb700  CPU: 5   COMMAND: "sensorservice" bt: WARNING:  stack address:0xe37f5b98, program counter:0xc0ee5b60  #0 [<c01002d8>] (do_DataAbort) from [<c010ad58>]     pc : [<c01f980c>]    lr : [<c01fa708>]    psr: 200f0013     sp : e37f5ec4  ip : 00000034  fp : e8236d9c     r10: 00000000  r9 : 00000000  r8 : b2c99000     r7 : c4616c80  r6 : e8236d68  r5 : 7f555034  r4 : 7f555034     r3 : e37f5f04  r2 : b2c97000  r1 : b2c95000  r0 : 7f555038     Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  #1 [<c010ad58>] (__dabt_svc) from [<c01fa708>]  #2 [<c01f980c>] (find_vma_links) from [<c01fa708>]  #3 [<c01fa708>] (vma_adjust) from [<c01fa9e4>]  #4 [<c01fa9e4>] (__split_vma) from [<c01fb364>]  #5 [<c01fb364>] (do_munmap) from [<c01fb558>]  #6 [<c01fb558>] (vm_munmap) from [<c0106820>]

Execution profile at the moment of kernel panic

[1]: R12 is updated as 0x34 where 0x34 = *0x7f555038 = *R0

[2]: Data abort is raised since base address for LDR execution is 0x28(0x34-0xC = R12-0xC)

0xc01f97f0 <find_vma_links>:    push    {r4, r5, lr} 0xc01f97f4 <find_vma_links+0x4>:        add     r0, r0, #4 0xc01f97f8 <find_vma_links+0x8>:        mov     r4, #0 0xc01f97fc <find_vma_links+0xc>:        mov     r5, r4 0xc01f9800 <find_vma_links+0x10>:       ldr     r12, [r0]  //<<--[1] 0xc01f9804 <find_vma_links+0x14>:       cmp     r12, #0 0xc01f9808 <find_vma_links+0x18>:       beq     0xc01f983c <find_vma_links+76> 0xc01f980c <find_vma_links+0x1c>:       ldr     r0, [r12, #-12] //<<--[2]

When tracing back to the context where the call to find_vma_links() is made inside vma_adjust(), R0 is copied from R7(0xC4616C80) whose data structure type is (struct mm_struct*) .

0xc01fa6e8 <vma_adjust+896>:    mov     r0, r7 0xc01fa6ec <vma_adjust+900>:    str     r3, [sp] 0xc01fa6f0 <vma_adjust+904>:    add     r3, sp, #60     ; 0x3c 0xc01fa6f4 <vma_adjust+908>:    str     r3, [sp, #4] 0xc01fa6f8 <vma_adjust+912>:    add     r3, sp, #52     ; 0x34 0xc01fa6fc <vma_adjust+916>:    ldr     r1, [r2] 0xc01fa700 <vma_adjust+920>:    ldr     r2, [r2, #4] 0xc01fa704 <vma_adjust+924>:    bl      0xc01f97f0 <find_vma_links>  //<<--

Identical debug information

crash> struct task_struct.mm e3ffb700   mm = 0xc4616d80

At logical level, when find_vma_links() is called, R0 should have been 0xC4616C80 instead of 0x7f555038. This signature cannot be understandable from SW point of view.

This issue ended up with replacing defective PMIC with normal one in the problematic target device.