Jetson Thor CPU permanently throttled to 242 MHz after OC3 event at boot

[henry74]

Jetson AGX Thor CPU permanently throttled to 242 MHz after OC3 event at boot (R38.4.0, Forecr DSBOARD-THRMAX)

Environment

• Module: Jetson AGX Thor
• Carrier board: Forecr DSBOARD-THRMAX
• BSP: L4T R38.4.0 (nvidia-l4t-core 38.4.0-20251230160601)
• Power mode: MAXN (mode 0), governor=performance, jetson_clocks applied

Problem

All 14 CPU cores are permanently throttled. The BPMP silently ignores frequency requests from the kernel without returning an error, so scaling_cur_freq reports success while the hardware remains stuck:

Before jetson_clocks (schedutil governor):

$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
972000  (most cores)

$ sudo cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
242000  (all cores)

After sudo jetson_clocks (performance governor, min=max=2601 MHz):

$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
2601000  (all cores — kernel thinks it succeeded)

$ sudo cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
649000  (all cores — actual hardware, 1/4 of requested)

jetson_clocks partially helps (242 → 649 MHz) but the BPMP still caps at ~25% of the requested frequency.

dmesg shows the cpufreq driver detecting the mismatch on readback, every second, for all cores:

cpufreq: cpu0,cur:649000,set:2601000,delta:1952000,set ndiv:289
cpufreq: cpu6,cur:242000,set:972000,delta:730000,set ndiv:108
cpufreq: cpu4,cur:337000,set:1350000,delta:1013000,set ndiv:150
(repeats every second for all cores, every frequency request fails)

Total system power is ~25W in MAXN mode. The module should be drawing 60-100W+ under load.

Cause

Immediately after every reboot — before any userspace load — OC3 has already fired:

$ sudo su -c 'grep "" /sys/class/hwmon/hwmon*/oc*'
oc1_event_cnt:0
oc1_throt_en:0
oc2_event_cnt:0
oc2_throt_en:1     # enabled despite zero events
oc3_event_cnt:1    # single event at boot
oc3_throt_en:1     # read-only, cannot clear from userspace

Thermals are 36°C — no thermal issue. The OC3 event appears to be an inrush current spike during power-on.

The BPMP confirms maximum throttling is latched:

$ sudo cat /sys/kernel/debug/bpmp/debug/ithrot/cal
sm_pwr_throttle = 0xffffffff

All throttle bits are set to maximum and never release. oc3_throt_en is read-only (-r--r--r--), so there is no userspace workaround.

Questions

1. Is the permanent latch to minimum frequency on a single OC3 event the intended BPMP behavior, or is this a firmware bug? Can the OC thresholds be adjusted via the BPMP device tree?
2. Why is oc2_throt_en enabled by default with zero events — could this contribute to the throttle behavior?

[WayneWWW]

please move to Jp7.1 ans test again.

[whitesscott]

This might be relevant; some of the frequencies in your post are equivalent to what is set by nvpmodel.

sudo nvpmodel -q

will show your current model. This file defines the models and sets cpu frequencies.

ls -al /etc/nvpmodel.conf → /etc/nvpmodel/nvpmodel_p3834_0008.conf.

[henry74]

@WayneWWW My Jetson Thor has L4T R38.4, which already corresponds to Jetpack 7.1.

Have you seen the issue I have described before?

[henry74]

@WayneWWW

Update: Additional diagnostics

I switched to 70W mode (nvpmodel -m 3) and found that the BPMP applies a fixed 25% divisor, not a frequency ceiling. The ratio is constant across all requested frequencies:

Mode	Requested	Actual	Ratio
MAXN	2601 MHz	650 MHz	25.0%
70W	1998 MHz	499 MHz	25.0%
70W	972 MHz	242 MHz	25.0%

The mode change required a reboot. After reboot, oc3_event_cnt is still 1 and sm_pwr_throttle is still 0xffffffff — the latch persists across reboots.

I confirmed the NAFLLs output the correct frequency — the PLLs are not clamped:

nafll_cpair0..5: 1998000000 Hz  (correct for requested frequency)
VDD_CPU: 800mV                  (regulator operating correctly)

The 25% divisor is being applied downstream by the BPMP internal throttle (ithrot), not by clamping the PLL.

I dug into the ithrot debugfs and it’s stuck at maximum throttle depth. ithrot is stuck at maximum throttle depth, and an OC3 event fires at every boot — though causation between the two has not been confirmed.

Register	gpc0 (GPU)	gpc1 (CPU)	gpc2 (CPU)
enable	na	1	1
gst	na	1	1
step	na	40 (max)	40 (max)
duration	na	39	39
slow_factor	na	1	1
weight	na	0xfafa0000	0xfafa0000
window	na	15	15

Other ithrot state:

sm_pwr_throttle = 0xffffffff  (all throttle bits maxed)
pwr_throttle    = 0x30000000
delta_us        = 0           (writable — ramp-down interval?)

delta_us = 0 is notable — if this controls the step decrement interval, a value of 0 would mean “never ramp down.”

I also compared against an AGX Orin in our fleet on the same carrier board family. That unit shows 51 OC3 events with oc3_throt_en: 1, yet cpuinfo_cur_freq matches scaling_cur_freq perfectly at full speed. On Orin, OC3 throttling is momentary and releases as expected. On Thor, a single event permanently latches sm_pwr_throttle = 0xffffffff with no recovery.

This suggests a Thor-specific BPMP firmware bug in the throttle release path rather than a power delivery issue.

[WayneWWW]

Hi,

Let make it more brief first.

What is the procedure to reproduce the error you saw?

It sounds like your board is in a state that is not able to recover?

[henry74]

Hi @WayneWWW ,

Yes, the CPU on my Thor is stuck in a throttled state, despite nominal operating conditions (37°C).

To replicate: put a Thor on R38.4 (JP 7.1) on the Forecr DSBOARD-THRMAX, power on, and run jetson_clocks. After that, scaling_cur_freq reports 2601 MHz but cpuinfo_cur_freq shows 650 MHz–exactly 25% of requested. This ratio holds across all power modes and frequencies.

I don’t know exactly why this is happening, but it appears the BPMP is applying a fixed 25% throttle to the CPU and never releasing it. Do you know what could cause this?

Thank you,
Henry

[WayneWWW]

Hi,

Just want to clarify again.

Is your board able to work normally if you flash the board once again or to some old Jetpack version like JP7.0?

Most of behavior from BPMP is related to hardware state. If your board fails to recover, it is possible to be hardware issue.

[henry74]

Hi @WayneWWW ,

We have not yet tried going back to an older version of Jetpack. We need the Thor to work with Jetpack 7.1. We can try Jetpack 7.0 as a last resort.

Yes, likely some hardware state triggered the BPMP throttle, but the issue is that the Thor does not recover from this throttled state. Do you know what might be causing this issue?

Thank you.

[WayneWWW]

I don’t think this is related to software problem here.

Do you have other carrier board that can do cross check?

[henry74]

Hi @WayneWWW ,

After more investigation, it appears that our carrier board is missing the INA238 chip, which, according to the AGX Thor design guide, is responsible for measuring and reporting the power consumed by the overall system.

Would the missing INA238 chip cause the persistent throttling state that my Jetson Thor is experiencing?

Thank you,
Henry

[WayneWWW]

Yes, that is possible