With nvmodel -m2 make -j6 use only 4 cores

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?
/etc/apt/sources.list.d/nvidia-l4t-apt-source.list.LOCKED

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

Hi

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.

Laurent.

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.
thanks

Jerry,

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.
before

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

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,
thanks

HI

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.

So glad I just flashed 4.3 rather than wait for this to get fixed…

crickets…

what is it ???

I’m still waiting for a fix. Jetpack 4.4 turns the TX2 into a worse performer than the nano by disabling 1/3 of the system.

Is NVIDIA going to fix this?
OR
Is the plan to leave it as it is for all future JetPack releases and force customers to make the described change if they want to run processes on the Denver cores?

It’s NOT fixed though. An update undoes the fix.

Hi,
Please refer to