kernel log spam after setting enable_depth= false #10158
Comments
|
Hi @gc-91 I note that you are using kernel 4.19. The librealsense SDK does not have official support for 4.19.
Whilst librealsense can work with kernels that are not officially supported, there may be unpredictable consequences in regard to stability. If librealsense is built from source code with CMake using the RSUSB backend installation method then you should be able to continue using 4.19, as an RSUSB-based librealsense build is not dependent on Linux versions or kernel versions and does not require patching. Instructions for building librealsense with the RSUSB method can be found at #9931 (comment) Alternatively, if you are using ROS and it works correctly for you already so long as depth is not disabled then a simpler workaround may be to allow depth to be published by having it set to True but configure it to a low setting such as 424x240 at 15 FPS so that it adds a minimal burden to overall processing. |
|
Hello MartyG, Thanks for your message. You are right, I use the camera in ROS. So I will implement your low-setting suggestion. However, I am still concerned that the system can freeze.
You can see that the tainted flag is set with the following options:
|
|
I cannot see anything obviously wrong in the log in regard to RealSense. As the freeze is occurring rarely for you when launching ROS with depth disabled, you could try adding initial_reset:=true to your roslaunch instruction if you are not doing so already in order to see whether this resolves the problem. Using this command resets the camera automatically during ROS launch. |
|
I already use the initial_reset option. After a bit of research, I came across the following article: The ioctl system call also appears frequently in my call trace. |
|
If librealsense is built with the RSUSB backend that bypasses video4linux and and communicates with the device using generic USB driver then it should not be experiencing kernel related conflicts. usbcore and uvcvideo are general Linux kernel modules and not specific to RealSense. Can you confirm please that you did not patch the kernel before building librealsense from source code with RSUSB, since - unlike a non-RSUSB source code build - kernel patching is not required with this method. |
|
Hello, In the meantime, I have checked the installation.
Otherwise the code cannot be compiled. Otherwise, I did try and compile the code with RSUSB-backend = false, the D435 still worked. For your information, I only use my system via the cli, so I cannot use applications such as the realsense viewer. |
|
If DFORCE_RSUSB_BACKEND=OFF is used in the CMake build instruction then the V4L2 backend (which will make use of video4linux) will be used in the librealsense build. If you go to #5212 (comment) and scroll down through the linked-to comment to the section headed What are the advantages and disadvantages of using libuvc vs patched kernel modules then there is a comparison of the advantages and disadvantages of RSUSB backend (formerly known as libuvc backend) versus a patched-kernel build. Regarding the precise kernel modules that the camera uses, I am uncertain about this question (I am not an SDK developer) but the list of module 'inserts' in the SDK's kernel patch script may be a useful reference. |
|
Hello Marty, thanks for the information now I have a better understanding about the RSUSB_BACKEND flag. I have now freshly set up my system, I have installed the librealsense according to your instructions (#9931). Before that, of course, I provided the necessary packages (libusb-1.0-0-dev, libglu1-mesa-dev, gffw). The compile flag RSUSB_BACKEND is ON. Nevertheless, I had a system freeze this morning when I started the realsense ROS node with Nodelt. Here is an excerpt from /var/log/messages:
The messages:
Are no longer permanently written to the system logs at 2Hz after switching from enable_depth= false to enable_depth = true, but only during the startup process of the realsense node. I suspect that something is wrong while the logs are being written, and it can therefore lead to a freeze in rare cases. |
|
You could test the theory about whether logging causes the freeze by disabling all ROS logging using the information in the link below. http://wiki.ros.org/rosconsole#Disable_all_logging Have you previously built librealsense from packages instead of source code on the same computer? If you have then I wonder whether there may be multiple udev rules installed on your computer that are causing a conflict. A warning message about multiple udev rules would normally be displayed in the RealSense Viewer, but you are not using the Viewer because of your CLI environment. If there is an udev rule present on your computer at the location /etc/udev/rules.d/ then deleting it from your computer automatically corrects the multiple udev rules conflict without you needing to check in the RealSense Viewer. Only delete the /etc rule though if there is also an udev rule present at /lib/udev/rules.d/60-librealsense2-udev-rules.rules. If you have rules at both /etc and /lib then you have multiple udev rules installed, and /etc is the correct one of those two rules to delete. |
|
Hi Marty, thanks for the suggestion to disable the ROS logs, however I wanted to know what is the cause of the posted kernel logs. I have NOT installed librealsense from the packages before, but built it directly from source. Nevertheless, I found udev-rules in both places (/etc.. and /lib/..). However, the one under /lib/... is called 60-ros-noetic-realsense2-camera.rules.
After a repeated reboot, the system ran without the udev-rule under /etc/.. |
|
The RealSense ROS packages in the wrapper's Method 1 instructions install both librealsense and the ROS wrapper together. So if you installed librealsense from source code and then afterwards installed the wrapper from packages with Method 1 then you could end up with a potentially conflicting setup of two librealsense versions on the same computer that were built with different methods (source code and packages). You could deal with the conflict by uninstalling all RealSense related packages on your computer using the instruction below.
This instruction would only affect packages, so the source-code build of librealsense should be left in place afterwards. If installing the ROS wrapper from the Method 1 packages is the most familiar and comfortable installation method for you, then you could try the following procedure.
|
|
Thanks for the tip, I was not aware that librealsense is also installed from the packages when installing the ROS wrapper from the packages. I have now rebuilt my system and built both librealsense and the ROS wrapper from source. (Since my kernel version is not supported, I'm not allowed to use method 1, am I?).
This entry is output 16 times in a row and is followed by the following message, which appears about 100 times in a row:
Therefore, I suspect that I can expect a freeze again after a few reboots. The ROS wrapper also writes the following warnings during the start-up process and during operation:
edit: the first freeze has just occurred. |
|
Correct, kernel 4.19 is not listed as an officially supported kernel as mentioned earlier in this discussion at #10158 (comment) The messages look to me like they might be caused by an unpatched kernel. When you built librealsense from source code this time, did you build using the RSUSB backend method in order to make the build non-dependent on the kernel version? |
|
Yes I built it with RSUSB-BACKEND = ON, just like you described it here #9931 (comment). |
|
If you built it with RSUSB-BACKEND = ON and librealsense 2.50.0, you may have greater stability if you build with 2.48.0 and ROS wrapper 2.3.1. This is because changes to RSUSB were made in 2.50.0 and a few RealSense users have since reported stability problems with their RSUSB build that they do not experience on earlier versions. |
|
Hello I have tested the 2.50.0 with the wrapper 2.3.2 further, almost every 3 start of the wrapper my system freezes. The behaviour is always the same, during the start process the following log is written cyclically 91 times:
Can you please give me hints about these logs? Is it usual that these messages occur? Is it also usual that they occur so frequently? What exactly do the messages say? After that I can receive pictures from the camera.
|
|
Do you see any improvement if you reload the udev rules by entering the commands below into your Ubuntu terminal? sudo udevadm control --reload-rules |
|
Hello, no unfortunately the commands do not help. |
|
If you have tried most other possible fixes without success, a complete wipe and reinstall of the computer (including the OS) may sometimes clear a problem with a RealSense installation without finding out what was causing the problem. |
|
Hi Marty, since I use the librealsense and ros-wrapper inside a Docker container, I have tested each of your suggestions in a fresh build container. Unfortunately you didn't address the question about kernel logs in my penultimate post, could you please answer my questions? |
|
It is difficult to provide an answer about the meaning of the 'entity type' kernel messages, since their cause tends to be vague and if they are corrected then you may never find out for sure what caused them in the first place. I enquired to Intel about them in 2020 and received the following explanation. The message “Entity camera ... not initialized" is related to UVC topology defined in the firmware descriptor for USB device. |
|
Hi @gc-91 Do you require further assistance with this case, please? Thanks! |
|
Hi Marty, In the meantime I have carried out further tests on my system and have been able to locate the reason for my freezes. Basically, it is as you had already suspected, namely that several variants / versions of librealsense had been installed on my system. The reason for the multiple installations was the use of rosdep install. |
|
It's excellent to hear that you found an answer. Thanks very much for the update and for sharing the details with the RealSense community :) |
Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):
All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)
Issue Description
Hello,
my kernel.log is flooded with the following messages:
input: Intel(R) RealSense(TM) Depth Ca as /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.3/2-3.3.2/2-3.3.2:1.0/input/input490
uvcvideo: Unknown video format 00000050-0000-0010-8000-00aa00389b71
uvcvideo: Found UVC 1.50 device Intel(R) RealSense(TM) Depth Camera 435 (8086:0b07)
uvcvideo: Unable to create debugfs 2-12 directory.
uvcvideo 2-3.3.2:1.0: Entity type for entity Intel(R) RealSense(TM) Depth Ca was not initialized!
uvcvideo 2-3.3.2:1.0: Entity type for entity Processing 2 was not initialized!
uvcvideo 2-3.3.2:1.0: Entity type for entity Camera 1 was not initialized!
The repetition rate is 2Hz.
I noticed that this behaviour only occurs when I set the option enable_depth = false.
In rare cases it happens that my system freezes and the following message is stored in the kernel:
BUG: unable to handle kernel paging request at fffff23aa82f1224
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 23636 Comm: nodelet Tainted: G OE 4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
Hardware name: CINCOZE DI-1000/DI-1000, BIOS 5.11 01/19/2019
RIP: 0010:__kmalloc_track_caller+0xa5/0x250
How can this behaviour be explained?
The text was updated successfully, but these errors were encountered: