Developing with SSD on Jetson TX2 and getting segmentaion fault

I use a SSD as the root directory for development following the tutorial
I’ve installed CUDA and CUDNN and used

nvcc -V

to verify.
Also, use cudnn_sample_v6 to verify CUDNN, but get “segmentation fault”.


Could you also test CUDA sample which is located at ‘/usr/local/cuda-[version]’?


Sure, all of the CUDA samples result in the same “Segmentation fault (core dumped)”.


You might want to run in gdb and get a stackframe/backtrace.


What do you mean and how to fix it?


Stack frames are just debug info…it won’t actually change anything. When you run a program in gdb and it crashes from a seg fault it’ll stop at the current location in the source code. The “bt” (backtrace) command will show the stack frame…which is a list of what actual source code is running at that instant and just prior.

Do you use arguments when you run the program? Assuming your program is named “sample”, and that you are in the directory where it is, then you would do something like this:

gdb ./sample

The “r” command says to run. Assuming the program crashes it will stop…then “bt” will show the backtrace (stack frame)…this is what you want to post here in the forum. “q” will quit…“y” is when it asks if you really want to quit a running program.


We are trying to reproduce this issue internally.
Just want to confirm that you are using JetPack 3.1 on TX2, is this correct?

We will update further information with you later.


Yes, I am using JetPack 3.1 on TX2.
The version of CUDA is 8.0.84-1 and CUDNN is 6.0.21-1.
The solid-state drive that I am using is Intel.



I am using JetPack 3.1 to install ubuntu 16.04 only.
Then, copy CUDA and CUDNN files in jetpack_download folder, and install them individually.



We have verified the functionality of an installation on SSD.
Everything works well and CUDA can be launched without a segmentation fault.

Guess that there are some issues when setting up the libraries.
Please remember that the CUDA driver for Jetson is included in the OS.
And it’s recommended to install the libraries from JetPack directly.

Please let us know if there is any installed driver or library that not originate from JetPack.


JetPack is capable of installing CUDA on the host as well. Are you sure you didn’t get the x86_64 CUDA files?

Hi, linuxdev

I am quite sure that it was CUDA for arm64, so

nvcc -V

could get the CUDA version.


Hi, AastallL

Follow your suggestion by installing all packages via Jetpack 3.1 and everything goes well before the following step:

I used buildJetsonTX2Kernel and got the new ImageSSD with version -jetsonbot-v0.1.

Then, changed the context in the extlinux.conf file shown as follows.

DEFAULT primary

MENU TITLE p2771-0000 eMMC boot options

LABEL primary
MENU LABEL primary kernel SSD
LINUX /boot/ImageSSD
APPEND ${cbootargs} root=/dev/sda1 rw rootwait rootfstype=ext4

LINUX /boot/Image
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

After rebooting, I ran the CUDA and cuDNN samples and got segmentation fault again.

Could you help me build the JetsonTX2 kernel properly?


When using that kernel what shows up from “uname -r”? Are there modules at “/lib/modules/$(uname -r)/”?

Hi linuxdev,

uname -r

There are two modules folders in the folder “/lib/modules/4.4.38-tegra”:
4.4.38-jetsonbot-v0.1 and 4.4.38-tegra


The main problem is that the new built “ImageSSD” is not going to work with GPU.

It shows only cpu information without gpu as I run “./tegrastats”

RAM 813/7851MB (lfb 1656x4MB) cpu [9%@345,0%@345,2%@345,7%@345,4%@345,3%@345]


This is a serious problem…most of your kernel is therefore missing. Take a look at the content from “/lib/modules/4.4.38-tegra/”. If the build configuration of this directory tree is different than from what you built, then the modules might not be interchangeable. If you only added new configuration, then likely you can just recursively copy the modules from “/lib/modules/4.4.38-tegra/” into your new module directory location, but no promises it will work. Do be careful to not copy symbolic link content and only copy the kernel modules, not the metadata files (then run “sudo depmod -a” and reboot). See if this helps.

Normally if your “uname -r” changes you’d want to run the “make modules” step and then install either to an alternate location and pick which module to copy, or just install the entire new module tree.

The code in buildJetsonTX2Kernel currently builds for L4T 28.2 (JetPack 3.2).
If your system is L4T 28.1 (JetPack 3.1), then you used the wrong kernel sources.

If you are compiling for L4T 28.1 (JetPack 3.1) you must use the kernel sources for 28.1
For example,

git clone git checkout vL4T28.1

Proceed with the rest of the build as directed in the file that was downloaded when the repository was cloned.