With nvmodel -m2 make -j6 use only 4 cores


I have installed JP4.4 on kit TX2. I have do an apt update upgrade.

Trying installing opencv+cuda 3.4.11.

I set jetsonclocks wich work (under jp4.3 fan start immediatly) do wait hight temperature to start. But working.

I set

sudo nvpmodel -m 2

(six cores enabled…) and tegrastats indicate two cores a 0%…

Idem with monitor system two cores at 0%…
CPU [100%@2035,0%@2035,0%@2035,100%@2035,100%@2035,100%@2035]

And when I compile opencv with

make -j6

same issue…

I do same things yesterday on jp4.3 and seem to me it’s works perfectly with all six cores.


See Cannot enable denver cores for TX2 (Jetpack 4.4 DP)
Apparently, NVIDIA has intentionally broke the support or the Denver cores are just so bad at executing ARM64 instructions that they just decided to turn them off in the latest version of the JetPack releases.

Welcome to the Jetpack 4.4 sucks club.

Doing this :

sudo ./flash.sh jetson-tx2 mmcblk0p1

and testing immediatly after :this is ok…


after apt update && apt upgrade

this stop working and another 0% on denver

(and I lose all my installations applications after flash…)

I didn’t test until I had it setup and updated, but I can confirm the second part.

I am curious, when all cores fail to be used, what is the output of this command:
cat /proc/cpuinfo | grep 'processor'
…and if you run the application “htop” (may need “sudo apt-get install htop”), do you see 6 core bar charts, or 4?

I don’t know if this matters for your case or not, but not all compiles will use six CPUs, it depends on how many independent compile targets there are. Most kernel compiles could easily use 6 CPUs, but it depends on the configuration and what might already be complete. Are you testing with a kernel build where there was a “make mrproper” (and new configuration set up) prior to start of build?

I think that an

isolcpus 1,2

is setting somewhere and so the denver cores are not in the scheduler thats explain the two core with 0% with make -j6. If there are inactive they are put off in tegrastats. So you can use six cores with openmp usage…

No need to recompile kernel I sugest first time to just block the apt source like this :


So you can update without lose benfit of update kernel with the modified script :

sudo vim p2771-0000.conf.common
Remove “isolcpus=1-2”: CMDLINE_ADD=“console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0”

This works fine : all six cores are scheduled. But the tx2 nvidia part isn’t updated…

Yes, I just saw this myself after my previous reply on the thread. This is probably correct. Anyone with this issue will want to check the output of “cat /proc/cmdline” and look for the “isocpus” token. If this exists, then the information from the other threads could be used to remove this from the command line. I don’t remember the exact file, but there was apparently a config file which might have this…otherwise a simple device tree edit ("chosen->bootargs") would be enough. However, if “isocpus” does not show up in “cat /proc/cmdline”, then this is probably not the issue.

I use jtop. I has all 6 cores listed. And when you change the profile to the low power ones it will physically say “disabled”.

so flash the drive, then remove that source from the updates before updating? I will try that tonight. If it fails I’ll scream at the sky and flash 4.3.

confirmed. I did this and blocked that update. Now all 6 cores are functioning.

Now I need Nvidia to fix the source.

I am curious, would you be able to post the actual content of this file?

deb https://repo.download.nvidia.com/jetson/common r32.4 main
deb https://repo.download.nvidia.com/jetson/t186 r32.4 main


Precision but I haven’t well test seem it’s should working better also . This command has suggested :

Flash kernel-dtb:
$ sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

should be more interesting than global flash, because it’s not erase your applications.


hi all,

please refer to Topic 124708, you should update p2771-0000.conf.common board configuration file, to remove isolcpus=1-2 property settings.
you cannot update kernel-dtb partition to make it works, please perform a whole flash (even without -r options) to update the images.


I think you are missing the point. We all did that. And yes…it fixes it. However, the first sudo update && upgrade then disables those 2 cores. There is something in the package that needs to be fixed.

I’ve had the /etc/apt/sources.list.d/nvidia-l4t-apt-source.list locked. Cores working.

just to humor you, I bricked my cores again. Here’s the after when unlocking and running an update (and reboot)

The package needs to be looked into. THE FLASH DOESN’T WORK AFTER AN UPDATE

hello vondalej,

it’s isolcpus=1-2 settings has been applied again after system update and upgrade.
please avoid to perform update and upgrade as your temporary solutions, we’ll check this internally,


I am not sure but: it seem thats sometimes the isolcpus is applied by the GRUB. So may be this grub.conf when execute upgrade do the isol cpu.

On TX2 kit the command line seem appear in /boot/extlinux/extlinux.conf and is located line :10…
Is somebody could verify if the isolcpus appears at this line after update/upgrade ?

Embedded systems do not have a BIOS/UEFI, which GRUB depends on, and so there is no GRUB. U-Boot updates could conceivably do this (the embedded equivalent to GRUB), but if U-Boot were updated, then I suspect boot would fail entirely. grub.conf either won’t exist, or will be completely ignored.

You are correct, the location of the equivalent file on a Jetson would be “/boot/extlinux/extlinux.conf”. The “APPEND” key/value pair appends to the kernel command line, but the device tree may provide part of this in earlier boot stages, followed by those boot stages performing slight edits and passing on to the next boot stage. If you look at the APPEND content “${cbootargs}”, this is how the inherited content is used to start the kernel arguments via macro expansion from the inherited previous boot stage environment.

If you look at the device tree “chosen->bootargs” node:

cd /proc/device-tree
cd chosen
cat bootargs

…then you will find the device tree content which was used to form “${cbootargs}”. The exact output of “cat /proc/cmdline” may not be an exact match for this because earlier boot stages can edit the content before passing on to the next boot stage. For example, cboot occurs prior to U-Boot, and will pass the information on to U-Boot, but may alter the content prior to doing so. To change this earlier content you would need to alter the device tree’s “chosen->bootargs” node.

A comment on this: When one boot stage hands off to another some of the result is simply from inheriting hardware in a particular stage. An example might be that a power rail is already up, clocks are running at some default speed, so on. Some of the content of the early boot stage editing may not matter to later boot stages, other than from having the hardware function (and thus not need to pass all of that information to the next boot stage, or to pass it modified). Overall though, I suspect the code which is adding the undesired isolcpus is either from the device tree, or from early boot stage edits. U-Boot itself is probably not involved other than by inheritance.

You can use serial console and interrupt U-Boot to get to its command line. Then you can examine the macros/variables which are being used, and observe if the isolcpus is part of that environment or not. If you hit a key during boot at the correct time (which is not long), then you drop into the boot environment console. Running command “boot” continues boot normally. Command “help” provides what you can do. Command “printenv” shows environment variables. You can also use “${}” syntax with “echo” and see what a variable is, e.g., “echo $foobar” would show you what is in variable “foobar”. Each of these can be altered.

Should you alter a variable in U-Boot, and then “boot”, the changes will only be for that boot. To save those changes across boots you would need to “saveenv”. You could hunt for where isolcpus is coming in to play.