IMX8MP galcore_deamon Undefined instruction

[James33]

Dear NXP Technical Support Team,

Hello!

BOARD: IMX8MP
Yocto: scarthgap 6.6.23

On the i.MX8mp development board, I encountered this error.

## imx8mp-lpddr4-evk kernel: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] PREEMPT SMP 
## imx8mp-lpddr4-evk kernel: Modules linked in: fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_fsl_asoc_card dw_hdmi_cec snd_soc_fsl_sai snd_soc_fsl_micfil snd_soc_fsl_xcvr imx8_media_dev(C) snd_soc_imx_audmux snd_soc_fsl_aud2htx snd_soc_fsl_easrc snd_soc_fsl_utils snd_soc_fsl_asrc imx_pcm_dma rtc_ds1307 snd_soc_wm8962 caam secvio error imx_dsp_rproc xt_conntrack nf_conntrack nf_defrag_ipv4 iptable_filter fuse 
## imx8mp-lpddr4-evk kernel: CPU: 3 PID: 79 Comm: galcore_deamon/ Tainted: G         C         6.6.23-lts-next-dirty #1 
## imx8mp-lpddr4-evk kernel: Hardware name: YTX FT Release Distro (DT) 
## imx8mp-lpddr4-evk kernel: pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) 
## imx8mp-lpddr4-evk kernel: pc : dma_fence_signal+0x58/0x64
## imx8mp-lpddr4-evk kernel: lr : gckOS_Signal+0x180/0x244
## imx8mp-lpddr4-evk kernel: sp : ffff800082a6bd00
	
## imx8mp-lpddr4-evk kernel: x29: ffff800082a6bd10 x28: 0000000000000000 x27: ffff800082a6be10 
## imx8mp-lpddr4-evk kernel: x26: 0000000000000000 x25: ffff800081b3c008 x24: ffff000026b7f3c4 
## imx8mp-lpddr4-evk kernel: x23: ffff0000d1b6c1e0 x22: ffff0000d0d64044 x21: 0000000000000000 
## imx8mp-lpddr4-evk kernel: x20: ffff0000d0d64048 x19: ffff000026b7f3c0 x18: 0000000000000000 
## imx8mp-lpddr4-evk kernel: x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8db25538 
## imx8mp-lpddr4-evk kernel: x14: 0000000000000000 x13: 0000000000000209 x12: 0000000000000002 
## imx8mp-lpddr4-evk kernel: x11: 0000000000000040 x10: ffff0000d0d64050 x9 : ffff0000d0d64048 
## imx8mp-lpddr4-evk kernel: x8 : ffff000006433b78 x7 : 0000000000000000 x6 : 000002a5fe056003 
## imx8mp-lpddr4-evk kernel: x5 : 00ffffffffffffff x4 : ffff0000d1b6c210 x3 : 0000000000000000 
## imx8mp-lpddr4-evk kernel: x2 : 0000000000000000 x1 : ffff0000d02b6740 x0 : 0000000000000000 
## imx8mp-lpddr4-evk kernel: Call trace: 
## imx8mp-lpddr4-evk kernel:  dma_fence_signal+0x58/0x64 
## imx8mp-lpddr4-evk kernel:  gckOS_UserSignal+0x7c/0xb0 
## imx8mp-lpddr4-evk kernel:  gckEVENT_Notify+0x21c/0x410 
## imx8mp-lpddr4-evk kernel:  gckHARDWARE_Notify+0x68/0xc8 
## imx8mp-lpddr4-evk kernel:  gckKERNEL_Notify+0x20/0x2c 
## imx8mp-lpddr4-evk kernel:  threadRoutine+0x1c/0x78 
## imx8mp-lpddr4-evk kernel:  kthread+0x110/0x114 
## imx8mp-lpddr4-evk kernel:  ret_from_fork+0x10/0x20 
## imx8mp-lpddr4-evk kernel: Code: 2a1303e0 a94153f3 a8c27bfd d50323bf (d65f03c0)  
## imx8mp-lpddr4-evk kernel: ---[ end trace 0000000000000000 ]---

According to "dma_fence_signal+0x58/0x64", I checked the "dma_fence_signal" function and found that the instruction corresponding to the 0x58 position is the "ret" instruction.

file path: imx8mp-xwayland/tmp/work-shared/imx8mp-lpddr4-evk/kernel-source/drivers/dma-buf/dma-fence.c

int dma_fence_signal(struct dma_fence *fence)
{
	unsigned long flags;
	int ret;
	bool tmp;

	if (!fence)
		return -EINVAL;

	tmp = dma_fence_begin_signalling();

	spin_lock_irqsave(fence->lock, flags);
	ret = dma_fence_signal_timestamp_locked(fence, ktime_get());
	spin_unlock_irqrestore(fence->lock, flags);

	dma_fence_end_signalling(tmp);

	return ret;
}
EXPORT_SYMBOL(dma_fence_signal);

## aarch64-linux-gnu-objdump -r -d vmlinux | grep -A 30 \<dma_fence_signal\>:
ffff8000809bcfe8 <dma_fence_signal>:
ffff8000809bcfe8:	d503233f 	paciasp
ffff8000809bcfec:	a9be7bfd 	stp	x29, x30, [sp, #-32]!
ffff8000809bcff0:	910003fd 	mov	x29, sp
ffff8000809bcff4:	a90153f3 	stp	x19, x20, [sp, #16]
ffff8000809bcff8:	b4000260 	cbz	x0, ffff8000809bd044 <dma_fence_signal+0x5c>
ffff8000809bcffc:	aa0003f3 	mov	x19, x0
ffff8000809bd000:	f9400000 	ldr	x0, [x0]
ffff8000809bd004:	942b4fed 	bl	ffff800081490fb8 <_raw_spin_lock_irqsave>
ffff8000809bd008:	aa0003f4 	mov	x20, x0
ffff8000809bd00c:	97dd9d70 	bl	ffff8000801245cc <ktime_get>
ffff8000809bd010:	aa0003e1 	mov	x1, x0
ffff8000809bd014:	aa1303e0 	mov	x0, x19
ffff8000809bd018:	97ffff6e 	bl	ffff8000809bcdd0 <dma_fence_signal_timestamp_locked>
ffff8000809bd01c:	2a0003e2 	mov	w2, w0
ffff8000809bd020:	aa1403e1 	mov	x1, x20
ffff8000809bd024:	f9400260 	ldr	x0, [x19]
ffff8000809bd028:	2a0203f3 	mov	w19, w2
ffff8000809bd02c:	942b4eb5 	bl	ffff800081490b00 <_raw_spin_unlock_irqrestore>
ffff8000809bd030:	2a1303e0 	mov	w0, w19
ffff8000809bd034:	a94153f3 	ldp	x19, x20, [sp, #16]
ffff8000809bd038:	a8c27bfd 	ldp	x29, x30, [sp], #32
ffff8000809bd03c:	d50323bf 	autiasp
ffff8000809bd040:	d65f03c0 	ret
ffff8000809bd044:	128002b3 	mov	w19, #0xffffffea            	// #-22
ffff8000809bd048:	17fffffa 	b	ffff8000809bd030 <dma_fence_signal+0x48>

I would like to know why the "ret" instruction is causing the problem? And what should I do to avoid this error? This is an occasional occurrence. I don't yet know what kind of action caused this problem to happen. I am unable to manually reproduce this issue.

[Zhiming_Liu]

Hi @James33 

Are you using the standard Linux kernel or PREEMPT Linux?

Best Regards,
Zhiming

[James33]

The yocto version is scarthgap6.6.23. I did not make any modifications to the linux-imx_6.6.bb file, nor did I modify the galcore related drivers. I only modified the dts file of the kernel. So it should be the standard Linux kernel.Sometimes the error occurs in other functions, and dma_fence_signal is just one of them.

## zcat /proc/config.gz | grep PREEMPT
CONFIG_PREEMPT_BUILD=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
# CONFIG_PREEMPT_DYNAMIC is not set
CONFIG_PREEMPT_RCU=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_KEY=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_DEBUG_PREEMPT is not set