The TX2 flashing system uses JetPack4.3, and only a usb2.0 camera is connected to the system. When the system runs normally for a period of time, it is found that video0 correctly recognized by the system suddenly becomes video1, and video1 cannot be called by the system. Could this be the cause of TX2?Below is syslog.
A serial console log would be much better since we can’t text search or quote an image.
The content of files in “/dev” is actually not in the filesystem itself, but is communications from drivers in the kernel pretending to be files. The udev system will see certain devices, e.g., USB video cameras, and create the “/dev/video0” if the camera uses a standard USB video driver. If there is a second camera, then it will be numbered sequentially as “/dev/video1”, and so on. This is actually the “udev” system monitoring USB and determining the naming pattern for the file.
If a camera disconnects and reconnects, then the udev system does not know that this isn’t removal of the video0 camera, followed by addition of a new camera. A disconnect/reconnect will thus “move” or “rename” from “video0” to “video1” even if it is the same camera.
FYI, I see something like this in the log:
uvcvideo: Failed to resubmit video URB (-19).
This is actually what I believe to be a USB error, and is basically the continuation of some USB log info. You are seeing a disconnect and reconnect due to some error in the data communications through USB. If not for that error, then the camera would not rename because then it wouldn’t fail and be restarted. I do not know what the particular error is, someone else will have to help with that.
There are some common things to consider with a USB error.
One possible issue is that two or more devices are on the same HUB such that there is not enough bandwidth to support all devices, in which case one might drop out. You’d never have to worry about the bandwidth taken by a keyboard or mouse…but a second camera would use a lot of bandwidth.
Another possibility is that you are going through a HUB and the combination of cables and HUB just can’t handle the signal properly.
A more common possibility is that the camera is taking significant power which the HUB and/or other parts of supply of power will fail momentarily for when there is peak power consumption. If the camera is externally powered, then this won’t ever be an issue. If you are using a HUB, and if the HUB is externally powered, then this will also not be a problem.
Sometimes the act of plugging the camera in directly will have a different signal quality than going through a HUB…with or without the HUB might lead to one combination working, but not the other.
Watch for those “Failed to resubmit video URB” messages. If the camera is not self-powered, then do what you can (e.g., a powered HUB) to remove the power delivery requirement from the Jetson, and watch again for those messages. Basically this is a USB error and power delivery is the first initial and most likely cause. Then move on to different HUB combinations (or direct to port instead of via a HUB).
Similar to the above problem, the video is disconnected, can you analyze this log for me?syslog (19.1 KB)
syslog.1 (260.5 KB)
syslog.2 (256.9 KB)
If you monitor “dmesg --follow”, and only then plug in the camera, what does it show? Once the camera has just plugged in, what do you see for “lsusb”? I’m trying to narrow down some logs to the specific device. Also, if you have an exact model for your USB camera, please add that information.
I did see this which makes me think perhaps it is an issue with the camera itself (which can probably be worked around if the log is for the camera):
Jul 1 17:00:21 uvision-desktop kernel: [ 94.023194] tegra-xusb 3530000.xhci: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
Jul 1 17:00:21 uvision-desktop kernel: [ 94.033205] tegra-xusb 3530000.xhci: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1
Jul 1 17:00:21 uvision-desktop kernel: [ 94.043631] tegra-xusb 3530000.xhci: Looking for event-dma 00000000ffe0e6d0 trb-start 00000000ffe0e6e0 trb-end 00000000ffe0e6e0 seg-start 00000000ffe0e000 seg-end 00000000ffe0eff0
Note in the above it is thinking that one might need to turn on the “quirk” code, which exists in the kernel, but would have to be associated with the device ID.