bcm2835_v4l2 module crash on RPi1

[jpeeler]

I've been experiencing issues with the camera module. This is the first trace I've managed to capture since upgrading to Jessie (was having issues on Wheezy as well). I've included the relevant output below. If further debugging is necessary, just let me know how to execute.

[137140.899242] bcm2835-v4l2: error 0 waiting for frame completion
[137146.949497] bcm2835_v4l2: error 0 waiting for sync completion
[137146.949660] bcm2835-v4l2: Failed to enable encode tunnel - error -62
[137146.949685] ------------[ cut here ]------------
[137146.949796] WARNING: CPU: 0 PID: 16048 at drivers/media/v4l2-core/videobuf2-core.c:1315 vb2_start_streaming+0xdc/0x164 [videobuf2_core]()
[137146.949895] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio bcm2835_v4l2 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media ipv6
[137146.950076] CPU: 0 PID: 16048 Comm: hawkeye Not tainted 4.4.38+ #938
[137146.950097] Hardware name: BCM2708
[137146.950221] [<c0016cfc>] (unwind_backtrace) from [<c0013c20>] (show_stack+0x20/0x24)
[137146.950323] [<c0013c20>] (show_stack) from [<c02e437c>] (dump_stack+0x20/0x28)
[137146.950379] [<c02e437c>] (dump_stack) from [<c0021ef4>] (warn_slowpath_common+0x8c/0xc4)
[137146.950468] [<c0021ef4>] (warn_slowpath_common) from [<c0021fe8>] (warn_slowpath_null+0x2c/0x34)
[137146.950596] [<c0021fe8>] (warn_slowpath_null) from [<bf0bf65c>] (vb2_start_streaming+0xdc/0x164 [videobuf2_core])
[137146.950765] [<bf0bf65c>] (vb2_start_streaming [videobuf2_core]) from [<bf0c08e4>] (vb2_core_streamon+0xfc/0x158 [videobuf2_core])
[137146.950962] [<bf0c08e4>] (vb2_core_streamon [videobuf2_core]) from [<bf0cb57c>] (vb2_streamon+0x3c/0x60 [videobuf2_v4l2])
[137146.951128] [<bf0cb57c>] (vb2_streamon [videobuf2_v4l2]) from [<bf0cb5f0>] (vb2_ioctl_streamon+0x50/0x54 [videobuf2_v4l2])
[137146.951688] [<bf0cb5f0>] (vb2_ioctl_streamon [videobuf2_v4l2]) from [<bf07e700>] (v4l_streamon+0x28/0x2c [videodev])
[137146.952329] [<bf07e700>] (v4l_streamon [videodev]) from [<bf0828ac>] (__video_do_ioctl+0x2a0/0x320 [videodev])
[137146.952966] [<bf0828ac>] (__video_do_ioctl [videodev]) from [<bf0821dc>] (video_usercopy+0x170/0x57c [videodev])
[137146.953599] [<bf0821dc>] (video_usercopy [videodev]) from [<bf082604>] (video_ioctl2+0x1c/0x24 [videodev])
[137146.954226] [<bf082604>] (video_ioctl2 [videodev]) from [<bf07c688>] (v4l2_ioctl+0xd4/0xec [videodev])
[137146.954608] [<bf07c688>] (v4l2_ioctl [videodev]) from [<c013ddd0>] (do_vfs_ioctl+0x3dc/0x5a8)
[137146.954700] [<c013ddd0>] (do_vfs_ioctl) from [<c013dfe0>] (SyS_ioctl+0x44/0x6c)
[137146.954750] [<c013dfe0>] (SyS_ioctl) from [<c000f820>] (ret_fast_syscall+0x0/0x1c)
[137146.954817] ---[ end trace 330510dcd1761438 ]---

Complete dmesg output included below. I had been using the camera for days (using Hawkeye) before the crash occurred.
https://gist.github.com/jpeeler/65ea5de118602f3df0e563230a13d7bd

[6by9]

Too little information to determine anything.
What resolution? What codec/image format (failure on encode tunnel implies H264, MJPEG, or JPEG)? What frame rate? What bitrate? What gpu_mem have you assigned?
Anything else potentially pertinent to being able to reproduce.

[jpeeler]

I'm using all the default settings below (except host=0.0.0.0) https://github.com/ipartola/hawkeye/blob/488f377a06f5ae9eb1ca2edcafd39a2c0de58146/doc/hawkeye.conf#L24.

640x480 @ 15fps. I'm not sure what that translates to for bitrate, might have to dig around in the source.
The format is mjpeg.
The gpu_mem setting in config.txt reads 128.

@6by9 are you willing to try and reproduce with Hawkeye? I wouldn't expect that from anybody really, especially given that it takes so long to occur. Is there any else I can collect to more accurately locate the problem?

[6by9]

are you willing to try and reproduce with Hawkeye?

Seeing you've said it is encoding as MJPEG, no.
The MJPEG codec is known to have a lockup on shutdown if the client hasn't been emptying the output FIFO in a timely manner. Presumably Hawkeye has been stopped streaming for whatever reason and wedged the codec, taking all of MMAL (the GPU IPC) with it. On trying to enable stuff again it fails (I can't find where the -62 comes from at the moment).
The MJPEG codec needs a heap of work to sort this threading issue, but it's not high on the priority list. The only mitigation is to service buffers in a timely manner, and possibly drop the bitrate .
Hawkeye appears not to configure bitrate, but you can do it manually with v4l2-ctl --set-ctrl=video_bitrate=100000 or similar (sudo apt-get install v4l-utils if not already installed).

[jpeeler]

@6by9
Using v4l2-ctl --get-ctrl=video_bitrate reports the the bitrate was set to 10000000. I've set it now to 3000000, but anything lower than that makes the video noticeably less quality.

Perhaps this isn't the best place to ask this, but I'm not particularly sold on the codec used (or using Hawkeye in general). When you say that the MJPEG codec has a known problem, it makes me wonder if the others are supported better. Do you recommend using H264 instead?

[6by9]

H264 is a much more efficient codec, and was the main supported encoder when Broadcom were developing VideoCore. If you can use it then I would recommend you do so.

Even 3Mbit/s for 15fps VGA is sickeningly inefficient. H264 should do that in 800kbit/s or less. Ballpark figures with H264 you should be looking at 10-15Mbit/s for 1080P30, or 3-5Mbit/s for 720P30, for good quality.

[JamesH65]

Closing due to lack of activity. Reopen if you feel this issue is still relevant.
Closing this issue as questions answered/issue resolved.