v2.6.1 (and 2.6.0) Kernel Panic in sysworkq

[NautDesigner]

Code runs fine in v2.53 but when running in v2.6, we get a kernel panic at the exit of a delayable workqueue function. 

Tracing the code and line number, it dies in Zephyr. No idea where to go from here so any help would be appreciated.

ASSERTION FAIL @ WEST_TOPDIR/zephyr/include/zephyr/drivers/gpio.h:883
[00:00:17.195,861] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000373 r2/a3: 0x00000000
[00:00:17.196,380] <err> os: r3/a4: 0x20010060 r12/ip: 0x000002ee r14/lr: 0x00045d0b
[00:00:17.196,899] <err> os: xpsr: 0x41000000
[00:00:17.197,265] <err> os: Faulting instruction address (r15/pc): 0x000668c2
[00:00:17.197,723] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:17.198,211] <err> os: Current thread: 0x2000fb38 (sysworkq)
[00:00:17.203,582] <err> os: Halting system

CONFIG_HW_STACK_PROTECTION=y
CONFIG_DYNAMIC_OBJECTS=y
CONFIG_HEAP_MEM_POOL_SIZE=98304
#131072
CONFIG_NRF_MODEM_LIB_HEAP_SIZE=4096
CONFIG_MAIN_STACK_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
#CONFIG_IDLE_STACK_SIZE=2048
CONFIG_AT_MONITOR_HEAP_SIZE=1024

[JyriLehtinen]

Our application is using the ST's LIS2DH on SPI bus with the Zephyr drivers, and it works fine on SDK version 2.5.1, but with 2.6.1 it causes the same assert error.

Still looking in to it, might have more information later.

[JyriLehtinen]

Alright, the issue was not present in the LIS2DH sample, but is in our production application, and for some reason the sensor driver doesn't handle the interrupts correctly, resulting in the assertion failure:

ASSERTION FAIL [(flags & ((1U << 21) | (1U << 22))) != 0U] @ WEST_TOPDIR/zephyr/include/zephyr/drivers/gpio.h:883
   Must either enable or disable interrupts

The 2.6.1 LIS2DH devicetree binding has new properties, int1-gpio-config and int2-gpio-config, setting them to <3> (LIS2DH_DT_GPIO_INT_LEVEL_HIGH) fixes the issue. A value of <0> results in the assert failure, I assume it's the default value.

EDIT: I noticed the LIS2DH sample did not have assert enabled, setting CONFIG_ASSERT=y replicated the assertion fail without the proper int-gpio-config setting. Seems to run just fine without the assert.