6.6.20 kernel call traces __memcpy

rizwan25

We are migrating over kernel from 5.10.41 to 6.6.20 for riscv platform
Its working till 6.1.110 but when we are trying it for 6.6.20 its causing call trace as mentioned below

INIT: version booting
mount: /sys: sysfs already mounted on /sys.
Starting udev
[ 2.266078] udevd[125]: starting version 3.2.9
[ 9.922822] random: crng init done
[ 9.930519] udevd[126]: starting eudev-3.2.9
sysctl: cannot stat /proc/sys/net/ipv4/tcp_syncookies: No such file or directory
[ 10.876616] Oops - store (or AMO) access fault [#1]
[ 10.876637] Modules linked in:
[ 10.876646] CPU: 2 PID: 177 Comm: rc Not tainted 6.6.20-nb2+ #1
[ 10.876654] Hardware name: SiFive Pearl (DT)
[ 10.876657] epc : __memcpy+0x60/0xf8
[ 10.876676] ra : do_wp_page+0x2ea/0xc28
[ 10.876684] epc : ffffffff80751e80 ra : ffffffff80125d76 sp : ffffffc80090bca0
[ 10.876688] gp : ffffffff834bebc0 tp : ffffffd80bdccb40 t0 : 2101200122012901
[ 10.876691] t1 : 2f01220120013d01 t2 : 2f01720161017601 s0 : ffffffc80090bd50
[ 10.876695] s1 : ffffffc80090bd68 a0 : ffffffd800000000 a1 : ffffffd848ffe000
[ 10.876698] a2 : 0000000000001000 a3 : ffffffd848fff000 a4 : 6e0169016c016401
[ 10.876701] a5 : 2f01220120016b01 a6 : 2f01720161017601 a7 : 220170016d017401
[ 10.876704] s2 : ffffffd80bdc2d00 s3 : ffffffff82cad598 s4 : ffffffd8046b36e0
[ 10.876707] s5 : 0000000000001a55 s6 : ffffffff830ef460 s7 : ffffffff83200008
[ 10.876711] s8 : ffffffff834c0bd8 s9 : ffffffff834f5900 s10: ffffffd9f99adb50
[ 10.876713] s11: ffffffd9f89b5bc0 t3 : 61016c016f017601 t4 : 65016c0169017401
[ 10.876717] t5 : 70016d0174012f01 t6 : ffffffd800000000
[ 10.876719] status: 0000000200000120 badaddr: ffffffd800000000 cause: 0000000000000007
[ 10.876723] [] __memcpy+0x60/0xf8
[ 10.876731] [] __handle_mm_fault+0x64a/0xa18
[ 10.876738] [] handle_mm_fault+0x3e/0x10c
[ 10.876743] [] handle_page_fault+0xb0/0x350
[ 10.876752] [] do_page_fault+0x1e/0x36
[ 10.876763] [] ret_from_exception+0x0/0x64
[ 10.876779] Code: b303 0285 b383 0305 be03 0385 be83 0405 bf03 0485 (b023) 00ef
[ 10.876784] ---[ end trace 0000000000000000 ]---
[ 10.876787] Kernel panic - not syncing: Fatal exception in interrupt
[ 10.876791] SMP: stopping secondary CPUs
[ 11.043199] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

nick.accuweb.cloud

@rizwan25

Thank you for sharing the complete error details.

Please try the following steps to troubleshoot and resolve the issue:

Use addr2line on the failing vmlinux to identify the exact source line where __memcpy was called. This will help determine which code path passed the invalid pointer.

If the caller appears to be a user-copy wrapper, check for swapped arguments or invalid pointer validation.

Rebuild the kernel with the following configurations enabled to get a more detailed trace:

CONFIG_DEBUG_VM

CONFIG_PAGE_POISONING

CONFIG_FRAME_POINTER

If the issue persists and the source is still unclear, perform a git bisect between versions v6.1.110 and v6.6.20 using your automated boot or QEMU test setup.

Example addr2line usage (adjust paths as needed):

Assume vmlinux is located at /work/linux/vmlinux and epc from the oops is 0xffffffff80751e80

VM=/work/linux/vmlinux
EPC=0xffffffff80751e80

Compute the offset

OFFSET=$(printf '%x' $((0xFFFFFFFF80751E80 - 0xFFFFFFFF80000000)))

Get the exact source line

riscv64-linux-gnu-addr2line -e $VM -f -p 0x$OFFSET

Repeat this for each instruction pointer listed in the oops.

If you still encounter errors after following these steps, please share the updated error logs so I can investigate further and suggest the next steps.

Nick R
Cloud Team Lead
AccuWeb.Cloud