Verifying realtime kernel for l4t32.6

Hi, I hae the (currently) latest JP 4.6 [rev 3] installed on my AGX. I went through the process of installing realtime kernel as explained in this document, except that I replaced 32.5 with 32.6. I have another machine, an NX running the 32.5 rt kernel. When I issue uname -r on the NX, rt appears in the output, but it doesn’t when I run the command on the AGX with 32.6 rt-kernel

#running on NX with jp4.5 and l4t32.5
jp45@jp45-desktop:~$ uname -r
4.9.201-rt134-tegra
#running on jp4.6 with l4t32.6
agx@agx-desktop:~$ uname -r
4.9.253-tegra

Of course I rebooted and verified the realtime kernel is set to default in /etc/extlinux/extlinux.conf. How do I verify if I’m running the realtime kernel or not?

If the “uname -r” changed prefix from “4.9.201” to “4.9.253”, then you are guaranteed you are running the newer image, although this does not guarantee anything in configuration is valid. However, if you know which configuration items were changed, then examine the content of “zcat /proc/config.gz” (or in a pager, “zcat /proc/config.gz | less”). The configuration shown in “config.gz” is not a real file, but is instead the kernel emulating a file in RAM, and that content is the configuration of the kernel at the time of its compile. If the expected “CONFIG_...” items you changed are there, then you know the kernel has those features.

Caveat: There may be unexpected consequences in changing from kernel 4.9.201 to 4.9.253. Perhaps there is no issue, but if there is a problem, then beware that changing the kernel release version has possible side effects.

Both kernels were compiled by NVIDIA. I did not change any configs, so I wouldn’t know which changes to look for. 4.9.201 and 4.9.253 are on two different jetsons. I did not compare output of uname -r on AGX running primary and rt kernels. I will do that and report back.

It is likely to have a failure if mixing the kernel from two different releases. I am only guessing, but I suspect that a simple copy like this lacks correct setup relative to the other files in the rootfs.

Possibly some of the initrd content could be updated and make it work (though this might still cause other failures while running). Can you post a serial console boot log for both the working and failing case? I’m interested in seeing the handling of both the kernel and the initrd.

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