Kernel msg happening too often makes debug way too harder "uvcvideo: Failed to query (GET_CUR) UVC control"

[130s]

Environment

Required Info
Camera Model	{ D415 (potentially L515 too) }
Firmware Version	(5_12_8_200)
Operating System & Version	{Linux (Ubuntu 16
Kernel Version (Linux Only)	4.15.0-96-generic
Platform	Industrial PC
SDK Version	{ 2.39.0 }
Language	{C++/pcl }
Segment	{Robot }
ROS wrapper version	Derived custom version based on 2.2.17 (Link to our fork)

Issue Description

The following message gets printed so often even when Realsense driver eventually functions. Although #7099 (comment) confirms that this error msg is bening to Realsense' functionality, seeing this printed too often pollutes system log and make debugging hard even for experienced developers, not to mention novice users.

uvcvideo: Failed to query (GET_CUR) UVC control

Responding to triage

• Is you question a frequently asked one?
• Try searching our GitHub Issues (open and closed) for a similar issue.

I can see multiple tickets that include this error msgs. I haven't come across a direct answer to my proposition, which is "this benign err msg is NOT causing system issue, but causing support/maintenance issue".

Possible approach

• Add entry to FAQ about this particular err case?
• Handle error message better? I see it's printed in kernel level, not by librealsense, so I do not know the level of complexity to implement such functionality.

How much impact would the issue have?

I can only speak for my usecases at Plus One Robotics #7618; we examine system logs from customers' system regularly and this issue definitely triggers unnecessary conversation until someone who knows it's not malignant.

[MartyG-RealSense]

Hi @130s I wonder if it would be possible for you to disable UVC logging of the trace function /sys/module/uvcvideo/parameters/trace

https://www.theimagingsource.com/documentation/tiscamera/uvc.html

[MartyG-RealSense]

hi @130s Do you require further assistance with this case, please? Thanks!

[130s]

I wonder if it would be possible for you to disable UVC logging of the trace function /sys/module/uvcvideo/parameters/trace

https://www.theimagingsource.com/documentation/tiscamera/uvc.html

Thanks for a suggestion. I tested disabling and I see no change. In fact on our Linux /sys/module/uvcvideo/parameters/trace contains 0, meaning it's disabled (when I enabled it, I see A LOT more output from uvcvideo like below).

That said, if the message in question can be easily suppressed on Linux level of config (not by Realsense driver's functionality) , personally I'd be fine.

$ tail -f /var/log/syslog | ack-grep -B 1 -A 1 -i uvc
:
Jan 29 09:30:25 nigunigu kernel: [218779.187673] uvcvideo: uvc_v4l2_poll
Jan 29 09:30:25 nigunigu kernel: [218779.187928] uvcvideo: Frame complete (EOF found).
Jan 29 09:30:25 nigunigu kernel: [218779.187938] uvcvideo: uvc_v4l2_poll
Jan 29 09:30:25 nigunigu kernel: [218779.189328] uvcvideo: uvc_v4l2_poll
Jan 29 09:30:25 nigunigu kernel: [218779.193679] uvcvideo: uvc_v4l2_poll
Jan 29 09:30:25 nigunigu kernel: [218779.205550] uvcvideo: frame 138 stats: 0/1/1 packets, 0/0/1 pts (!early initial), 0/1 scr, last pts/stc/sof 11652688/11653284/38
Jan 29 09:30:25 nigunigu kernel: [218779.205870] uvcvideo: frame 136 stats: 0/1/1 packets, 0/0/1 pts (!early initial), 0/1 scr, last pts/stc/sof 11652688/11653654/41
Jan 29 09:30:25 nigunigu kernel: [218779.221000] uvcvideo: Frame complete (EOF found).
Jan 29 09:30:25 nigunigu kernel: [218779.221013] uvcvideo: uvc_v4l2_poll
Jan 29 09:30:25 nigunigu kernel: [218779.221247] uvcvideo: Frame complete (EOF found).
Jan 29 09:30:25 nigunigu kernel: [218779.221285] uvcvideo: uvc_v4l2_poll
Jan 29 09:30:25 nigunigu kernel: [218779.222344] uvcvideo: uvc_v4l2_poll

I asked (unix.stackexchange.com#631648) for a way to suppress that particular line.

Googling that line makes me wonder why most of the search results are about Realsense. Is it possible that that line of the message gets printed by the part of the Kernel that librealsense modifies upon installation?

[MartyG-RealSense]

I will tag in @ev-mp to this discussion for an expert development opinion on this subject of the possibility of muting uvcvideo log messages and how it might be done if it is possible.

[MartyG-RealSense]

Hi @130s Are you still experiencing the problems that you reported before in this case, please?

[130s]

Are you still experiencing the problems that you reported before in this case, please?

Yes, the issue in question has been seen for months.

Note I didn't mean this ticket to be a bug report. It is an annoyance, but I think this is an improvement idea.

[MartyG-RealSense]

I will raise your query with Intel to obtain some feedback about your feature request.

[MartyG-RealSense]

After discussion with Intel, an official feature request has now been filed for the creation of an option to disable logging of uvcvideo messages. This case will be kept open whilst the feature request is being considered regarding whether to implement the feature.

[MartyG-RealSense]

Hi @130s Intel considered your change request carefully but decided not to proceed with implementing it. The key reasons for this decision are:

1. Suppressing kernel-generated logs is not feasible by design. RealSense is a user-space SDK and must not affect third party applications (driver) running in the kernel space.

2. The kernel warning messages that arise from temporal glitches are cosmetic annoyances and there is not a degradation in the functionality of librealsense.

3. Depending on the use-case, the frequency that the messages are generated at may be between once every several seconds and a lengthy period of minutes between each one. The log may therefore typically not be a burden to read.

[MartyG-RealSense]

Hi @130s Given that your change request has been concluded without implementation for the reasons described in the comment above, do you have any comment that you would like to add? This case will be closed after 7 days from the time of writing this is we do not hear from you. Thanks!

[MartyG-RealSense]

Case closed due to no further comments received.

[130s]

Thanks for the consideration. I'm sorry to fail responding promptly.

I understand these reasonings, from developer's perspective. Unfortunately, my issue report was much more driven by non-developers' usecases. Yes, the log we're talking about is printed by Kernel, gets only printed in low level logging pipeline. But looking into low-level logs is inevitable in our applications (we've been continously dealing with Realsense disconnection issues). Even non-developers in the field/customers' site frequently look into them at the moment. Then the very log I highlighted in this ticket adds a layer of confusion, results in slower decision at the critical debugging in the field.

2. The kernel warning messages that arise from temporal glitches are cosmetic annoyances and there is not a degradation in the functionality of librealsense.

I agree it migh be a "cosmetic annoyance" for developers. It is NOT for people who are working with customers in their facility. Anything labled "fatal/critical/fail/error" etc. draws people's attention, especially those who are under excessive pressure at a customer's facility.

3. Depending on the use-case, the frequency that the messages are generated at may be between once every several seconds and a lengthy period of minutes between each one. The log may therefore typically not be a burden to read.

Again I agree from developer's point of view, but not from the perspective of people under immediate peer pressure.

Potential resolution suggestion

Can't some key messages from Kernel be captured in the driver level (librealsense or ROS driver)? And pass it via API? That way application developers have full control about the log.

[130s]

@MartyG-RealSense For some reason I don't see "reopen" option even though I opened this ticket. Would you mind reopning, and continue conversation?

[MartyG-RealSense]

Hi @130s I do have a reopen option available. Doing so may not lead to a useful outcome though, as it will not change the outcome of the decision not to implement the requested logging feature.