Enabling CONFIG_DEBUG_INFO_BTF=y on L4T R36.5 and R39.2.1 without losing nvgpu

This is L4T R36.5 (JetPack 6.2.2, kernel 5.15.185) and R39.2.1 (JetPack 7.2.1, kernel 6.8.12).

Posting this because the question comes up every year or so and the answers are scattered across threads that are mostly closed now.

ShaneCCC answered the kprobes half of this back in 2019 for TX2, on kernel 4.4. What has changed since is BTF, which most eBPF tooling now needs, and the fact that rebuilding the kernel takes your GPU with it unless you handle the out-of-tree modules.

What stock ships. Pulled from the running kernel with scripts/extract-ikconfig against an untouched /boot/Image, on JetPack 6.2.2 (R36.5, 5.15.185-tegra):

# CONFIG_KPROBES is not set
# CONFIG_DEBUG_INFO_BTF is not set
# CONFIG_DEBUG_INFO_BTF_MODULES is not set
CONFIG_DEBUG_INFO_REDUCED=y

Same posture in NVIDIA’s 6.8 tree for JetPack 7.2.1 / Jetson Linux 39.2.1. Upgrading JetPack does not turn these on. CONFIG_DEBUG_INFO_REDUCED=y matters too, since CONFIG_DEBUG_INFO_BTF depends on it being off.

The delta is five lines on JetPack 6:

CONFIG_KPROBES=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_LOCALVERSION="-tegra-tetragon"

On JetPack 7 you also need CONFIG_DEBUG_INFO=y written out, because it is absent from the 6.8 defconfig where it was already on in 5.15.

The line that costs you the GPU. CONFIG_LOCALVERSION on stock R36.5 is the empty string. The -tegra you see in uname -r does not come from there. If you set it to -tegra, your module path collides with stock’s and modules_install overwrites the tree you were keeping as a fallback. Give your build a distinct suffix. Ours says tetragon because that is what we run; any distinct string works.

Then rebuild the out-of-tree NVIDIA modules against the new Module.symvers, or nvidia-smi stops working and /dev/nvgpu* disappears. On R36.5 the rebuilt nvgpu.ko lands in updates/, not where the original was, so a path check against the old location fails on a build that actually succeeded.

On BTFIDS. There are reports going back to L4T 35.1 in 2022 of BTFIDS vmlinux / FAILED unresolved symbol netlink_sock, and NVIDIA supplied a fix in this Orin NX thread last August, adding BTF_ID(struct, netlink_sock) to net/netlink/af_netlink.c.

Every report I can find is on the 5.10 line. We did not hit it on 5.15.185 or 6.8.12, building natively on the board with pahole v1.25, gcc 11.4.0 and GNU ld 2.38. No patch, nothing suppressed, .BTF and .BTF_ids present in vmlinux both times.

I am not saying the bug is fixed and I am not claiming pahole 1.25 is the reason. Two builds, those tool versions, newer kernels than the reports. If you are on JetPack 6 or 7, it is worth trying the build before patching source.

One thing worth knowing if you are doing this on a workstation. CONFIG_DEBUG_INFO_BTF_MODULES depends on PAHOLE_HAS_SPLIT_BTF. With no pahole on the build host, olddefconfig drops the symbol silently, exit code 0, no warning. You get a kernel that looks right and has no module BTF. Install pahole 1.19 or newer on whatever runs the build, often packaged as dwarves.

Boundary. Built and booted on JetPack 6.2.2 on an AGX Orin devkit. JetPack 7.2.1 is built and BTF-verified but not flashed or booted. I have not run any of this on Thor.

Full scripts, the config profiles, known failures and a file listing what is and is not actually demonstrated: GitHub - sentoclaw/jetson-tetragon-kernel · GitHub . Apache-2.0.

Thanks for information.

Thanks