I’ve been trying out a few different USB (UVC) cameras on Jetson TX1. And I can reproduce the problem with all of them. For example, when I plugged a Logitech C920 into the USB 3.0 port of Jetson TX1 and ran the OpenCV “hog” sample (samples/gpu/hog) with live camera feed, the TX1 system would usually hard hang within 2~3 hours. If I ran the same OpenCV “hog” sample with a video file input, the TX1 system could work overnight without problem.
I’m using JetPack 2.0 on Jetson TX1. Has anyone experienced a similar problem?
Thanks for reporting the issue, we are currently investigating the case and we’ll let you know when we have an update.
Because the Jetson is mostly designed to be an embedded device, it tries to conserve power by automatically suspending inactive USB ports to save power. Not sure if the hang was caused by “temporarily” disabling USB.
You may need to disable USB auto suspend mode, this is a link to being sure lower power is not entered:
[url]http://elinux.org/Jetson/Performance[/url]
We are working on reproducing the issue. In the meantime, I would request you to send us the sample along with the steps followed for running it, which could help us in replicating the scenario at our end.
I did more testing and found the problem only occurred when I used the UVC camera and the GPU (for computer vision tasks) simultaneously. I’m now trying to find an easy and deterministic way to reproduce the problem. I think I’ll post the repro steps in 1~2 days.
(Since the OpenCV4Tegra which comes with JetPack-2.1 does not support live camera input, I have to compile OpenCV from source to be able to repro the problem.)
Here’s some additional validation work I’ve tried on Jetson TX1:
Environment: Jetson TX1 with fresh Jetpack-2.1, with a Logitech C920r camera plugged into the USB 3.0 port
If I only exercise the camera, I cannot repro the problem. The following works fine overnight.
I have 2 Jetson TX1 boards on hand. I can now conclude that the USB hard-hanging problem is more easily reproduced on the older board (bought around Dec. 2015), but it’s very difficult to repro the problem on the newer board. I’ll post more information, such as S/N, about the boards later.
Here’s how I reproduce the problem on Jetson TX1.
Download “OpenCV for Linux/Mac (Version 3.1)” from Releases - OpenCV
Compile and install OpenCV-3.1.0 by following the official Jetson Installing_OpenCV guide.
# Add universal repository to Ubuntu
sudo apt-add-repository universe
sudo apt-get update
# Some general development libraries
sudo apt-get install -y build-essential make cmake cmake-curses-gui g++
# libav video input/output development libraries
sudo apt-get install -y libavformat-dev libavutil-dev libswscale-dev
# Video4Linux camera development libraries
sudo apt-get install -y libv4l-dev
# Eigen3 math development libraries
sudo apt-get install -y libeigen3-dev
# OpenGL development libraries (to allow creating graphical windows)
sudo apt-get install -y libglew1.6-dev
# GTK development libraries (to allow creating graphical windows)
sudo apt-get install -y libgtk2.0-dev
# Compile and install opencv
cd ~
mkdir src
cd src
unzip ~/Downloads/opencv-3.1.0.zip
cd opencv-3.1.0
mkdir build
cd build
cmake -DWITH_CUDA=ON -DCUDA_ARCH_BIN="5.3" -DCUDA_ARCH_PTX="" -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF -DCUDA_FAST_MATH=ON -DCMAKE_INSTALL_PREFIX=/home/ubuntu/opencv-3.1.0 ..
make -j4 install
Compile and run the OpenCV gpu “hog” sample program with Logitech C920r camera as the video source.
When running the gpu hog program with UVC camera source, I can see xhci related messages in dmesg. And the older TX1 board usually hard-hangs within 2~3 hours. (Note the same test runs OK on Jetson TK1.)
The issue you met is the same USB3.0 camera + OpenCV4Tegra hang issue as below?
“USB 3.0 port of Jetson TX1 and ran the OpenCV “hog” sample (samples/gpu/hog) with live camera feed, the TX1 system would usually hard hang within 2~3 hours. If I ran the same OpenCV “hog” sample with a video file input, the TX1 system could work overnight without problem.”
Or it’s other symptom?
If it’s OpenCV related, then we will have a new version updated within JetPack2.2 release, please stay tuned.
hi, im on a usb webcam, i run the videoCapture code, but it always give me -216 error, could not get any frame, i test the webcam with luvcview, it is working. im on Jetpack 2.1 with opencv4tegra. is there anything i could do to solve the problem? or is there any “for sure” c++ code that can run on Jetpack 2.1?
I am new to Tegra and OpenCV4Tegra. I am having a lot of problems trying to get OpenCV4Tegra to work with the nvidia camera and logitech camera on the TX1.
This command, from the console will display video from the USB camera on the monitor…
$ gst-launch-1.0 v4l2src device=“/dev/video0” ! xvimagesink -e
How can I use the gst pipeline from OpenCV4Tegra to access the camera? If I do the following:
VideoCapture cap (“v4l2src device=‘/dev/video0’ ! xvimagesink -e”)
and then open the cap stream… I get no output. The program does not generate errors, but also does not open any frames from the camera. I have looked at the threads in this forum and it appears that the problem is OpenCV4Tegra on Jetpack 2.1 is not compiled to allow gst usage. Can somebody confirm this?
If this is true, then what good is OpenCV4tegra if I can’t open a video stream from a USB camera or the TX1 provided camera?
Hi AutobotCV, you might want to take a look at this page for some testing info: [url]http://elinux.org/Jetson/Installing_OpenCV[/url]. It’s for TK1 but the interface should be the same for TX1.
Regarding your OpenCV 3.1.0 install issue, that might be the known issue, OpenCV compiling frequently crash in R24.1 64-bit environment. Please repeat compiling till it’s done, or to wait for next release.
Hi, We are facing almost similar issue in Jetson TK1 (R21.4) when using USB3 (UVC) Camera and encoder together.
(Note: if using separately, there was no issue at all. And usb auto-suspend is -1).
[60654.282051] Host read timeout at address 4300
[60654.285137] MSELECT error detected! status=0x3
[60654.285154] ------------[ cut here ]------------
[60654.285156] kernel BUG at drivers/platform/tegra/hier_ictlr/hier_ictlr.c:54!
[60654.285158] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[60654.285169] Modules linked in: dm_crypt dm_mod rfcomm bnep bluetooth rfkill nvhost_vi
[60654.285173] CPU: 0 PID: 3660 Comm: kworker/0:1 Tainted: G W 3.10.40-g868897a #1
[60654.285182] Workqueue: host_syncpt syncpt_thresh_cascade_fn
[60654.285184] task: d2e35080 ti: cfe3c000 task.ti: cfe3c000
[60654.285189] PC is at tegra_hier_ictlr_irq_handler+0x38/0x40
[60654.285192] LR is at tegra_hier_ictlr_irq_handler+0x38/0x40
[60654.285194] pc : [] lr : [] psr: 60030193
[60654.285194] sp : cfe3dc38 ip : 00000000 fp : c0d0a198
[60654.285196] r10: 00000000 r9 : 00000000 r8 : cfe3c000
[60654.285198] r7 : cfe3dcd8 r6 : 0000009f r5 : c0bcb910 r4 : d70ca780
[60654.285199] r3 : 00000000 r2 : 00010100 r1 : 00000000 r0 : 00000023
[60654.285202] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[60654.285204] Control: 10c5387d Table: 8f99006a DAC: 00000015
We are using gstreamer-1.0 for streaming and encoding. Please help us.
You’ll also want to post the camera model/info and lsusb -vvv for that camera (plus lsusb -t). The command producing the OOPS would be useful. Actual L4T version can be posted via “head -n 1 /etc/nv_tegra_release”.