Large amounts of information dumped to syslog and kern.log when using entron cameras

Autonomous Vehicles DRIVE AGX Xavier DRIVE AGX Xavier General
1

Please provide the following info (check/uncheck the boxes after clicking “+ Create Topic”):
Software Version
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other

Target Operating System
Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.5.0.7774
other

Host Machine Version
native Ubuntu 18.04
other

When I use the SAL layer with Entron cameras with the following parameters:
“interface=csi-gh,camera-name=F008A030BM0A_24BIT_RGGB,output-format=processed,link=1”

I see large amounts of text dumped to
sample_kern.log (72.0 KB)
/var/log/kern.log

Attached are some sample outputs. The camera still works, but the hard drive eventually runs out of space. I can set up logrotate to mask the issue, but I want to know the root cause of this.

2

Dear @ylin1,
Could you provide reproducible steps ?

3

@SivaRamaKrishnaNV

Unfortunately the issue only happens sometimes so I don’t have a way to reproduce the problem reliably. I did attach a sample of what got dumped to kern.log though so if anyone who can parse the log can provide any insight, that would be very helpful.

4

Hi @ylin1 ,

Please see if Kernel warning "jump label: negative count" helps on the problem. Thanks.

5

Thanks @VickNV , will follow up after testing it out

7

I saw your kernel log is from Xavier B.
just curious if this issue is also on Xavier A or camera module other than the Entron one?
Thanks.

8

Yes, same issue also occurs on xavier a from time to time. we are using Sekonix cameras for xavier a. an example parameter for one of them is
"interface=csi-a,camera-name=SF3324,output-format=processed,link=3"
I don’t have a kernel dump handy right now though. I can keep an eye out for when this happens next time on XavierA if you want more data

9

I asked because the issue had a higher reproducing rate on Xavier B when we looked into it in the other topic.
You can try if the fix helps on your problem here. Thanks.

12

Hi, @VickNV

I am able to recompile the kernel following the instructions here. It’s not entirely clear to me though how to flash the new kernel from the documentation. Do I just flash via SDK manager?. Here’s the /lib/modules after following the instructions btw:

yclin@OR-LIN-6CW:~/nvidia/nvidia_sdk/DRIVE_OS_5.2.0_SDK_Linux_OS_DRIVE_AGX_XAVIER/DRIVEOS/drive-t186ref-linux/targetfs/lib/modules$ ls 4.14.150-rt67-tegra 4.14.150-tegra

the one named 4.14.150-rt67-tegra is what I built. So it looks like if I flash the targetfs verbatim, I will end up with two versions of the kernel. Is that what the depmod -a in the last step of the instructions is about?

13

Yes, you should just flash it with SDK Manager. Did you see any problem?

14

no problem flashing with the SDK manag. I was able to flash and uname -a shows the correct kernel version. Thanks.

I did some reboot tests, and the syslog/kern.log problem seems to have been fixed out of the 20/20 times I tested.

15

Thanks for letting us know. hope it solves the problem.