Cause for the Kernel Panic on B4860 with SDK2.0

[ambarish_a]

Hi,

We are seeing below kernel panic on our B4860 platform.  We would like to know what could be the possible cause for this? Is this a hardware issue or software one?

Dec 23 13:30:28 kdb kernel: Machine check in kernel mode.
Dec 23 13:30:28 kdb kernel: EDAC MPC85xx MC0: Err Detect Register: 0x8000000c
Dec 23 13:30:28 kdb kernel: Caused by (from MCSR=10000): Instruction Fetch Error Report
Dec 23 13:30:28 kdb kernel: Oops: Machine check, sig: 7 [#1]
Dec 23 13:30:28 kdb kernel: EDAC MPC85xx MC0: Faulty Data bit: 52
Dec 23 13:30:28 kdb kernel: EDAC MPC85xx MC0: Expected Data / ECC:^I0x00100010_5529103a / 0xe4
Dec 23 13:30:28 kdb kernel: EDAC MPC85xx MC0: Captured Data / ECC:^I0x00000010_5529103a / 0xe4
Dec 23 13:30:28 kdb kernel: EDAC MPC85xx MC0: Err addr: 0x2fff30e0
Dec 23 13:30:28 kdb kernel: EDAC MPC85xx MC0: PFN: 0x0002fff3
Dec 23 13:30:28 kdb kernel: EDAC MC0: 1 CE mpc85xx_mc_err on mc#0csrow#0channel#0 (csrow:0 channel:0 page:0x2fff3 offset:0xe0 grain:8 syndrome:0xe4)
Dec 23 13:30:28 kdb kernel: Machine check in kernel mode.
Dec 23 13:30:28 kdb kernel: Caused by (from MCSR=8000): Load Error Report
Dec 23 13:30:28 kdb kernel: SMP NR_CPUS=24 CoreNet Generic
Dec 23 13:30:28 kdb kernel: Modules linked in: tti_multi(O) l1d(O) shm(O) hetmgr(O) sctp crc32c_generic libcrc32c
Dec 23 13:30:28 kdb kernel: CPU: 1 PID: 18782 Comm: sleep Tainted: G O 4.1.35-rt41 #K20191223115904
Dec 23 13:30:28 kdb kernel: task: c00000004cc58190 ti: c00000004be04000 task.ti: c00000004be04000
Dec 23 13:30:28 kdb kernel: NIP: 000000000fe8d0f0 LR: 0000000010001504 CTR: 000000000fe8d0f0
Dec 23 13:30:28 kdb kernel: REGS: c00000004be07ea0 TRAP: 0000 Tainted: G O (4.1.35-rt41)
Dec 23 13:30:28 kdb kernel: MSR: 000000000202f000 <VEC,CE,EE,PR,FP,ME> CR: 48000222 XER: 00000000
Dec 23 13:30:28 kdb kernel: SOFTE: 1
Dec 23 13:30:28 kdb kernel: GPR00: 0000000000000060 00000000ffee42a0 00000000f79fd4c0 0000000000001fbf
Dec 23 13:30:28 kdb kernel: GPR04: 000000001000640c 0000000000000000 0000000010001460 00000000ffee4ea8
Dec 23 13:30:28 kdb kernel: GPR08: 0000000000000000 0000000000000000 0000000000000000 00000000ffee4220
Dec 23 13:30:28 kdb kernel: GPR12: 0000000028000222 000000001001f330 0000000010100000 0000000000000000
Dec 23 13:30:28 kdb kernel: GPR16: 0000000000000000 00000000100fda18 00000000100fda08 0000000010100000
Dec 23 13:30:28 kdb kernel: GPR20: 0000000000000000 0000000010006000 0000000010006004 0000000010006008
Dec 23 13:30:28 kdb kernel: GPR24: 0000000010005ffc 0000000010006010 0000000010006360 0000000010001460
Dec 23 13:30:28 kdb kernel: GPR28: 00000000ffee4318 00000000ffee4ea8 00000000ffee42c8 0000000010010000
Dec 23 13:30:28 kdb kernel: NIP [000000000fe8d0f0] 0xfe8d0f0
Dec 23 13:30:28 kdb kernel: LR [0000000010001504] 0x10001504
Dec 23 13:30:28 kdb kernel: Call Trace:
Dec 23 13:30:28 kdb kernel: ---[ end trace 68b8962c51df51cf ]---
Dec 23 13:30:28 kdb kernel:
Dec 23 13:30:28 kdb kernel: Oops: Machine check, sig: 7 [#2]
Connection reset by 172.21.148.62

[yipingwang]

Hello Ambarish Anjaneyareddy,

According to your console log, there is Machine check exception, Instruction Fetch Error.

Probably there is DDR controller initialization problem. Have you used QCVS DDRv tool to connect to the target board to validate and optimize DDR controller configuration parameters? Then modify board/freescale/b4860qds/ddr.c in u-boot source code according to the optimized DDR controller configuration parameters for you custom board.

You could use mtest utility provided in u-boot to do DDR memory test.

Please configure CONFIG_CMD_MEMTEST in include/configs/B4860QDS.h, then run the following command in u-boot prompt to test DDR memory.

mtest <start_address> <end_address>

Thanks,

Yiping