I have a new Xavier kit successfully installed with Jetpack 4.1, however, I face with an issue whenever I like to restart or shutdown the kit. Particularly, the shutting down process was pending at line "[OK] Stopped target Remote File Systems (Pre). " and I had to physically force shutdown button to have the kit off.
For more info, before facing this issue, I’ve once installed jetpack4.1 in this kit and it worked fine. However, there were reasons I had to reinstall software.
For more info, before facing this issue, I've once installed jetpack4.1 in this kit and it worked fine. However, there were reasons I had to reinstall software.
Could you elaborate more about what’s going one in above comment?
If default BSP from jetpack working fine, I doubt it may come from some setting in ubuntu.
My kit is planed to real-time work with a 3D Camera, particularly Intel D435, and connected with it by a USB 3.0 cable. Then the booting issue only happens whenever the 2 device are connected, which means if I remove the USB cable from the Xavier before starting/restarting, everything will work fine.
However, in my target system it does not allow to perform action of removing camera cable like this, so I still need for help from you. Maybe some configuration for USB input needed?
I think the issue not coming from Xavier basing on the following test case:
With other usb devices connected through usb 3.0, there was no issue happened. I also tested with another kind of camera (ZED M) which also connected to Xavier using usb 3.0 cable, and it worked.
I tried to connect D435 using a usb hub having four usb 3.0 output, then start/restart/shutdown process succeeded but other devices as mouse and keyboard in this hub were deactivated/not worked even when I re-plugged them to other usb ports of the kit.
The original issue still happened in case the camera cable was connect to Xavier’s usb type C port.
Basing on these behaviors, maybe there is an issue in port configuration of D435 during booting time of the Xavier.
Do you have any idea about the case? Should I ask for a customer support from Intel as well ?!
I tested 2 cases, one D435 directly connected to usb type A port of Xavier, another one was through a type C->type A adapter to test Xavier’s type C port
Is the D435 in some way treated as a “mass storage” device? Some cameras do this, and the images they provide look like a hard drive. If you run “lsusb”, then you will see an “ID” for the camera. You can limit lsusb to just that ID, and also get a verbose listing, then post here. As an example, if “ID” is “0955:7019” (this is actually a recovery mode Xavier), then the query is like this:
sudo lsusb -d 0955:7019 -vvv
For a quick idea of what kinds of modes the camera might have (it’s one cable, but multiple devices are possible on a single cable), something like this:
Here my check for “what kinds of modes the camera might have” :
nvidia@jetson-0423318029489:~$ sudo lsusb -d 8086:0b07 -vvvv | grep -i class
[sudo] password for nvidia:
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
FIXME: alloc bigger buffer for device capability descriptors
None of the classes are mass storage, and so there should be no reason the device can’t disconnect. On the other hand, I don’t know what this implies, but having made its way through the grep implies it was stderr output:
FIXME: alloc bigger buffer for device capability descriptors
It is only speculation, but this is probably related to the problem since it is an error and not normal operation.
I am also having a similar issue - XAVIER, Connectech Rogue carrier, Jetpack 4.3, XIMEA MC23 USB3 camera, USB Mass storage device (NVME+adaptor).
When I shutdown the process often hangs, then reboots after 2-3 minutes.
On the USB Debug terminal I get this
[ 37.590561] systemd-shutdow: 44 output lines suppressed due to ratelimiting
[ 37.733683] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 38.597688] CPU1: shutdown
[ 38.660408] CPU2: shutdown
[ 38.716346] CPU3: shutdown
[ 38.764540] CPU4: shutdown
\FF\E2WARNING: at platform/drivers/mailbox/mail_mach.c:148
WARNING: at platform/drivers/mailbox/mail_mach.c:161
WARNING: at platform/drivers/mailbox/mail_mach.c:177
WARNING: at platform/drivers/mailbox/mail_mach.c:161
WARNING: at platform/drivers/mailbox/mail_mach.c:177
WARNING: at platform/drivers/mailbox/mail_mach.c:161
WARNING: at platform/drivers/mailbox/mail_mach.c:177
WARNING: at platform/drivers/mailbox/mail_mach.c:161
WARNING: at platform/drivers/mailbox/mail_mach.c:177
WARNING: at platform/drivers/mailbox/mail_mach.c:161
WARNING: at platform/drivers/mailbox/mail_mach.c:177
WARNING: at platform/drivers/mailbox/mail_mach.c:161
…repeats until reboot
What’s the significance of the USB mass storage device in this thread - is there a known issue???
I am seeing the mail_mach.c warnings at shutdown on a Xavier, Rogue board, JetPack 4.2.2, but with no USB cameras attached. I did not see the warnings on the same board with JetPack 4.3.
Did you ever figure out anything?
@linuxdev is there a method to re-connect the USB camera to the Jetson but without actually replugging it ? I mean, something like a shell command that re-establishes the connection to the USB Camera.
There probably is a way, but I do not know what it is. USB is hot plug, and most hot plug systems have some sort of “rescan” ability, but I’ve not used it.