iMX6Q kernel crash with BSP 4.0

[ronjacoby]

hi

i'm developing on a custom imx6q-based board.

the board booted and worked fine with earlier versions of the BSP - 12.09.01 and 1.1.0.

when moving to 4.0, the kernel crashed randomly after initializing the FEC. see bellow an terminal screen capture.

after some investigation, i found that if i changed the following code in system.c, the problem seems to be fixed.

this means having CCM_CLPCR LPM bits in "allowed transfer to wait mode".

is this a known issue ? is this a correct solution ?

#if 0

  if (enet_is_active)

   /* Don't allow the chip to enter WAIT mode if enet is active

     * and the GPIO workaround for ENET interrupts is not used,

     * since all ENET interrupts donot wake up the SOC.

     */

   mxc_cpu_lp_set(WAIT_CLOCKED);

  else

#endif 

   mxc_cpu_lp_set(WAIT_UNCLOCKED_POWER_OFF);

0x000000000000-0x000000200000 : "boot"

0x000000200000-0x000000700000 : "kernel"

0x000000700000-0x000006b00000 : "rootfs"

0x000006b00000-0x000008000000 : "user"

GPMI NAND driver registered. (IMX)

FEC Ethernet Driver

fec_enet_mii_bus: probed

Unable to handle kernel NULL pointer dereference at virtual address 00000000

Unable to handle kernel NULL pointer dereference at virtual address 00000002

pgd = 80004000

[00000002] *pgd=00000000

Internal error: Oops: 5 [#1] PREEMPT SMP

Modules linked in:

CPU: 1    Not tainted  (3.0.35-2508-g54750ff #12)

PC is at memcpy+0xe4/0x330

LR is at crypto_pcbc_decrypt_inplace.isra.3+0x50/0xbc

pc : [<80225da4>]    lr : [<80206428>]    psr: 20000093

sp : e9fadfbc  ip : 00000003  fp : 00000000

r10: 00000000  r9 : 412fc09a  r8 : 1000406a

r7 : 80a56c1c  r6 : 96525f48  r5 : 80a95104  r4 : e9fac000

r3 : 00000011  r2 : 00000000  r1 : 00000002  r0 : 00000001

Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel

Control: 10c53c7d  Table: 1000404a  DAC: 00000015

Process swapper (pid: 0, stack limit = 0xe9fac2f0)

Stack: (0xe9fadfbc to 0xe9fae000)

dfa0:                                                                00000001

dfc0: e9fac000 80206428 80a56c1c 00000001 412fc09a 8003cb00 8003cae0 8003cd08

dfe0: 804c6c9c 79fb006a 00000015 10c03c7d 80a952a0 104c6cb4 fc5ffaf7 26bdbed9

Code: 24c0c001 e8bd8011 e26cc004 e35c0002 (c4d13001)

---[ end trace 5e6e4e3f2c2f7fc6 ]---

Kernel panic - not syncing: Attempted to kill the idle task!

[<80042834>] (unwind_backtrace+0x0/0xf8) from [<804c9e74>] (panic+0x74/0x18c)

[<804c9e74>] (panic+0x74/0x18c) from [<800701bc>] (do_exit+0x684/0x6e8)

[<800701bc>] (do_exit+0x684/0x6e8) from [<8003f724>] (die+0x228/0x284)

[<8003f724>] (die+0x228/0x284) from [<804c9c6c>] (__do_kernel_fault.part.4+0x54/0x74)

[<804c9c6c>] (__do_kernel_fault.part.4+0x54/0x74) from [<8004640c>] (do_page_fault+0x2b4/0x31c)

[<8004640c>] (do_page_fault+0x2b4/0x31c) from [<80036384>] (do_DataAbort+0x34/0x9c)

[<80036384>] (do_DataAbort+0x34/0x9c) from [<8003b990>] (__dabt_svc+0x70/0xa0)

Exception stack(0xe9fadf70 to 0xe9fadfb8)

df60:                                     00000001 00000002 00000000 00000011

df80: e9fac000 80a95104 96525f48 80a56c1c 1000406a 412fc09a 00000000 00000000

dfa0: 00000003 e9fadfbc 80206428 80225da4 20000093 ffffffff

[<8003b990>] (__dabt_svc+0x70/0xa0) from [<80225da4>] (memcpy+0xe4/0x330)

CPU2: stopping

[<80042834>] (unwind_backtrace+0x0/0xf8) from [<80036324>] (do_IPI+0x150/0x17c)

[<80036324>] (do_IPI+0x150/0x17c) from [<8003ba0c>] (__irq_svc+0x4c/0xe8)

Exception stack(0xe9fb5f98 to 0xe9fb5fe0)

5f80:                                                       00000001 00000002

5fa0: 80a9c548 00000000 e9fb4000 80a95104 804d1f48 80a56c1c 1000406a 412fc09a

5fc0: 00000000 00000000 00000002 e9fb5fe0 8003ccf8 8003ccbc 20000013 ffffffff

[<8003ba0c>] (__irq_svc+0x4c/0xe8) from [<8003ccbc>] (cpu_idle+0x7c/0x108)

[<8003ccbc>] (cpu_idle+0x7c/0x108) from [<104c6cb4>] (0x104c6cb4)

CPU3: stopping

[<80042834>] (unwind_backtrace+0x0/0xf8) from [<80036324>] (do_IPI+0x150/0x17c)

[<80036324>] (do_IPI+0x150/0x17c) from [<8003ba0c>] (__irq_svc+0x4c/0xe8)

Exception stack(0xe9f01f90 to 0xe9f01fd8)

1f80:                                     80a9c520 80000093 00000001 00000000

1fa0: e9f00000 80a95104 804d1f48 80a56c1c 1000406a 412fc09a 00000000 00000000

1fc0: 00000000 e9f01fd8 8004a648 8003cb04 40000013 ffffffff

[<8003ba0c>] (__irq_svc+0x4c/0xe8) from [<8003cb04>] (default_idle+0x24/0x28)

[<8003cb04>] (default_idle+0x24/0x28) from [<8003cd08>] (cpu_idle+0xc8/0x108)

[<8003cd08>] (cpu_idle+0xc8/0x108) from [<104c6cb4>] (0x104c6cb4)

pgd = 80004000

[00000000] *pgd=00000000

Internal error: Oops: 5 [#2] PREEMPT SMP

Modules linked in:

CPU: 0    Tainted: G      D      (3.0.35-2508-g54750ff #12)

PC is at memcpy+0x114/0x330

LR is at crypto_pcbc_decrypt_inplace.isra.3+0x50/0xbc

pc : [<80225dd4>]    lr : [<80206428>]    psr: 60000093

sp : 80a3ff94  ip : 00000002  fp : 00000000

r10: 00000000  r9 : 412fc09a  r8 : 1000406a

r7 : 80a56c1c  r6 : ffa93f48  r5 : 80a95104  r4 : 80a3e000

r3 : 00000011  r2 : 00000000  r1 : 00000000  r0 : 00000000

Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel

Control: 10c53c7d  Table: 1000404a  DAC: 00000015

Process swapper (pid: 0, stack limit = 0x80a3e2f0)

Stack: (0x80a3ff94 to 0x80a40000)

ff80:                                              00000000 80a3e000 80206428

ffa0: 80a56c1c 00000000 412fc09a 8003cb00 8003cae0 8003cd08 00000001 80a53b3c

ffc0: 80a95060 8002b0d0 8c80b0e0 80008868 800082f8 00000000 00000000 8002b0d0

ffe0: 00000000 10c53c7d 80a53a8c 8002b0cc 80a56c14 10008040 00000000 00000000

Code: e211c003 0affffc4 e3c11003 e35c0002 (e491e004)

CPU0: stopping

[<80042834>] (unwind_backtrace+0x0/0xf8) from [<80036324>] (do_IPI+0x150/0x17c)

[<80036324>] (do_IPI+0x150/0x17c) from [<8003ba0c>] (__irq_svc+0x4c/0xe8)

Exception stack(0x80a3fd60 to 0x80a3fda8)

fd60: 80a95278 80a96270 00000080 00000000 80a3e000 00000000 00000001 80225dd6

fd80: 00000000 80225dd8 80a3fdea 809841c8 00000000 80a3fda8 8003f5b4 804cfc68

fda0: 60000113 ffffffff

[<8003ba0c>] (__irq_svc+0x4c/0xe8) from [<804cfc68>] (_raw_spin_unlock_irq+0x18/0x40)

[<804cfc68>] (_raw_spin_unlock_irq+0x18/0x40) from [<8003f5b4>] (die+0xb8/0x284)

[<8003f5b4>] (die+0xb8/0x284) from [<804c9c6c>] (__do_kernel_fault.part.4+0x54/0x74)

[<804c9c6c>] (__do_kernel_fault.part.4+0x54/0x74) from [<8004640c>] (do_page_fault+0x2b4/0x31c)

[<8004640c>] (do_page_fault+0x2b4/0x31c) from [<80036384>] (do_DataAbort+0x34/0x9c)

[<80036384>] (do_DataAbort+0x34/0x9c) from [<8003b990>] (__dabt_svc+0x70/0xa0)

Exception stack(0x80a3ff48 to 0x80a3ff90)

ff40:                   00000000 00000000 00000000 00000011 80a3e000 80a95104

ff60: ffa93f48 80a56c1c 1000406a 412fc09a 00000000 00000000 00000002 80a3ff94

ff80: 80206428 80225dd4 60000093 ffffffff

[<8003b990>] (__dabt_svc+0x70/0xa0) from [<80225dd4>] (memcpy+0x114/0x330)

[LeonardoSandova]

from EnriqueOchoaVazquez

"The latest release (Linux 4.0.0, Android JB4.2.2) has dropped support for MX6DQ TO1.0/TO1.1, MX6DL TO1.1.

If you want to make pre-built software run on old boards with older MX6 TO chips, please remember to add  “enable_wait_mode=off” option. This option will disable wait mode. Otherwise, you may see crash when probing FEC driver.

This change is related to “ENGR00257847 MX6Q/DL-Fix Ethernet performance issue when WAIT mode is active” which only works for MP chips (MX6DQ TO1.2 and MX6DL TO1.1). You can also select to revert these patches if you still want to enable wait mode on old chips."

[clementmartin]

Thank you :

I got the same trouble with BSP 4.0 on sabre lite (default X11 preconfiguration provided with ltib)
I get only the "Unable to handle kernel NULL pointer dereference at virtual address 00000002", but anyway your solution avoid to crash on startup :smileyhappy:.

Sadly I can't tell you if it is the best solution or not :smileysad:

[AnsonHuang]

Can you tell me your i.MX6Q's chip version? As far as I know, this is a known issue on old TOs. The chip version can be seen in the start of uboot log.

[ronjacoby]

Hi,

It is TO1.1

ron

[AnsonHuang]

Hi, Ron

     Sorry for confusion, this workaround only supports TO1.2, TO1.1 may met random crash, this is an known issue. Please try it on TO1.2, otherwise, you will have to revert this ENET patch for TO version < 1.2.