xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument

[alxhoff]

Hello,

I have been in contact with Yusheng from the zen desk but MartyG-realsense from the librealsense repository suggested I also post here. The issue has appeared after applying the udev rules, via setup_udev_rules.sh which fixed some issues with the HWMC controls. I am now being presented with the issue in the title.

I am using a Jetpack 5.1.5 kernel which contains the d4xx driver, which works for us in a sort of unstable state if we don't apply the udev rules. After applying them we loose the HWMC errors but are unable to bring librealsense up. The devices still enumerate with the kernel and from the kernel side seem to be fine during probing. There are 4 GMSL cameras attached with firmware 5.16.1.112.

From my email to Yusheng:

To trigger the issue, I am doing the following:

• make installing librealsense v2.56.3 (note the release notes do not list a 5.10 kernel as being supported, but since the realsense driver quite literally is only released for 5.10 and 5.15, I believe this is an oversight)
• patch my kernel with the following three patches from the librealsense source, as done in the patch-realsense-ubuntu-L4T.sh script, 01-realsense-camera-formats-L4T-5.0.2.patch, 02-realsense-metadata-L4T-5.0.2.patch, and 05-realsense-powerlinefrequency-control-fix.patch. I patch my kernel directly instead of building the modules out-of-tree as the script does, but the end result is the same. This is vaguely discussed in the installation_jetson.md.
• run the setup_udev_rules.sh script which bind the DS5 MUX, DFU devs etc. This step seems to remove the issues in the log above, which makes sense since v4l can now set the ds5 controls, although this is where my current issue surfaces

REALSENSE_INITIALIZATION_FAILURE: Initialization failed: Exception thrown in 'rs2_create_device' (xioctl(VIDIOC_S_EXT_CTRLS) failed Last Error: Invalid argument)

It seems that there are existing issues with this issue, such as the Github issue here, but these are for USB-attached devices, and in this case, it seems the best solution is to use a backend that skips the kernel (not possible for us sadly).

So my natural instinct is something like a userspace ioctl call with an invalid ctrl ID, but this doesn't seem to be the issue after trying to catch such an issue. Instead, when tracking down the point of failure, it appears to be inside ds5_dfu_device_release.
[ 265.879210] d4xx 31-000a: ds5_dfu_device_release(): was NOT able to get DS5_FW_BUILD

here is a small dump of the issue

[ 331.525966] d4xx 31-002a: ds5_dfu_device_release(): reading firmware from 0x030c failed, sleeping
[ 331.566000] d4xx 31-002a: ds5_read(): i2c read failed (-121), reg: 0x030c
[ 331.566455] CPU: 0 PID: 17182 Comm: realsense_drive Not tainted 5.10.216-cartken5.1.5dev #21
[ 331.566459] Hardware name: NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 6.1-39721438 03/04/2025
[ 331.566462] Call trace:
[ 331.566476] dump_backtrace+0x0/0x1e0
[ 331.566481] show_stack+0x30/0x40
[ 331.566490] dump_stack+0xf0/0x130
[ 331.566501] ds5_read.isra.0+0x94/0xa0 [d4xx]
[ 331.566506] ds5_dfu_device_release+0x1d0/0x2b0 [d4xx]
[ 331.566515] __fput+0x80/0x260
[ 331.566519] ____fput+0x24/0x30
[ 331.566529] task_work_run+0x88/0xe0
[ 331.566533] do_notify_resume+0x24c/0x990
[ 331.566537] work_pending+0xc/0x738

I should mention that librealsense seems to be stuck in a constant loop of calling ds5_dfu_device_release, here is a small exert of my dmesg

dmesg-dump.txt

Thanks in advance for any help!

[dmipx]

Hi Alex.
I see your camera in DFU state.
Can you plug it as USB device and verify/flash? We support DFU from Linux but let first try to release pressure with DFU state and stabilize device functionality on jetson.

[alxhoff]

Hi @dmipx, they are GMSL cameras. I agree that it seems to be stuck in a dfu state but this is the default behaviour after booting. I think I mentioned it but this issue only started after applying the udev rules from librealsense which created the dfu symlinks in /dev. Before installing them I was able to flash into the default dfu devices, eg. /dev/d4xx-dfu-30-00XX . I will be digging into our userspace code today to see what the guys are doing there.