Kernel panic on jetson kernel

Hi I am constantly having issues like the orin dev kit shutting down because of this kernel panic error

<1>[108613.089703] Unable to handle kernel paging request at virtual address ffff4c8d52afe000
<1>[108613.089714] Mem abort info:
<1>[108613.089715]   ESR = 0x0000000096000004
<1>[108613.089717]   EC = 0x25: DABT (current EL), IL = 32 bits
<1>[108613.089720]   SET = 0, FnV = 0
<1>[108613.089721]   EA = 0, S1PTW = 0
<1>[108613.089721]   FSC = 0x04: level 0 translation fault
<1>[108613.089723] Data abort info:
<1>[108613.089723]   ISV = 0, ISS = 0x00000004
<1>[108613.089724]   CM = 0, WnR = 0
<1>[108613.089726] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000121656000
<1>[108613.089729] [ffff4c8d52afe000] pgd=0000000000000000, p4d=0000000000000000
<0>[108613.089735] Internal error: Oops: 0000000096000004 [#1] PREEMPT_RT SMP
<6>[108613.089739] Modules linked in: xt_tcpudp(E) xt_mark(E) xt_conntrack(E) xt_MASQUERADE(E) nf_conntrack_netlink(E) xt_addrtype(E) br_netfilter(E) nvidia_modeset(OE) can_raw(E) can(E) lzo_rle(E) lzo_compress(E) zram(E) ec_generic(OE) zsmalloc(E) ec_master(OE) ramoops(E) reed_solomon(E) nf_tables(E) nfnetlink(E) ip6table_nat(E) ip6table_filter(E) ip6_tables(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) libcrc32c(E) iptable_filter(E) algif_hash(E) algif_skcipher(E) af_alg(E) snd_soc_tegra210_admaif(OE) snd_soc_tegra186_asrc(OE) snd_soc_tegra186_arad(OE) snd_soc_tegra210_afc(OE) snd_soc_tegra210_mixer(OE) snd_soc_tegra_pcm(E) snd_soc_tegra210_mvc(OE) snd_soc_tegra210_ope(OE) snd_soc_tegra186_dspk(OE) snd_soc_tegra210_dmic(OE) snd_soc_tegra210_amx(OE) snd_soc_tegra210_sfc(OE) snd_soc_tegra210_adx(OE) snd_soc_tegra210_i2s(OE) snd_soc_tegra210_ahub(OE) tegra210_adma(E) spidev(E) nvvrs_pseq_rtc(OE) gs_usb(E) can_dev(E) rtk_btusb(OE) btusb(E) btrtl(E) btintel(E)
<6>[108613.089804]  btbcm(E) bluetooth(E) ecdh_generic(E) ecc(E) snd_soc_tegra_machine_driver(OE) snd_soc_tegra_utils(OE) snd_soc_simple_card_utils(E) crct10dif_ce(E) tegra234_oc_event(OE) r8125(OE) fusb301(OE) nvpmodel_clk_cap(OE) thermal_trip_event(OE) tegra_cactmon_mc_all(OE) tegra234_aon(OE) tegra_aconnect(E) r8168(OE) rtl8822ce(OE) snd_hda_codec_hdmi(E) snd_hda_tegra(E) cfg80211(E) snd_hda_codec(E) pwm_tegra_tachometer(OE) nvidia(OE) nv_imx219(OE) snd_hda_core(E) at24(E) spi_tegra114(E) mc_hwpm(OE) tegra_pcie_dma_test(OE) nvidia_vrs_pseq(OE) rfkill(E) host1x_fence(OE) tegra_pcie_edma(OE) tegra_dce(OE) tsecriscv(OE) bridge(E) stp(E) llc(E) usb_f_ncm(E) usb_f_mass_storage(E) usb_f_acm(E) u_serial(E) usb_f_rndis(E) u_ether(E) nvhost_vi5(OE) nvhost_nvcsi_t194(OE) nvhost_isp5(OE) libcomposite(E) tegra_camera(OE) v4l2_dv_timings(E) nvhost_nvcsi(OE) tegra_camera_platform(OE) capture_ivc(OE) governor_userspace(E) tegra_camera_rtcpu(OE) ivc_bus(OE) tegra_drm(OE) hsp_mailbox_client(OE) ivc_ext(OE)
<6>[108613.089870]  v4l2_fwnode(E) v4l2_async(E) videobuf2_dma_contig(E) videobuf2_memops(E) videobuf2_v4l2(E) videobuf2_common(E) tegra_wmark(OE) videodev(E) nvhwpm(OE) cec(E) mc(E) nvhost_capture(OE) drm_kms_helper(E) host1x_nvhost(OE) nvidia_p2p(OE) ina3221(E) nvgpu(OE) governor_pod_scaling(OE) host1x(OE) mc_utils(OE) nvmap(OE) nvsciipc(OE) drm(E) fuse(E) ip_tables(E) x_tables(E) ipv6(E) pwm_fan pwm_tegra tegra_bpmp_thermal tegra_xudc ucsi_ccg typec_ucsi typec nvme nvme_core phy_tegra194_p2u pcie_tegra194
<6>[108613.089915] CPU: 5 PID: 162 Comm: kswapd0 Tainted: G           OE     5.15.136-rt-tegra #1
<6>[108613.089919] Hardware name: NVIDIA NVIDIA Jetson Orin Nano Developer Kit/Jetson, BIOS 36.3.0-gcid-36191598 05/06/2024
<6>[108613.089921] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
<6>[108613.089925] pc : percpu_ref_get_many+0x40/0xd0
<6>[108613.089937] lr : percpu_ref_get_many+0x1c/0xd0
<6>[108613.089940] sp : ffff800008fc3510
<6>[108613.089941] x29: ffff800008fc3510 x28: 0000000000000001 x27: ffff00009d8a902f
<6>[108613.089945] x26: ffff0000800d0a00 x25: 0000000000000001 x24: ffff800008fc3530
<6>[108613.089948] x23: ffff00009d8a6200 x22: ffffb3749e7da670 x21: ffff00009d8a902f
<6>[108613.089950] x20: ffff00009d8a902f x19: 0000000000000001 x18: 0000000000000000
<6>[108613.089953] x17: 0000000000000000 x16: ffffb3749dae7ea0 x15: 0000aaaacadd70b0
<6>[108613.089956] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000080000000
<6>[108613.089958] x11: ffff800008fc36c8 x10: 0000000000000002 x9 : 0000000000000001
<6>[108613.089961] x8 : 0000000000000238 x7 : 0000000000000000 x6 : ffff4c8d52afe000
<6>[108613.089963] x5 : fffffffffffff820 x4 : ffff00008a487000 x3 : 000000000000000c
<6>[108613.089966] x2 : ffff4c8d52afe000 x1 : ffff000080e99f00 x0 : ffff4c8d52afe000
<6>[108613.089969] Call trace:
<6>[108613.089971]  percpu_ref_get_many+0x40/0xd0
<6>[108613.089974]  refill_obj_stock+0x80/0x1c0
<6>[108613.089979]  obj_cgroup_uncharge+0x34/0x50
<6>[108613.089983]  memcg_slab_free_hook+0x94/0x160
<6>[108613.089989]  kmem_cache_free+0x2d8/0x320
<6>[108613.089991]  free_buffer_head+0x44/0xc0
<6>[108613.089996]  try_to_free_buffers+0xbc/0x140
<6>[108613.089998]  jbd2_journal_try_to_free_buffers+0x120/0x150
<6>[108613.090003]  ext4_releasepage+0x58/0x110
<6>[108613.090007]  try_to_release_page+0x80/0xb0
<6>[108613.090012]  invalidate_inode_page+0xb0/0xd0
<6>[108613.090017]  __invalidate_mapping_pages+0x188/0x1e0
<6>[108613.090021]  invalidate_mapping_pages+0x40/0x60
<6>[108613.090025]  inode_lru_isolate+0x1e0/0x240
<6>[108613.090028]  __list_lru_walk_one+0x88/0x150
<6>[108613.090032]  list_lru_walk_one+0x6c/0xa0
<6>[108613.090034]  prune_icache_sb+0x60/0xd0
<6>[108613.090036]  super_cache_scan+0x15c/0x1c0
<6>[108613.090038]  do_shrink_slab+0x180/0x490
<6>[108613.090041]  shrink_slab+0x214/0x350
<6>[108613.090043]  shrink_node+0x3c4/0x760
<6>[108613.090045]  balance_pgdat+0x2e8/0x6a0
<6>[108613.090047]  kswapd+0x1f8/0x480
<6>[108613.090049]  kthread+0x198/0x1b0
<6>[108613.090054]  ret_from_fork+0x10/0x20
<0>[108613.090060] Code: 11000442 b9001822 d53cd042 8b020000 (f833001f) 
<4>[108613.090067] ---[ end trace 0000000000000002 ]---

My kernel version is: 5.15.136-rt-tegra

HW used- Jetson orin nano devkit

OS version- Ubuntu 22.04

Hi 0e355f7dd4ed74e0f4b2704d4,

I’ve moved your topic to the correct category for Orin Nano.

What’s the Jetpack version in use?

Do you have any customization in kernel which may cause this panic?
Please share the steps to reproduce the issue.

1 Like

Jetpack version:

sudo apt-cache show nvidia-jetpack
[sudo] password for cobot: 
Package: nvidia-jetpack
Source: nvidia-jetpack (6.0)
Version: 6.0+b106
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.0+b106), nvidia-jetpack-dev (= 6.0+b106)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.0+b106_arm64.deb
Size: 29296
SHA256: 561d38f76683ff865e57b2af41e303be7e590926251890550d2652bdc51401f8
SHA1: ef3fca0c1b5c780b2bad1bafae6437753bd0a93f
MD5sum: 95de21b4fce939dee11c6df1f2db0fa5
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

Package: nvidia-jetpack
Source: nvidia-jetpack (6.0)
Version: 6.0+b87
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.0+b87), nvidia-jetpack-dev (= 6.0+b87)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.0+b87_arm64.deb
Size: 29298
SHA256: 70be95162aad864ee0b0cd24ac8e4fa4f131aa97b32ffa2de551f1f8f56bc14e
SHA1: 36926a991855b9feeb12072694005c3e7e7b3836
MD5sum: 050cb1fd604a16200d26841f8a59a038
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

About kernel customization, we have following things added:

  1. Install a non-stock EtherCAT stack from source (not just apt default).
  2. Build EtherCAT kernel modules (make modules) and install them (make modules_install).
  3. Run depmod after EtherCAT module install.
  4. Force EtherCAT master binding to base NIC by setting MASTER0_DEVICE to eth0 MAC.
  5. Force EtherCAT to use the generic driver path (DEVICE_MODULES=“generic”).
  6. Add udev rule KERNEL==“EtherCAT[0-9]*”, MODE=“0666” for device permissions.
  7. Enable and auto-start ethercat.service on boot.
  8. Modify ethercat.service ordering to require/start after network-online.target.
  9. Build and install out-of-tree Realtek r8125 NIC kernel module against target kernel headers.
  10. Package that r8125 module into flashed rootfs/initrd flow.
  11. Blacklist rtl8822ce kernel module on base.
  12. Explicitly unload blacklisted modules if already loaded.
  13. I think we have one more usb to can driver which is added while making the flashing image but other then that we dont have any major out of tree changes.

This are the only modifications which I dont even think are kernel level mods

Steps to reproduce-

This isnt something that we can reproduce because this is a long running system which runs for 8 hrs and the issue itself is not something we can reproduce without having deep knowledge of the linux kernel, so this is the best I can give you

The panic is a kernel memory‑corruption crash: kswapd0 is freeing ext4 pages, goes through kmem_cache_free → memcg_slab_free_hook → obj_cgroup_uncharge → percpu_ref_get_many, and there it dereferences a completely invalid pointer (ffff4c8d52afe000, level‑0 translation fault). That means some earlier code has already corrupted or freed the memcg/objcg/percpu_ref data, and the generic memory‑reclaim path is just where it finally explodes.

I have noticed that you are using rt-kernel.
Have you confirmed that your EtherCAT module was built with rt enabled?

Please also provide the full log as file here for further check.

I will checkout the packaging of ethercat module and rt kernel packaging, give me some time. Meanwhile here are the full logs

2026-02-27T19-19-27__console-ramoops-0.txt (512.0 KB)

2026-02-27T19-16-45__dmesg-ramoops-0.txt (106.6 KB)

2026-02-27T19-16-46__dmesg-ramoops-1.txt (106.6 KB)

<0>[108613.090060] Code: 11000442 b9001822 d53cd042 8b020000 (f833001f) 
<4>[108613.090067] ---[ end trace 0000000000000002 ]---
<6>[108613.090595] EtherCAT 0: Domain 0: Working counter changed to 0/33.
<0>[108613.599168] Kernel panic - not syncing:

It seems the kernel panic is caused from your EtherCAT module.

You can also check if there’s the similar issue if you don’t enable rt-kernel.

1 Like

Thats insightful, and I am checking my kernel driver config as we speak, may I know though that how can something in my kernel driver cause a kernel panic?

Especially if you see the calltrace it points to an issue in the linux kernel and not in the kernel driver itself, if it was actually the ethercat driver wouldnt the call trace have function/API/ABI calls related to that? Just a curious question before I start rooting apart completely the ethercat driver

I checked the build workflow I have answers on it with a few caveats-

The ethercat driver is loaded as a kernel module and is not part of the base kernel image.

If you are asking, that was the ethercat module built with sysroot as the rt kernel of jetson, yes that does happen,

If you are asking the ethercat driver itself has rt-enabled flag, I dont think so

Hi @KevinFFF can anyone respond

As you are using the rt kernel, please build your driver with rt-enabled.
You can simply run the following command to check.

$ modinfo <EtherCAT module> | egrep 'vermagic'

Or, please check if there’s the similar issue if you use normal kernel.

Hi @KevinFFF Here is the grep which I assume says that the module was compiled with rt kernel as sysroot

$ modinfo ec_master
filename: /lib/modules/5.15.136-rt-tegra/ethercat/master/ec_master.ko
version: 1.5.2-sncn-13 unknown
license: GPL
description: EtherCAT master driver module
author: Florian Pose fp@igh-essen.com
srcversion: E502E788209561333B5BC3C
depends:
name: ec_master
vermagic: 5.15.136-rt-tegra SMP preempt_rt mod_unload modversions aarch64
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 5A:74:98:5F:31:CD:24:4A:1F:78:53:1E:78:D1:EE:9C:52:23:59:08
sig_hashalgo: sha512
signature: A4:7A:98:F9:F9:49:DB:65:32:B9:84:1B:99:B2:EA:6A:81:DC:85:98:
AD:27:01:34:9C:93:40:BE:24:43:84:4B:CA:6B:46:03:22:64:C4:3D:
30:30:FB:52:67:D3:9A:1B:BC:E8:3E:0B:4F:71:DE:C4:44:4F:E9:7C:
E8:D6:43:8D:14:51:BB:7C:4C:0D:A5:A5:EA:85:6D:C6:32:F0:EC:ED:
AD:C5:2A:16:93:38:D9:97:10:42:B1:ED:6B:96:47:B8:B9:A7:50:2A:
7D:A9:1B:EA:FF:8E:EE:A4:2B:16:6A:8A:58:67:26:CD:EC:82:BD:6A:
18:35:6D:11:65:8F:B2:7A:7C:6F:17:22:07:AB:E5:B9:07:A0:0B:33:
CA:A4:C9:55:CE:97:25:CF:F8:BE:A6:34:CF:FF:AA:33:A9:3C:4D:7E:
83:54:04:82:7A:1F:A6:2B:E3:9E:A2:E3:21:CE:21:FE:53:7B:22:3A:
1B:31:F5:DA:D1:25:86:01:81:B7:49:DF:9E:66:E0:1D:FA:43:9A:E2:
F4:1B:BE:49:C0:87:07:3C:17:8B:E1:BC:B6:CA:6E:95:08:0A:47:25:
96:23:09:B5:DD:B7:EB:99:66:28:59:B7:33:AF:79:C1:4E:94:B6:A0:
73:C1:7D:D8:CF:8A:2B:A4:B9:D1:31:80:22:37:06:EC:B0:E2:5B:A7:
35:1A:0C:14:FA:31:5D:B4:AD:79:EB:EB:A0:E0:8C:64:EE:E0:35:39:
7F:21:BB:11:C2:AD:9E:11:10:1A:70:AE:33:FC:61:BB:1E:8A:7C:7F:
2D:AF:DB:4C:9A:21:66:E6:D0:3C:08:72:04:BE:C9:8A:3B:A2:81:6C:
3C:B4:EB:B9:29:1C:05:FF:BF:43:4C:D0:A7:35:68:70:16:DD:7B:3E:
72:75:03:82:04:29:4B:AE:DF:A3:11:EC:C4:F6:67:A4:69:5C:DF:9F:
84:BF:BF:91:46:2F:CE:60:E5:FB:E6:2F:28:A2:C5:31:BF:C8:AC:37:
4F:66:88:AD:D5:B1:0A:0B:5A:94:5F:01:C5:C1:00:39:81:81:0C:B9:
B3:26:35:3F:91:92:20:76:03:5F:9F:AA:E5:E7:94:79:22:98:50:71:
1D:FE:85:51:AB:B0:66:03:AC:A4:FD:B2:7D:D7:71:85:47:74:5A:C7:
22:F1:BC:71:72:7F:8A:C1:98:72:3F:55:7B:F0:B3:46:F4:65:95:8B:
75:34:69:71:4B:DF:B6:E7:0F:4A:B3:47:0C:31:B5:4C:7A:FB:83:8F:
40:CF:D3:51:60:7D:01:19:5C:71:CE:3D:B8:3A:75:6F:17:CF:C1:5C:
CD:FE:3D:D9:3D:54:CD:DF:D7:22:60:BA
parm: main_devices:MAC addresses of main devices (array of charp)
parm: backup_devices:MAC addresses of backup devices (array of charp)
parm: eoe_interfaces:EOE interfaces (array of charp)
parm: eoe_autocreate:EOE atuo create mode (bool)
parm: debug_level:Debug level (uint)
parm: pcap_size:Pcap buffer size (ulong)
$ modinfo ec_generic
filename: /lib/modules/5.15.136-rt-tegra/ethercat/devices/ec_generic.ko
version: 1.5.2-sncn-13 unknown
license: GPL
description: EtherCAT master generic Ethernet device module
author: Florian Pose fp@igh-essen.com
srcversion: 554EB723DDBCE2DF00D93D4
depends: ec_master
name: ec_generic
vermagic: 5.15.136-rt-tegra SMP preempt_rt mod_unload modversions aarch64
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 5A:74:98:5F:31:CD:24:4A:1F:78:53:1E:78:D1:EE:9C:52:23:59:08
sig_hashalgo: sha512
signature: 5C:B1:B1:71:72:0B:10:12:49:6A:C2:EE:5B:06:C2:E6:BA:67:51:EC:
5B:62:9E:2C:40:67:5E:EA:52:B7:5D:09:AA:8D:74:B5:F5:98:7B:22:
DA:80:A2:23:B5:30:A3:33:ED:0B:17:EC:29:EB:49:6B:9D:5E:6E:67:
E4:88:A9:80:53:40:CC:DD:A7:DE:3E:7A:54:13:47:6B:68:29:93:D5:
70:BF:34:09:6E:B2:75:F1:60:3D:BB:BE:9C:00:02:4C:54:58:54:DA:
AE:2B:15:0F:9C:B4:A5:4C:98:BD:43:8D:11:62:D6:87:FB:10:A3:E9:
E8:70:49:20:3A:0F:7E:86:67:D8:1C:F6:DA:7D:59:C3:C3:4A:85:A6:
54:32:E5:96:E3:56:B9:46:CF:6C:83:F0:39:D2:BC:D0:05:8C:6D:49:
9A:4D:06:56:54:40:76:A0:54:8F:46:36:A7:18:9C:2C:46:77:C6:B8:
FC:C1:92:63:A6:E2:CB:6C:3E:C9:94:DE:27:64:C4:C4:4B:99:99:F3:
6D:7A:66:81:01:6D:6D:1A:82:01:F5:54:00:89:C8:9A:18:54:65:E4:
80:73:BA:35:4D:13:0C:05:3E:9C:77:26:C0:D1:17:92:62:22:2F:C8:
45:18:33:28:5D:EF:B4:70:50:90:2D:68:B9:59:C5:6C:BE:1A:18:3C:
62:CE:B9:08:D1:AB:31:26:93:D7:AD:07:D2:5C:F4:78:96:7C:D3:B0:
8E:5E:3A:59:4B:57:3D:86:CC:15:28:19:FF:48:89:EA:A4:54:3D:C8:
B4:CF:5C:2F:65:DE:D9:67:6E:81:BE:6B:9F:E5:A3:4C:6D:90:F7:AD:
76:55:14:E3:0B:1B:A1:19:CD:9B:34:01:76:38:E8:2A:4B:D9:BD:91:
3E:A9:84:C7:84:FE:9C:F2:9B:E5:E9:B0:19:A7:A5:82:91:A1:64:A6:
10:FF:5B:FA:FA:90:4F:D1:AD:9A:84:6C:C6:D9:79:7A:7E:0B:8C:14:
71:78:DB:81:C1:BD:79:1C:4E:3E:ED:5F:58:E5:FF:CA:ED:77:05:28:
D2:8A:4D:1B:D2:69:18:29:49:1F:EB:8F:0E:4F:62:93:CC:84:A0:65:
1C:50:E2:84:64:70:28:36:B2:78:5E:92:B1:A0:92:1D:B3:41:6D:BC:
F3:A8:92:A0:DD:59:1E:04:5A:67:69:F4:67:C7:F0:01:5A:4F:1B:AA:
A9:71:6E:C2:26:A7:3F:6D:7D:50:8C:DF:39:51:5A:36:B2:0F:85:49:
11:BA:6D:9E:DD:8F:34:0C:DB:45:B5:55:74:80:29:F2:58:9F:AC:4C:
F2:30:76:DC:6B:42:0C:A9:D9:60:42:9D

Is ec_master your kernel module for EtherCAT?
It seems there’s the preempt_rt flag.

Could you also help to check this?

1 Like

Yes ec_master and ec_generic both are compiled with preempt-rt. I am guessing that is nominal in your perspective for the 5.15.136 rt tegra kernel?

About the non-rt run, I can check it out, but a lot of our userspace applications need preempt-rt feats and cannot work without that. Those userspace applications are responsible for querying this ec_master kernel module and have sched_rr and rtprio set, w/o that we loose the rt behavior of those apps.

Yes, preempt_rt flag is expected for the rt-kernel.
As both ec_master and ec_generic are the custom kernel drivers for EtherCAT, please also ask the help from your vendor.

Okay, it is just helping to clarify if the current kernel panic is caused from rt-kernel.

Yes but those drivers arent the one causing a kernel crash, something in kswapd is causing one? Can you answer this @KevinFFF

Even though the crash happens in kswapd, the trace shows it’s using a completely invalid internal pointer, which strongly indicates earlier memory corruption. With your out‑of‑tree modules (ec_master, ec_generic) loaded, the most likely root cause is a custom driver corrupting kernel memory, and kswapd just happens to be where it finally panics.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.