D435 Entity Camera, Processing Not Initialized and uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).

[kochhalm]

---

| Required Info | |
|----------------------- ----------|--------------------------------------------------------- |
| Camera Model | D435 |
| Firmware Version | 05.12.06.00 |
| Operating System & Version | Ubuntu 18.04 |
| Kernel Version (Linux Only) | 4.15.0-112-generic |
| Platform | PC |
| SDK Version | latest |
| Language | c |
| Segment | Robot |

Issue Description

On kernel 4.18 and on ward and upto 5.3.0-61-generic including the recommended 4.15 kernel, I have always seen the following errors reported:
(1) uvcvideo 2-2:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
(2) uvcvideo 2-2:1.0: Entity type for entity Processing 2 was not initialized!
(3) uvcvideo 2-2:1.0: Entity type for entity Camera 1 was not initialized!
(4) uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).

Can you please confirm whether this is OK. Here are the logs relevant to realsense:

[ 844.349710] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[ 844.370483] usb 2-2: New USB device found, idVendor=8086, idProduct=0adb
[ 844.370487] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 844.370490] usb 2-2: Product: Intel(R) RealSense(TM) SR400 Device
[ 844.370493] usb 2-2: Manufacturer: Intel
[ 844.370495] usb 2-2: SerialNumber: 111111111111
[ 869.690648] usb 2-2: USB disconnect, device number 4
[ 870.257147] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
[ 870.277645] usb 2-2: New USB device found, idVendor=8086, idProduct=0af5
[ 870.277646] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 870.277647] usb 2-2: Product: Intel(R) RealSense(TM) Depth Camera 4xx
[ 870.277647] usb 2-2: Manufacturer: Intel(R) RealSense(TM) Depth Camera 4xx
[ 870.277648] usb 2-2: SerialNumber: 824613020954
[ 883.124865] usb 2-2: USB disconnect, device number 5
[ 883.400906] usb 2-2: new SuperSpeed USB device number 6 using xhci_hcd
[ 883.421802] usb 2-2: New USB device found, idVendor=8086, idProduct=0b07
[ 883.421806] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 883.421809] usb 2-2: Product: Intel(R) RealSense(TM) Depth Camera 435
[ 883.421812] usb 2-2: Manufacturer: Intel(R) RealSense(TM) Depth Camera 435
[ 883.421815] usb 2-2: SerialNumber: 824613020954
[ 883.423330] uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435 (8086:0b07)
[ 883.425823] uvcvideo: Unable to create debugfs 2-6 directory.
[ 883.425958] uvcvideo 2-2:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
[ 883.425962] uvcvideo 2-2:1.0: Entity type for entity Processing 2 was not initialized!
[ 883.425964] uvcvideo 2-2:1.0: Entity type for entity Camera 1 was not initialized!
[ 883.426107] input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/input/input17
[ 883.426823] uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435 (8086:0b07)
[ 883.427983] uvcvideo: Unable to create debugfs 2-6 directory.
[ 883.428113] uvcvideo 2-2:1.3: Entity type for entity Processing 7 was not initialized!
[ 883.428117] uvcvideo 2-2:1.3: Entity type for entity Extension 8 was not initialized!
[ 883.428119] uvcvideo 2-2:1.3: Entity type for entity Camera 6 was not initialized!
[ 1552.185976] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.433739] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.534637] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.621227] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.671454] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.722187] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.772432] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.923041] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1561.973282] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.599347] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.649457] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.699903] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.750073] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.800399] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.850655] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.901148] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1577.951442] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1578.001855] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1578.052142] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1578.102659] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[ 1578.152845] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
(base) ➜ build git:(master) ✗

[MartyG-RealSense]

Hi @kochhalm If you are consistently experiencing these errors no matter which kernel you use, I would recommend trying to build librealsense from source code with the RSUSB backend method instead. It requires an internet connection to perform the installation but is not dependent on Linux versions or kernel versions and does not require patching.

#6368 (comment)

[kochhalm]

@MartyG-RealSense - are there any specific instructions documented to uninstall deb/patch methods and install with RSUSB backend method.

[MartyG-RealSense]

Debian packages can be removed with the instructions in the link below:

https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#uninstalling-the-packages

Regarding cleanly deleting previous source code builds, a RealSense team member provides advice here:

#4519 (comment)

[kochhalm]

@MartyG-RealSense what does it mean that the backend needs an Internet connection? Do you need a consistent connection to check frame metadata et al.? I dont understand what does RSUSB Backend do and what does it require? Pros/Cons v/s patching method.

[MartyG-RealSense]

No, the internet connection is only for the installation stage because this is the method by which dependencies are installed instead of through patching. There are reasons why a patch-based installation can be preferable and is the recommended method. RSUSB backend installation is useful though if you want to set up a quick test environment for a hobbyist / experimental project with a single camera, or if librealsense is unable to install successfully on a particular computing device / computer when using patching.

The link below discusses the advantages and disadvantages of using libuvc / RSUSB installation versus a patch-based installation. Please scroll down through the comment to the section headed What are the advantages and disadvantages of using libuvc vs patched kernel modules?

#5212 (comment)

[kochhalm]

Thanks @MartyG-RealSense. In that case, can you give me an idea of the most stable Ubuntu LTS release with kernel version, where the manual patch for uvcvideo does not cause the aforementioned errors. We have three installations running Ubuntu 18.04 LTS with kernel images 4.15.0-112-generic, 5.3.0-64-generic, and 5.3.0-61-generic. We are using 3x D435i cameras on the latest firmware image.

Whichever kernel image you can suggest, we are willing to downgrade to that to avoid these errors.

[MartyG-RealSense]

Ubuntu 18.04 LTS is a good choice along with kernel 5.3. Kernel 5.4 is not officially validated for librealsense yet, though does work.

If you are working on a project that requires production-level stability, I would recommend a policy of 'one version back' for SDK and firmware (one version older than the most recent one). That way, it helps to avoid issues that might be found in the newest release after its launch and allows time for fixes to be released before you upgrade again if issues are found in a new release.

[kochhalm]

Also, I found from this post, that power management may be an issue with errors like uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024). Can you recommend USB interface power management etc. configurations on LINUX and other requirements (besides USB HW v > 3.0 or something) for multi-camera usage. Also, what do these errors mean "Entity camera * not initialized" and "uvcvideo: failed to query"

[MartyG-RealSense]

These are questions that a member of the RealSense developer team will be better able to answer than myself. @dorodnic Could you help @kochhalm with the above queries, please?

[kochhalm]

Thanks @MartyG-RealSense. @dorodnic please let me know.

[MartyG-RealSense]

Re-tagging @dorodnic on this question ...

[MartyG-RealSense]

I will try a different tag for help with your question. @RealSenseSupport

[kochhalm]

Thanks @MartyG-RealSense

[MartyG-RealSense]

I will refer this case directly by email in Intel today to ensure that it receives attention.

[kochhalm]

Thanks @MartyG-RealSense ... I have tried again with a fresh install of Ubuntu 18.04 and kernel 4.15.0-117-generic. And this is with a regular apt-get install (not patch). I see the same errors in dmesg:

[1177848.601551] uvcvideo 2-3:1.3: Entity type for entity Processing 7 was not initialized!
[1177848.601556] uvcvideo 2-3:1.3: Entity type for entity Extension 8 was not initialized!
[1177848.601562] uvcvideo 2-3:1.3: Entity type for entity Camera 6 was not initialized!```


I also get the errors: ```[417026.492540] uvcvideo: Non-zero status (-71) in video completion handler.
[417026.511319] uvcvideo: Non-zero status (-71) in video completion handler.
[417026.776367] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[417027.328309] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
[417027.495361] uvcvideo: Failed to query (GET_CUR) UVC control 11 on unit 3: -32 (exp. 1).
[417027.581277] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).

[MartyG-RealSense]

Hi @kochhalm I received a response to my query to Intel about your case. I have pasted the received information below.

---

The nominal DC current drawn while streaming for D400 is ~350mA==1.7 Watt, while the USB3.0 spec allows for 900mA.
This means that on a single USB hub you should be able to connect 2 cameras without using external power. When multiple devices are connected to the same hub then an externally powered USB hub is required.

The message “Entity camera * not initialized" is related to UVC topology defined in the firmware descriptor for USB device. Those are protocol-specific messages and are apparently stemmed from firmware, but since there are no observed misbehaviors reported and we have them from day1 with D400, it is likely to remain that way for a while.

The message “uvcvideo: Failed to query (GET_CUR) UVC control” indicates a failure on (kernel) driver level to read the requested parameter, for instance if the device was busy with internal operation or that the incoming requests queue is full. In most cases this message can be disregarded as the SDK has built-in auto-retry mechanism to compensate for the temporalities.

[MartyG-RealSense]

Hi @kochhalm Do you require further assistance with this case, please? Thanks!

[MartyG-RealSense]

Case closed due to no further comments received.

[lucbettaieb]

@MartyG-RealSense This is still a problem for users. The cameras typically work with this error message present but it is spamming dmesg.

[MartyG-RealSense]

Hi @lucbettaieb I carefully researched your question. However, I don't think there is any single solution within the librealsense SDK that could prevent the kernel-related log message Entity type for entity Processing 'x' was not initialized! from occuring.

[lucbettaieb]

@MartyG-RealSense Where does it originate from?

[MartyG-RealSense]

@lucbettaieb The messages are connected to the uvcvideo Linux kenel module that typically deals with camera devices in Linux.

https://www.linuxtv.org/wiki/index.php/Uvcvideo

It is my personal experience that Entity type for entity Processing 'x' was not initialized! messages may be useful as a general indicator of the direction in which to look for problems, but not useful for precise diagnostics to find the exact cause of problems as their apperarance is as informative as a message that says "Something went wrong".

[lucbettaieb]

@MartyG-RealSense I understand that uvcvideois causing the error. Where in the realsense stack is this module used? I would suspect that this is a result of some sort of API being called incorrectly.

[MartyG-RealSense]

I researched your question extensively but could not find a simple and clear answer, unfortunately. We know that the uvcvideo module is part of Linux. When building librealsense manually from source code, a kernel patch is applied to the uvcvideo module to provide support for RealSense cameras.

For Ubuntu 14, 16 and 18 the script ./scripts/patch-realsense-ubuntu-lts.sh is run, and on Arch-based distributions the script ./patch-arch.sh is run.

https://github.com/IntelRealSense/librealsense/blob/master/scripts/patch-realsense-ubuntu-lts.sh

https://github.com/IntelRealSense/librealsense/blob/master/scripts/patch-arch.sh

[lucbettaieb]

@MartyG-RealSense When installing librealsense-dkms from apt, a kernel module is build - so is that when the patch is applied to the uvcvideo module?

Perhaps the bug lies within that patch, then?

There is one patch applied to uvcvideo here: https://github.com/IntelRealSense/librealsense/blob/master/scripts/v1-media-uvcvideo-mark-buffer-error-where-overflow.patch#L101
That looks like it's "marking an error when a buffer overflows".

On the master branch of the linux kernel, this looks to already be applied:
https://github.com/torvalds/linux/blob/master/drivers/media/usb/uvc/uvc_video.c#L1152

As it is on 5.3
https://github.com/torvalds/linux/blob/v5.3/drivers/media/usb/uvc/uvc_video.c#L1152

So I'm guessing this doesn't really do anything.

Perhaps it would be more prudent to patch this line of the module:
https://github.com/torvalds/linux/blob/v5.3/drivers/media/usb/uvc/uvc_video.c#L79

Where the error is being generated? It could be suppressed...?

Or, since this seems to be querying the actual device for something, perhaps the firmware of the camera needs to be patched so that this query succeeds.

This is a really annoying error to see polluting dmesg as it makes it harder to debug other issues happening on the system.

[lucbettaieb]

Furthermore, it looks like it's just being called every time? I'm no kernel expert, but to me it looks like the specific print call should be wrapped by some predicate, like a weird return code?

The actual function just calls printk with a log level:
https://github.com/torvalds/linux/blob/v5.3/drivers/media/usb/uvc/uvcvideo.h#L733

[lucbettaieb]

@MartyG-RealSense Would you mind re-opening this issue so the appropriate folks on your team might be able to look into how this query is processed on the camera's firmware?

My gut tells me that's the right thing to do, but again, I'm no expert.

[MartyG-RealSense]

Hi @lucbettaieb I am not on the developer team, so this subject is outside of my scope. If you know how to edit the code to correct the issue that you are concerned about, I would recommend creating a Pull Request for submitting the change for the developers' consideration regarding merging it into the SDK.

https://github.com/IntelRealSense/librealsense/pulls

[lucbettaieb]

@MartyG-RealSense Can you share this with the developer team please? I do not know the implications of patching the kernel to surpress this issue. Furthermore, I think it would be more of the right thing to do to edit the firmware.

I dont think the firmware is tracked here, is it? Is it open source?

[MartyG-RealSense]

No, the firmware is not open-source.

I already referred this case to Intel in September 2020. Their response is here:

#7099 (comment)