How to automatically run jetson_clocks.sh on TX2 at startup ?

Hi:
How to automatically run jetson_clocks.sh on TX2 at startup.

Hi aravind24.ece,

Add jetson_clocks.sh command at the end of the /etc/profile script and reboot the TX2 board.By default jetson_clocks.sh command will be loaded at startup while launching the initial UI screen.

You might also consider adding this to the end of “/etc/rc.local” (assumes “~ubuntu/jetson_clocks.sh”, but in later releases it might be “/usr/bin/jetson_clocks”):

sleep 60
# For releases prior to R32.x:
~ubuntu/jetson_clocks.sh
# For releases of R32.x+:
/usr/bin/jetson_clocks

It’s easy to test or remove if it doesn’t help. The reason I suggest this instead of the profile is that profile might require a login. The profile login method would actually be a better choice in cases where you know someone is logging in (there is no need for a timer and no waste of heat/power until it is needed).

You could also consider nvpmodel setup this way, or simply setting that model as default.

The sleep 60 is because until the kernel reaches a stage where “/sys” files can accept input the command will fail. I’m blindly assuming that 60 seconds after rc.local is reached login and jetson_clocks will be available.

Jetson AGX Xavier
JetPack 4.4

I tried it and it appears to work. But the system getting unstable and auto reboot frequently. Then I delete the /etc/rc.local, system get back to normal again. Wonder why?

I can think of a few possibilities. First is that when you run at maxed out clocks more heat is generated, and shutdown might be due to thermal reasons.

The second reason would be that as clocks max out so does power consumption. Perhaps the power supply has a weakness when run at full power (the weakness could be nothing more than reduced regulation…changing power voltages can trigger shutdown).

The final reason might be that RAM or disk is used up. Not likely since things work when clocks are not maxed, but if for some reason the system got more work done, then perhaps this accelerated an existing issue of running out of resources.

You might connect to this with a serial console (which will not fail when the Jetson dies) and run the “tegrastats” program on the console.

After the unknown shutdown and reboot you might also check the output of:
sudo cat /sys/kernel/pmc/tegra_reset_reason
(you could actually make that part of “message of the day” and/or “/etc/rc.local”)

thank you linuxdev.

I always manually “sudo jetson_clocks” whenever power up and the system run normal without frequently reboot (at least in the past few weeks never experience that). That’s why I try this solution and would like to have system do that for me whenever I power up. But after put “sleep 60” and “jetson_clocks” in rc.local, it kept rebooting in couple minutes…

Then I delete the rc.local file, everything goes back to normal again (no rebooting automatically any more)

I wonder if the “jetson_clocks” run before certain event might mess up the system…?

By the way, I check the /sys/kernel/pmc/tegra_reset_reason when it automatically reset:

-r--r--r-- 1 root root 4096 Jul 31 14:22 tegra_reset_level
-r--r--r-- 1 root root 4096 Jul 31 14:22 tegra_reset_reason
paul@agx:/sys/kernel/pmc$ cat tegra_reset_reason
TEGRA_SOFTWARE_RESET
paul@agx:/sys/kernel/pmc$ cat tegra_reset_level
TEGRA_RESET_LEVEL_L1

I suppose that is possible, but doubtful. At certain points during boot, as various drivers load, content begins to be added to “/sys”. Various arguments passed to drivers, whether through “/sys” or other means, can also add or change what is visible in “/sys”. At the point in boot where it becomes possible for jetson_clocks to pass arguments through “/sys” implies drivers were up and running.

There may be a “gotcha” to this, though I doubt it is occurring. Consider that the applications “nvpmodel” sets up a range of available clocks and which cores are available. This establishes ranges of values, but does not actually change the current state unless the current stage is outside of that range. jetson_clocks will set max for that state. The result of jetson_clocks will differ if and only if nvpmodel was different at the time of running jetson_clocks. If for some reason nvpmodel was different than what you would normally do at the point of running in rc.local, then it becomes possible for jetson_clocks to have alternate behavior.

So I am going to propose an experiment for you. In a normal boot, without the rc.local, prior to running “jetson_clocks”, query nvpmodel to ask it what the current state is:
sudo nvpmodel -q

Most likely the default model “2” will be shown. In your rc.local script, try adding the jetson_clocks back in (sleep the 60 seconds first), and run “/usr/sbin/nvpmodel” before and after the call to jetson_clocks. I’m thinking that you should see the output in boot messages, but if not, then you could redirect the result to a file. See if the jetson_clocks was in nvpmodel state 2 or some other state.

Another test is that when you run manually, if you really want max performance, then first run “sudo nvpmodel -m 0” before running “jetson_clocks”. If you were previously running in the default model 2 state, then model 0 can be expected to consume more power and produce more heat…if this is why rc.local running jetson_clocks, then manually going to model 0 (which enables everything to its max, but does not actually set clocks until jetson_clocks runs), then it too may cause reboot.

However, your /sys/kernel/pmc/tegra_reset_reason says probably shutdown has nothing to do with heat or power. Something is most likely telling the system to shut down or reboot. One possibility for this is the out of memory (“OOM”) killer. This kicks in when RAM is nearly gone, and if applications cannot be shut down in time, then the system may just fail and shutdown or reboot. For this I recommend using serial console and monitoring something like :

  • htop
  • tegrastats
  • watch -n 1 egrep -i 'mem' /proc/meminfo
  • dmesg --follow

…viewing this from a serial console means you’ll see the last view prior to shutdown without it being erased (serial console displays to the host PC, not the Jetson, so whatever the Jetson did last will stay visible).