Could someone please explain to me what is the message I am getting?
It seems to me like a kernel module/driver crash, but I can’t really decode it.
It mentions v4l, so I am guessing it is the v4l driver that crashes?
I had opened an issue with Intel on Github, but all they did was tell me to update my L4T kernel.
Also, if I do dist-upgrade on L4T will I get a newer kernel from the L4T repository, or will I brake my system?
I can’t answer everything, but a “dist-upgrade” will make the system unusable. A newer kernel might not be an option.
Did you custom build the kernel? I see the “uname -r” has changed to “4.4.38+”, which means the default kernel module search location has changed. If you did not build and/or copy modules to this new location, then anything which is a module will fail.
At some point I built a kernel module for an Orbitty Carrier board, hasn’t given me any trouble other than with the D415. I don’t remember rebuilding the kernel my self, only that I downloaded some patches.
“build” and “source” are not actually modules and can be ignored. These can be used by package systems when building for the “current” kernel. This isn’t used with Jetsons.
I see both uvcvideo and videobuf2_vmalloc loaded, although i don’t know which version.
The v4l2_ioctl seems to be exported by the linux kernel? At which point I don’t know how to proceed.
I think this is the guide I had followed about a year ago:
and the repository with the scripts that built it and installed it:
I have Jetson 3.1 on the workstation so I’m assuming it is the one that is flashed, had to also use Orbitty’s custom firmware for the carrier board and to enable USB3.
I may have R28.1 or R28.2, don’t know how to find out from the board.
Looking at the archives I’d say R28.1
But at this stage, 3 days before shipping off for testing I can’t do that.
I might make an image of it just for a back-up and try again in a month if this can’t be fixed.
I’ve managed to make the camera work by soft resetting the usb every time, but there’s obviously a problem somewhere.
I’m not sure that the RealSense driver is even involved. The OOPS seems to be V4L2 triggered from a Python program. On the other hand, I’m not sure what it takes to get the RealSense driver working…I have seen many comments on this, but am not sure of the status.
It does look like you have kernel modules fully installed for both “uname -r” versions (original plus the one you are now using). Someone else may know more about RealSense status and whether this is possibly part of the V4L2 problem.
Thanks for helping @linuxdev!
Yes the python app is what I’ve written, it uses pyrealsense, which uses the C++ bindings that rely on the intel driver which uses v4l.
I might just bite the bullet end of the month and try an upgrade to see if it fixes anything.