IPCF course kernel panic when memcpy from sram to kfifo

superyyf — Mon, 03 Apr 2023 06:53:50 GMT

Hi， Based on the module(ipc-shm-dev) provided in ipcf, I implemented another module to receive mcore messages and distribute them. when i use the kfifo_in() api , copying data from sram to kernel space buffer, kernel panic occurred. According to the dmesg log, the problem is in the memcpy() function. When i use ipc_memcpy(), which copy byte to byte, no error occurred. So i use ipc_memcpy() to copy data from sram to kernel space, then use the kfifo_in() api. this will increase the data process time, which is important to my use case. Do you know how to fix the memcpy problem?

[ 97.621545] ipc-shm-com: ch 1 << 49 bytes: 1
[ 97.621551] ipc-shm-com: get message 12545
[ 97.621554] ipc-shm-com: data_chan_rx_cb(): message id 12545, ipc channel mask: 4
[ 97.621559] ipc-shm-com: data_chan_rx_cb(): ipc channel : 2 want message id 12545
[ 97.621576] Unable to handle kernel paging request at virtual address ffffffc014400746
[ 103.432905] Mem abort info:
[ 103.441557] ESR = 0x96000021
[ 103.456041] EC = 0x25: DABT (current EL), IL = 32 bits
[ 103.468617] SET = 0, FnV = 0
[ 103.477557] EA = 0, S1PTW = 0
[ 103.492139] Data abort info:
[ 103.502294] ISV = 0, ISS = 0x00000021
[ 103.512016] CM = 0, WnR = 0
[ 103.526425] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080ca6000
[ 103.540399] [ffffffc014400746] pgd=00000008dffff003, p4d=00000008dffff003, pud=00000008dffff003, pmd=000000088361e003, pte=0068000034200717
[ 103.558804] Internal error: Oops: 96000021 [#1] PREEMPT SMP
[ 103.570271] ipc-shm-dev: ipc_hw_irq_notify(): *********ipc irq notify**********
[ 103.570272] printk: console [ttyLF0]: printing thread stopped
[ 103.575805] Modules linked in: ipc_shm_com(O) ipc_shm_dev(O) pfeng(O) [last unloaded: ipc_shm_dev]
[ 103.597765] CPU: 0 PID: 403 Comm: mcu_forwarding_ Tainted: G O 5.10.109-rt65 #1
[ 103.612258] Hardware name: NXP S32G399A-RDB3 (DT)
[ 103.628403] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 103.641683] pc : __memcpy+0x84/0x180
[ 103.651144] lr : kfifo_copy_in+0x78/0x98
[ 103.666507] sp : ffffffc01115bcb0
[ 103.677096] x29: ffffffc01115bcb0 x28: ffffffc0089e8958
[ 103.682391] x27: 0000000000000004 x26: ffffff8801361530
[ 103.687686] x25: ffffffc0089f2180 x24: ffffffc0089f0000
[ 103.692981] x23: 0000000000000026 x22: ffffffc014400720
[ 103.698275] x21: ffffff8801361530 x20: 0000000000000031
[ 103.709473] x19: 0000000000000026 x18: 0000000000000001
[ 103.726225] x17: 0000000000000000 x16: 0000000000000000
[ 103.738811] x15: ffffff88015927e8 x14: ffffffffffffffff
[ 103.750008] x13: ffffffc01110d309 x12: ffffffc01110d302
[ 103.766761] x11: ffffffc011014840 x10: ffffffc010feeff0
[ 103.779347] x9 : ffffffc0100981ac x8 : 000000c040000010
[ 103.790544] x7 : fa00080000007b01 x6 : ffffff8804a07000
[ 103.807296] x5 : ffffff885f856890 x4 : 0000000000000000
[ 103.819882] x3 : 0000000000000000 x2 : 000000000000000b
[ 103.831079] x1 : ffffffc014400746 x0 : ffffff8804a07000
[ 103.847835] Call trace:
[ 103.857556] __memcpy+0x84/0x180
[ 103.866668] __kfifo_in+0x38/0x58
[ 103.881423] data_chan_rx_cb+0x1b8/0x284 [ipc_shm_com]
[ 103.893836] ipc_shm_rx+0x12c/0x220 [ipc_shm_dev]
[ 103.904426] ipc_shm_softirq+0x64/0xe0 [ipc_shm_dev]
[ 103.920831] tasklet_action_common.isra.0+0x138/0x150
[ 103.933156] tasklet_action+0x30/0x40
[ 103.936802] __do_softirq+0x130/0x3e0
[ 103.940447] irq_exit+0xc0/0xe8
[ 103.943573] __handle_domain_irq+0x70/0xc8
[ 103.947652] gic_handle_irq+0x60/0x12c
[ 103.951386] el1_irq+0xcc/0x180
[ 103.960413] vprintk_store+0x27c/0x4a8
[ 103.975603] vprintk_emit+0x4c/0x88
[ 103.986366] printk+0x88/0xb0
[ 103.995219] __dynamic_pr_debug+0x78/0xa8
[ 104.010670] ipc_shm_com_read+0xd8/0x270 [ipc_shm_com]
[ 104.023082] vfs_read+0xb4/0x1a8
[ 104.032196] ksys_read+0x74/0x108
[ 104.046951] __arm64_sys_read+0x24/0x30
[ 104.058062] el0_svc_common.constprop.0+0x80/0x1d0
[ 104.068738] do_el0_svc+0x2c/0x98
[ 104.083494] el0_svc+0x20/0x30
[ 104.093825] el0_sync_handler+0xb0/0xb8
[ 104.103545] el0_sync+0x180/0x1c0
[ 104.118307] Code: a88120c7 a8c12027 a88120c7 36180062 (f8408423)
[ 104.131674] ---[ end trace d813e9c44a4d873a ]---
[ 104.242446] Kernel panic - not syncing:
[ 104.251252] Oops: Fatal exception in interrupt
[ 104.351558] SMP: stopping secondary CPUs
[ 104.355045] Kernel Offset: disabled
[ 104.358511] CPU features: 0x00040022,2000200c
[ 104.362851] Memory Limit: none
[ 104.365895] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Re: IPCF course kernel panic when memcpy from sram to kfifo

Daniel-Aguirre — Mon, 03 Apr 2023 17:15:55 GMT

Hi,

Could you provide which BSP/IPCF/RTD version are you using? Are you using an NXP platform? Or is it a custom board?

Also, have you disabled dcache on u-boot? This is explained on the "description.txt" file available on the M7 core project.

Please, let us know.

Re: IPCF course kernel panic when memcpy from sram to kfifo

superyyf — Tue, 04 Apr 2023 05:14:17 GMT

BSP version: 33.0

IPCF: SW32G_IPCF_4.7.0_D2208

RTD: 3.0.2

we did not disabled dcache on u-boot

Re: IPCF course kernel panic when memcpy from sram to kfifo

Daniel-Aguirre — Tue, 04 Apr 2023 18:40:56 GMT

Hi,

Thanks for your feedback.

Have you tried running with dcahe off?

Also, have you zeroed the region where you are having the shared memory space?

There is an example provided on IPCF for M7 which describes some pre-requisites that need to be done on u-boot, have you had this same problem under the example itself?

Please, let us know.

S32GのトピックRe: IPCF course kernel panic when memcpy from sram to kfifo

IPCF course kernel panic when memcpy from sram to kfifo

Re: IPCF course kernel panic when memcpy from sram to kfifo

Re: IPCF course kernel panic when memcpy from sram to kfifo

Re: IPCF course kernel panic when memcpy from sram to kfifo