I thought it would be more useful to start a new thread about this.
On another thread (here: https://groups.google.com/d/msg/beagleboard/G2l4uzUMnzk/aGV6jsJJAwAJ) :
If you look at Derek Molloy’s video on using Logitech C920 camera with Debian one the BBB, it worked fine. The C920 does H264 encoding in the camera and reduces the cpu requirements on the BBB.
Regards,
John
Thanks John, I have seen Derek’s videos and other resources, and I’ve ordered a C920 but haven’t received it yet. We’ll see, but frankly I doubt that it will solve these issues completely. I find it hard to believe that cpu load is the main issue here. For example, I just booted up with the webcam unplugged. I plugged it in, checked dmesg to see that the webcam and uvcvideo were registered and seemed to be working, and they were. I ran v4l2-ctl --all to verify that I could connect to the camera. Then I immediately rebooted (sudo reboot), leaving the camera plugged in to the usb jack. Guess what? No good! When I try to run
v4l2-ctl --all I get:
Failed to open /dev/video0: Permission denied
I hesitate to post the entire output from dmesg, but here’s the last section – this entire group of lines was repeated 4 times:
[ 601.019165] INFO: task v4l_id:551 blocked for more than 120 seconds.
[ 601.025624] Not tainted 4.1.15-ti-rt-r40 #1
[ 601.031932] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
[ 601.040887] v4l_id D c09d0558 0 551 1 0x00000001
[ 601.041028] [] (__schedule) from [] (schedule+0x58/0xe4)
[ 601.041089] [] (schedule) from [] (__rt_mutex_slowlock+0xf4/0x188)
[ 601.041142] [] (__rt_mutex_slowlock) from [] (rt_mutex_slowlock+0x13c/0x338)
[ 601.041192] [] (rt_mutex_slowlock) from [] (rt_mutex_lock+0x74/0x78)
[ 601.041245] [] (rt_mutex_lock) from [] (__rt_down_read+0x3c/0x4c)
[ 601.041298] [] (__rt_down_read) from [] (rt_down_read+0x1c/0x20)
[ 601.041515] [] (rt_down_read) from [] (snd_usb_autoresume+0x24/0x60 [snd_usb_audio])
[ 601.041710] [] (snd_usb_autoresume [snd_usb_audio]) from [] (snd_usb_mixer_set_ctl_value+0xb8/0x24c [snd_usb_audio])
[ 601.041895] [] (snd_usb_mixer_set_ctl_value [snd_usb_audio]) from [] (snd_usb_set_cur_mix_value+0x7c/0xe4 [snd_usb_audio])
[ 601.042073] [] (snd_usb_set_cur_mix_value [snd_usb_audio]) from [] (restore_mixer_value+0xa8/0xb0 [snd_usb_audio])
[ 601.042255] [] (restore_mixer_value [snd_usb_audio]) from [] (snd_usb_mixer_resume+0x48/0x8c [snd_usb_audio])
[ 601.042426] [] (snd_usb_mixer_resume [snd_usb_audio]) from [] (__usb_audio_resume+0x78/0x104 [snd_usb_audio])
[ 601.042579] [] (__usb_audio_resume [snd_usb_audio]) from [] (usb_audio_reset_resume+0x1c/0x20 [snd_usb_audio])
[ 601.042705] [] (usb_audio_reset_resume [snd_usb_audio]) from [] (usb_resume_interface+0xa0/0x158)
[ 601.042768] [] (usb_resume_interface) from [] (usb_resume_both+0x80/0x14c)
[ 601.042822] [] (usb_resume_both) from [] (usb_runtime_resume+0x20/0x24)
[ 601.042889] [] (usb_runtime_resume) from [] (__rpm_callback+0x34/0x4c)
[ 601.042945] [] (__rpm_callback) from [] (rpm_callback+0x30/0x90)
[ 601.042999] [] (rpm_callback) from [] (rpm_resume+0x438/0x6d8)
[ 601.043053] [] (rpm_resume) from [] (rpm_resume+0x2a4/0x6d8)
[ 601.043107] [] (rpm_resume) from [] (__pm_runtime_resume+0x5c/0x74)
[ 601.043163] [] (__pm_runtime_resume) from [] (usb_autopm_get_interface+0x28/0x6c)
[ 601.043291] [] (usb_autopm_get_interface) from [] (uvc_v4l2_open+0x50/0x140 [uvcvideo])
[ 601.043558] [] (uvc_v4l2_open [uvcvideo]) from [] (v4l2_open+0xb4/0xf0 [videodev])
[ 601.043706] [] (v4l2_open [videodev]) from [] (chrdev_open+0xbc/0x1a8)
[ 601.043765] [] (chrdev_open) from [] (do_dentry_open+0x1e4/0x310)
[ 601.043817] [] (do_dentry_open) from [] (vfs_open+0x70/0x78)
[ 601.043871] [] (vfs_open) from [] (do_last+0x3c8/0xf08)
[ 601.043923] [] (do_last) from [] (path_openat+0x90/0x618)
[ 601.043975] [] (path_openat) from [] (do_filp_open+0x3c/0x90)
[ 601.044026] [] (do_filp_open) from [] (do_sys_open+0x11c/0x1e0)
[ 601.044075] [] (do_sys_open) from [] (SyS_open+0x2c/0x30)
[ 601.044135] [] (SyS_open) from [] (ret_fast_syscall+0x0/0x3c)
This all occurred before any attempt was made to capture any video or even turn the camera on, so it’s hard to see why hardware encoding would make any difference. Maybe Derek was just lucky.
And if talking about luck sounds silly consider this: a couple of days ago, during one of the occasions that the webcam managed to get itself registered successfully, I compiled a simple little program (similar to but simpler than Derek’s “boneCV”, using cv::VideoCapture to grab and save a single image. Time after time it saved a completely black image. And then (I can’t explain why I tried it so many times - just stubbornness I guess) it worked. Seems to work about 10-15% of the time, saving a perfectly good image. Then it goes back to black. I don’t think that’s cpu load.
Humm... how about without the RT patchset?
sudo apt-get update
sudo apt-get install linux-image-4.1.17-ti-r48
sudo reboot
(you can return to the previous kernel vit uname_r= in /boot/uEnv.txt )
Regards,
That is strange because there are several developers who have managed to get logitech cameras working:
I recommend you start with Robert’s latest Debian. I’ve had issues with Ubuntu in the past.
Regards,
John
@John: Yes, I will try a Debian image, after I try the kernel Robert suggested. Maybe I can give him some useful feedback.
Also, I’d rather not bog things down with a desktop environment that I don’t need. The latest Jessie image seems to have LXDE and enough other stuff to fill up 4GB. Is there a console image of Jessie hidden away somewhere?
@Robert:
Before switching the kernel I ran apt-get update and apt-get upgrade. Hit a little snag at the end of the update. I just want to document this here in case things get worse:
Processing triggers for initramfs-tools (0.103ubuntu4.2-1rcnee1~bpo1404+20151007+1) …
update-initramfs: Generating /boot/initrd.img-4.4.0-armv7-x3
WARNING: missing /lib/modules/4.4.0-armv7-x3
Device driver support needs thus be built-in linux image!
depmod: ERROR: could not open directory /lib/modules/4.4.0-armv7-x3: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open /tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.order: No such file or directory
depmod: WARNING: could not open /tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.builtin: No such file or directory
apt-get does not offer to upgrade anything else at this point. Rebooted OK. /boot contains initrd.img-4.4.0-armv7-x3 with size == 2122190 and timestamped just 10 minutes ago. I don’t know what’s missing or how important it is.
Before changing kernel, uname -r gives 4.1.15-ti-rt-r40
Updating the kernel was uneventful.
Rebooted OK.
Robert, you’re a hero. motion runs & its http server sends a stream over the web. same goes for koudevoeten, although I had to kill -9 to stop it. So far so good.
So please tell me – what is this evil RT patchset that’s been causing so much grief? And how will I know which kernels have it and which don’t? Which Debian images (preferable console-only) can I use?
@John: Yes, I will try a Debian image, after I try the kernel Robert
suggested. Maybe I can give him some useful feedback.Also, I'd rather not bog things down with a desktop environment that I don't
need. The latest Jessie image seems to have LXDE and enough other stuff to
fill up 4GB. Is there a console image of Jessie hidden away somewhere?@Robert:
Before switching the kernel I ran apt-get update and apt-get upgrade. Hit a
little snag at the end of the update. I just want to document this here in
case things get worse:Processing triggers for initramfs-tools
(0.103ubuntu4.2-1rcnee1~bpo1404+20151007+1) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-armv7-x3
WARNING: missing /lib/modules/4.4.0-armv7-x3
Device driver support needs thus be built-in linux image!
depmod: ERROR: could not open directory /lib/modules/4.4.0-armv7-x3: No
such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open
/tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.order: No such
file or directory
depmod: WARNING: could not open
/tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.builtin: No such
file or directory
That's nothing to worry about, it's dual board base image,
4.4.0-armv7-x3 is the kernel for the beagleboard xM...
apt-get does not offer to upgrade anything else at this point. Rebooted OK.
/boot contains initrd.img-4.4.0-armv7-x3 with size == 2122190 and
timestamped just 10 minutes ago. I don't know what's missing or how
important it is.Before changing kernel, uname -r gives 4.1.15-ti-rt-r40
Updating the kernel was uneventful.
Rebooted OK.Robert, you're a hero. motion runs & its http server sends a stream over
the web. same goes for koudevoeten, although I had to kill -9 to stop it.
So far so good.So please tell me -- what is this evil RT patchset that's been causing so
much grief? And how will I know which kernels have it and which don't?
Which Debian images (preferable console-only) can I use?
RT plays with a lot of things to try and make the kernel tasks operate
in Real Time... It's a work and progress, looking at your dmesg, your
camera driver had issues with it. It was still 50/50 that it would
help, we just got lucky..
Regards,
RT plays with a lot of things to try and make the kernel tasks operate
in Real Time… It’s a work and progress, looking at your dmesg, your
camera driver had issues with it. It was still 50/50 that it would
help, we just got lucky…
More than that, I seriously doubt an RT kernel is going to help with this type of situation. RT kernels are meant to help with real time situations, and camera applications do not to my knowledge do not need, or even want real time operation. In fact, I do believe if you do the research a real time kernel can potentially slow down disk access, disk caching, and the like.
Yes, but maybe you misread the discussion. RT was already built into the image I downloaded. Robert suggested that I install the non-RT kernel and so far that seems to have solved the problems, so yes, it seems that something in the RT kernel was probably causing my trouble.
When I run apt-cache search linux-image it gives me a list of choices with suffixes like …armv7… …ti… and …bone… with various versions of each. Where can I find some documentation that describes what each of them is?
armv7 = generic
bone = tuned for the am335x on the beaglebone's
ti = uses ti's kernel as a basis..
then they each have an rt varient..
there's also lpae but this cortex core doesn't support that..
The common ones are listed here:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Options
Regards,
For the most part, RT shouldn’t break anything. As you can see from the rt-kernel notes below, the rt-kernel is simply breaking up the the big kernel lock by replacing spinlocks with mutexes so that code can be preempted. Unless there is some other code that is causing preemption, your app should not run any slower. It is true that latency and throughput have an inverse relationship, but that is only true if you are using an app that requires reduced latencies and only then will you see throughput slow down.### How does the CONFIG_PREEMPT_RT patch work?The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic is done with:
- Making in-kernel locking-primitives (using spinlocks) preemptible though reimplementation with rtmutexes.
- Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t).
- Implementing priority inheritance for in-kernel spinlocks and semaphores. For more information on priority inversion and priority inheritance please consult Introduction to Priority Inversion.
- Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common user space process. However it is also possible to register an IRQ in kernel context.
- Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to user space POSIX timers with high resolution.
Regards,
John
Shouldn’t maybe, but apparently it does break something. I considered the possibility that one of the upgrades that I did just before installing linux-image-4.1.17-ti-r48 had solved the problem, so I installed linux-image-4.1.17-ti-rt-r48 and the problems returned as soon as I booted it. Again i started getting “Failed to open video device /dev/video0” errors, and more often than not, when the webcam was plugged into the usb slot, sudo reboot resulted in just shutting down with no reboot.
And now after reconfiguring back to the non-RT image i can consistently open /dev/video0 and it successfully reboots from the command line every time.
One thing I’ve noticed that seems odd is that with the non-RT kernel, there seems to be constant cpu activity – user led2 is flickering incessantly. With the RT kernel there were long periods with no light from that led.
Well, that is the difference between theory and reality. Perhaps the RT patch is causing a race condition that isn’t present when the BKL is used. I would recommend that you report your findings to the RT developers as this is something they might want to address.
Regards,
John