Jetpack 7.2 log spamming

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

On Jetson Orin AGX devkit running Jetpack 7.2, “sudo dmesg” fills with those “cpufreq” messages. Did Nvidia forget to turn off the debug log, or are those messages trying to tell me something?

[75708.273434] cpufreq: cpu8,cur:1253000,set:2201600,delta:948600,set ndiv:172
[75726.827553] cpufreq: cpu0,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[75736.124872] cpufreq: cpu0,cur:1098000,set:2201600,delta:1103600,set ndiv:172
[75764.030244] cpufreq: cpu0,cur:1100000,set:2201600,delta:1101600,set ndiv:172
[75774.414472] cpufreq: cpu0,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[75808.485174] cpufreq: cpu4,cur:1889000,set:2201600,delta:312600,set ndiv:172
[75838.464325] cpufreq: cpu0,cur:1095000,set:2201600,delta:1106600,set ndiv:172
[76114.163150] cpufreq: cpu4,cur:1100000,set:2201600,delta:1101600,set ndiv:172
[76278.225035] cpufreq: cpu4,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[76326.780834] cpufreq: cpu0,cur:1720000,set:2201600,delta:481600,set ndiv:172
[76355.734308] cpufreq: cpu8,cur:1171000,set:2201600,delta:1030600,set ndiv:172
[76538.556597] cpufreq: cpu0,cur:1096000,set:2201600,delta:1105600,set ndiv:172
[76547.806806] cpufreq: cpu0,cur:1721000,set:2201600,delta:480600,set ndiv:172
[76554.031632] cpufreq: cpu0,cur:1100000,set:2201600,delta:1101600,set ndiv:172
[76630.363702] cpufreq: cpu0,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[76760.582311] cpufreq: cpu0,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[76765.755356] cpufreq: cpu8,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[76926.708209] cpufreq: cpu0,cur:1099000,set:2201600,delta:1102600,set ndiv:172
[76950.506399] cpufreq: cpu8,cur:1237000,set:2201600,delta:964600,set ndiv:172
[76983.464406] cpufreq: cpu8,cur:1291000,set:2201600,delta:910600,set ndiv:172
[77014.433904] cpufreq: cpu8,cur:1892000,set:2201600,delta:309600,set ndiv:172
[77094.057686] cpufreq: cpu8,cur:1291000,set:2201600,delta:910600,set ndiv:172
[77118.886507] cpufreq: cpu0,cur:1873000,set:2201600,delta:328600,set ndiv:172
4

On T264/TB50x, Linux/governor provides the desired performance/frequency request, but the final clock is influenced by the AVFS/NAFLL hardware path. In CFOV_LUT skip/min-skip modes, the hardware can use skipper behavior and the final active/average frequency may differ from the raw LUT/NDIV request.

Also, there are existing Thor/T264 bug discussions noting that cur in dmesg can appear lower than set, and some cases specifically question whether this is real throttling or a known set-vs-readback discrepancy rather than an actual failure.

For your specific sample, all the messages are trying to move CPUs up to 2201600 kHz, but the readback stays around 1.09 GHz for cpu0 and 1.89 GHz for cpu4, so the log is basically saying: “request accepted/programmed, but observed frequency is still below target right now.”

If you want, I can help you do the next step too: tell you whether this pattern looks more like normal cpufreq debug noise, thermal throttling, or a real T264 cpufreq issue based on your full log.

Suppose it could be power-supply related.

5

Hi @ShaneCCC

Thanks for the detailed breakdown of the AVFS/NAFLL hardware path and the CFOV_LUT skip behavior. That makes a lot of sense regarding the set-vs-readback discrepancy we are seeing.

Regarding your points, here is a bit more context:

  • Thermals: Thermal throttling seems highly unlikely. Our tegrastats show the CPU and TJ sitting comfortably around 62°C, well below the throttling thresholds.

  • Power Supply: We are using the official power supply that came with the devkit. We aren’t seeing any under-voltage warnings, and the VDD_CPU/GPU power draw looks normal for our load.

  • Active Frequency: Interestingly, while dmesg shows the readback at ~1.1 GHz, tegrastats shows the active cores accurately hitting the target (e.g., CPU [15%@2201,20%@2201...]). This definitely leans toward the known readback discrepancy rather than an actual failure to boost.

If this turns out to be normal cpufreq debug noise/skip-mode behavior and not a real power constraint, is there a recommended way (or a patch) to silence these specific delta prints in JetPack 7.2 so they don’t flood the system logs?

Thanks for taking a look at this!

6

Ways to stop it:

  1. Quiet printk (all warnings, not just this):

echo 3 > /proc/sys/kernel/printk # or: dmesg -n 3

  1. Patch the driver (cleanest for just this message) — change pr_warn → pr_debug (or delete it) in tegra194-cpufreq.c around the MAX_DELTA_KHZ check, then rebuild/reload the kernel module/image.

  2. Widen the threshold — raise MAX_DELTA_KHZ so large deltas don’t warn (hides the symptom; doesn’t fix the freq mismatch).

7

I patched tegra194-cpufreq.c and recompiled the kernel

--- Linux_for_Tegra/source/kernel/kernel-noble/drivers/cpufreq/tegra194-cpufreq.c.orig	2026-06-01 20:08:16.000000000 +0000
+++ Linux_for_Tegra/source/kernel/kernel-noble/drivers/cpufreq/tegra194-cpufreq.c	2026-07-24 20:10:34.841979709 +0000
@@ -610,7 +610,7 @@
 			continue;
 
 		if (abs(pos->frequency - rate) > MAX_DELTA_KHZ) {
-			pr_warn("cpufreq: cpu%d,cur:%u,set:%u,delta:%d,set ndiv:%llu\n",
+			pr_debug("cpufreq: cpu%d,cur:%u,set:%u,delta:%d,set ndiv:%llu\n",
 				cpu, rate, pos->frequency, abs(rate - pos->frequency), ndiv);
 		} else {
 			rate = pos->frequency;

Now the log spamming goes away.

Can you please make sure the patch is included in next release?

8

I don’t think it’s a bug to modify it.

Thanks

9

Hi @ShaneCCC

Thanks for confirming and suggesting the kernel patch that worked!

Since this is a known readback discrepancy with the hardware AVFS/NAFLL path rather than an actual failure, could you please pass this patch (or this thread) along to the internal kernel engineering team to be tracked as a formal bug/enhancement?

Spamming pr_warn every few seconds for a benign hardware state fills up /var/log on edge devices, degrades eMMC lifespan, and masks actual system warnings. Changing it to pr_debug (or adjusting the threshold) in a future R39 release would save a lot of disk I/O and headaches for anyone running these platforms in MAXN mode.

In the meantime, we will deploy an rsyslog drop rule to our fleet to filter out the strings so we don’t have to redeploy a custom kernel Image just to silence the logs.

Thanks again for your help and the deep dive into the hardware behavior!