Re: [GIT PATCHES FOR 2.6.35] videobuf refactoring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hans Verkuil wrote:
> The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
>   Jonathan Corbet (1):
>         V4L/DVB: ov7670: silence some compiler warnings
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf
> 
> Hans Verkuil (8):
>       v4l videobuf: remove unused mmap callback.
>       v4l videobuf: remove mmap_free callback
>       v4l videobuf: remove unused is_mmapped field
>       v4l videobuf: use struct videobuf_buffer * instead of void * for videobuf_alloc
>       v4l videobuf: rename .vmalloc to .vaddr
>       v4l videobuf: rename videobuf_queue_to_vmalloc to videobuf_queue_to_vaddr
>       v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
>       v4l videobuf: move video_copy_to_user and copy_stream to core.
> 
>  drivers/media/video/videobuf-core.c       |   95 +++++++++++++++-----
>  drivers/media/video/videobuf-dma-contig.c |  109 +++--------------------
>  drivers/media/video/videobuf-dma-sg.c     |  139 ++++++++---------------------
>  drivers/media/video/videobuf-dvb.c        |    2 +-
>  drivers/media/video/videobuf-vmalloc.c    |  104 ++--------------------
>  include/media/videobuf-core.h             |   29 ++-----
>  6 files changed, 137 insertions(+), 341 deletions(-)
> 
> Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
> The tests were done with userptr, mmap and read().
> 
> There is a lot more that needs to be done, but this is a good start.

I got this error when testing the patches with a saa7134 card:

[ 9171.989707] =======================================================
[ 9171.992696] [ INFO: possible circular locking dependency detected ]
[ 9171.992696] 2.6.33 #3
[ 9171.992696] -------------------------------------------------------
[ 9171.992696] xawtv/13330 is trying to acquire lock:
[ 9171.992696]  (&mm->mmap_sem){++++++}, at: [<f80f6c50>] videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696] 
[ 9171.992696] but task is already holding lock:
[ 9171.992696]  (&q->vb_lock){+.+.+.}, at: [<f80ed8bf>] videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696] 
[ 9171.992696] which lock already depends on the new lock.
[ 9171.992696] 
[ 9171.992696] 
[ 9171.992696] the existing dependency chain (in reverse order) is:
[ 9171.992696] 
[ 9171.992696] -> #1 (&q->vb_lock){+.+.+.}:
[ 9171.992696]        [<c1078b3d>] __lock_acquire+0xd1d/0x1220
[ 9171.992696]        [<c10790cd>] lock_acquire+0x8d/0x100
[ 9171.992696]        [<c1499f6c>] __mutex_lock_common+0x4c/0x370
[ 9171.992696]        [<c149a36f>] mutex_lock_nested+0x3f/0x50
[ 9171.992696]        [<f80ec3c9>] videobuf_mmap_mapper+0x39/0xf0 [videobuf_core]
[ 9171.992696]        [<f83ce5e9>] video_mmap+0x29/0x40 [saa7134]
[ 9171.992696]        [<f82df23b>] v4l2_mmap+0x3b/0x40 [videodev]
[ 9171.992696]        [<c10ee292>] mmap_region+0x342/0x480
[ 9171.992696]        [<c10ee62f>] do_mmap_pgoff+0x25f/0x300
[ 9171.992696]        [<c10ee869>] sys_mmap_pgoff+0x199/0x1c0
[ 9171.992696]        [<c1002fff>] sysenter_do_call+0x12/0x38
[ 9171.992696] 
[ 9171.992696] -> #0 (&mm->mmap_sem){++++++}:
[ 9171.992696]        [<c1078ddf>] __lock_acquire+0xfbf/0x1220
[ 9171.992696]        [<c10790cd>] lock_acquire+0x8d/0x100
[ 9171.992696]        [<c149a6ee>] down_read+0x4e/0x60
[ 9171.992696]        [<f80f6c50>] videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]        [<f80f71c4>] __videobuf_iolock+0xc4/0x110 [videobuf_dma_sg]
[ 9171.992696]        [<f80ec343>] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696]        [<f83cded6>] buffer_prepare+0x1d6/0x230 [saa7134]
[ 9171.992696]        [<f80ed9f6>] videobuf_read_one+0x176/0x340 [videobuf_core]
[ 9171.992696]        [<f83ce7cb>] video_read+0x8b/0xc0 [saa7134]
[ 9171.992696]        [<f82df08d>] v4l2_read+0x5d/0x70 [videodev]
[ 9171.992696]        [<c1107b3f>] vfs_read+0x9f/0x190
[ 9171.992696]        [<c1108052>] sys_read+0x42/0x70
[ 9171.992696]        [<c1002fff>] sysenter_do_call+0x12/0x38
[ 9171.992696] 
[ 9171.992696] other info that might help us debug this:
[ 9171.992696] 
[ 9171.992696] 1 lock held by xawtv/13330:
[ 9171.992696]  #0:  (&q->vb_lock){+.+.+.}, at: [<f80ed8bf>] videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696] 
[ 9171.992696] stack backtrace:
[ 9171.992696] Pid: 13330, comm: xawtv Tainted: G         C 2.6.33 #3
[ 9171.992696] Call Trace:
[ 9171.992696]  [<c1498793>] ? printk+0x1d/0x22
[ 9171.992696]  [<c1076cb2>] print_circular_bug+0xc2/0xd0
[ 9171.992696]  [<c1078ddf>] __lock_acquire+0xfbf/0x1220
[ 9171.992696]  [<c10790cd>] lock_acquire+0x8d/0x100
[ 9171.992696]  [<f80f6c50>] ? videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]  [<c149a6ee>] down_read+0x4e/0x60
[ 9171.992696]  [<f80f6c50>] ? videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]  [<f80f6c50>] videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]  [<f80f71c4>] __videobuf_iolock+0xc4/0x110 [videobuf_dma_sg]
[ 9171.992696]  [<f80f6a22>] ? videobuf_dma_free+0x62/0xb0 [videobuf_dma_sg]
[ 9171.992696]  [<c107787b>] ? trace_hardirqs_on+0xb/0x10
[ 9171.992696]  [<f80f7100>] ? __videobuf_iolock+0x0/0x110 [videobuf_dma_sg]
[ 9171.992696]  [<f80ec343>] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696]  [<f83c786e>] ? saa7134_dma_free+0x4e/0x70 [saa7134]
[ 9171.992696]  [<f83cded6>] buffer_prepare+0x1d6/0x230 [saa7134]
[ 9171.992696]  [<c1075c5c>] ? lockdep_init_map+0x3c/0x110
[ 9171.992696]  [<c12697a2>] ? __raw_spin_lock_init+0x32/0x60
[ 9171.992696]  [<f80ed9f6>] videobuf_read_one+0x176/0x340 [videobuf_core]
[ 9171.992696]  [<f83ce7cb>] video_read+0x8b/0xc0 [saa7134]
[ 9171.992696]  [<c1107712>] ? rw_verify_area+0x62/0xd0
[ 9171.992696]  [<f83ce740>] ? video_read+0x0/0xc0 [saa7134]
[ 9171.992696]  [<f82df08d>] v4l2_read+0x5d/0x70 [videodev]
[ 9171.992696]  [<c1107b3f>] vfs_read+0x9f/0x190
[ 9171.992696]  [<c1067a1b>] ? up_read+0x1b/0x30
[ 9171.992696]  [<f82df030>] ? v4l2_read+0x0/0x70 [videodev]
[ 9171.992696]  [<c1098feb>] ? audit_syscall_entry+0x1db/0x200
[ 9171.992696]  [<c1108052>] sys_read+0x42/0x70
[ 9171.992696]  [<c1002fff>] sysenter_do_call+0x12/0x38

Not sure if it is a regression or not.

Had you test running the videobuf with both Overlay and mmap modes enabled?
This is probably the most complex case. You need to use xawtv (without libv4l2
patches) and either a bttv or saa7134 card.

I tried to run a test here today, with a saa7134, plus xawtv3 from:
	http://git.linuxtv.org/mchehab/xawtv3.git
(this version is basically Gerd's original one, plus some patches from Fedora and
two fixes patches I had to do to make it compile)

Unfortunately, my video adapter driver didn't support overlay mode. I'll likely
try to re-test it with a different driver this weekend.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux