[PATCH 0 of 9] videobuf fixes

[PATCH 0 of 9] videobuf fixes

[Brandon Philips]

Hello-

Sorry for the mess-up on the first round.  :-(

The following set fixes problems I discovered while tracking down bugs in both
vivi and videobuf.  Hopefully most of these can make it into 2.6.25 since they
all seem pretty critical.

Please take a good look at the set and test if possible.  Particularly:
  [RFC] videobuf: Avoid deadlock with QBUF

Also, is anyone using videobuf-vmalloc besides vivi?  The current videobuf API
feels over extended trying to take on the task of a second backend type. 

Pullable from http://ifup.org/hg/v4l-dvb 

- soc_camera: Introduce a spinlock for use with videobuf
- videobuf: Require spinlocks for all videobuf users
- videobuf: Wakeup queues after changing the state to ERROR
- videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup
- videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close
- videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure
- vivi: Simplify the vivi driver and avoid deadlocks
- videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue
- videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility

 b/linux/drivers/media/video/pxa_camera.c       |   11 
 b/linux/drivers/media/video/soc_camera.c       |    5 
 b/linux/drivers/media/video/videobuf-core.c    |   46 -
 b/linux/drivers/media/video/videobuf-dma-sg.c  |   16 
 b/linux/drivers/media/video/videobuf-vmalloc.c |    2 
 b/linux/drivers/media/video/vivi.c             |  332 ++--------
 b/linux/include/media/soc_camera.h             |    1 
 b/linux/include/media/videobuf-core.h          |    3 
 linux/drivers/media/video/videobuf-core.c      |  169 +++--
 linux/drivers/media/video/videobuf-vmalloc.c   |   43 -
 linux/include/media/videobuf-core.h            |    2 
 11 files changed, 262 insertions(+), 368 deletions(-)

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 1 of 9] soc_camera: Introduce a spinlock for use with videobuf

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699276 25200
# Node ID 7876c2bc2446dc3e3630e7a30a76f50874116cf1
# Parent  1df4f66ca1fc98ccad4c8377484a56adaf23e49d
soc_camera: Introduce a spinlock for use with videobuf

Videobuf will require all drivers to use a spinlock to protect the IRQ queue.
Introduce this lock for the SOC/PXA drivers.

Signed-off-by: Brandon Philips <bphilips@suse.de>
CC: Guennadi Liakhovetski <kernel@pengutronix.de>

---
 linux/drivers/media/video/pxa_camera.c |   11 ++++-------
 linux/drivers/media/video/soc_camera.c |    5 +++--
 linux/include/media/soc_camera.h       |    1 +
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/linux/drivers/media/video/pxa_camera.c b/linux/drivers/media/video/pxa_camera.c
--- a/linux/drivers/media/video/pxa_camera.c
+++ b/linux/drivers/media/video/pxa_camera.c
@@ -108,8 +108,6 @@ struct pxa_camera_dev {
 	unsigned long		platform_mclk_10khz;
 
 	struct list_head	capture;
-
-	spinlock_t		lock;
 
 	struct pxa_buffer	*active;
 };
@@ -283,7 +281,7 @@ static void pxa_videobuf_queue(struct vi
 
 	dev_dbg(&icd->dev, "%s (vb=0x%p) 0x%08lx %d\n", __FUNCTION__,
 		vb, vb->baddr, vb->bsize);
-	spin_lock_irqsave(&pcdev->lock, flags);
+	spin_lock_irqsave(&icd->irqlock, flags);
 
 	list_add_tail(&vb->queue, &pcdev->capture);
 
@@ -343,7 +341,7 @@ static void pxa_videobuf_queue(struct vi
 			DCSR(pcdev->dma_chan_y) = DCSR_RUN;
 	}
 
-	spin_unlock_irqrestore(&pcdev->lock, flags);
+	spin_unlock_irqrestore(&icd->irqlock, flags);
 
 }
 
@@ -384,7 +382,7 @@ static void pxa_camera_dma_irq_y(int cha
 	unsigned int status;
 	struct videobuf_buffer *vb;
 
-	spin_lock_irqsave(&pcdev->lock, flags);
+	spin_lock_irqsave(&pcdev->icd->irqlock, flags);
 
 	status = DCSR(pcdev->dma_chan_y);
 	DCSR(pcdev->dma_chan_y) = status;
@@ -429,7 +427,7 @@ static void pxa_camera_dma_irq_y(int cha
 				   vb.queue);
 
 out:
-	spin_unlock_irqrestore(&pcdev->lock, flags);
+	spin_unlock_irqrestore(&pcdev->icd->irqlock, flags);
 }
 
 static struct videobuf_queue_ops pxa_videobuf_ops = {
@@ -869,7 +867,6 @@ static int pxa_camera_probe(struct platf
 	}
 
 	INIT_LIST_HEAD(&pcdev->capture);
-	spin_lock_init(&pcdev->lock);
 
 	/*
 	 * Request the regions.
diff --git a/linux/drivers/media/video/soc_camera.c b/linux/drivers/media/video/soc_camera.c
--- a/linux/drivers/media/video/soc_camera.c
+++ b/linux/drivers/media/video/soc_camera.c
@@ -229,8 +229,8 @@ static int soc_camera_open(struct inode 
 	dev_dbg(&icd->dev, "camera device open\n");
 
 	/* We must pass NULL as dev pointer, then all pci_* dma operations
-	 * transform to normal dma_* ones. Do we need an irqlock? */
-	videobuf_queue_sg_init(&icf->vb_vidq, ici->vbq_ops, NULL, NULL,
+	 * transform to normal dma_* ones. */
+	videobuf_queue_sg_init(&icf->vb_vidq, ici->vbq_ops, NULL, &icd->irqlock,
 				V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
 				ici->msize, icd);
 
@@ -714,6 +714,7 @@ static int soc_camera_probe(struct devic
 	if (ret >= 0) {
 		const struct v4l2_queryctrl *qctrl;
 
+		spin_lock_init(&icd->irqlock);
 		qctrl = soc_camera_find_qctrl(icd->ops, V4L2_CID_GAIN);
 		icd->gain = qctrl ? qctrl->default_value : (unsigned short)~0;
 		qctrl = soc_camera_find_qctrl(icd->ops, V4L2_CID_EXPOSURE);
diff --git a/linux/include/media/soc_camera.h b/linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.h
+++ b/linux/include/media/soc_camera.h
@@ -19,6 +19,7 @@ struct soc_camera_device {
 	struct list_head list;
 	struct device dev;
 	struct device *control;
+	spinlock_t irqlock;
 	unsigned short width;		/* Current window */
 	unsigned short height;		/* sizes */
 	unsigned short x_min;		/* Camera capabilities */

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 2 of 9] videobuf: Require spinlocks for all videobuf users

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699277 25200
# Node ID d9780aaf14ad2fca7eeaa79f3a8476e5f551ed25
# Parent  7876c2bc2446dc3e3630e7a30a76f50874116cf1
videobuf: Require spinlocks for all videobuf users

A spinlock is necessary for queue_cancel to work with every driver in the tree.
Otherwise a race exists between IRQ handlers removing buffers from the queue
and queue_cancel invalidating the queue.

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-core.c |   46 +++++++++++-------------------
 1 file changed, 18 insertions(+), 28 deletions(-)

diff --git a/linux/drivers/media/video/videobuf-core.c b/linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c
+++ b/linux/drivers/media/video/videobuf-core.c
@@ -145,6 +145,9 @@ void videobuf_queue_core_init(struct vid
 	BUG_ON(!q->ops->buf_queue);
 	BUG_ON(!q->ops->buf_release);
 
+	/* Lock is mandatory for queue_cancel to work */
+	BUG_ON(!irqlock);
+
 	/* Having implementations for abstract methods are mandatory */
 	BUG_ON(!q->int_ops);
 
@@ -197,8 +200,7 @@ void videobuf_queue_cancel(struct videob
 	int i;
 
 	/* remove queued buffers from list */
-	if (q->irqlock)
-		spin_lock_irqsave(q->irqlock, flags);
+	spin_lock_irqsave(q->irqlock, flags);
 	for (i = 0; i < VIDEO_MAX_FRAME; i++) {
 		if (NULL == q->bufs[i])
 			continue;
@@ -207,8 +209,7 @@ void videobuf_queue_cancel(struct videob
 			q->bufs[i]->state = VIDEOBUF_ERROR;
 		}
 	}
-	if (q->irqlock)
-		spin_unlock_irqrestore(q->irqlock, flags);
+	spin_unlock_irqrestore(q->irqlock, flags);
 
 	/* free all buffers + clear queue */
 	for (i = 0; i < VIDEO_MAX_FRAME; i++) {
@@ -564,11 +565,9 @@ int videobuf_qbuf(struct videobuf_queue 
 
 	list_add_tail(&buf->stream, &q->stream);
 	if (q->streaming) {
-		if (q->irqlock)
-			spin_lock_irqsave(q->irqlock, flags);
+		spin_lock_irqsave(q->irqlock, flags);
 		q->ops->buf_queue(q, buf);
-		if (q->irqlock)
-			spin_unlock_irqrestore(q->irqlock, flags);
+		spin_unlock_irqrestore(q->irqlock, flags);
 	}
 	dprintk(1, "qbuf: succeded\n");
 	retval = 0;
@@ -653,13 +652,11 @@ int videobuf_streamon(struct videobuf_qu
 	if (q->streaming)
 		goto done;
 	q->streaming = 1;
-	if (q->irqlock)
-		spin_lock_irqsave(q->irqlock, flags);
+	spin_lock_irqsave(q->irqlock, flags);
 	list_for_each_entry(buf, &q->stream, stream)
 		if (buf->state == VIDEOBUF_PREPARED)
 			q->ops->buf_queue(q, buf);
-	if (q->irqlock)
-		spin_unlock_irqrestore(q->irqlock, flags);
+	spin_unlock_irqrestore(q->irqlock, flags);
 
  done:
 	mutex_unlock(&q->vb_lock);
@@ -715,11 +712,9 @@ static ssize_t videobuf_read_zerocopy(st
 		goto done;
 
 	/* start capture & wait */
-	if (q->irqlock)
-		spin_lock_irqsave(q->irqlock, flags);
+	spin_lock_irqsave(q->irqlock, flags);
 	q->ops->buf_queue(q, q->read_buf);
-	if (q->irqlock)
-		spin_unlock_irqrestore(q->irqlock, flags);
+	spin_unlock_irqrestore(q->irqlock, flags);
 	retval = videobuf_waiton(q->read_buf, 0, 0);
 	if (0 == retval) {
 		CALL(q, sync, q, q->read_buf);
@@ -780,12 +775,11 @@ ssize_t videobuf_read_one(struct videobu
 			q->read_buf = NULL;
 			goto done;
 		}
-		if (q->irqlock)
-			spin_lock_irqsave(q->irqlock, flags);
 
+		spin_lock_irqsave(q->irqlock, flags);
 		q->ops->buf_queue(q, q->read_buf);
-		if (q->irqlock)
-			spin_unlock_irqrestore(q->irqlock, flags);
+		spin_unlock_irqrestore(q->irqlock, flags);
+
 		q->read_off = 0;
 	}
 
@@ -851,12 +845,10 @@ static int __videobuf_read_start(struct 
 			return err;
 		list_add_tail(&q->bufs[i]->stream, &q->stream);
 	}
-	if (q->irqlock)
-		spin_lock_irqsave(q->irqlock, flags);
+	spin_lock_irqsave(q->irqlock, flags);
 	for (i = 0; i < count; i++)
 		q->ops->buf_queue(q, q->bufs[i]);
-	if (q->irqlock)
-		spin_unlock_irqrestore(q->irqlock, flags);
+	spin_unlock_irqrestore(q->irqlock, flags);
 	q->reading = 1;
 	return 0;
 }
@@ -970,11 +962,9 @@ ssize_t videobuf_read_stream(struct vide
 		if (q->read_off == q->read_buf->size) {
 			list_add_tail(&q->read_buf->stream,
 				      &q->stream);
-			if (q->irqlock)
-				spin_lock_irqsave(q->irqlock, flags);
+			spin_lock_irqsave(q->irqlock, flags);
 			q->ops->buf_queue(q, q->read_buf);
-			if (q->irqlock)
-				spin_unlock_irqrestore(q->irqlock, flags);
+			spin_unlock_irqrestore(q->irqlock, flags);
 			q->read_buf = NULL;
 		}
 		if (retval < 0)

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 3 of 9] videobuf: Wakeup queues after changing the state to ERROR

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699277 25200
# Node ID 05ec6ba3e9c3c42cf397ca71b8aefe9573d28c6a
# Parent  d9780aaf14ad2fca7eeaa79f3a8476e5f551ed25
videobuf: Wakeup queues after changing the state to ERROR

The waitqueues must be woken up every time state changes.

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-core.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/linux/drivers/media/video/videobuf-core.c b/linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c
+++ b/linux/drivers/media/video/videobuf-core.c
@@ -207,6 +207,7 @@ void videobuf_queue_cancel(struct videob
 		if (q->bufs[i]->state == VIDEOBUF_QUEUED) {
 			list_del(&q->bufs[i]->queue);
 			q->bufs[i]->state = VIDEOBUF_ERROR;
+			wake_up_all(&q->bufs[i]->done);
 		}
 	}
 	spin_unlock_irqrestore(q->irqlock, flags);

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 4 of 9] videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699278 25200
# Node ID 3ac2b9752844e2635575e50594d50cea665ca09b
# Parent  05ec6ba3e9c3c42cf397ca71b8aefe9573d28c6a
videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup

Possible missed wakeup- use kernel helpers for wait queues
  http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg27983.html

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-core.c |   37 ++++++++++++------------------
 1 file changed, 15 insertions(+), 22 deletions(-)

diff --git a/linux/drivers/media/video/videobuf-core.c b/linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c
+++ b/linux/drivers/media/video/videobuf-core.c
@@ -65,32 +65,25 @@ void *videobuf_alloc(struct videobuf_que
 	return vb;
 }
 
+#define WAITON_CONDITION (vb->state != VIDEOBUF_ACTIVE &&\
+				vb->state != VIDEOBUF_QUEUED)
 int videobuf_waiton(struct videobuf_buffer *vb, int non_blocking, int intr)
 {
-	int retval = 0;
-	DECLARE_WAITQUEUE(wait, current);
+	MAGIC_CHECK(vb->magic, MAGIC_BUFFER);
 
-	MAGIC_CHECK(vb->magic, MAGIC_BUFFER);
-	add_wait_queue(&vb->done, &wait);
-	while (vb->state == VIDEOBUF_ACTIVE || vb->state == VIDEOBUF_QUEUED) {
-		if (non_blocking) {
-			retval = -EAGAIN;
-			break;
-		}
-		set_current_state(intr  ? TASK_INTERRUPTIBLE
-					: TASK_UNINTERRUPTIBLE);
-		if (vb->state == VIDEOBUF_ACTIVE ||
-		    vb->state == VIDEOBUF_QUEUED)
-			schedule();
-		set_current_state(TASK_RUNNING);
-		if (intr && signal_pending(current)) {
-			dprintk(1, "buffer waiton: -EINTR\n");
-			retval = -EINTR;
-			break;
-		}
+	if (non_blocking) {
+		if (WAITON_CONDITION)
+			return 0;
+		else
+			return -EAGAIN;
 	}
-	remove_wait_queue(&vb->done, &wait);
-	return retval;
+
+	if (intr)
+		return wait_event_interruptible(vb->done, WAITON_CONDITION);
+	else
+		wait_event(vb->done, WAITON_CONDITION);
+
+	return 0;
 }
 
 int videobuf_iolock(struct videobuf_queue *q, struct videobuf_buffer *vb,

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 5 of 9] videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699279 25200
# Node ID eb99bdd0a7e3f70eb40fcc6918794a8b8822ac49
# Parent  3ac2b9752844e2635575e50594d50cea665ca09b
videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close

Remove the buf_release on vm_close because it will lead to a buffer being
released multiple times since all buffers are already freed under the two
possible cases: device close or STREAMOFF.

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-vmalloc.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/linux/drivers/media/video/videobuf-vmalloc.c b/linux/drivers/media/video/videobuf-vmalloc.c
--- a/linux/drivers/media/video/videobuf-vmalloc.c
+++ b/linux/drivers/media/video/videobuf-vmalloc.c
@@ -78,8 +78,6 @@ videobuf_vm_close(struct vm_area_struct 
 
 			if (q->bufs[i]->map != map)
 				continue;
-
-			q->ops->buf_release(q,q->bufs[i]);
 
 			q->bufs[i]->map   = NULL;
 			q->bufs[i]->baddr = 0;

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699280 25200
# Node ID ab74ebf10c01d6a8a54a39b6750bc86ec3e72286
# Parent  eb99bdd0a7e3f70eb40fcc6918794a8b8822ac49
videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

In videobuf-vmalloc.c remap_vmalloc_range is failing when applications are
trying to mmap buffers immediately after reqbuf.  It fails because the vmalloc
area isn't setup until the first QBUF when drivers call iolock.

This patch introduces mmap_setup to the qtype_ops and it is called in
__videobuf_mmap_setup if the buffer type is mmap.  In the case of vmalloc
buffers this calls iolock, and sets the state to idle.

I don't think this is needed for dma-sg buffers and it defaults to a no-op for
everything but vmalloc.

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-core.c    |   29 +++++++-----------
 linux/drivers/media/video/videobuf-vmalloc.c |   43 +++++++++++++--------------
 linux/include/media/videobuf-core.h          |    3 +
 3 files changed, 35 insertions(+), 40 deletions(-)

diff --git a/linux/drivers/media/video/videobuf-core.c b/linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c
+++ b/linux/drivers/media/video/videobuf-core.c
@@ -92,24 +92,16 @@ int videobuf_iolock(struct videobuf_queu
 	MAGIC_CHECK(vb->magic, MAGIC_BUFFER);
 	MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS);
 
-	/* This is required to avoid OOPS on some cases,
-	   since mmap_mapper() method should be called before _iolock.
-	   On some cases, the mmap_mapper() is called only after scheduling.
-	 */
-	if (vb->memory == V4L2_MEMORY_MMAP) {
-		wait_event_timeout(vb->done, q->is_mmapped,
-				   msecs_to_jiffies(100));
-		if (!q->is_mmapped) {
-			printk(KERN_ERR
-			       "Error: mmap_mapper() never called!\n");
-			return -EINVAL;
-		}
-	}
-
 	return CALL(q, iolock, q, vb, fbuf);
 }
 
 /* --------------------------------------------------------------------- */
+
+static int videobuf_mmap_setup_default(struct videobuf_queue *q,
+					struct videobuf_buffer *vb)
+{
+	return 0;
+}
 
 
 void videobuf_queue_core_init(struct videobuf_queue *q,
@@ -131,6 +123,9 @@ void videobuf_queue_core_init(struct vid
 	q->ops       = ops;
 	q->priv_data = priv;
 	q->int_ops   = int_ops;
+
+	if (!q->int_ops->mmap_setup)
+		q->int_ops->mmap_setup = videobuf_mmap_setup_default;
 
 	/* All buffer operations are mandatory */
 	BUG_ON(!q->ops->buf_setup);
@@ -305,8 +300,6 @@ static int __videobuf_mmap_free(struct v
 
 	rc  = CALL(q, mmap_free, q);
 
-	q->is_mmapped = 0;
-
 	if (rc < 0)
 		return rc;
 
@@ -358,6 +351,9 @@ static int __videobuf_mmap_setup(struct 
 		switch (memory) {
 		case V4L2_MEMORY_MMAP:
 			q->bufs[i]->boff  = bsize * i;
+			err = q->int_ops->mmap_setup(q, q->bufs[i]);
+			if (err)
+				break;
 			break;
 		case V4L2_MEMORY_USERPTR:
 		case V4L2_MEMORY_OVERLAY:
@@ -1018,7 +1014,6 @@ int videobuf_mmap_mapper(struct videobuf
 
 	mutex_lock(&q->vb_lock);
 	retval = CALL(q, mmap_mapper, q, vma);
-	q->is_mmapped = 1;
 	mutex_unlock(&q->vb_lock);
 
 	return retval;
diff --git a/linux/drivers/media/video/videobuf-vmalloc.c b/linux/drivers/media/video/videobuf-vmalloc.c
--- a/linux/drivers/media/video/videobuf-vmalloc.c
+++ b/linux/drivers/media/video/videobuf-vmalloc.c
@@ -152,21 +152,26 @@ static int __videobuf_iolock (struct vid
 				(unsigned long)mem->vmalloc,
 				pages << PAGE_SHIFT);
 
-	/* It seems that some kernel versions need to do remap *after*
-	   the mmap() call
-	 */
-	if (mem->vma) {
-		int retval=remap_vmalloc_range(mem->vma, mem->vmalloc,0);
-		kfree(mem->vma);
-		mem->vma=NULL;
-		if (retval<0) {
-			dprintk(1,"mmap app bug: remap_vmalloc_range area %p error %d\n",
-				mem->vmalloc,retval);
-			return retval;
+	return 0;
+}
+
+static int __videobuf_mmap_setup(struct videobuf_queue *q,
+			      struct videobuf_buffer *vb)
+{
+	int retval = 0;
+	BUG_ON(vb->memory != V4L2_MEMORY_MMAP);
+	if (vb->state == VIDEOBUF_NEEDS_INIT) {
+		/* bsize == size since the buffer needs to be large enough to
+		 * hold an entire frame, not the case in the read case for
+		 * example*/
+		vb->size = vb->bsize;
+		retval = __videobuf_iolock(q, vb, NULL);
+		if (!retval) {
+			/* Don't IOLOCK later */
+			vb->state = VIDEOBUF_IDLE;
 		}
 	}
-
-	return 0;
+	return retval;
 }
 
 static int __videobuf_sync(struct videobuf_queue *q,
@@ -239,15 +244,8 @@ static int __videobuf_mmap_mapper(struct
 	/* Try to remap memory */
 	retval=remap_vmalloc_range(vma, mem->vmalloc,0);
 	if (retval<0) {
-		dprintk(1,"mmap: postponing remap_vmalloc_range\n");
-
-		mem->vma=kmalloc(sizeof(*vma),GFP_KERNEL);
-		if (!mem->vma) {
-			kfree(map);
-			q->bufs[first]->map=NULL;
-			return -ENOMEM;
-		}
-		memcpy(mem->vma,vma,sizeof(*vma));
+		dprintk(1, "mmap: failed to remap_vmalloc_range\n");
+		return -EINVAL;
 	}
 
 	dprintk(1,"mmap %p: q=%p %08lx-%08lx (%lx) pgoff %08lx buf %d\n",
@@ -315,6 +313,7 @@ static struct videobuf_qtype_ops qops = 
 	.alloc        = __videobuf_alloc,
 	.iolock       = __videobuf_iolock,
 	.sync         = __videobuf_sync,
+	.mmap_setup   = __videobuf_mmap_setup,
 	.mmap_free    = __videobuf_mmap_free,
 	.mmap_mapper  = __videobuf_mmap_mapper,
 	.video_copy_to_user = __videobuf_copy_to_user,
diff --git a/linux/include/media/videobuf-core.h b/linux/include/media/videobuf-core.h
--- a/linux/include/media/videobuf-core.h
+++ b/linux/include/media/videobuf-core.h
@@ -144,6 +144,8 @@ struct videobuf_qtype_ops {
 				 int vbihack,
 				 int nonblocking);
 	int (*mmap_free)	(struct videobuf_queue *q);
+	int (*mmap_setup)	(struct videobuf_queue *q,
+				 struct videobuf_buffer *vb);
 	int (*mmap_mapper)	(struct videobuf_queue *q,
 				struct vm_area_struct *vma);
 };
@@ -168,7 +170,6 @@ struct videobuf_queue {
 
 	unsigned int               streaming:1;
 	unsigned int               reading:1;
-	unsigned int		   is_mmapped:1;
 
 	/* capture via mmap() + ioctl(QBUF/DQBUF) */
 	struct list_head           stream;

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699281 25200
# Node ID 304e0a371d12f77e1575ae43fa0133855165f63e
# Parent  ab74ebf10c01d6a8a54a39b6750bc86ec3e72286
vivi: Simplify the vivi driver and avoid deadlocks

vivi previously had a very complex queuing system and held spinlocks while
doing copy_to_user, kmalloc, etc.  This caused the driver to easily deadlock
when a multi-threaded application used it and revealed bugs in videobuf too.

This replaces the copy_to_user with memcpy since we were never copying to user
space addresses.  And makes the kmalloc atomic.

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/vivi.c |  318 ++++++++++-----------------------------
 1 file changed, 82 insertions(+), 236 deletions(-)

diff --git a/linux/drivers/media/video/vivi.c b/linux/drivers/media/video/vivi.c
--- a/linux/drivers/media/video/vivi.c
+++ b/linux/drivers/media/video/vivi.c
@@ -5,6 +5,7 @@
  *      Mauro Carvalho Chehab <mchehab--a.t--infradead.org>
  *      Ted Walther <ted--a.t--enumera.com>
  *      John Sokol <sokol--a.t--videotechnology.com>
+ *      Brandon Philips <brandon@ifup.org>
  *      http://v4l.videotechnology.com/
  *
  * This program is free software; you can redistribute it and/or modify
@@ -155,8 +156,6 @@ struct vivi_buffer {
 
 struct vivi_dmaqueue {
 	struct list_head       active;
-	struct list_head       queued;
-	struct timer_list      timeout;
 
 	/* thread for generating video stream*/
 	struct task_struct         *kthread;
@@ -175,11 +174,6 @@ struct vivi_dev {
 struct vivi_dev {
 	struct list_head           vivi_devlist;
 
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 16)
-	struct mutex               lock;
-#else
-	struct semaphore           lock;
-#endif
 	spinlock_t                 slock;
 
 	int                        users;
@@ -339,24 +333,26 @@ end:
 end:
 	return;
 }
+
 static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
 {
 	int h , pos = 0;
 	int hmax  = buf->vb.height;
 	int wmax  = buf->vb.width;
 	struct timeval ts;
-	char *tmpbuf = kmalloc(wmax * 2, GFP_KERNEL);
+	char *tmpbuf = kmalloc(wmax * 2, GFP_ATOMIC);
 	void *vbuf = videobuf_to_vmalloc(&buf->vb);
 
 	if (!tmpbuf)
 		return;
 
+	if (!vbuf)
+		return;
+
 	for (h = 0; h < hmax; h++) {
 		gen_line(tmpbuf, 0, wmax, hmax, h, dev->mv_count,
 			 dev->timestr);
-		/* FIXME: replacing to __copy_to_user */
-		if (copy_to_user(vbuf + pos, tmpbuf, wmax * 2) != 0)
-			dprintk(dev, 2, "vivifill copy_to_user failed.\n");
+		memcpy(vbuf + pos, tmpbuf, wmax * 2);
 		pos += wmax*2;
 	}
 
@@ -389,67 +385,58 @@ static void vivi_fillbuff(struct vivi_de
 			dev->timestr, (unsigned long)tmpbuf, pos);
 
 	/* Advice that buffer was filled */
-	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
 	do_gettimeofday(&ts);
 	buf->vb.ts = ts;
+	buf->vb.state = VIDEOBUF_DONE;
+}
+
+static void vivi_thread_tick(struct vivi_fh *fh)
+{
+	struct vivi_buffer *buf;
+	struct vivi_dev *dev = fh->dev;
+	struct vivi_dmaqueue *dma_q = &dev->vidq;
+
+	unsigned long flags = 0;
+
+	dprintk(dev, 1, "Thread tick\n");
+
+	spin_lock_irqsave(&dev->slock, flags);
+	if (list_empty(&dma_q->active)) {
+		dprintk(dev, 1, "No active queue to serve\n");
+		goto unlock;
+	}
+
+	buf = list_entry(dma_q->active.next,
+			 struct vivi_buffer, vb.queue);
+
+	/* Nobody is waiting on this buffer, return */
+	if (!waitqueue_active(&buf->vb.done))
+		goto unlock;
 
 	list_del(&buf->vb.queue);
+
+	do_gettimeofday(&buf->vb.ts);
+
+	/* Fill buffer */
+	vivi_fillbuff(dev, buf);
+	dprintk(dev, 1, "filled buffer %p\n", buf);
+
 	wake_up(&buf->vb.done);
-}
-
-static int restart_video_queue(struct vivi_dmaqueue *dma_q);
-
-static void vivi_thread_tick(struct vivi_dmaqueue  *dma_q)
-{
-	struct vivi_buffer    *buf;
-	struct vivi_dev *dev = container_of(dma_q, struct vivi_dev, vidq);
-
-	int bc;
-
-	spin_lock(&dev->slock);
-	/* Announces videobuf that all went ok */
-	for (bc = 0;; bc++) {
-		if (list_empty(&dma_q->active)) {
-			dprintk(dev, 1, "No active queue to serve\n");
-			break;
-		}
-
-		buf = list_entry(dma_q->active.next,
-				 struct vivi_buffer, vb.queue);
-
-		/* Nobody is waiting something to be done, just return */
-		if (!waitqueue_active(&buf->vb.done)) {
-			mod_timer(&dma_q->timeout, jiffies+BUFFER_TIMEOUT);
-			spin_unlock(&dev->slock);
-			return;
-		}
-
-		do_gettimeofday(&buf->vb.ts);
-		dprintk(dev, 2, "[%p/%d] wakeup\n", buf, buf->vb. i);
-
-		/* Fill buffer */
-		vivi_fillbuff(dev, buf);
-
-		if (list_empty(&dma_q->active)) {
-			del_timer(&dma_q->timeout);
-		} else {
-			mod_timer(&dma_q->timeout, jiffies + BUFFER_TIMEOUT);
-		}
-	}
-	if (bc != 1)
-		dprintk(dev, 1, "%s: %d buffers handled (should be 1)\n",
-			__FUNCTION__, bc);
-	spin_unlock(&dev->slock);
+	dprintk(dev, 2, "[%p/%d] wakeup\n", buf, buf->vb. i);
+unlock:
+	spin_unlock_irqrestore(&dev->slock, flags);
+	return;
 }
 
 #define frames_to_ms(frames)					\
 	((frames * WAKE_NUMERATOR * 1000) / WAKE_DENOMINATOR)
 
-static void vivi_sleep(struct vivi_dmaqueue  *dma_q)
+static void vivi_sleep(struct vivi_fh *fh)
 {
-	struct vivi_dev *dev = container_of(dma_q, struct vivi_dev, vidq);
-	int timeout, running_time;
+	struct vivi_dev *dev = fh->dev;
+	struct vivi_dmaqueue *dma_q = &dev->vidq;
+	int timeout;
 	DECLARE_WAITQUEUE(wait, current);
 
 	dprintk(dev, 1, "%s dma_q=0x%08lx\n", __FUNCTION__,
@@ -464,37 +451,10 @@ static void vivi_sleep(struct vivi_dmaqu
 		goto stop_task;
 #endif
 
-	running_time = jiffies - dma_q->ini_jiffies;
-	dma_q->frame++;
+	/* Calculate time to wake up */
+	timeout = msecs_to_jiffies(frames_to_ms(1));
 
-	/* Calculate time to wake up */
-	timeout = msecs_to_jiffies(frames_to_ms(dma_q->frame)) - running_time;
-
-	if (timeout > msecs_to_jiffies(frames_to_ms(2)) || timeout <= 0) {
-		int old = dma_q->frame;
-		int nframes;
-
-		dma_q->frame = (jiffies_to_msecs(running_time) /
-			       frames_to_ms(1)) + 1;
-
-		timeout = msecs_to_jiffies(frames_to_ms(dma_q->frame))
-			  - running_time;
-
-		if (unlikely (timeout <= 0))
-			timeout = 1;
-
-		nframes = (dma_q->frame > old)?
-				  dma_q->frame - old : old - dma_q->frame;
-
-		dprintk(dev, 1, "%ld: %s %d frames. "
-			"Current frame is %d. Will sleep for %d jiffies\n",
-			jiffies,
-			(dma_q->frame > old)? "Underrun, losed" : "Overrun of",
-			nframes, dma_q->frame, timeout);
-	} else
-		dprintk(dev, 1, "will sleep for %d jiffies\n", timeout);
-
-	vivi_thread_tick(dma_q);
+	vivi_thread_tick(fh);
 
 	schedule_timeout_interruptible(timeout);
 
@@ -505,8 +465,8 @@ stop_task:
 
 static int vivi_thread(void *data)
 {
-	struct vivi_dmaqueue  *dma_q = data;
-	struct vivi_dev *dev = container_of(dma_q, struct vivi_dev, vidq);
+	struct vivi_fh  *fh = data;
+	struct vivi_dev *dev = fh->dev;
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
 	daemonize();
@@ -524,11 +484,10 @@ static int vivi_thread(void *data)
 #endif
 	dprintk(dev, 1, "thread started\n");
 
-	mod_timer(&dma_q->timeout, jiffies+BUFFER_TIMEOUT);
 	set_freezable();
 
 	for (;;) {
-		vivi_sleep(dma_q);
+		vivi_sleep(fh);
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
 		if (dma_q->rmmod || signal_pending(current))
@@ -547,9 +506,10 @@ static int vivi_thread(void *data)
 	return 0;
 }
 
-static int vivi_start_thread(struct vivi_dmaqueue  *dma_q)
+static int vivi_start_thread(struct vivi_fh *fh)
 {
-	struct vivi_dev *dev = container_of(dma_q, struct vivi_dev, vidq);
+	struct vivi_dev *dev = fh->dev;
+	struct vivi_dmaqueue *dma_q = &dev->vidq;
 
 	dma_q->frame = 0;
 	dma_q->ini_jiffies = jiffies;
@@ -557,7 +517,7 @@ static int vivi_start_thread(struct vivi
 	dprintk(dev, 1, "%s\n", __FUNCTION__);
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 5, 0)
-	dma_q->kthread = kthread_run(vivi_thread, dma_q, "vivi");
+	dma_q->kthread = kthread_run(vivi_thread, fh, "vivi");
 
 	if (IS_ERR(dma_q->kthread)) {
 		printk(KERN_ERR "vivi: kernel_thread() failed\n");
@@ -570,7 +530,7 @@ static int vivi_start_thread(struct vivi
 	dma_q->notify = &sem;
 	dma_q->rmmod = 0;
 
-	if (kernel_thread(vivi_thread, dma_q, 0) < 0) {
+	if (kernel_thread(vivi_thread, fh, 0) < 0) {
 		printk(KERN_ERR "sdim: kernel_thread() failed\n");
 		return -EINVAL;
 	}
@@ -609,91 +569,6 @@ static void vivi_stop_thread(struct vivi
 	}
 }
 
-static int restart_video_queue(struct vivi_dmaqueue *dma_q)
-{
-	struct vivi_dev *dev = container_of(dma_q, struct vivi_dev, vidq);
-	struct vivi_buffer *buf, *prev;
-
-	dprintk(dev, 1, "%s dma_q=0x%08lx\n", __FUNCTION__,
-		(unsigned long)dma_q);
-
-	if (!list_empty(&dma_q->active)) {
-		buf = list_entry(dma_q->active.next,
-				 struct vivi_buffer, vb.queue);
-		dprintk(dev, 2, "restart_queue [%p/%d]: restart dma\n",
-			buf, buf->vb.i);
-
-		dprintk(dev, 1, "Restarting video dma\n");
-		vivi_stop_thread(dma_q);
-
-		/* cancel all outstanding capture / vbi requests */
-		list_for_each_entry_safe(buf, prev, &dma_q->active, vb.queue) {
-			list_del(&buf->vb.queue);
-			buf->vb.state = VIDEOBUF_ERROR;
-			wake_up(&buf->vb.done);
-		}
-		mod_timer(&dma_q->timeout, jiffies+BUFFER_TIMEOUT);
-
-		return 0;
-	}
-
-	prev = NULL;
-	for (;;) {
-		if (list_empty(&dma_q->queued))
-			return 0;
-		buf = list_entry(dma_q->queued.next,
-				 struct vivi_buffer, vb.queue);
-		if (NULL == prev) {
-			list_del(&buf->vb.queue);
-			list_add_tail(&buf->vb.queue, &dma_q->active);
-
-			dprintk(dev, 1, "Restarting video dma\n");
-			vivi_stop_thread(dma_q);
-			vivi_start_thread(dma_q);
-
-			buf->vb.state = VIDEOBUF_ACTIVE;
-			mod_timer(&dma_q->timeout, jiffies+BUFFER_TIMEOUT);
-			dprintk(dev, 2,
-				"[%p/%d] restart_queue - first active\n",
-				buf, buf->vb.i);
-
-		} else if (prev->vb.width  == buf->vb.width  &&
-			   prev->vb.height == buf->vb.height &&
-			   prev->fmt       == buf->fmt) {
-			list_del(&buf->vb.queue);
-			list_add_tail(&buf->vb.queue, &dma_q->active);
-			buf->vb.state = VIDEOBUF_ACTIVE;
-			dprintk(dev, 2,
-				"[%p/%d] restart_queue - move to active\n",
-				buf, buf->vb.i);
-		} else {
-			return 0;
-		}
-		prev = buf;
-	}
-}
-
-static void vivi_vid_timeout(unsigned long data)
-{
-	struct vivi_dev      *dev  = (struct vivi_dev *)data;
-	struct vivi_dmaqueue *vidq = &dev->vidq;
-	struct vivi_buffer   *buf;
-
-	spin_lock(&dev->slock);
-
-	while (!list_empty(&vidq->active)) {
-		buf = list_entry(vidq->active.next,
-				 struct vivi_buffer, vb.queue);
-		list_del(&buf->vb.queue);
-		buf->vb.state = VIDEOBUF_ERROR;
-		wake_up(&buf->vb.done);
-		printk(KERN_INFO "vivi/0: [%p/%d] timeout\n", buf, buf->vb.i);
-	}
-	restart_video_queue(vidq);
-
-	spin_unlock(&dev->slock);
-}
-
 /* ------------------------------------------------------------------
 	Videobuf operations
    ------------------------------------------------------------------*/
@@ -722,13 +597,13 @@ static void free_buffer(struct videobuf_
 	struct vivi_fh  *fh = vq->priv_data;
 	struct vivi_dev *dev  = fh->dev;
 
-	dprintk(dev, 1, "%s\n", __FUNCTION__);
+	dprintk(dev, 1, "%s, state: %i\n", __FUNCTION__, buf->vb.state);
 
 	if (in_interrupt())
 		BUG();
 
-	videobuf_waiton(&buf->vb, 0, 0);
 	videobuf_vmalloc_free(&buf->vb);
+	dprintk(dev, 1, "free_buffer: freed");
 	buf->vb.state = VIDEOBUF_NEEDS_INIT;
 }
 
@@ -741,28 +616,25 @@ buffer_prepare(struct videobuf_queue *vq
 	struct vivi_fh     *fh  = vq->priv_data;
 	struct vivi_dev    *dev = fh->dev;
 	struct vivi_buffer *buf = container_of(vb, struct vivi_buffer, vb);
-	int rc, init_buffer = 0;
+	int rc;
 
 	dprintk(dev, 1, "%s, field=%d\n", __FUNCTION__, field);
 
 	BUG_ON(NULL == fh->fmt);
+
 	if (fh->width  < 48 || fh->width  > norm_maxw() ||
 	    fh->height < 32 || fh->height > norm_maxh())
 		return -EINVAL;
+
 	buf->vb.size = fh->width*fh->height*2;
 	if (0 != buf->vb.baddr  &&  buf->vb.bsize < buf->vb.size)
 		return -EINVAL;
 
-	if (buf->fmt       != fh->fmt    ||
-	    buf->vb.width  != fh->width  ||
-	    buf->vb.height != fh->height ||
-	buf->vb.field  != field) {
-		buf->fmt       = fh->fmt;
-		buf->vb.width  = fh->width;
-		buf->vb.height = fh->height;
-		buf->vb.field  = field;
-		init_buffer = 1;
-	}
+	/* These properties only change when queue is idle, see s_fmt */
+	buf->fmt       = fh->fmt;
+	buf->vb.width  = fh->width;
+	buf->vb.height = fh->height;
+	buf->vb.field  = field;
 
 	if (VIDEOBUF_NEEDS_INIT == buf->vb.state) {
 		rc = videobuf_iolock(vq, &buf->vb, NULL);
@@ -785,45 +657,12 @@ buffer_queue(struct videobuf_queue *vq, 
 	struct vivi_buffer    *buf  = container_of(vb, struct vivi_buffer, vb);
 	struct vivi_fh        *fh   = vq->priv_data;
 	struct vivi_dev       *dev  = fh->dev;
-	struct vivi_dmaqueue  *vidq = &dev->vidq;
-	struct vivi_buffer    *prev;
+	struct vivi_dmaqueue *vidq = &dev->vidq;
 
-	if (!list_empty(&vidq->queued)) {
-		dprintk(dev, 1, "adding vb queue=0x%08lx\n",
-			(unsigned long)&buf->vb.queue);
-		list_add_tail(&buf->vb.queue, &vidq->queued);
-		buf->vb.state = VIDEOBUF_QUEUED;
-		dprintk(dev, 2, "[%p/%d] buffer_queue - append to queued\n",
-			buf, buf->vb.i);
-	} else if (list_empty(&vidq->active)) {
-		list_add_tail(&buf->vb.queue, &vidq->active);
+	dprintk(dev, 1, "%s\n", __FUNCTION__);
 
-		buf->vb.state = VIDEOBUF_ACTIVE;
-		mod_timer(&vidq->timeout, jiffies+BUFFER_TIMEOUT);
-		dprintk(dev, 2, "[%p/%d] buffer_queue - first active\n",
-			buf, buf->vb.i);
-
-		vivi_start_thread(vidq);
-	} else {
-		prev = list_entry(vidq->active.prev,
-				  struct vivi_buffer, vb.queue);
-		if (prev->vb.width  == buf->vb.width  &&
-		    prev->vb.height == buf->vb.height &&
-		    prev->fmt       == buf->fmt) {
-			list_add_tail(&buf->vb.queue, &vidq->active);
-			buf->vb.state = VIDEOBUF_ACTIVE;
-			dprintk(dev, 2,
-				"[%p/%d] buffer_queue - append to active\n",
-				buf, buf->vb.i);
-
-		} else {
-			list_add_tail(&buf->vb.queue, &vidq->queued);
-			buf->vb.state = VIDEOBUF_QUEUED;
-			dprintk(dev, 2,
-				"[%p/%d] buffer_queue - first queued\n",
-				buf, buf->vb.i);
-		}
-	}
+	buf->vb.state = VIDEOBUF_QUEUED;
+	list_add_tail(&buf->vb.queue, &vidq->active);
 }
 
 static void buffer_release(struct videobuf_queue *vq,
@@ -832,11 +671,8 @@ static void buffer_release(struct videob
 	struct vivi_buffer   *buf  = container_of(vb, struct vivi_buffer, vb);
 	struct vivi_fh       *fh   = vq->priv_data;
 	struct vivi_dev      *dev  = (struct vivi_dev *)fh->dev;
-	struct vivi_dmaqueue *vidq = &dev->vidq;
 
 	dprintk(dev, 1, "%s\n", __FUNCTION__);
-
-	vivi_stop_thread(vidq);
 
 	free_buffer(vq, buf);
 }
@@ -943,9 +779,19 @@ static int vidioc_s_fmt_cap(struct file 
 					struct v4l2_format *f)
 {
 	struct vivi_fh  *fh = priv;
+	struct videobuf_queue *q = &fh->vb_vidq;
+
 	int ret = vidioc_try_fmt_cap(file, fh, f);
 	if (ret < 0)
 		return (ret);
+
+	mutex_lock(&q->vb_lock);
+
+	if (videobuf_queue_is_busy(&fh->vb_vidq)) {
+		dprintk(fh->dev, 1, "%s queue busy\n", __FUNCTION__);
+		ret = -EBUSY;
+		goto out;
+	}
 
 	fh->fmt           = &format;
 	fh->width         = f->fmt.pix.width;
@@ -953,7 +799,11 @@ static int vidioc_s_fmt_cap(struct file 
 	fh->vb_vidq.field = f->fmt.pix.field;
 	fh->type          = f->type;
 
-	return (0);
+	ret = 0;
+out:
+	mutex_unlock(&q->vb_lock);
+
+	return (ret);
 }
 
 static int vidioc_reqbufs(struct file *file, void *priv,
@@ -1158,6 +1008,8 @@ found:
 			NULL, &dev->slock, fh->type, V4L2_FIELD_INTERLACED,
 			sizeof(struct vivi_buffer), fh);
 
+	vivi_start_thread(fh);
+
 	return 0;
 }
 
@@ -1310,16 +1162,10 @@ static int __init vivi_init(void)
 
 		/* init video dma queues */
 		INIT_LIST_HEAD(&dev->vidq.active);
-		INIT_LIST_HEAD(&dev->vidq.queued);
 		init_waitqueue_head(&dev->vidq.wq);
 
 		/* initialize locks */
-		mutex_init(&dev->lock);
 		spin_lock_init(&dev->slock);
-
-		dev->vidq.timeout.function = vivi_vid_timeout;
-		dev->vidq.timeout.data     = (unsigned long)dev;
-		init_timer(&dev->vidq.timeout);
 
 		vfd = video_device_alloc();
 		if (NULL == vfd)

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 8 of 9] videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699281 25200
# Node ID 0b7eea4e7b7dc24b1c015e5768fdb8f70f70c751
# Parent  304e0a371d12f77e1575ae43fa0133855165f63e
videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue

Add a waitqueue to wait on when there are no buffers in the buffer queue.
DQBUF waits on this queue without holding vb_lock to allow a QBUF to happen.
Once a buffer has been queued we recheck that the queue is still streaming and
wait on the new buffer's waitqueue while holding the vb_lock.  The driver
should come along in a timely manner and put the buffer into its next state
finishing the DQBUF.

By implementing this waitqueue it also brings the videobuf DQBUF up to spec and
it now blocks on O_NONBLOCK even when no buffers have been queued via QBUF:

"By default VIDIOC_DQBUF blocks when no buffer is in the outgoing queue."
 - V4L2 spec

CC: Trent Piepho <xyzzy@speakeasy.org>
CC: Carl Karsten <carl@personnelware.com>
CC: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-core.c |   96 +++++++++++++++++++++++-------
 linux/include/media/videobuf-core.h       |    2
 2 files changed, 78 insertions(+), 20 deletions(-)

diff --git a/linux/drivers/media/video/videobuf-core.c b/linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c
+++ b/linux/drivers/media/video/videobuf-core.c
@@ -140,6 +140,7 @@ void videobuf_queue_core_init(struct vid
 	BUG_ON(!q->int_ops);
 
 	mutex_init(&q->vb_lock);
+	init_waitqueue_head(&q->wait);
 	INIT_LIST_HEAD(&q->stream);
 }
 
@@ -186,6 +187,10 @@ void videobuf_queue_cancel(struct videob
 {
 	unsigned long flags = 0;
 	int i;
+
+	q->streaming = 0;
+	q->reading  = 0;
+	wake_up_all(&q->wait);
 
 	/* remove queued buffers from list */
 	spin_lock_irqsave(q->irqlock, flags);
@@ -561,6 +566,7 @@ int videobuf_qbuf(struct videobuf_queue 
 	}
 	dprintk(1, "qbuf: succeded\n");
 	retval = 0;
+	wake_up(&q->wait);
 
  done:
 	mutex_unlock(&q->vb_lock);
@@ -571,37 +577,88 @@ int videobuf_qbuf(struct videobuf_queue 
 	return retval;
 }
 
+
+/* Locking: Caller holds q->vb_lock */
+static int stream_next_buffer_check_queue(struct videobuf_queue *q, int noblock)
+{
+	int retval;
+
+checks:
+	if (!q->streaming) {
+		dprintk(1, "next_buffer: Not streaming\n");
+		retval = -EINVAL;
+		goto done;
+	}
+
+	if (list_empty(&q->stream)) {
+		if (noblock) {
+			retval = -EAGAIN;
+			dprintk(2, "next_buffer: no buffers to dequeue\n");
+			goto done;
+		} else {
+			dprintk(2, "next_buffer: waiting on buffer\n");
+
+			/* Drop lock to avoid deadlock with qbuf */
+			mutex_unlock(&q->vb_lock);
+
+			/* Checking list_empty and streaming is safe without
+			 * locks because we goto checks to validate while
+			 * holding locks before proceeding */
+			retval = wait_event_interruptible(q->wait,
+				!list_empty(&q->stream) || !q->streaming);
+			mutex_lock(&q->vb_lock);
+
+			if (retval)
+				goto done;
+
+			goto checks;
+		}
+	}
+
+	retval = 0;
+
+done:
+	return retval;
+}
+
+
+/* Locking: Caller holds q->vb_lock */
+static int stream_next_buffer(struct videobuf_queue *q,
+			struct videobuf_buffer **vb, int nonblocking)
+{
+	int retval;
+	struct videobuf_buffer *buf = NULL;
+
+	retval = stream_next_buffer_check_queue(q, nonblocking);
+	if (retval)
+		goto done;
+
+	buf = list_entry(q->stream.next, struct videobuf_buffer, stream);
+	retval = videobuf_waiton(buf, nonblocking, 1);
+	if (retval < 0)
+		goto done;
+
+	*vb = buf;
+done:
+	return retval;
+}
+
 int videobuf_dqbuf(struct videobuf_queue *q,
 	       struct v4l2_buffer *b, int nonblocking)
 {
-	struct videobuf_buffer *buf;
+	struct videobuf_buffer *buf = NULL;
 	int retval;
 
 	MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS);
 
 	mutex_lock(&q->vb_lock);
-	retval = -EBUSY;
-	if (q->reading) {
-		dprintk(1, "dqbuf: Reading running...\n");
+
+	retval = stream_next_buffer(q, &buf, nonblocking);
+	if (retval < 0) {
+		dprintk(1, "dqbuf: next_buffer error: %i\n", retval);
 		goto done;
 	}
-	retval = -EINVAL;
-	if (b->type != q->type) {
-		dprintk(1, "dqbuf: Wrong type.\n");
-		goto done;
-	}
-	if (list_empty(&q->stream)) {
-		dprintk(1, "dqbuf: stream running\n");
-		goto done;
-	}
-	buf = list_entry(q->stream.next, struct videobuf_buffer, stream);
-	mutex_unlock(&q->vb_lock);
-	retval = videobuf_waiton(buf, nonblocking, 1);
-	mutex_lock(&q->vb_lock);
-	if (retval < 0) {
-		dprintk(1, "dqbuf: waiton returned %d\n", retval);
-		goto done;
-	}
+
 	switch (buf->state) {
 	case VIDEOBUF_ERROR:
 		dprintk(1, "dqbuf: state is error\n");
@@ -648,6 +705,7 @@ int videobuf_streamon(struct videobuf_qu
 			q->ops->buf_queue(q, buf);
 	spin_unlock_irqrestore(q->irqlock, flags);
 
+	wake_up(&q->wait);
  done:
 	mutex_unlock(&q->vb_lock);
 	return retval;
@@ -660,7 +718,6 @@ static int __videobuf_streamoff(struct v
 		return -EINVAL;
 
 	videobuf_queue_cancel(q);
-	q->streaming = 0;
 
 	return 0;
 }
@@ -858,7 +915,6 @@ static void __videobuf_read_stop(struct 
 		q->bufs[i] = NULL;
 	}
 	q->read_buf = NULL;
-	q->reading  = 0;
 
 }
 
diff --git a/linux/include/media/videobuf-core.h b/linux/include/media/videobuf-core.h
--- a/linux/include/media/videobuf-core.h
+++ b/linux/include/media/videobuf-core.h
@@ -159,6 +159,8 @@ struct videobuf_queue {
 	spinlock_t                 *irqlock;
 	struct device		   *dev;
 
+	wait_queue_head_t	   wait; /* wait if queue is empty */
+
 	enum v4l2_buf_type         type;
 	unsigned int               inputs; /* for V4L2_BUF_FLAG_INPUT */
 	unsigned int               msize;

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH 9 of 9] videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility

[Brandon Philips]

# HG changeset patch
# User Brandon Philips <brandon@ifup.org>
# Date 1206699283 25200
# Node ID 91e7d2afab2c180c435e5dc85b4cb749b1001e5a
# Parent  0b7eea4e7b7dc24b1c015e5768fdb8f70f70c751
videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/videobuf-dma-sg.c |   16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/linux/drivers/media/video/videobuf-dma-sg.c b/linux/drivers/media/video/videobuf-dma-sg.c
--- a/linux/drivers/media/video/videobuf-dma-sg.c
+++ b/linux/drivers/media/video/videobuf-dma-sg.c
@@ -592,6 +592,14 @@ static int __videobuf_mmap_mapper(struct
 		goto done;
 	}
 
+	/* This function maintains backwards compatibility with V4L1 and will
+	 * map more than one buffer if the vma length is equal to the combined
+	 * size of multiple buffers than it will map them together.  See
+	 * VIDIOCGMBUF in the v4l spec
+	 *
+	 * TODO: Allow drivers to specify if they support this mode
+	 */
+
 	/* look for first buffer to map */
 	for (first = 0; first < VIDEO_MAX_FRAME; first++) {
 		if (NULL == q->bufs[first])
@@ -636,10 +644,16 @@ static int __videobuf_mmap_mapper(struct
 	map = kmalloc(sizeof(struct videobuf_mapping),GFP_KERNEL);
 	if (NULL == map)
 		goto done;
-	for (size = 0, i = first; i <= last; size += q->bufs[i++]->bsize) {
+
+	size = 0;
+	for (i = first; i <= last; i++) {
+		if (NULL == q->bufs[i])
+			continue;
 		q->bufs[i]->map   = map;
 		q->bufs[i]->baddr = vma->vm_start + size;
+		size += q->bufs[i]->bsize;
 	}
+
 	map->count    = 1;
 	map->start    = vma->vm_start;
 	map->end      = vma->vm_end;

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks

[Mauro Carvalho Chehab]

Hi Brandon,

I'll try to test the patch series. They seems fine to my eyes, on a first look.
I have just some comments about patch 7/9.

> Also, is anyone using videobuf-vmalloc besides vivi?  The current videobuf API
> feels over extended trying to take on the task of a second backend type.

The only current driver at the tree using videobuf-vmalloc is vivi.
There's another driver using it at tm6000 driver, not merged yet [1].

On Fri, 28 Mar 2008 03:18:38 -0700
Brandon Philips <brandon@ifup.org> wrote:

> --- a/linux/drivers/media/video/vivi.c
> +++ b/linux/drivers/media/video/vivi.c
> @@ -5,6 +5,7 @@
>   *      Mauro Carvalho Chehab <mchehab--a.t--infradead.org>
>   *      Ted Walther <ted--a.t--enumera.com>
>   *      John Sokol <sokol--a.t--videotechnology.com>
> + *      Brandon Philips <brandon@ifup.org>

This is under copyright (2006), as if you were one of the authors of the
original driver. Also, I prefer if you add a short line bellow your copyright
for the job you've done on the driver. Something like:

+ *
+ *  Copyright (c) 2008 by Brandon Philips <brandon@ifup.org>
+ *       - Fix bad locks and cleans up streaming code

> -static int restart_video_queue(struct vivi_dmaqueue *dma_q)
> -{
...
> -}

While the restart and timeout code is not needed on vivi driver, IMO, we should
keep it, since the main reason for this driver is to be a reference code. 

This kind of code is important on real drivers, since the IRQ's may not be called
for some reason. On cx88 and on saa7134, this happens on several situations[2]. 

Without a timeout, the driver will wait forever to receive a buffer.

This task is also needed by tm6000 driver, for the same reasons.

[1] Available at: http://linuxtv.org/hg/~mchehab/tm6010

[2] For example, I suffered an issue yesterday with my machine, that I believe
to be caused by an excess of power consumption. The effect is that cx88 weren't
generating DMA interrupts, if I loaded my machine with 3 pci boards. The
removal of one board made the cx88 board to work again. I'll test today again
with a newer power supply. Without the timeout code, the player would just
hang, waiting forever for some data at the video buffer.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Mauro Carvalho Chehab]

[-- Attachment #1: Type: text/plain, Size: 9239 bytes --]

On Fri, 28 Mar 2008 03:18:31 -0700
Brandon Philips <brandon@ifup.org> wrote:

> Hello-
> 
> Sorry for the mess-up on the first round.  :-(
> 
> The following set fixes problems I discovered while tracking down bugs in both
> vivi and videobuf.  Hopefully most of these can make it into 2.6.25 since they
> all seem pretty critical.
> 
> Please take a good look at the set and test if possible.  Particularly:
>   [RFC] videobuf: Avoid deadlock with QBUF
> 
> Also, is anyone using videobuf-vmalloc besides vivi?  The current videobuf API
> feels over extended trying to take on the task of a second backend type. 
> 
> Pullable from http://ifup.org/hg/v4l-dvb 
> 
> - soc_camera: Introduce a spinlock for use with videobuf
> - videobuf: Require spinlocks for all videobuf users
> - videobuf: Wakeup queues after changing the state to ERROR
> - videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup
> - videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close
> - videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure
> - vivi: Simplify the vivi driver and avoid deadlocks
> - videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue
> - videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility
> 
>  b/linux/drivers/media/video/pxa_camera.c       |   11 
>  b/linux/drivers/media/video/soc_camera.c       |    5 
>  b/linux/drivers/media/video/videobuf-core.c    |   46 -
>  b/linux/drivers/media/video/videobuf-dma-sg.c  |   16 
>  b/linux/drivers/media/video/videobuf-vmalloc.c |    2 
>  b/linux/drivers/media/video/vivi.c             |  332 ++--------
>  b/linux/include/media/soc_camera.h             |    1 
>  b/linux/include/media/videobuf-core.h          |    3 
>  linux/drivers/media/video/videobuf-core.c      |  169 +++--
>  linux/drivers/media/video/videobuf-vmalloc.c   |   43 -
>  linux/include/media/videobuf-core.h            |    2 
>  11 files changed, 262 insertions(+), 368 deletions(-)

Hmm... it seems that there are still some troubles.

I've opened 3 mplayer windows, reading /dev/video0. I closed the second one and
opened again. I got an error:

[  665.465701] vivi: open called (minor=0)
[  677.931020] vivi: open called (minor=0)
[  686.961359] vivi: open called (minor=0)
[  700.881962] vivi: open called (minor=0)
[  705.709878] general protection fault: 0000 [1] PREEMPT SMP
[  705.709885] CPU 0
[  705.709888] Modules linked in: vivi compat_ioctl32 videodev v4l1_compat videobuf_vmalloc videobuf_core arc4 ecb blkcipher cryptomgr crypto_algapi rtl8187 mac80211 cfg80211 eeprom_93cx6 vmnet(P) vmblock vmmon(P) af_packet snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device iptable_filter ip_tables x_tables binfmt_misc nls_cp437 vfat fat nls_cp850 ntfs nls_base pata_atiixp libata scsi_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave powernow_k8 tifm_7xx1 nvram cryptoloop loop mmc_block tifm_sd mmc_core tifm_core snd_pcm_oss pcmcia snd_mixer_oss snd_hda_intel snd_pcm snd_timer yenta_socket snd_page_alloc snd_hwdep rtc_cmos rsrc_nonstatic ohci1394 snd ide_cd rtc_core pcmcia_core ieee1394 k8temp cdrom i2c_piix4 rtc_lib hwmon pcspkr sky2 i2c_core thermal soundcore processor battery ac button bitrev crc32 evdev unix ide_generic ide_disk ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd usbcore atiixp ide_core
[  705.709967] Pid: 5583, comm: vivi Tainted: P        2.6.24.3-4mnbcustom #4
[  705.709970] RIP: 0010:[<ffffffff885536cc>]  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  705.709980] RSP: 0018:ffff810058039e30  EFLAGS: 00010246
[  705.709983] RAX: ffff81005968cc00 RBX: 01c0055b0007033b RCX: ffff81005953b800
[  705.709986] RDX: ffffffff88553652 RSI: 0000000000000001 RDI: 0000000000000001
[  705.709988] RBP: 0000000000096000 R08: 0000000000000002 R09: 0000000000000000
[  705.709991] R10: ffffffff80253d69 R11: 0000000000000001 R12: 0000000000000140
[  705.709994] R13: ffff810059649000 R14: ffff8100773f9c80 R15: 0000000000000140
[  705.709997] FS:  00002ac9a2490a00(0000) GS:ffffffff80547000(0000) knlGS:0000000000000000
[  705.710000] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  705.710003] CR2: 000000000090bdd0 CR3: 0000000065d03000 CR4: 00000000000006e0
[  705.710005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  705.710008] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  705.710011] Process vivi (pid: 5583, threadinfo ffff810058038000, task ffff81005968cc00)
[  705.710014] Stack:  0000000000000000 ffff810059649080 0000000000000140 0000014102b32e00
[  705.710021]  ffff8100773f9c90 ffff8100773f9d58 ffff81005953b800 ffff8100773f9c80
[  705.710027]  01c0055b00070393 0000000000000009 0000000000000282 ffff810068890c00
[  705.710032] Call Trace:
[  705.710052]  [<ffffffff80233eb0>] default_wake_function+0x0/0x10
[  705.710061]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  705.710068]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  705.710076]  [<ffffffff8025379b>] kthread+0x4b/0x80
[  705.710083]  [<ffffffff8020d428>] child_rip+0xa/0x12
[  705.710089]  [<ffffffff802366d7>] finish_task_switch+0x57/0xe0
[  705.710094]  [<ffffffff8020cb13>] restore_args+0x0/0x30
[  705.710098]  [<ffffffff80253897>] kthreadd+0xc7/0x150
[  705.710107]  [<ffffffff80253750>] kthread+0x0/0x80
[  705.710111]  [<ffffffff8020d41e>] child_rip+0x0/0x12
[  705.710116]
[  705.710117]
[  705.710117] Code: 48 8b 43 50 44 8b 98 8c 03 00 00 45 85 db 7e 1a 48 8b 54 24
[  705.710131] RIP  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  705.710136]  RSP <ffff810058039e30>
[  705.710142] ---[ end trace 4d468849a38ba2e0 ]---
[  710.814272] vivi: open called (minor=0)

Yet, all 3 windows are working fine.

I'm running here with all spinlock modules here.

After closing all modules, I got another error dump:
[  934.913481] general protection fault: 0000 [2] PREEMPT SMP
[  934.913489] CPU 0
[  934.913492] Modules linked in: vivi compat_ioctl32 videodev v4l1_compat videobuf_vmalloc videobuf_core arc4 ecb blkcipher cryptomgr crypto_algapi rtl8187 mac80211 cfg80211 eeprom_93cx6 vmnet(P) vmblock vmmon(P) af_packet snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device iptable_filter ip_tables x_tables binfmt_misc nls_cp437 vfat fat nls_cp850 ntfs nls_base pata_atiixp libata scsi_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave powernow_k8 tifm_7xx1 nvram cryptoloop loop mmc_block tifm_sd mmc_core tifm_core snd_pcm_oss pcmcia snd_mixer_oss snd_hda_intel snd_pcm snd_timer yenta_socket snd_page_alloc snd_hwdep rtc_cmos rsrc_nonstatic ohci1394 snd ide_cd rtc_core pcmcia_core ieee1394 k8temp cdrom i2c_piix4 rtc_lib hwmon pcspkr sky2 i2c_core thermal soundcore processor battery ac button bitrev crc32 evdev unix ide_generic ide_disk ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd usbcore atiixp ide_core
[  934.913573] Pid: 5566, comm: vivi Tainted: P      D 2.6.24.3-4mnbcustom #4
[  934.913576] RIP: 0010:[<ffffffff885536cc>]  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  934.913588] RSP: 0018:ffff810063eb1e30  EFLAGS: 00010246
[  934.913590] RAX: ffff8100580ceb40 RBX: 0420000222e20012 RCX: ffff8100637bf400
[  934.913593] RDX: ffffffff88553652 RSI: 0000000000000001 RDI: 0000000000000001
[  934.913596] RBP: ffff8100773f9cd8 R08: 0000000000000002 R09: 0000000000000000
[  934.913599] R10: ffffffff80253d69 R11: 0000000000000001 R12: 0000000000000140
[  934.913602] R13: ffff810059649800 R14: ffff8100773f9c80 R15: 0000000000000140
[  934.913605] FS:  00002ac4a8b4b730(0000) GS:ffffffff80547000(0000) knlGS:0000000000000000
[  934.913608] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  934.913610] CR2: 00002b38780da350 CR3: 000000006f8d1000 CR4: 00000000000006e0
[  934.913613] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  934.913616] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  934.913619] Process vivi (pid: 5566, threadinfo ffff810063eb0000, task ffff8100580ceb40)
[  934.913621] Stack:  0000000000000000 ffff810059649880 0000000000000140 0000014102acae00
[  934.913629]  ffff8100773f9c90 ffff8100773f9d58 ffff8100637bf400 ffff8100773f9c80
[  934.913635]  0420000222e2006a 0000000000000009 0000000000000282 ffff810068890c00
[  934.913640] Call Trace:
[  934.913660]  [<ffffffff80233eb0>] default_wake_function+0x0/0x10
[  934.913669]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  934.913676]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  934.913685]  [<ffffffff8025379b>] kthread+0x4b/0x80
[  934.913692]  [<ffffffff8020d428>] child_rip+0xa/0x12
[  934.913698]  [<ffffffff802366d7>] finish_task_switch+0x57/0xe0
[  934.913704]  [<ffffffff8020cb13>] restore_args+0x0/0x30
[  934.913707]  [<ffffffff80253897>] kthreadd+0xc7/0x150
[  934.913715]  [<ffffffff80253750>] kthread+0x0/0x80
[  934.913720]  [<ffffffff8020d41e>] child_rip+0x0/0x12
[  934.913724]
[  934.913725]
[  934.913726] Code: 48 8b 43 50 44 8b 98 8c 03 00 00 45 85 db 7e 1a 48 8b 54 24
[  934.913739] RIP  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  934.913745]  RSP <ffff810063eb1e30>
[  934.913751] ---[ end trace 4d468849a38ba2e0 ]---

I suspect that the errors happened at the close().

I'm enclosing the full dmesg.

Cheers,
Mauro

[-- Attachment #2: dmesg.err --]
[-- Type: application/octet-stream, Size: 37884 bytes --]

[    0.000000] Linux version 2.6.24.3-4mnbcustom (root@gaivota) (gcc version 4.2.3 (4.2.3-6mnb1)) #4 SMP PREEMPT Fri Mar 28 11:37:53 BRT 2008
[    0.000000] Command line: BOOT_IMAGE=2.6.24.3-4mnbcustom root=/dev/hda5 resume=/dev/hda6 maxcpus=2
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
[    0.000000]  BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000077e80000 (usable)
[    0.000000]  BIOS-e820: 0000000077e80000 - 0000000077e92000 (ACPI data)
[    0.000000]  BIOS-e820: 0000000077e92000 - 0000000077f00000 (ACPI NVS)
[    0.000000]  BIOS-e820: 0000000077f00000 - 0000000080000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
[    0.000000] Entering add_active_range(0, 0, 157) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 491136) 1 entries of 256 used
[    0.000000] end_pfn_map = 1048576
[    0.000000] DMI present.
[    0.000000] ACPI: RSDP 000F8530, 0014 (r0 PTLTD )
[    0.000000] ACPI: RSDT 77E8C396, 0038 (r1 GATEWA SYSTEM   20061127  LTP        0)
[    0.000000] ACPI: FACP 77E91BFA, 0074 (r1 GATEWA SYSTEM   20061127 ATI     F4240)
[    0.000000] ACPI: DSDT 77E8C3CE, 582C (r1 GATEWA SYSTEM   20061127 MSFT  100000E)
[    0.000000] ACPI: FACS 77E92FC0, 0040
[    0.000000] ACPI: SSDT 77E91C6E, 0182 (r1 GATEWA SYSTEM   20061127  LTP        1)
[    0.000000] ACPI: APIC 77E91DF0, 005E (r1 GATEWA SYSTEM   20061127  LTP        0)
[    0.000000] ACPI: MCFG 77E91E4E, 003C (r1 GATEWA SYSTEM   20061127  LTP        0)
[    0.000000] ACPI: SLIC 77E91E8A, 0176 (r1 GATEWA SYSTEM   20061127  LTP        0)
[    0.000000] Entering add_active_range(0, 0, 157) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 491136) 1 entries of 256 used
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   DMA32        4096 ->  1048576
[    0.000000]   Normal    1048576 ->  1048576
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0:        0 ->      157
[    0.000000]     0:      256 ->   491136
[    0.000000] On node 0 totalpages: 491037
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 2093 pages reserved
[    0.000000]   DMA zone: 1848 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 6658 pages used for memmap
[    0.000000]   DMA32 zone: 480382 pages, LIFO batch:31
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] ATI board detected. Disabling timer routing over 8254.
[    0.000000] ACPI: PM-Timer IO Port: 0x8008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] Processor #0 (Bootup-CPU)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] Processor #1
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level)
[    0.000000] Setting APIC routing to flat
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] swsusp: Registered nosave memory region: 000000000009d000 - 000000000009e000
[    0.000000] swsusp: Registered nosave memory region: 000000000009e000 - 00000000000a0000
[    0.000000] swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000d2000
[    0.000000] swsusp: Registered nosave memory region: 00000000000d2000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:60000000)
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] PERCPU: Allocating 423400 bytes of per cpu data
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 482230
[    0.000000] Kernel command line: BOOT_IMAGE=2.6.24.3-4mnbcustom root=/dev/hda5 resume=/dev/hda6 maxcpus=2
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[    0.000000] TSC calibrated against PM_TIMER
[   17.784534] Marking TSC unstable due to TSCs unsynchronized
[   17.784537] time.c: Detected 1596.007 MHz processor.
[   17.785503] Console: colour VGA+ 80x25
[   17.785511] console [tty0] enabled
[   17.790094] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[   17.790178] ... MAX_LOCKDEP_SUBCLASSES:    8
[   17.790240] ... MAX_LOCK_DEPTH:          30
[   17.790301] ... MAX_LOCKDEP_KEYS:        2048
[   17.790363] ... CLASSHASH_SIZE:           1024
[   17.790426] ... MAX_LOCKDEP_ENTRIES:     8192
[   17.790489] ... MAX_LOCKDEP_CHAINS:      16384
[   17.790551] ... CHAINHASH_SIZE:          8192
[   17.790613]  memory used by lock dependency info: 1712 kB
[   17.790675]  per task-struct memory footprint: 2160 bytes
[   17.790737] ------------------------
[   17.790798] | Locking API testsuite:
[   17.790858] ----------------------------------------------------------------------------
[   17.790940]                                  | spin |wlock |rlock |mutex | wsem | rsem |
[   17.791025]   --------------------------------------------------------------------------
[   17.791114]                      A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.792641]                  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.794165]              A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.795773]              A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.797372]          A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.799061]          A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.800738]          A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.802431]                     double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.803886]                   initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.805358]                  bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
[   17.806889]   --------------------------------------------------------------------------
[   17.806974]               recursive read-lock:             |  ok  |             |  ok  |
[   17.807621]            recursive read-lock #2:             |  ok  |             |  ok  |
[   17.808285]             mixed read-write-lock:             |  ok  |             |  ok  |
[   17.808940]             mixed write-read-lock:             |  ok  |             |  ok  |
[   17.809594]   --------------------------------------------------------------------------
[   17.809678]      hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[   17.810448]      soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[   17.811238]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[   17.812007]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[   17.812780]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[   17.813551]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[   17.814323]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[   17.815105]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[   17.815878]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[   17.816648]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[   17.817420]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[   17.818239]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[   17.819042]     hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[   17.819842]     soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[   17.820646]     hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[   17.821460]     soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[   17.822262]     hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[   17.823053]     soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[   17.823848]     hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[   17.824638]     soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[   17.825420]     hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[   17.826213]     soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[   17.827008]     hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[   17.827816]     soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[   17.828615]     hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[   17.829406]     soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[   17.830205]     hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[   17.830998]     soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[   17.831811]     hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[   17.832599]     soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[   17.833390]     hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[   17.834182]     soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[   17.834995]     hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[   17.835781]     soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
[   17.836572]       hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
[   17.837366]       soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
[   17.838180]       hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
[   17.838975]       soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
[   17.839778]       hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
[   17.840573]       soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
[   17.841392]       hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
[   17.842178]       soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
[   17.842973]       hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
[   17.843767]       soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
[   17.844582]       hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
[   17.845368]       soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
[   17.846164]       hard-irq read-recursion/123:  ok  |
[   17.846499]       soft-irq read-recursion/123:  ok  |
[   17.846832]       hard-irq read-recursion/132:  ok  |
[   17.847164]       soft-irq read-recursion/132:  ok  |
[   17.847497]       hard-irq read-recursion/213:  ok  |
[   17.847844]       soft-irq read-recursion/213:  ok  |
[   17.848176]       hard-irq read-recursion/231:  ok  |
[   17.848509]       soft-irq read-recursion/231:  ok  |
[   17.848844]       hard-irq read-recursion/312:  ok  |
[   17.849176]       soft-irq read-recursion/312:  ok  |
[   17.849510]       hard-irq read-recursion/321:  ok  |
[   17.849842]       soft-irq read-recursion/321:  ok  |
[   17.850178] -------------------------------------------------------
[   17.850243] Good, all 218 testcases passed! |
[   17.850304] ---------------------------------
[   17.851498] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   17.853228] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[   17.853871] Checking aperture...
[   17.854313] CPU 0: aperture @ a822000000 size 32 MB
[   17.854377] Aperture too small (32 MB)
[   17.866487] No AGP bridge found
[   18.027900] Memory: 1921804k/1964544k available (2212k kernel code, 41604k reserved, 1143k data, 612k init)
[   18.110848] Calibrating delay using timer specific routine.. 3196.52 BogoMIPS (lpj=5325645)
[   18.111155] Mount-cache hash table entries: 256
[   18.111876] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   18.111942] CPU: L2 Cache: 512K (64 bytes/line)
[   18.112007] CPU: Physical Processor ID: 0
[   18.112068] CPU: Processor Core ID: 0
[   18.112163] lockdep: not fixing up alternatives.
[   18.112490] Early unpacking initramfs... done
[   18.214115] Freeing initrd memory: 2192k freed
[   18.215582] ACPI: Core revision 20070126
[   18.215821] ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
[   18.721217] Using local APIC timer interrupts.
[   18.783884] APIC timer calibration result 12468802
[   18.783887] Detected 12.468 MHz APIC timer.
[   18.784493] lockdep: not fixing up alternatives.
[   18.784680] Booting processor 1/2 APIC 0x1
[   18.795577] Initializing CPU#1
[   18.877966] Calibrating delay using timer specific routine.. 3193.03 BogoMIPS (lpj=5320055)
[   18.877973] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   18.877975] CPU: L2 Cache: 512K (64 bytes/line)
[   18.877978] CPU: Physical Processor ID: 0
[   18.877980] CPU: Processor Core ID: 1
[   18.878096] AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping 02
[   18.878123] AMD C1E detected late. Force timer broadcast.
[   18.877436] Brought up 2 CPUs
[   18.877508] CPU0 attaching sched-domain:
[   18.877511]  domain 0: span 3
[   18.877513]   groups: 1 2
[   18.877517] CPU1 attaching sched-domain:
[   18.877519]  domain 0: span 3
[   18.877520]   groups: 2 1
[   18.878248] net_namespace: 152 bytes
[   18.879115] NET: Registered protocol family 16
[   18.879637] ACPI: bus type pci registered
[   18.880284] PCI: Using MMCONFIG at e0000000 - e07fffff
[   18.880408] PCI: No mmconfig possible on device 00:18
[   18.883812] ACPI: EC: Look up EC in DSDT
[   18.886881] ACPI: Interpreter enabled
[   18.886947] ACPI: (supports S0 S3 S4 S5)
[   18.887201] ACPI: Using IOAPIC for interrupt routing
[   18.894615] ACPI: EC: non-query interrupt received, switching to interrupt mode
[   18.896162] ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
[   18.896231] ACPI: EC: driver started in interrupt mode
[   18.896407] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   18.898490] PCI: Transparent bridge - 0000:00:14.4
[   18.898689] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   18.898994] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PB4_._PRT]
[   18.899200] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P_._PRT]
[   18.899349] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[   18.904158] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.904826] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.905491] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.906146] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.906799] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.907450] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.908103] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.908825] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.909480] ACPI: PCI Interrupt Link [LNKU] (IRQs 3 4 5 7 10 11) *0, disabled.
[   18.910255] Linux Plug and Play Support v0.97 (c) Adam Belay
[   18.910394] pnp: PnP ACPI init
[   18.910488] ACPI: bus type pnp registered
[   18.914361] pnp: PnP ACPI: found 10 devices
[   18.914429] ACPI: ACPI bus type pnp unregistered
[   18.914854] PCI: Using ACPI for IRQ routing
[   18.914921] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   18.925443] DMAR:No DMAR devices found
[   18.925876] ACPI: RTC can wake from S4
[   18.938792] system 00:01: iomem range 0xe0000000-0xefffffff could not be reserved
[   18.938879] system 00:01: iomem range 0xfec00000-0xfec00fff could not be reserved
[   18.938964] system 00:01: iomem range 0xfee00000-0xfee00fff could not be reserved
[   18.939067] system 00:08: ioport range 0x1080-0x1080 has been reserved
[   18.939134] system 00:08: ioport range 0x220-0x22f has been reserved
[   18.939204] system 00:08: ioport range 0x40b-0x40b has been reserved
[   18.939270] system 00:08: ioport range 0x4d0-0x4d1 has been reserved
[   18.939337] system 00:08: ioport range 0x4d6-0x4d6 has been reserved
[   18.939403] system 00:08: ioport range 0x530-0x537 has been reserved
[   18.939468] system 00:08: ioport range 0xc00-0xc01 has been reserved
[   18.939534] system 00:08: ioport range 0xc14-0xc14 has been reserved
[   18.939601] system 00:08: ioport range 0xc50-0xc52 has been reserved
[   18.939666] system 00:08: ioport range 0xc6c-0xc6c has been reserved
[   18.939732] system 00:08: ioport range 0xc6f-0xc6f has been reserved
[   18.939798] system 00:08: ioport range 0xcd4-0xcd5 has been reserved
[   18.939865] system 00:08: ioport range 0xcd6-0xcd7 has been reserved
[   18.939931] system 00:08: ioport range 0xcd8-0xcdf has been reserved
[   18.939997] system 00:08: ioport range 0x8000-0x805f has been reserved
[   18.940063] system 00:08: ioport range 0xf40-0xf47 has been reserved
[   18.940129] system 00:08: ioport range 0x87f-0x87f has been reserved
[   18.940205] system 00:09: iomem range 0xe0000-0xfffff could not be reserved
[   18.940272] system 00:09: iomem range 0xfff00000-0xffffffff could not be reserved
[   18.940359] system 00:09: iomem range 0x0-0xfff could not be reserved
[   18.941700] PCI: Bridge: 0000:00:01.0
[   18.941765]   IO window: 9000-9fff
[   18.941829]   MEM window: c0100000-c01fffff
[   18.941893]   PREFETCH window: c8000000-cfffffff
[   18.941958] PCI: Bridge: 0000:00:04.0
[   18.942020]   IO window: a000-afff
[   18.941346] Time: acpi_pm clocksource has been installed.
[   18.941417] Clockevents: could not switch to one-shot mode:<6>  MEM window: c0200000-c02fffff
[   18.942174]   PREFETCH window: disabled.
[   18.942196] PCI: Bus 6, cardbus bridge: 0000:05:09.0
[   18.942198]   IO window: 00001400-000014ff
[   18.942206]   IO window: 00001800-000018ff
[   18.942213]   PREFETCH window: 88000000-8bffffff
[   18.942221]   MEM window: 8c000000-8fffffff
[   18.942229] PCI: Bridge: 0000:00:14.4
[   18.942231]   IO window: disabled.
[   18.942242]   MEM window: c0300000-c03fffff
[   18.942249]   PREFETCH window: disabled.
[   18.942283] PCI: Setting latency timer of device 0000:00:04.0 to 64
[   18.942330] ACPI: PCI Interrupt 0000:05:09.0[A] -> GSI 20 (level, low) -> IRQ 20
[   18.942257]  lapic is not functional.
[   18.942320] Could not switch to high resolution mode on CPU 0
[   18.943172] NET: Registered protocol family 2
[   18.945365] Clockevents: could not switch to one-shot mode: lapic is not functional.
[   18.945491] Could not switch to high resolution mode on CPU 1
[   18.978824] IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
[   18.979811] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[   18.982319] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes)
[   18.988954] TCP: Hash tables configured (established 262144 bind 65536)
[   18.989059] TCP reno registered
[   19.001409] Initializing RT-Tester: OK
[   19.001595] audit: initializing netlink socket (disabled)
[   19.001699] audit(1206730252.696:1): initialized
[   19.002727] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[   19.002825] io scheduler noop registered
[   19.002888] io scheduler deadline registered (default)
[   19.002956] PCI: MSI quirk detected. MSI deactivated.
[   19.004035] Boot video device is 0000:01:05.0
[   19.004458] PCI: Setting latency timer of device 0000:00:04.0 to 64
[   19.004491] assign_interrupt_mode Found MSI capability
[   19.004560] Allocate Port Service[0000:00:04.0:pcie00]
[   19.064316] Linux agpgart interface v0.102
[   19.064614] PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64 irq 1,12
[   19.067797] serio: i8042 KBD port at 0x60,0x64 irq 1
[   19.067888] serio: i8042 AUX port at 0x60,0x64 irq 12
[   19.068112] mice: PS/2 mouse device common for all mice
[   19.068734] EDAC MC: Ver: 2.1.0 Mar 28 2008
[   19.069110] cpuidle: using governor ladder
[   19.069175] cpuidle: using governor menu
[   19.070125] registered taskstats version 1
[   19.070428] Freeing unused kernel memory: 612k freed
[   19.071648] Write protecting the kernel read-only data: 860k
[   19.364367] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   19.364443] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[   19.365310] ATIIXP: IDE controller (0x1002:0x4376 rev 0x80) at  PCI slot 0000:00:14.1
[   19.365424] ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16
[   19.365557] ATIIXP: not 100% native mode: will probe irqs later
[   19.365631]     ide0: BM-DMA at 0x8410-0x8417, BIOS settings: hda:DMA, hdb:DMA
[   19.365806] ATIIXP: simplex device: DMA disabled
[   19.365868] ide1: ATIIXP Bus-Master DMA disabled (BIOS)
[   19.365935] Probing IDE interface ide0...
[   19.441573] Clockevents: could not switch to one-shot mode:<6>Clockevents: could not switch to one-shot mode: lapic is not functional.
[   19.440842] Could not switch to high resolution mode on CPU 0
[   19.441775]  lapic is not functional.
[   19.441839] Could not switch to high resolution mode on CPU 1
[   19.650333] Synaptics Touchpad, model: 1, fw: 5.9, id: 0x23aeb3, caps: 0xa04713/0x10008
[   19.682925] input: SynPS/2 Synaptics TouchPad as /class/input/input0
[   19.726738] input: AT Translated Set 2 keyboard as /class/input/input1
[   20.120661] hdb: PHILIPS DVD+/-RW SDVD8820, ATAPI CD/DVD-ROM drive
[   20.440374] hda: ST9160821A, ATA DISK drive
[   20.440487] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[   20.440726] hda: UDMA/100 mode selected
[   20.441066] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[   20.441342] hdb: UDMA/33 mode selected
[   20.445837] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[   20.449747] Probing IDE interface ide1...
[   21.007724] usbcore: registered new interface driver usbfs
[   21.007932] usbcore: registered new interface driver hub
[   21.008057] usbcore: registered new device driver usb
[   21.009686] ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 19
[   21.009987] ehci_hcd 0000:00:13.2: EHCI Host Controller
[   21.010921] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1
[   21.011104] ehci_hcd 0000:00:13.2: irq 19, io mem 0xc0006000
[   21.019435] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   21.020137] usb usb1: configuration #1 chosen from 1 choice
[   21.020403] hub 1-0:1.0: USB hub found
[   21.020534] hub 1-0:1.0: 8 ports detected
[   21.128164] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[   21.128241] ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 19
[   21.128550] ohci_hcd 0000:00:13.0: OHCI Host Controller
[   21.128820] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 2
[   21.128933] ohci_hcd 0000:00:13.0: irq 19, io mem 0xc0004000
[   21.180383] usb usb2: configuration #1 chosen from 1 choice
[   21.180533] hub 2-0:1.0: USB hub found
[   21.180612] hub 2-0:1.0: 4 ports detected
[   21.283550] ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 19
[   21.283846] ohci_hcd 0000:00:13.1: OHCI Host Controller
[   21.284067] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 3
[   21.284178] ohci_hcd 0000:00:13.1: irq 19, io mem 0xc0005000
[   21.336936] usb usb3: configuration #1 chosen from 1 choice
[   21.337087] hub 3-0:1.0: USB hub found
[   21.337166] hub 3-0:1.0: 4 ports detected
[   21.349172] usb 1-6: new high speed USB device using ehci_hcd and address 2
[   21.373675] usb 1-6: configuration #1 chosen from 1 choice
[   21.446606] USB Universal Host Controller Interface driver v3.0
[   21.465727] hda: max request size: 512KiB
[   21.465960] hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63
[   21.466261] hda: cache flushes supported
[   21.466739]  hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 >
[   21.542425] Probing IDE interface ide1...
[   22.404335] swsusp: Marking nosave pages: 000000000009d000 - 0000000000100000
[   22.404408] swsusp: Basic memory bitmaps created
[   22.415592] swsusp: Basic memory bitmaps freed
[   22.508819] kjournald starting.  Commit interval 5 seconds
[   22.510121] EXT3-fs: mounted filesystem with ordered data mode.
[   23.727783] NET: Registered protocol family 1
[   27.639497] input: Power Button (FF) as /class/input/input2
[   27.689746] ACPI: Power Button (FF) [PWRF]
[   27.689921] input: Lid Switch as /class/input/input3
[   27.717934] ACPI: Lid Switch [LID]
[   27.718083] input: Sleep Button (CM) as /class/input/input4
[   27.750370] ACPI: Sleep Button (CM) [SLPB]
[   27.750493] input: Power Button (CM) as /class/input/input5
[   27.806982] ACPI: Power Button (CM) [PWRB]
[   27.807887] ACPI: AC Adapter [ACAD] (on-line)
[   27.825325] ACPI: Battery Slot [BAT1] (battery present)
[   27.858141] ACPI: Processor [CPU0] (supports 8 throttling states)
[   28.184421] ACPI: Thermal Zone [THRM] (66 C)
[   28.433116] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[   28.433134] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   28.433336] sky2 0000:02:00.0: v1.20 addr 0xc0200000 irq 16 Yukon-FE (0xb7) rev 1
[   28.434117] sky2 eth0: addr 00:e0:b8:ba:33:39
[   28.483515] input: PC Speaker as /class/input/input6
[   28.710151] piix4_smbus 0000:00:14.0: Found 0000:00:14.0 device
[   29.284431] hdb: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
[   29.284442] Uniform CD-ROM driver Revision: 3.20
[   29.523039] ACPI: PCI Interrupt 0000:05:09.1[B] -> GSI 21 (level, low) -> IRQ 21
[   29.552232] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[   29.552277] rtc0: alarms up to one month
[   29.574042] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[21]  MMIO=[c0305000-c03057ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[   29.786925] Yenta: CardBus bridge found at 0000:05:09.0 [107b:0367]
[   29.786959] Yenta: Using CSCINT to route CSC interrupts to PCI
[   29.786961] Yenta: Routing CardBus interrupts to PCI
[   29.786969] Yenta TI: socket 0000:05:09.0, mfunc 0x01ac1b22, devctl 0x64
[   30.022650] Yenta: ISA IRQ mask 0x0ef8, PCI irq 20
[   30.022656] Socket status: 30000006
[   30.022662] pcmcia: parent PCI bridge Memory window: 0xc0300000 - 0xc03fffff
[   30.251428] ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16
[   30.840437] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00e0b80367022549]
[   31.824815] loop: module loaded
[   32.024944] Non-volatile memory driver v1.2
[   32.152335] ACPI: PCI Interrupt 0000:05:09.2[A] -> GSI 20 (level, low) -> IRQ 20
[   32.281660] powernow-k8: Found 1 AMD Turion(tm) 64 X2 Mobile Technology TL-52 processors (2 cpu cores) (version 2.20.00)
[   32.282635] powernow-k8:    0 : fid 0x8 (1600 MHz), vid 0x12
[   32.282641] powernow-k8:    1 : fid 0x0 (800 MHz), vid 0x14
[   35.529956] floppy0: no floppy controllers found
[   35.853626] SCSI subsystem initialized
[   35.958647] libata version 3.00 loaded.
[   37.071929] EXT3 FS on hda5, internal journal
[   39.395095] kjournald starting.  Commit interval 5 seconds
[   39.396171] EXT3 FS on hda8, internal journal
[   39.396188] EXT3-fs: mounted filesystem with ordered data mode.
[   39.444592] kjournald starting.  Commit interval 5 seconds
[   39.445601] EXT3 FS on hda7, internal journal
[   39.445616] EXT3-fs: mounted filesystem with ordered data mode.
[   39.649351] NTFS driver 2.1.29 [Flags: R/O DEBUG MODULE].
[   39.738469] NTFS volume version 3.1.
[   40.019102] kjournald starting.  Commit interval 5 seconds
[   40.019849] EXT3 FS on loop0, internal journal
[   40.019865] EXT3-fs: mounted filesystem with ordered data mode.
[   41.478102] Adding 4088500k swap on /dev/hda6.  Priority:-1 extents:1 across:4088500k
[   43.851369] hda: UDMA/100 mode selected
[   46.320488] ip_tables: (C) 2000-2006 Netfilter Core Team
[   55.528333] NET: Registered protocol family 17
[   57.135382] sky2 eth0: enabling interface
[  122.972218] vmmon: module license 'unspecified' taints kernel.
[  122.974851] [3619]: VMCI: Driver initialized.
[  122.974899] [3619]: Module vmmon: registered with major=10 minor=165
[  122.974921] [3619]: Module vmmon: initialized
[  126.359627] /dev/vmnet: open called by PID 3732 (vmnet-bridge)
[  126.359643] /dev/vmnet: hub 0 does not exist, allocating memory.
[  126.359658] /dev/vmnet: port on hub 0 successfully opened
[  126.359676] bridge-eth0: enabling the bridge
[  126.359683] bridge-eth0: up
[  126.359686] bridge-eth0: already up
[  126.359689] bridge-eth0: attached
[  127.314630] /dev/vmnet: open called by PID 3757 (vmnet-netifup)
[  127.314646] /dev/vmnet: hub 1 does not exist, allocating memory.
[  127.314664] /dev/vmnet: port on hub 1 successfully opened
[  128.158318] /dev/vmnet: open called by PID 3756 (vmnet-dhcpd)
[  128.158341] /dev/vmnet: port on hub 1 successfully opened
[  128.180544] /dev/vmnet: open called by PID 3786 (vmnet-netifup)
[  128.180656] /dev/vmnet: hub 8 does not exist, allocating memory.
[  128.180715] /dev/vmnet: port on hub 8 successfully opened
[  128.526803] /dev/vmnet: open called by PID 3800 (vmnet-dhcpd)
[  128.526826] /dev/vmnet: port on hub 8 successfully opened
[  129.385046] /dev/vmnet: open called by PID 3811 (vmnet-natd)
[  129.385066] /dev/vmnet: port on hub 8 successfully opened
[  165.019373] sky2 eth0: disabling interface
[  165.065287] bridge-eth0: disabling the bridge
[  165.092618] bridge-eth0: down
[  165.093267] sky2 eth0: enabling interface
[  165.117786] bridge-eth0: enabling the bridge
[  165.118021] bridge-eth0: up
[  166.220752] powertweakd[3894] general protection rip:2b9fbf3d92b8 rsp:7fffece405e8 error:0
[  614.594547] CPU0 attaching NULL sched-domain.
[  614.594556] CPU1 attaching NULL sched-domain.
[  614.613208] CPU0 attaching sched-domain:
[  614.613213]  domain 0: span 3
[  614.613216]   groups: 1 2
[  614.613220] CPU1 attaching sched-domain:
[  614.613222]  domain 0: span 3
[  614.613224]   groups: 2 1
[  615.279282] Clocksource tsc unstable (delta = -123240263 ns)
[  636.946958] phy0: Selected rate control algorithm 'simple'
[  637.024961] phy0: hwaddr 00:c0:a8:ca:12:fd, rtl8187 V1 + rtl8225z2
[  637.024995] usbcore: registered new interface driver rtl8187
[  646.737927] wlan0: Initial auth_alg=0
[  646.737935] wlan0: authenticate with AP 00:18:3f:7f:bc:91
[  646.738902] wlan0: RX authentication from 00:18:3f:7f:bc:91 (alg=0 transaction=2 status=0)
[  646.738907] wlan0: authenticated
[  646.738909] wlan0: associate with AP 00:18:3f:7f:bc:91
[  646.739896] wlan0: RX AssocResp from 00:18:3f:7f:bc:91 (capab=0x11 status=0 aid=11)
[  646.739901] wlan0: associated
[  646.739906] wlan0: CTS protection enabled (BSSID=00:18:3f:7f:bc:91)
[  655.107496] Linux video capture interface: v2.00
[  655.114071] Video Technology Magazine Virtual Video Capture Board successfully loaded.
[  665.465701] vivi: open called (minor=0)
[  677.931020] vivi: open called (minor=0)
[  686.961359] vivi: open called (minor=0)
[  700.881962] vivi: open called (minor=0)
[  705.709878] general protection fault: 0000 [1] PREEMPT SMP 
[  705.709885] CPU 0 
[  705.709888] Modules linked in: vivi compat_ioctl32 videodev v4l1_compat videobuf_vmalloc videobuf_core arc4 ecb blkcipher cryptomgr crypto_algapi rtl8187 mac80211 cfg80211 eeprom_93cx6 vmnet(P) vmblock vmmon(P) af_packet snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device iptable_filter ip_tables x_tables binfmt_misc nls_cp437 vfat fat nls_cp850 ntfs nls_base pata_atiixp libata scsi_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave powernow_k8 tifm_7xx1 nvram cryptoloop loop mmc_block tifm_sd mmc_core tifm_core snd_pcm_oss pcmcia snd_mixer_oss snd_hda_intel snd_pcm snd_timer yenta_socket snd_page_alloc snd_hwdep rtc_cmos rsrc_nonstatic ohci1394 snd ide_cd rtc_core pcmcia_core ieee1394 k8temp cdrom i2c_piix4 rtc_lib hwmon pcspkr sky2 i2c_core thermal soundcore processor battery ac button bitrev crc32 evdev unix ide_generic ide_disk ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd usbcore atiixp ide_core
[  705.709967] Pid: 5583, comm: vivi Tainted: P        2.6.24.3-4mnbcustom #4
[  705.709970] RIP: 0010:[<ffffffff885536cc>]  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  705.709980] RSP: 0018:ffff810058039e30  EFLAGS: 00010246
[  705.709983] RAX: ffff81005968cc00 RBX: 01c0055b0007033b RCX: ffff81005953b800
[  705.709986] RDX: ffffffff88553652 RSI: 0000000000000001 RDI: 0000000000000001
[  705.709988] RBP: 0000000000096000 R08: 0000000000000002 R09: 0000000000000000
[  705.709991] R10: ffffffff80253d69 R11: 0000000000000001 R12: 0000000000000140
[  705.709994] R13: ffff810059649000 R14: ffff8100773f9c80 R15: 0000000000000140
[  705.709997] FS:  00002ac9a2490a00(0000) GS:ffffffff80547000(0000) knlGS:0000000000000000
[  705.710000] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  705.710003] CR2: 000000000090bdd0 CR3: 0000000065d03000 CR4: 00000000000006e0
[  705.710005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  705.710008] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  705.710011] Process vivi (pid: 5583, threadinfo ffff810058038000, task ffff81005968cc00)
[  705.710014] Stack:  0000000000000000 ffff810059649080 0000000000000140 0000014102b32e00
[  705.710021]  ffff8100773f9c90 ffff8100773f9d58 ffff81005953b800 ffff8100773f9c80
[  705.710027]  01c0055b00070393 0000000000000009 0000000000000282 ffff810068890c00
[  705.710032] Call Trace:
[  705.710052]  [<ffffffff80233eb0>] default_wake_function+0x0/0x10
[  705.710061]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  705.710068]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  705.710076]  [<ffffffff8025379b>] kthread+0x4b/0x80
[  705.710083]  [<ffffffff8020d428>] child_rip+0xa/0x12
[  705.710089]  [<ffffffff802366d7>] finish_task_switch+0x57/0xe0
[  705.710094]  [<ffffffff8020cb13>] restore_args+0x0/0x30
[  705.710098]  [<ffffffff80253897>] kthreadd+0xc7/0x150
[  705.710107]  [<ffffffff80253750>] kthread+0x0/0x80
[  705.710111]  [<ffffffff8020d41e>] child_rip+0x0/0x12
[  705.710116] 
[  705.710117] 
[  705.710117] Code: 48 8b 43 50 44 8b 98 8c 03 00 00 45 85 db 7e 1a 48 8b 54 24 
[  705.710131] RIP  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  705.710136]  RSP <ffff810058039e30>
[  705.710142] ---[ end trace 4d468849a38ba2e0 ]---
[  710.814272] vivi: open called (minor=0)
[  934.913481] general protection fault: 0000 [2] PREEMPT SMP 
[  934.913489] CPU 0 
[  934.913492] Modules linked in: vivi compat_ioctl32 videodev v4l1_compat videobuf_vmalloc videobuf_core arc4 ecb blkcipher cryptomgr crypto_algapi rtl8187 mac80211 cfg80211 eeprom_93cx6 vmnet(P) vmblock vmmon(P) af_packet snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device iptable_filter ip_tables x_tables binfmt_misc nls_cp437 vfat fat nls_cp850 ntfs nls_base pata_atiixp libata scsi_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave powernow_k8 tifm_7xx1 nvram cryptoloop loop mmc_block tifm_sd mmc_core tifm_core snd_pcm_oss pcmcia snd_mixer_oss snd_hda_intel snd_pcm snd_timer yenta_socket snd_page_alloc snd_hwdep rtc_cmos rsrc_nonstatic ohci1394 snd ide_cd rtc_core pcmcia_core ieee1394 k8temp cdrom i2c_piix4 rtc_lib hwmon pcspkr sky2 i2c_core thermal soundcore processor battery ac button bitrev crc32 evdev unix ide_generic ide_disk ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd usbcore atiixp ide_core
[  934.913573] Pid: 5566, comm: vivi Tainted: P      D 2.6.24.3-4mnbcustom #4
[  934.913576] RIP: 0010:[<ffffffff885536cc>]  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  934.913588] RSP: 0018:ffff810063eb1e30  EFLAGS: 00010246
[  934.913590] RAX: ffff8100580ceb40 RBX: 0420000222e20012 RCX: ffff8100637bf400
[  934.913593] RDX: ffffffff88553652 RSI: 0000000000000001 RDI: 0000000000000001
[  934.913596] RBP: ffff8100773f9cd8 R08: 0000000000000002 R09: 0000000000000000
[  934.913599] R10: ffffffff80253d69 R11: 0000000000000001 R12: 0000000000000140
[  934.913602] R13: ffff810059649800 R14: ffff8100773f9c80 R15: 0000000000000140
[  934.913605] FS:  00002ac4a8b4b730(0000) GS:ffffffff80547000(0000) knlGS:0000000000000000
[  934.913608] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  934.913610] CR2: 00002b38780da350 CR3: 000000006f8d1000 CR4: 00000000000006e0
[  934.913613] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  934.913616] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  934.913619] Process vivi (pid: 5566, threadinfo ffff810063eb0000, task ffff8100580ceb40)
[  934.913621] Stack:  0000000000000000 ffff810059649880 0000000000000140 0000014102acae00
[  934.913629]  ffff8100773f9c90 ffff8100773f9d58 ffff8100637bf400 ffff8100773f9c80
[  934.913635]  0420000222e2006a 0000000000000009 0000000000000282 ffff810068890c00
[  934.913640] Call Trace:
[  934.913660]  [<ffffffff80233eb0>] default_wake_function+0x0/0x10
[  934.913669]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  934.913676]  [<ffffffff885535f0>] :vivi:vivi_thread+0x0/0x760
[  934.913685]  [<ffffffff8025379b>] kthread+0x4b/0x80
[  934.913692]  [<ffffffff8020d428>] child_rip+0xa/0x12
[  934.913698]  [<ffffffff802366d7>] finish_task_switch+0x57/0xe0
[  934.913704]  [<ffffffff8020cb13>] restore_args+0x0/0x30
[  934.913707]  [<ffffffff80253897>] kthreadd+0xc7/0x150
[  934.913715]  [<ffffffff80253750>] kthread+0x0/0x80
[  934.913720]  [<ffffffff8020d41e>] child_rip+0x0/0x12
[  934.913724] 
[  934.913725] 
[  934.913726] Code: 48 8b 43 50 44 8b 98 8c 03 00 00 45 85 db 7e 1a 48 8b 54 24 
[  934.913739] RIP  [<ffffffff885536cc>] :vivi:vivi_thread+0xdc/0x760
[  934.913745]  RSP <ffff810063eb1e30>
[  934.913751] ---[ end trace 4d468849a38ba2e0 ]---

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 1 of 9] soc_camera: Introduce a spinlock for use with videobuf

[Guennadi Liakhovetski]

On Fri, 28 Mar 2008, Brandon Philips wrote:

> # HG changeset patch
> # User Brandon Philips <brandon@ifup.org>
> # Date 1206699276 25200
> # Node ID 7876c2bc2446dc3e3630e7a30a76f50874116cf1
> # Parent  1df4f66ca1fc98ccad4c8377484a56adaf23e49d
> soc_camera: Introduce a spinlock for use with videobuf
> 
> Videobuf will require all drivers to use a spinlock to protect the IRQ queue.
> Introduce this lock for the SOC/PXA drivers.
> 
> Signed-off-by: Brandon Philips <bphilips@suse.de>
> CC: Guennadi Liakhovetski <kernel@pengutronix.de>

I have a couple of questions to this one.

> diff --git a/linux/drivers/media/video/pxa_camera.c b/linux/drivers/media/video/pxa_camera.c
> --- a/linux/drivers/media/video/pxa_camera.c
> +++ b/linux/drivers/media/video/pxa_camera.c
> @@ -108,8 +108,6 @@ struct pxa_camera_dev {
>  	unsigned long		platform_mclk_10khz;
>  
>  	struct list_head	capture;
> -
> -	spinlock_t		lock;
>  
>  	struct pxa_buffer	*active;
>  };

You see, here the spinlock was per camera-bus, i.e., it would be common 
for all cameras on this bus and all open /dev/videoX instances and just 
one per IRQ "thread" (in case of shared IRQs). If you want to make it 
accessible globally, also in soc-camera core but preserve this locality, 
we could put it into "struct soc_camera_host".

> @@ -714,6 +714,7 @@ static int soc_camera_probe(struct devic
>  	if (ret >= 0) {
>  		const struct v4l2_queryctrl *qctrl;
>  
> +		spin_lock_init(&icd->irqlock);
>  		qctrl = soc_camera_find_qctrl(icd->ops, V4L2_CID_GAIN);
>  		icd->gain = qctrl ? qctrl->default_value : (unsigned short)~0;
>  		qctrl = soc_camera_find_qctrl(icd->ops, V4L2_CID_EXPOSURE);

Initialization - wouldn't it be enough to initialize it once on 
allocation? In your case if we really put it into struct 
soc_camera_device, in soc_camera_device_register(). Probe can be called 
multiple times for one device, e.g., if the bus gets unloaded and loaded 
again.

> diff --git a/linux/include/media/soc_camera.h b/linux/include/media/soc_camera.h
> --- a/linux/include/media/soc_camera.h
> +++ b/linux/include/media/soc_camera.h
> @@ -19,6 +19,7 @@ struct soc_camera_device {
>  	struct list_head list;
>  	struct device dev;
>  	struct device *control;
> +	spinlock_t irqlock;
>  	unsigned short width;		/* Current window */
>  	unsigned short height;		/* sizes */
>  	unsigned short x_min;		/* Camera capabilities */

Now to where to put it. I see at least three possibilities:

1. as you put it in struct soc_camera_device. This means one spinlock per 
camera device.

2. in struct soc_camera_file, then it would be one spinlock per open 
/dev/videoX instance and thus per struct videobuf_queue.

3. in struct soc_camera_host, then it is one per camera bus and per IRQ 
thread.

I am not quite sure what this spinlock is supposed to protect. If it is 
protecting the videobuf queue, then, maybe, variant (2) above is correct? 
And then just put initialization in soc_camera_open() right after the 
allocation of a struct soc_camera_file instance?

OTOH, at least the PXA270 hardware needs a more global protection - to 
protect the DMA channel setup. And this is hardware specific. We can just 
assume that (imaginary) systems with multiple camera busses will have an 
own DMA channel per bus and will allow their concurrent onfiguration... 
Maybe we should let the hardware host driver decide on spinlock locality 
and just use whatever it provides?

Thanks
Guennadi
---
Guennadi Liakhovetski

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 1 of 9] soc_camera: Introduce a spinlock for use with videobuf

[Brandon Philips]

On 21:53 Fri 28 Mar 2008, Guennadi Liakhovetski wrote:
> On Fri, 28 Mar 2008, Brandon Philips wrote:
> I have a couple of questions to this one.

Good- I obviously had no way of testing and just took a shot :D

> > @@ -714,6 +714,7 @@ static int soc_camera_probe(struct devic
> >  	if (ret >= 0) {
> >  		const struct v4l2_queryctrl *qctrl;
> >  
> > +		spin_lock_init(&icd->irqlock);
> >  		qctrl = soc_camera_find_qctrl(icd->ops, V4L2_CID_GAIN);
> >  		icd->gain = qctrl ? qctrl->default_value : (unsigned short)~0;
> >  		qctrl = soc_camera_find_qctrl(icd->ops, V4L2_CID_EXPOSURE);
> 
> Initialization - wouldn't it be enough to initialize it once on 
> allocation? In your case if we really put it into struct 
> soc_camera_device, in soc_camera_device_register(). Probe can be called 
> multiple times for one device, e.g., if the bus gets unloaded and loaded 
> again.

Oops, yes it should only happen once per allocation.

> > diff --git a/linux/include/media/soc_camera.h b/linux/include/media/soc_camera.h
> > --- a/linux/include/media/soc_camera.h
> > +++ b/linux/include/media/soc_camera.h
> > @@ -19,6 +19,7 @@ struct soc_camera_device {
> >  	struct list_head list;
> >  	struct device dev;
> >  	struct device *control;
> > +	spinlock_t irqlock;
> >  	unsigned short width;		/* Current window */
> >  	unsigned short height;		/* sizes */
> >  	unsigned short x_min;		/* Camera capabilities */
> 
>
> 2. in struct soc_camera_file, then it would be one spinlock per open 
> /dev/videoX instance and thus per struct videobuf_queue.

This is what should happen.  The spinlock has to protect the struct
videobuf_buffer.queue and should also be held throughout the interrupt
handler as you manipulate the buffer. 

> 3. in struct soc_camera_host, then it is one per camera bus and per IRQ 
> thread.

What do you mean by per IRQ thread?

> I am not quite sure what this spinlock is supposed to protect. If it is 
> protecting the videobuf queue, then, maybe, variant (2) above is correct? 

Yes, I think 2 is correct.

> And then just put initialization in soc_camera_open() right after the 
> allocation of a struct soc_camera_file instance?

I think so.

> OTOH, at least the PXA270 hardware needs a more global protection - to 
> protect the DMA channel setup. And this is hardware specific. We can just 
> assume that (imaginary) systems with multiple camera busses will have an 
> own DMA channel per bus and will allow their concurrent onfiguration... 
> Maybe we should let the hardware host driver decide on spinlock locality 
> and just use whatever it provides?

I don't know enough about the hardware to comment.

Thank You,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Brandon Philips]

> I've opened 3 mplayer windows, reading /dev/video0. I closed the second one and
> opened again. I got an error:

Shouldn't V4L2 devices not be able to stream to multiple applications at
once?  Quoting the spec:

"V4L2 drivers should not support multiple applications reading or
writing the same data stream on a device by copying buffers, time
multiplexing or similar means. This is better handled by a proxy
application in user space. When the driver supports stream sharing
anyway it must be implemented transparently. The V4L2 API does not
specify how conflicts are solved."

How about this patch?

Signed-off-by: Brandon Philips <bphilips@suse.de>

---
 linux/drivers/media/video/vivi.c |   23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

Index: v4l-dvb/linux/drivers/media/video/vivi.c
===================================================================
--- v4l-dvb.orig/linux/drivers/media/video/vivi.c
+++ v4l-dvb/linux/drivers/media/video/vivi.c
@@ -5,9 +5,10 @@
  *      Mauro Carvalho Chehab <mchehab--a.t--infradead.org>
  *      Ted Walther <ted--a.t--enumera.com>
  *      John Sokol <sokol--a.t--videotechnology.com>
- *      Brandon Philips <brandon@ifup.org>
  *      http://v4l.videotechnology.com/
  *
+ * Copyright (c) 2008 by Brandon Philips <bphilips@suse.de>
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the BSD Licence, GNU General Public License
  * as published by the Free Software Foundation; either version 2 of the
@@ -175,6 +176,7 @@ struct vivi_dev {
 	struct list_head           vivi_devlist;
 
 	spinlock_t                 slock;
+	mutex			   mutex;
 
 	int                        users;
 
@@ -960,6 +962,7 @@ static int vivi_open(struct inode *inode
 	struct vivi_dev *dev;
 	struct vivi_fh *fh;
 	int i;
+	int retval;
 
 	printk(KERN_DEBUG "vivi: open called (minor=%d)\n", minor);
 
@@ -969,9 +972,15 @@ static int vivi_open(struct inode *inode
 	return -ENODEV;
 
 found:
-	/* If more than one user, mutex should be added */
+	mutex_lock(&dev->mutex);
 	dev->users++;
 
+	if (dev->users > 1) {
+		dev->users--;
+		retval = -EBUSY;
+		goto unlock;
+	}
+
 	dprintk(dev, 1, "open minor=%d type=%s users=%d\n", minor,
 		v4l2_type_names[V4L2_BUF_TYPE_VIDEO_CAPTURE], dev->users);
 
@@ -979,8 +988,13 @@ found:
 	fh = kzalloc(sizeof(*fh), GFP_KERNEL);
 	if (NULL == fh) {
 		dev->users--;
-		return -ENOMEM;
+		retval = -ENOMEM;
+		goto unlock;
 	}
+unlock:
+	if (retval)
+		return retval;
+	mutex_unlock(&dev->mutex);
 
 	file->private_data = fh;
 	fh->dev      = dev;
@@ -1054,7 +1068,9 @@ static int vivi_close(struct inode *inod
 
 	kfree(fh);
 
+	mutex_lock(&dev->mutex);
 	dev->users--;
+	mutex_unlock(&dev->mutex);
 
 	dprintk(dev, 1, "close called (minor=%d, users=%d)\n",
 		minor, dev->users);
@@ -1166,6 +1182,7 @@ static int __init vivi_init(void)
 
 		/* initialize locks */
 		spin_lock_init(&dev->slock);
+		INIT_MUTEX(&dev->mutex);
 
 		vfd = video_device_alloc();
 		if (NULL == vfd)

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks

[Brandon Philips]

On 15:34 Fri 28 Mar 2008, Mauro Carvalho Chehab wrote:
> This is under copyright (2006), as if you were one of the authors of the
> original driver. Also, I prefer if you add a short line bellow your copyright
> for the job you've done on the driver. Something like:
> 
> + *
> + *  Copyright (c) 2008 by Brandon Philips <brandon@ifup.org>
> + *       - Fix bad locks and cleans up streaming code

Ok, this is fixed in the patch I just sent.  I didn't add the
"changelog" entry below the copyright because the git-log will show what
I did.

> > -static int restart_video_queue(struct vivi_dmaqueue *dma_q)
> > -{
> ...
> > -}
> 
> While the restart and timeout code is not needed on vivi driver, IMO, we should
> keep it, since the main reason for this driver is to be a reference code. 

I couldn't figure out how it worked well enough to fix it.   In
particular code similar to the following is copied around throughout
several drivers and I have no idea what it does:  

@@ -785,45 +657,12 @@ buffer_queue(struct videobuf_queue *vq, 
-       if (!list_empty(&vidq->queued)) {
-               dprintk(dev, 1, "adding vb queue=0x%08lx\n",
-                       (unsigned long)&buf->vb.queue);
-               list_add_tail(&buf->vb.queue, &vidq->queued);
-               buf->vb.state = VIDEOBUF_QUEUED;
-               dprintk(dev, 2, "[%p/%d] buffer_queue - append to queued\n",
-                       buf, buf->vb.i);
-       } else if (list_empty(&vidq->active)) {
-               list_add_tail(&buf->vb.queue, &vidq->active);
-               buf->vb.state = VIDEOBUF_ACTIVE;
-               mod_timer(&vidq->timeout, jiffies+BUFFER_TIMEOUT);
-               dprintk(dev, 2, "[%p/%d] buffer_queue - first active\n",
-                       buf, buf->vb.i);
-
-               vivi_start_thread(vidq);
-       } else {
-               prev = list_entry(vidq->active.prev,
-                                 struct vivi_buffer, vb.queue);
-               if (prev->vb.width  == buf->vb.width  &&
-                   prev->vb.height == buf->vb.height &&
-                   prev->fmt       == buf->fmt) {
-                       list_add_tail(&buf->vb.queue, &vidq->active);
-                       buf->vb.state = VIDEOBUF_ACTIVE;
-                       dprintk(dev, 2,
-                               "[%p/%d] buffer_queue - append to active\n",
-                               buf, buf->vb.i);
-
-               } else {
-                       list_add_tail(&buf->vb.queue, &vidq->queued);
-                       buf->vb.state = VIDEOBUF_QUEUED;
-                       dprintk(dev, 2,
-                               "[%p/%d] buffer_queue - first queued\n",
-                               buf, buf->vb.i);
-               }
-       }

What is the difference between VIDEOBUF_ACTIVE and VIDEOBUF_QUEUED?

> This kind of code is important on real drivers, since the IRQ's may not be called
> for some reason. On cx88 and on saa7134, this happens on several situations[2]. 

Yes, I agree.  But, as I said I couldn't figure it out.

> Without a timeout, the driver will wait forever to receive a buffer.

Well, yes on real hardware.  But, in the case of vivi we can just create
the frames as they are needed.  It is dead simple for a fake device :D

> This task is also needed by tm6000 driver, for the same reasons.

Huh?  What task?

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Vanessa Ezekowitz]

On Saturday 29 March 2008 12:25:59 am Brandon Philips wrote:
> > I've opened 3 mplayer windows, reading /dev/video0. I closed the second one and
> > opened again. I got an error:
> 
> Shouldn't V4L2 devices not be able to stream to multiple applications at
> once?  Quoting the spec:

I'm not exactly on top of current driver development, so I apologize if this response if misdirected.

I disagree with the proposal.

In certain instances, it is desirable for more than one application at a time to read from a stream (provided both are receiving the exact same stream, i.e. without lost/duplicate frames).  The case could be argued that one may want to use a command-line tool set like mjpegtools and ffmpeg to record a stream, while using xawtv to view the stream.  In point of fact, I've done this myself and have found it incredibly handy.

I can see how it would be especially useful on machines with fewer resources than are needed for complex applications like mythtv.

> "V4L2 drivers should not support multiple applications reading or
> writing the same data stream on a device by copying buffers, time
> multiplexing or similar means. This is better handled by a proxy
> application in user space. When the driver supports stream sharing
> anyway it must be implemented transparently. The V4L2 API does not
> specify how conflicts are solved."

Rather that lose a useful capability, why not just extend the spec to allow for it (and the potential error condition of course)?  It's not as though all of the applications prior to this would suddenly stop working once you do.

-- 
"Life is full of happy and sad events.  If you take the time
to concentrate on the former, you'll get further in life."
Vanessa Ezekowitz  <vanessaezekowitz@gmail.com>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Mauro Carvalho Chehab]

On Fri, 28 Mar 2008 22:25:59 -0700
Brandon Philips <brandon@ifup.org> wrote:

> > I've opened 3 mplayer windows, reading /dev/video0. I closed the second one and
> > opened again. I got an error:
> 
> Shouldn't V4L2 devices not be able to stream to multiple applications at
> once?  Quoting the spec:
> 
> "V4L2 drivers should not support multiple applications reading or
> writing the same data stream on a device by copying buffers, time
> multiplexing or similar means. This is better handled by a proxy
> application in user space. When the driver supports stream sharing
> anyway it must be implemented transparently. The V4L2 API does not
> specify how conflicts are solved."
> 
> How about this patch?

The patch is wrong. 

V4L2 API states that it should be possible for a driver to have multiple opens[1]. Most drivers support this. There are two main usages for multiple open:

	1) a driver may open the device for streaming, while another thread or userspace app will open to configure. This is generally the way I use here to test video controls: I open "qv4l2" (under v4l2-apps/util) while streaming. This way, I can test any changes at the driver, without needing to have the feature implemented at the userspace app;

	2) you can see a program with an userspace app and record the stream with another app. Both xawtv and xdtv do this, when you ask for record: They call mencoder, asking it to read from /dev/video0. This way, you'll have the tv app reading, using mmap() or overlay methods, while mencoder is calling read() to receive the stream.

In fact, at least bttv, cx88 and saa7134 allows multiple opens for streaming. They have a limit, due to driver/hardware constraints: You cannot open two transfers of the same type. But you can open one overlay, one mmap() and one read() at the same time.

While I don't have much concerns of not allowing multiple streaming on vivi for the same device (since you can ask vivi to create several different virtual devices, by using "n_devs" modprobe parameter), for sure videobuf should keep supporting this feature, otherwise it will break the other drivers that relies on this feature. Yet, vivi should allow multiple open to allow "panel" applications, to be compliant with V4L2 API.

[1] From V4L2 API doc, rev 0.24:

"1.1.3. Multiple Opens

In general, V4L2 devices can be opened more than once. When this is supported by the driver, users can for example start a "panel" application to change controls like brightness or audio volume, while another application captures video and audio. In other words, panel applications are comparable to an OSS or ALSA audio mixer application. When a device supports multiple functions like capturing and overlay simultaneously, multiple opens allow concurrent use of the device by forked processes or specialized applications.

Multiple opens are optional, although drivers should permit at least concurrent accesses without data exchange, i. e. panel applications. This implies open() can return an EBUSY error code when the device is already in use, as well as ioctl() functions initiating data exchange (namely the VIDIOC_S_FMT ioctl), and the read() and write() functions."

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Brandon Philips]

On 15:35 Mon 31 Mar 2008, Mauro Carvalho Chehab wrote:
> On Fri, 28 Mar 2008 22:25:59 -0700
> Brandon Philips <brandon@ifup.org> wrote:
> 
> > > I've opened 3 mplayer windows, reading /dev/video0. I closed the second one and
> > > opened again. I got an error:
> > 
> > Shouldn't V4L2 devices not be able to stream to multiple applications at
> > once?  Quoting the spec:
> > 
> > "V4L2 drivers should not support multiple applications reading or
> > writing the same data stream on a device by copying buffers, time
> > multiplexing or similar means. This is better handled by a proxy
> > application in user space. When the driver supports stream sharing
> > anyway it must be implemented transparently. The V4L2 API does not
> > specify how conflicts are solved."
> > 
> > How about this patch?
> 
> The patch is wrong. 

The patch fixes the unsafe way vivi is doing multiple opens right now
and I am uninterested in spending anymore time trying to fix up vivi
right now.  If you could fix vivi up that would be great.  

Here are the obvious things I see that would would need to be fixed:

- fillbuff would need a mutex for access to all of the vivi_dev fields
- mv_count would should only be updated by the first user
- vivi_stop_thread should only be called once users reaches 0

Otherwise, this patch will need to go in to keep vivi from blowing up in
2.6.25.

> V4L2 API states that it should be possible for a driver to have
> multiple opens[1]. Most drivers support this. There are two main
> usages for multiple open:
> 
> 	1) a driver may open the device for streaming, while another
> 	thread or userspace app will open to configure. This is
> 	generally the way I use here to test video controls: I open
> 	"qv4l2" (under v4l2-apps/util) while streaming. This way, I can
> 	test any changes at the driver, without needing to have the
> 	feature implemented at the userspace app;
>
> 	2) you can see a program with an userspace app and record the
> 	stream with another app. Both xawtv and xdtv do this, when you
> 	ask for record: They call mencoder, asking it to read from
> 	/dev/video0. This way, you'll have the tv app reading, using
> 	mmap() or overlay methods, while mencoder is calling read() to
> 	receive the stream.

Yes, I know.  But, vivi has no permission control mechanism right now
for differentiating between streaming file handles and control ones.

> While I don't have much concerns of not allowing multiple streaming on
> vivi for the same device (since you can ask vivi to create several
> different virtual devices, by using "n_devs" modprobe parameter), for
> sure videobuf should keep supporting this feature, otherwise it will
> break the other drivers that relies on this feature. 

I think videobuf can handle this case just fine.  But, vivi doesn't do
the proper locking and management to support it.

> Yet, vivi should allow multiple open to allow "panel" applications, to
> be compliant with V4L2 API.

Yes, but someone needs to add the code to support this in vivi.  And
until someone does vivi can only support one open at a time without
crashing.

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks

[Mauro Carvalho Chehab]

On Fri, 28 Mar 2008 22:35:20 -0700
Brandon Philips <brandon@ifup.org> wrote:

> On 15:34 Fri 28 Mar 2008, Mauro Carvalho Chehab wrote:
> > This is under copyright (2006), as if you were one of the authors of the
> > original driver. Also, I prefer if you add a short line bellow your copyright
> > for the job you've done on the driver. Something like:
> > 
> > + *
> > + *  Copyright (c) 2008 by Brandon Philips <brandon@ifup.org>
> > + *       - Fix bad locks and cleans up streaming code
> 
> Ok, this is fixed in the patch I just sent.
Ok.

>  I didn't add the
> "changelog" entry below the copyright because the git-log will show what
> I did.

I prefer if you do so. I had to much stress in the past due to those copyright
messages. I very much prefer to have a very short description, when newer
copyrights are added. This avoids later senseless discussions.

> > While the restart and timeout code is not needed on vivi driver, IMO, we should
> > keep it, since the main reason for this driver is to be a reference code. 
> 
> I couldn't figure out how it worked well enough to fix it.   In
> particular code similar to the following is copied around throughout
> several drivers and I have no idea what it does:  
> 
> @@ -785,45 +657,12 @@ buffer_queue(struct videobuf_queue *vq, 
> -       if (!list_empty(&vidq->queued)) {
> -               dprintk(dev, 1, "adding vb queue=0x%08lx\n",
> -                       (unsigned long)&buf->vb.queue);
> -               list_add_tail(&buf->vb.queue, &vidq->queued);
> -               buf->vb.state = VIDEOBUF_QUEUED;
> -               dprintk(dev, 2, "[%p/%d] buffer_queue - append to queued\n",
> -                       buf, buf->vb.i);
> -       } else if (list_empty(&vidq->active)) {
> -               list_add_tail(&buf->vb.queue, &vidq->active);
> -               buf->vb.state = VIDEOBUF_ACTIVE;
> -               mod_timer(&vidq->timeout, jiffies+BUFFER_TIMEOUT);
> -               dprintk(dev, 2, "[%p/%d] buffer_queue - first active\n",
> -                       buf, buf->vb.i);
> -
> -               vivi_start_thread(vidq);
> -       } else {
> -               prev = list_entry(vidq->active.prev,
> -                                 struct vivi_buffer, vb.queue);
> -               if (prev->vb.width  == buf->vb.width  &&
> -                   prev->vb.height == buf->vb.height &&
> -                   prev->fmt       == buf->fmt) {
> -                       list_add_tail(&buf->vb.queue, &vidq->active);
> -                       buf->vb.state = VIDEOBUF_ACTIVE;
> -                       dprintk(dev, 2,
> -                               "[%p/%d] buffer_queue - append to active\n",
> -                               buf, buf->vb.i);
> -
> -               } else {
> -                       list_add_tail(&buf->vb.queue, &vidq->queued);
> -                       buf->vb.state = VIDEOBUF_QUEUED;
> -                       dprintk(dev, 2,
> -                               "[%p/%d] buffer_queue - first queued\n",
> -                               buf, buf->vb.i);
> -               }
> -       }
> 
> What is the difference between VIDEOBUF_ACTIVE and VIDEOBUF_QUEUED?
I think we can later try to simplify the state machine. From what I understood,
VIDEOBUF_ACTIVE is used to indicate that a driver started, but hasn't yet
received anything.

About the same logic used on vivi is present also on bttv, cx88 and saa7134.

> Well, yes on real hardware.  But, in the case of vivi we can just create
> the frames as they are needed.  It is dead simple for a fake device :D

 
> > This task is also needed by tm6000 driver, for the same reasons.
> 
> Huh?  What task?

I mean the watchdog task. If the device stops sending streams for more than a
certain amount of time [1], a task is wake. This task unblocks the userspace app
(this returns an error to userspace), and tries to restart the streaming.

[1] Since a TV device is expected to receive 25 to 30 frames/sec, In thesis,
you should have a frame on each 33 ms or 40ms. The watchdog is configured to a
higher value (for example, 500ms), since, on real devices, some frames could be
lost due to bad signal.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Mauro Carvalho Chehab]

> > The patch is wrong. 
> 
> The patch fixes the unsafe way vivi is doing multiple opens right now
> and I am uninterested in spending anymore time trying to fix up vivi
> right now.  If you could fix vivi up that would be great.  

If the issue is specific to to vivi, that's ok. I'm just wandering if the
changesets would break a driver for a real device.

Unfortunately, I couldn't test your patch on a real hardware. The hardware I use
here to test PCI boards is currently broken[1].

> > 	2) you can see a program with an userspace app and record the
> > 	stream with another app. Both xawtv and xdtv do this, when you
> > 	ask for record: They call mencoder, asking it to read from
> > 	/dev/video0. This way, you'll have the tv app reading, using
> > 	mmap() or overlay methods, while mencoder is calling read() to
> > 	receive the stream.
> 
> Yes, I know.  But, vivi has no permission control mechanism right now
> for differentiating between streaming file handles and control ones.

What the other drivers do is to implement a small code for this lock. You may
take a look on res_get(), for example, on cx88. 

Btw, we had this lock on past versions of vivi, but this were removed on this
changeset:

changeset:   6275:cba23263534b
user:        bphilips@suse.de <bphilips@suse.de>
date:        Thu Sep 27 20:55:17 2007 -0300
files:       linux/drivers/media/video/vivi.c
description:
V4L: vivi.c remove the "resource" locking

The "resource" locking in vivi isn't needed since
streamon/streamoff/read_stream do mutual exclusion using
q->reading/q->streaming.

Maybe we can just revert this changeset.

> > Yet, vivi should allow multiple open to allow "panel" applications, to
> > be compliant with V4L2 API.
> 
> Yes, but someone needs to add the code to support this in vivi.  And
> until someone does vivi can only support one open at a time without
> crashing.

This is a small regression, but I think it is OK for now.

[1] I tried to fix it during the weekend, without success. The Ethernet
interface is not working fine - most of the time, it doesn't send packets.
Also, with 2 PCI's inside, only one is working fine. If I plug 3 PCI devices,
all devices work badly. I tried to replace the power supply, but the troubles
still continue. I think I'll need to start saving some money to buy a newer
hardware :(

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Brandon Philips]

On 18:31 Mon 31 Mar 2008, Mauro Carvalho Chehab wrote:
> > > The patch is wrong. 
> > 
> > The patch fixes the unsafe way vivi is doing multiple opens right now
> > and I am uninterested in spending anymore time trying to fix up vivi
> > right now.  If you could fix vivi up that would be great.  
> 
> If the issue is specific to to vivi, that's ok. I'm just wandering if the
> changesets would break a driver for a real device.
> 
> Unfortunately, I couldn't test your patch on a real hardware. The hardware I use
> here to test PCI boards is currently broken[1].

I have tested my series on saa7134 hardware and it went OK.  Although,
having someone else play with my patchset would be nice :)

> > > 	2) you can see a program with an userspace app and record the
> > > 	stream with another app. Both xawtv and xdtv do this, when you
> > > 	ask for record: They call mencoder, asking it to read from
> > > 	/dev/video0. This way, you'll have the tv app reading, using
> > > 	mmap() or overlay methods, while mencoder is calling read() to
> > > 	receive the stream.
> > 
> > Yes, I know.  But, vivi has no permission control mechanism right now
> > for differentiating between streaming file handles and control ones.
> 
> What the other drivers do is to implement a small code for this lock. You may
> take a look on res_get(), for example, on cx88. 

Yes, I know.  But, I don't don't have time to fix vivi up all the way.

> Btw, we had this lock on past versions of vivi, but this were removed on this
> changeset:
> 
> changeset:   6275:cba23263534b
> user:        bphilips@suse.de <bphilips@suse.de>
> date:        Thu Sep 27 20:55:17 2007 -0300
> files:       linux/drivers/media/video/vivi.c
> description:
> V4L: vivi.c remove the "resource" locking
> 
> The "resource" locking in vivi isn't needed since
> streamon/streamoff/read_stream do mutual exclusion using
> q->reading/q->streaming.
> 
> Maybe we can just revert this changeset.

That won't fix it.  The locking I removed in cba23263534b is not related
to the locking that is required to protect the problems that we are
seeing with opening up multiple mplayers.  The multiple mplayers issue
is mostly related to the shutting down of the kthreads and lack of
locking on the vivi_dev fields.

Cheers,

	Brandon

> [1] I tried to fix it during the weekend, without success. The
> Ethernet interface is not working fine - most of the time, it doesn't
> send packets.  Also, with 2 PCI's inside, only one is working fine. If
> I plug 3 PCI devices, all devices work badly. I tried to replace the
> power supply, but the troubles still continue. I think I'll need to
> start saving some money to buy a newer hardware :(

Isn't shipping hardware to Brazil is really hard?

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Mauro Carvalho Chehab]

On Mon, 31 Mar 2008 20:11:30 -0700
Brandon Philips <brandon@ifup.org> wrote:

> On 18:31 Mon 31 Mar 2008, Mauro Carvalho Chehab wrote:
> > > > The patch is wrong. 
> > > 
> > > The patch fixes the unsafe way vivi is doing multiple opens right now
> > > and I am uninterested in spending anymore time trying to fix up vivi
> > > right now.  If you could fix vivi up that would be great.  
> > 
> > If the issue is specific to to vivi, that's ok. I'm just wandering if the
> > changesets would break a driver for a real device.
> > 
> > Unfortunately, I couldn't test your patch on a real hardware. The hardware I use
> > here to test PCI boards is currently broken[1].
> 
> I have tested my series on saa7134 hardware and it went OK.  Although,
> having someone else play with my patchset would be nice :)

Have you tested to run ffmpeg or mencoder under /dev/video0, while listening to
something using mmap()? The errors I got with vivi seems to occur if I do something like:

App A starts streaming;
App B starts streaming;
Stop A app -> OOPS

I didn't got error with this sequence:

App A starts streaming;
App B starts streaming;
Stop B;
Stop A.

> > > > 	2) you can see a program with an userspace app and record the
> > > > 	stream with another app. Both xawtv and xdtv do this, when you
> > > > 	ask for record: They call mencoder, asking it to read from
> > > > 	/dev/video0. This way, you'll have the tv app reading, using
> > > > 	mmap() or overlay methods, while mencoder is calling read() to
> > > > 	receive the stream.
> > > 
> > > Yes, I know.  But, vivi has no permission control mechanism right now
> > > for differentiating between streaming file handles and control ones.
> > 
> > What the other drivers do is to implement a small code for this lock. You may
> > take a look on res_get(), for example, on cx88. 
> 
> Yes, I know.  But, I don't don't have time to fix vivi up all the way.

Ok. Could you please update your tree with the latest patches? I think the
better way is to merge they on v4l/dvb and ask more people to test.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Brandon Philips]

On 17:49 Tue 01 Apr 2008, Mauro Carvalho Chehab wrote:
> On Mon, 31 Mar 2008 20:11:30 -0700
> Brandon Philips <brandon@ifup.org> wrote:
> 
> > On 18:31 Mon 31 Mar 2008, Mauro Carvalho Chehab wrote:
> > > > > The patch is wrong. 
> > > > 
> > > > The patch fixes the unsafe way vivi is doing multiple opens right now
> > > > and I am uninterested in spending anymore time trying to fix up vivi
> > > > right now.  If you could fix vivi up that would be great.  
> > > 
> > > If the issue is specific to to vivi, that's ok. I'm just wandering if the
> > > changesets would break a driver for a real device.
> > > 
> > > Unfortunately, I couldn't test your patch on a real hardware. The hardware I use
> > > here to test PCI boards is currently broken[1].
> > 
> > I have tested my series on saa7134 hardware and it went OK.  Although,
> > having someone else play with my patchset would be nice :)
> 
> Have you tested to run ffmpeg or mencoder under /dev/video0, while listening to
> something using mmap()? The errors I got with vivi seems to occur if I do something like:
> 
> App A starts streaming;
> App B starts streaming;
> Stop A app -> OOPS
> 
> I didn't got error with this sequence:
> 
> App A starts streaming;
> App B starts streaming;
> Stop B;
> Stop A.

On saa7134 I can't start more than one application streaming at once.
The other application gets -EBUSY when it tries to do streamon.

I tried with mplayer and fswebcam and combinations of them.

I did get fswebcam using read() and mplayer using mmap() and it worked
fine, although each application was only getting half the frames.

How do you use ffmpeg/mencoder with v4l2 devices?  I Googled around but
couldn't find anything that worked.

> > > > > 	2) you can see a program with an userspace app and record the
> > > > > 	stream with another app. Both xawtv and xdtv do this, when you
> > > > > 	ask for record: They call mencoder, asking it to read from
> > > > > 	/dev/video0. This way, you'll have the tv app reading, using
> > > > > 	mmap() or overlay methods, while mencoder is calling read() to
> > > > > 	receive the stream.
> > > > 
> > > > Yes, I know.  But, vivi has no permission control mechanism right now
> > > > for differentiating between streaming file handles and control ones.
> > > 
> > > What the other drivers do is to implement a small code for this lock. You may
> > > take a look on res_get(), for example, on cx88. 
> > 
> > Yes, I know.  But, I don't don't have time to fix vivi up all the way.
> 
> Ok. Could you please update your tree with the latest patches? I think the
> better way is to merge they on v4l/dvb and ask more people to test.

Updated with Jon's comments too and I just removed the copyright updates
for vivi- too much trouble: http://ifup.org/hg/v4l-dvb

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Brandon Philips]

On 17:49 Tue 01 Apr 2008, Mauro Carvalho Chehab wrote:
> On Mon, 31 Mar 2008 20:11:30 -0700
> Brandon Philips <brandon@ifup.org> wrote:
> 
> > On 18:31 Mon 31 Mar 2008, Mauro Carvalho Chehab wrote:
> > > > > The patch is wrong. 
> Ok. Could you please update your tree with the latest patches? I think the
> better way is to merge they on v4l/dvb and ask more people to test.

Oh, I also dropped the spin_lock patches for soc/pxa/videobuf until
Guennadi has a chance to send in working patches for his driver.

 http://ifup.org/hg/v4l-dvb

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 0 of 9] videobuf fixes

[Mauro Carvalho Chehab]

> On saa7134 I can't start more than one application streaming at once.
> The other application gets -EBUSY when it tries to do streamon.

The resource lock won't let you open two applications trying to read using the
same method.

> I tried with mplayer and fswebcam and combinations of them.
> 
> I did get fswebcam using read() and mplayer using mmap() and it worked
> fine, although each application was only getting half the frames.

Weird. You should be able to get the entire frame on each.

> How do you use ffmpeg/mencoder with v4l2 devices?  I Googled around but
> couldn't find anything that worked.

There's a small script at V4L/DVB tree, at:

v4l2-apps/util/v4l_rec.pl

It calls mencoder. Also there is inside a commented is a line for it usage with ffmpeg.

The syntax is about the same as when you activate record inside xawtv or xdtv.
 
> Updated with Jon's comments too and I just removed the copyright updates
> for vivi- too much trouble: http://ifup.org/hg/v4l-dvb

Ok, I've merged it at master.

People,

Please test.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

[PATCH] soc-camera: use a spinlock for videobuffer queue

[Guennadi Liakhovetski]

All drivers should provide a spinlock to be used in videobuf operations.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>

---

On Fri, 28 Mar 2008, Brandon Philips wrote:

> On 21:53 Fri 28 Mar 2008, Guennadi Liakhovetski wrote:
> 
> > OTOH, at least the PXA270 hardware needs a more global protection - to 
> > protect the DMA channel setup. And this is hardware specific. We can just 
> > assume that (imaginary) systems with multiple camera busses will have an 
> > own DMA channel per bus and will allow their concurrent onfiguration... 
> > Maybe we should let the hardware host driver decide on spinlock locality 
> > and just use whatever it provides?
> 
> I don't know enough about the hardware to comment.

How about this one? Mauro, note: it should be applied after the previous 
patch, introducing soc_camera_host_ops.

diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 9758f7e..bef3c9c 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -803,6 +803,15 @@ static int pxa_camera_querycap(struct soc_camera_host *ici,
 	return 0;
 }
 
+static spinlock_t *pxa_camera_spinlock_alloc(struct soc_camera_file *icf)
+{
+	struct soc_camera_host *ici =
+		to_soc_camera_host(icf->icd->dev.parent);
+	struct pxa_camera_dev *pcdev = ici->priv;
+
+	return &pcdev->lock;
+}
+
 static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
 	.owner		= THIS_MODULE,
 	.add		= pxa_camera_add_device,
@@ -814,6 +823,7 @@ static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
 	.querycap	= pxa_camera_querycap,
 	.try_bus_param	= pxa_camera_try_bus_param,
 	.set_bus_param	= pxa_camera_set_bus_param,
+	.spinlock_alloc	= pxa_camera_spinlock_alloc,
 };
 
 /* Should be allocated dynamically too, but we have only one. */
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 43c8110..1e92157 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -184,6 +184,7 @@ static int soc_camera_open(struct inode *inode, struct file *file)
 	struct soc_camera_device *icd;
 	struct soc_camera_host *ici;
 	struct soc_camera_file *icf;
+	spinlock_t *lock;
 	int ret;
 
 	icf = vmalloc(sizeof(*icf));
@@ -209,10 +210,16 @@ static int soc_camera_open(struct inode *inode, struct file *file)
 		goto emgi;
 	}
 
-	icd->use_count++;
-
 	icf->icd = icd;
 
+	icf->lock = ici->ops->spinlock_alloc(icf);
+	if (!icf->lock) {
+		ret = -ENOMEM;
+		goto esla;
+	}
+
+	icd->use_count++;
+
 	/* Now we really have to activate the camera */
 	if (icd->use_count == 1) {
 		ret = ici->ops->add(icd);
@@ -229,8 +236,8 @@ static int soc_camera_open(struct inode *inode, struct file *file)
 	dev_dbg(&icd->dev, "camera device open\n");
 
 	/* We must pass NULL as dev pointer, then all pci_* dma operations
-	 * transform to normal dma_* ones. Do we need an irqlock? */
-	videobuf_queue_sg_init(&icf->vb_vidq, ici->vbq_ops, NULL, NULL,
+	 * transform to normal dma_* ones. */
+	videobuf_queue_sg_init(&icf->vb_vidq, ici->vbq_ops, NULL, icf->lock,
 				V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
 				ici->msize, icd);
 
@@ -238,6 +245,11 @@ static int soc_camera_open(struct inode *inode, struct file *file)
 
 	/* All errors are entered with the video_lock held */
 eiciadd:
+	lock = icf->lock;
+	icf->lock = NULL;
+	if (ici->ops->spinlock_free)
+		ici->ops->spinlock_free(lock);
+esla:
 	module_put(ici->ops->owner);
 emgi:
 	module_put(icd->ops->owner);
@@ -253,16 +265,20 @@ static int soc_camera_close(struct inode *inode, struct file *file)
 	struct soc_camera_device *icd = icf->icd;
 	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
 	struct video_device *vdev = icd->vdev;
+	spinlock_t *lock = icf->lock;
 
 	mutex_lock(&video_lock);
 	icd->use_count--;
 	if (!icd->use_count)
 		ici->ops->remove(icd);
+	icf->lock = NULL;
+	if (ici->ops->spinlock_free)
+		ici->ops->spinlock_free(lock);
 	module_put(icd->ops->owner);
 	module_put(ici->ops->owner);
 	mutex_unlock(&video_lock);
 
-	vfree(file->private_data);
+	vfree(icf);
 
 	dev_dbg(vdev->dev, "camera device close\n");
 
@@ -762,6 +778,21 @@ static void dummy_release(struct device *dev)
 {
 }
 
+static spinlock_t *spinlock_alloc(struct soc_camera_file *icf)
+{
+	spinlock_t *lock = kmalloc(sizeof(spinlock_t), GFP_KERNEL);
+
+	if (lock)
+		spin_lock_init(lock);
+
+	return lock;
+}
+
+static void spinlock_free(spinlock_t *lock)
+{
+	kfree(lock);
+}
+
 int soc_camera_host_register(struct soc_camera_host *ici)
 {
 	int ret;
@@ -792,6 +823,11 @@ int soc_camera_host_register(struct soc_camera_host *ici)
 	if (ret)
 		goto edevr;
 
+	if (!ici->ops->spinlock_alloc) {
+		ici->ops->spinlock_alloc = spinlock_alloc;
+		ici->ops->spinlock_free = spinlock_free;
+	}
+
 	scan_add_host(ici);
 
 	return 0;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 80e1193..6a8c8be 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -48,6 +48,7 @@ struct soc_camera_device {
 struct soc_camera_file {
 	struct soc_camera_device *icd;
 	struct videobuf_queue vb_vidq;
+	spinlock_t *lock;
 };
 
 struct soc_camera_host {
@@ -73,6 +74,8 @@ struct soc_camera_host_ops {
 	int (*try_bus_param)(struct soc_camera_device *, __u32);
 	int (*set_bus_param)(struct soc_camera_device *, __u32);
 	unsigned int (*poll)(struct file *, poll_table *);
+	spinlock_t* (*spinlock_alloc)(struct soc_camera_file *);
+	void (*spinlock_free)(spinlock_t *);
 };
 
 struct soc_camera_link {

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH] soc-camera: use a spinlock for videobuffer queue

[Brandon Philips]

On 15:46 Fri 04 Apr 2008, Guennadi Liakhovetski wrote:
> All drivers should provide a spinlock to be used in videobuf operations.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>

This looks OK.  Thanks.

Reviewed-by: Brandon Philips <bphilips@suse.de>

> ---
> 
> On Fri, 28 Mar 2008, Brandon Philips wrote:
> 
> > On 21:53 Fri 28 Mar 2008, Guennadi Liakhovetski wrote:
> > 
> > > OTOH, at least the PXA270 hardware needs a more global protection - to 
> > > protect the DMA channel setup. And this is hardware specific. We can just 
> > > assume that (imaginary) systems with multiple camera busses will have an 
> > > own DMA channel per bus and will allow their concurrent onfiguration... 
> > > Maybe we should let the hardware host driver decide on spinlock locality 
> > > and just use whatever it provides?
> > 
> > I don't know enough about the hardware to comment.
> 
> How about this one? Mauro, note: it should be applied after the previous 
> patch, introducing soc_camera_host_ops.
> 
> diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
> index 9758f7e..bef3c9c 100644
> --- a/drivers/media/video/pxa_camera.c
> +++ b/drivers/media/video/pxa_camera.c
> @@ -803,6 +803,15 @@ static int pxa_camera_querycap(struct soc_camera_host *ici,
>  	return 0;
>  }
>  
> +static spinlock_t *pxa_camera_spinlock_alloc(struct soc_camera_file *icf)
> +{
> +	struct soc_camera_host *ici =
> +		to_soc_camera_host(icf->icd->dev.parent);
> +	struct pxa_camera_dev *pcdev = ici->priv;
> +
> +	return &pcdev->lock;
> +}
> +
>  static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
>  	.owner		= THIS_MODULE,
>  	.add		= pxa_camera_add_device,
> @@ -814,6 +823,7 @@ static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
>  	.querycap	= pxa_camera_querycap,
>  	.try_bus_param	= pxa_camera_try_bus_param,
>  	.set_bus_param	= pxa_camera_set_bus_param,
> +	.spinlock_alloc	= pxa_camera_spinlock_alloc,
>  };
>  
>  /* Should be allocated dynamically too, but we have only one. */
> diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
> index 43c8110..1e92157 100644
> --- a/drivers/media/video/soc_camera.c
> +++ b/drivers/media/video/soc_camera.c
> @@ -184,6 +184,7 @@ static int soc_camera_open(struct inode *inode, struct file *file)
>  	struct soc_camera_device *icd;
>  	struct soc_camera_host *ici;
>  	struct soc_camera_file *icf;
> +	spinlock_t *lock;
>  	int ret;
>  
>  	icf = vmalloc(sizeof(*icf));
> @@ -209,10 +210,16 @@ static int soc_camera_open(struct inode *inode, struct file *file)
>  		goto emgi;
>  	}
>  
> -	icd->use_count++;
> -
>  	icf->icd = icd;
>  
> +	icf->lock = ici->ops->spinlock_alloc(icf);
> +	if (!icf->lock) {
> +		ret = -ENOMEM;
> +		goto esla;
> +	}
> +
> +	icd->use_count++;
> +
>  	/* Now we really have to activate the camera */
>  	if (icd->use_count == 1) {
>  		ret = ici->ops->add(icd);
> @@ -229,8 +236,8 @@ static int soc_camera_open(struct inode *inode, struct file *file)
>  	dev_dbg(&icd->dev, "camera device open\n");
>  
>  	/* We must pass NULL as dev pointer, then all pci_* dma operations
> -	 * transform to normal dma_* ones. Do we need an irqlock? */
> -	videobuf_queue_sg_init(&icf->vb_vidq, ici->vbq_ops, NULL, NULL,
> +	 * transform to normal dma_* ones. */
> +	videobuf_queue_sg_init(&icf->vb_vidq, ici->vbq_ops, NULL, icf->lock,
>  				V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
>  				ici->msize, icd);
>  
> @@ -238,6 +245,11 @@ static int soc_camera_open(struct inode *inode, struct file *file)
>  
>  	/* All errors are entered with the video_lock held */
>  eiciadd:
> +	lock = icf->lock;
> +	icf->lock = NULL;
> +	if (ici->ops->spinlock_free)
> +		ici->ops->spinlock_free(lock);
> +esla:
>  	module_put(ici->ops->owner);
>  emgi:
>  	module_put(icd->ops->owner);
> @@ -253,16 +265,20 @@ static int soc_camera_close(struct inode *inode, struct file *file)
>  	struct soc_camera_device *icd = icf->icd;
>  	struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
>  	struct video_device *vdev = icd->vdev;
> +	spinlock_t *lock = icf->lock;
>  
>  	mutex_lock(&video_lock);
>  	icd->use_count--;
>  	if (!icd->use_count)
>  		ici->ops->remove(icd);
> +	icf->lock = NULL;
> +	if (ici->ops->spinlock_free)
> +		ici->ops->spinlock_free(lock);
>  	module_put(icd->ops->owner);
>  	module_put(ici->ops->owner);
>  	mutex_unlock(&video_lock);
>  
> -	vfree(file->private_data);
> +	vfree(icf);
>  
>  	dev_dbg(vdev->dev, "camera device close\n");
>  
> @@ -762,6 +778,21 @@ static void dummy_release(struct device *dev)
>  {
>  }
>  
> +static spinlock_t *spinlock_alloc(struct soc_camera_file *icf)
> +{
> +	spinlock_t *lock = kmalloc(sizeof(spinlock_t), GFP_KERNEL);
> +
> +	if (lock)
> +		spin_lock_init(lock);
> +
> +	return lock;
> +}
> +
> +static void spinlock_free(spinlock_t *lock)
> +{
> +	kfree(lock);
> +}
> +
>  int soc_camera_host_register(struct soc_camera_host *ici)
>  {
>  	int ret;
> @@ -792,6 +823,11 @@ int soc_camera_host_register(struct soc_camera_host *ici)
>  	if (ret)
>  		goto edevr;
>  
> +	if (!ici->ops->spinlock_alloc) {
> +		ici->ops->spinlock_alloc = spinlock_alloc;
> +		ici->ops->spinlock_free = spinlock_free;
> +	}
> +
>  	scan_add_host(ici);
>  
>  	return 0;
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index 80e1193..6a8c8be 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -48,6 +48,7 @@ struct soc_camera_device {
>  struct soc_camera_file {
>  	struct soc_camera_device *icd;
>  	struct videobuf_queue vb_vidq;
> +	spinlock_t *lock;
>  };
>  
>  struct soc_camera_host {
> @@ -73,6 +74,8 @@ struct soc_camera_host_ops {
>  	int (*try_bus_param)(struct soc_camera_device *, __u32);
>  	int (*set_bus_param)(struct soc_camera_device *, __u32);
>  	unsigned int (*poll)(struct file *, poll_table *);
> +	spinlock_t* (*spinlock_alloc)(struct soc_camera_file *);
> +	void (*spinlock_free)(spinlock_t *);
>  };
>  
>  struct soc_camera_link {

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

[Mauro Carvalho Chehab]

[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]

On Tue, 8 Apr 2008 08:22:38 -0700
Brandon Philips <bphilips@suse.de> wrote:

> On 18:32 Mon 07 Apr 2008, Mauro Carvalho Chehab wrote:
> > Hi Brandon,
> > 
> > On Sun, 6 Apr 2008 01:00:11 -0700
> > Brandon Philips <bphilips@suse.de> wrote:
> > 
> > > > If I don't revert this patch, mmap() stops working. Reverting it fixed the issue.
> > > 
> > > How does it stop working?  I don't see anything obvious.
> > 
> > I've revisited videobuf-vmalloc. I've discovered why remap were not properly
> > working at videobuf_mapper function. I've fixed it on:
> > 	http://linuxtv.org/hg/~mchehab/em28xx-vb/rev/ab0ca0f1f093
> > 
> > I think that the approach of the above patch is much cleaner and seems to be correct.
> > 
> > So, if it is ok for you, I think the better is to revert patch 6/9, and
> > applying this one, instead, at v4l/dvb. What do you think?
> 
> I don't think it quite works right and I think making the allocation in
> reqbufs, as 6/9 did, is the right thing to do.

With 6/9 or with this patch, the allocation will happen when you try to use an
mmap command. This can happen on streamon, reqbufs, dqbuf, qbuf or reqbuf.

Sorry, but I think I missed your point.

> > One interesting thing is that tvtime behavior has changed after this patch.
> > Yet, it is not working. However, before this patch, the buffers weren't
> > mmapped. Now, this part occurred successfully.
> 
> Does this really work?

Yes, it works.

> > +	case V4L2_MEMORY_USERPTR:
> > +	{
> 
> Why are you adding braces here?
> 
> > +		int pages = PAGE_ALIGN(vb->size);

To declare pages var on above code. without braces, a warning is generated.

> > @@ -218,46 +250,55 @@ static int __videobuf_mmap_mapper(struct
> >  	}
> >  
> >  	/* create mapping + update buffer list */
> > -	map = q->bufs[first]->map = kzalloc(sizeof(struct videobuf_mapping),GFP_KERNEL);
> > +	map = kzalloc(sizeof(struct videobuf_mapping), GFP_KERNEL);
> >  	if (NULL == map)
> >  		return -ENOMEM;
> >  
> > +	q->bufs[first]->map = map;
> >  	map->start = vma->vm_start;
> >  	map->end   = vma->vm_end;
> >  	map->q     = q;
> >  
> >  	q->bufs[first]->baddr = vma->vm_start;
> >  
> > +	mem = q->bufs[first]->priv;
> > +	BUG_ON(!mem);
> > +	MAGIC_CHECK(mem->magic, MAGIC_VMAL_MEM);
> > +
> > +	pages = PAGE_ALIGN(vma->vm_end - vma->vm_start);
> > +	mem->vmalloc = vmalloc_user(pages);
> 
> What happens when an application unmaps then remaps?  The memory backing
> that drivers depend on will be freed on vm_close then come back on mmap.

Are you thinking on an userspace application explicitly calling munmap()? 

Hmm... Interesting. Test attached. 

Basically, this worked as expected.

Probably, in this case, we may have some troubles, due to vfree() if we get an
interrupt between:
	vfree(mem->vmalloc)
		and
	mem->vmalloc=NULL.

A fix could be to disable IRQ during that interval of time, and/or protecting
with a spinlock.

I can't see any other issues. Btw, the same kind of code is also used on
videobuf-dma-sg, cafe-ccic, and several other USB drivers.

> Really, I think the allocation should happen in REQBUF as I did.

By looking on your code, it didn't work previously, due to a bug on this line:

	retval=remap_vmalloc_range(vma, mem->vmalloc,0);

This bug were present on the previous version, and were corrected by this patch.

Also, all userspace clients already do something like this, on buffer_prepare:

        if (VIDEOBUF_NEEDS_INIT == buf->vb.state) {
                rc = videobuf_iolock(vq, &buf->vb, NULL);
                if (rc < 0)
                        goto fail;
        }

Btw, I think that this flag should be set automatically by videobuf_vmalloc_free().

Cheers,
Mauro

---

I'm enclosing two files:

1) A diff file, against em28xx-vb tree, with some additional printk's and a
patch for capture_example.c. The patch basically captures 5 frames, stops,
unmaps, request buffers, and captures 5 more frames;

2) the dmesg output of running capture_example, with vivi.

All seemed to work fine.

I also tested this (increasing the second capture to 50 frames, in order to see more):

./capture_example -o | mplayer -demuxer 26 -rawvideo w=640:h=480:format=yuy2 -

Also worked perfectly.

[-- Attachment #2: dmesg --]
[-- Type: application/octet-stream, Size: 42613 bytes --]

Apr  8 15:30:55 gaivota kernel: [ 7194.057735] Linux video capture interface: v2.00
Apr  8 15:30:55 gaivota kernel: [ 7194.075505] Video Technology Magazine Virtual Video Capture Board successfully loaded.
Apr  8 15:30:57 gaivota kernel: [ 7196.106675] vivi: open called (minor=0)
Apr  8 15:30:57 gaivota kernel: [ 7196.106685] vivi: open minor=0 type=video-cap users=1
Apr  8 15:30:57 gaivota kernel: [ 7196.106691] vivi: vivi_start_thread
Apr  8 15:30:57 gaivota kernel: [ 7196.107195] vivi: returning from vivi_start_thread
Apr  8 15:30:57 gaivota kernel: [ 7196.107208] vivi (0): v4l2 ioctl VIDIOC_QUERYCAP, dir=r- (0x80685600)
Apr  8 15:30:57 gaivota kernel: [ 7196.107214] vivi (0): driver=vivi, card=vivi, bus=, version=0x00000400, capabilities=0x05000001
Apr  8 15:30:57 gaivota kernel: [ 7196.107220] vivi (0): v4l2 ioctl VIDIOC_CROPCAP, dir=rw (0xc02c563a)
Apr  8 15:30:57 gaivota kernel: [ 7196.107230] vivi (0): v4l2 ioctl VIDIOC_S_FMT, dir=rw (0xc0d05605)
Apr  8 15:30:57 gaivota kernel: [ 7196.107234] vivi (0): type=video-cap
Apr  8 15:30:57 gaivota kernel: [ 7196.107237] vivi (0): width=640, height=480, format=YUYV, field=interlaced, bytesperline=0 sizeimage=0, colorspace=0
Apr  8 15:30:57 gaivota kernel: [ 7196.107244] vivi: buffer_setup, count=4, size=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.107248] vbuf: reqbufs: bufs=4, size=0x96000 [600 pages total]
Apr  8 15:30:57 gaivota kernel: [ 7196.107250] vbuf: __videobuf_mmap_setup called
Apr  8 15:30:57 gaivota kernel: [ 7196.107253] vbuf-vmalloc: __videobuf_mmap_free
Apr  8 15:30:57 gaivota kernel: [ 7196.107257] vbuf-vmalloc: __videobuf_alloc: allocated at ffff810076cc5600(232+8) & ffff810076cc56f0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.107261] vbuf-vmalloc: __videobuf_alloc: allocated at ffff810077012c00(232+8) & ffff810077012cf0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.107266] vbuf-vmalloc: __videobuf_alloc: allocated at ffff8100771fac00(232+8) & ffff8100771facf0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.107270] vbuf-vmalloc: __videobuf_alloc: allocated at ffff8100593fb000(232+8) & ffff8100593fb0f0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.107273] vbuf: mmap setup: 4 buffers, 614400 bytes each
Apr  8 15:30:57 gaivota kernel: [ 7196.107276] vivi (0): v4l2 ioctl VIDIOC_REQBUFS, dir=rw (0xc0145608)
Apr  8 15:30:57 gaivota kernel: [ 7196.107279] vivi (0): count=4, type=video-cap, memory=mmap
Apr  8 15:30:57 gaivota kernel: [ 7196.107372] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:57 gaivota kernel: [ 7196.107379] vivi (0): 00:00:00.00000000 index=0, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.107383] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.107394] vivi: mmap called, vma=0xffff81006180e288
Apr  8 15:30:57 gaivota kernel: [ 7196.107397] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:57 gaivota kernel: [ 7196.107773] vbuf-vmalloc: vmalloc is at addr ffffc20001418000 (614400 pages)
Apr  8 15:30:57 gaivota kernel: [ 7196.107859] vbuf-vmalloc: mmap ffff81005b3eedc0: q=ffff8100729bcc18 2b021bf6b000-2b021c001000 (96000) pgoff 00000000 buf 0
Apr  8 15:30:57 gaivota kernel: [ 7196.107863] vivi: vma start=0x2b021bf6b000, size=614400, ret=0
Apr  8 15:30:57 gaivota kernel: [ 7196.107873] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:57 gaivota kernel: [ 7196.107880] vivi (0): 00:00:00.00000000 index=1, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00096000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.107885] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.107890] vivi: mmap called, vma=0xffff810061b463d8
Apr  8 15:30:57 gaivota kernel: [ 7196.107893] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:57 gaivota kernel: [ 7196.108325] vbuf-vmalloc: vmalloc is at addr ffffc200014af000 (614400 pages)
Apr  8 15:30:57 gaivota kernel: [ 7196.108403] vbuf-vmalloc: mmap ffff81005b2f8640: q=ffff8100729bcc18 2b021c001000-2b021c097000 (96000) pgoff 00000096 buf 1
Apr  8 15:30:57 gaivota kernel: [ 7196.108407] vivi: vma start=0x2b021c001000, size=614400, ret=0
Apr  8 15:30:57 gaivota kernel: [ 7196.108415] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:57 gaivota kernel: [ 7196.108421] vivi (0): 00:00:00.00000000 index=2, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x0012c000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.108426] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.108432] vivi: mmap called, vma=0xffff810065068c60
Apr  8 15:30:57 gaivota kernel: [ 7196.108435] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:57 gaivota kernel: [ 7196.108851] vbuf-vmalloc: vmalloc is at addr ffffc20001546000 (614400 pages)
Apr  8 15:30:57 gaivota kernel: [ 7196.108928] vbuf-vmalloc: mmap ffff81005b2f8700: q=ffff8100729bcc18 2b021c097000-2b021c12d000 (96000) pgoff 0000012c buf 2
Apr  8 15:30:57 gaivota kernel: [ 7196.108932] vivi: vma start=0x2b021c097000, size=614400, ret=0
Apr  8 15:30:57 gaivota kernel: [ 7196.108941] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:57 gaivota kernel: [ 7196.108947] vivi (0): 00:00:00.00000000 index=3, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x001c2000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.108952] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.108958] vivi: mmap called, vma=0xffff81006194dbb8
Apr  8 15:30:57 gaivota kernel: [ 7196.108961] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:57 gaivota kernel: [ 7196.109373] vbuf-vmalloc: vmalloc is at addr ffffc200015dd000 (614400 pages)
Apr  8 15:30:57 gaivota kernel: [ 7196.109452] vbuf-vmalloc: mmap ffff81005b2f8720: q=ffff8100729bcc18 2b021c4bf000-2b021c555000 (96000) pgoff 000001c2 buf 3
Apr  8 15:30:57 gaivota kernel: [ 7196.109456] vivi: vma start=0x2b021c4bf000, size=614400, ret=0
Apr  8 15:30:57 gaivota kernel: [ 7196.109467] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.109470] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.109473] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:57 gaivota kernel: [ 7196.109475] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.109478] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.109484] vivi (0): 00:00:00.00000000 index=0, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:57 gaivota kernel: [ 7196.109489] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.109493] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.109496] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.109498] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:57 gaivota kernel: [ 7196.109500] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.109502] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.109507] vivi (0): 00:00:00.00000000 index=1, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:57 gaivota kernel: [ 7196.109512] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.109516] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.109519] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.109521] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:57 gaivota kernel: [ 7196.109523] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.109525] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.109530] vivi (0): 00:00:00.00000000 index=2, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:57 gaivota kernel: [ 7196.109535] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.109539] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.109541] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.109543] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:57 gaivota kernel: [ 7196.109546] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.109548] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.109553] vivi (0): 00:00:00.00000000 index=3, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:57 gaivota kernel: [ 7196.109558] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.109561] vivi (0): v4l2 ioctl VIDIOC_STREAMON, dir=-w (0x40045612)
Apr  8 15:30:57 gaivota kernel: [ 7196.109565] vivi (0): type=video-cap
Apr  8 15:30:57 gaivota kernel: [ 7196.109568] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.109569] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.109571] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.109573] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.109583] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.109593] vivi: thread started
Apr  8 15:30:57 gaivota kernel: [ 7196.109596] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:57 gaivota kernel: [ 7196.109598] vivi: Thread tick
Apr  8 15:30:57 gaivota kernel: [ 7196.117778] vivi: vivifill at 00:00:00:003: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:57 gaivota kernel: [ 7196.117783] vivi: filled buffer ffff810076cc5600
Apr  8 15:30:57 gaivota kernel: [ 7196.117790] vivi: [ffff810076cc5600/0] wakeup
Apr  8 15:30:57 gaivota kernel: [ 7196.122632] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.122646] vbuf: dqbuf: state is done
Apr  8 15:30:57 gaivota kernel: [ 7196.122649] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:57 gaivota kernel: [ 7196.122658] vivi (0): 335466:30:57.00770992 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.122663] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.122726] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.122729] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.122732] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.122734] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.122737] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.122743] vivi (0): 335466:30:57.00770992 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.122748] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.122753] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.132043] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:57 gaivota kernel: [ 7196.132047] vivi: Thread tick
Apr  8 15:30:57 gaivota kernel: [ 7196.140214] vivi: vivifill at 00:00:00:036: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:57 gaivota kernel: [ 7196.140219] vivi: filled buffer ffff810077012c00
Apr  8 15:30:57 gaivota kernel: [ 7196.140226] vivi: [ffff810077012c00/1] wakeup
Apr  8 15:30:57 gaivota kernel: [ 7196.140796] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.140808] vbuf: dqbuf: state is done
Apr  8 15:30:57 gaivota kernel: [ 7196.140811] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:57 gaivota kernel: [ 7196.140818] vivi (0): 335466:30:57.00815902 index=1, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00096000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.140823] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.140840] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.140843] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.140845] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.140847] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.140850] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.140856] vivi (0): 335466:30:57.00815902 index=1, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00096000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.140861] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.140865] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.155464] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:57 gaivota kernel: [ 7196.155473] vivi: Thread tick
Apr  8 15:30:57 gaivota kernel: [ 7196.163645] vivi: vivifill at 00:00:00:069: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:57 gaivota kernel: [ 7196.163651] vivi: filled buffer ffff8100771fac00
Apr  8 15:30:57 gaivota kernel: [ 7196.163656] vivi: [ffff8100771fac00/2] wakeup
Apr  8 15:30:57 gaivota kernel: [ 7196.163738] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.163751] vbuf: dqbuf: state is done
Apr  8 15:30:57 gaivota kernel: [ 7196.163754] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:57 gaivota kernel: [ 7196.163761] vivi (0): 335466:30:57.00862807 index=2, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x0012c000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.163766] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.163787] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.163790] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.163793] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.163795] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.163798] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.163804] vivi (0): 335466:30:57.00862807 index=2, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x0012c000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.163809] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.163814] vivi: vivi_poll

==> /var/log/kernel/warnings.log <==
Apr  8 15:30:57 gaivota kernel: [ 7196.107218] vivi (0): err:

==> /var/log/kernel/info.log <==
Apr  8 15:30:57 gaivota kernel: [ 7196.178209] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:57 gaivota kernel: [ 7196.178216] vivi: Thread tick
Apr  8 15:30:57 gaivota kernel: [ 7196.186383] vivi: vivifill at 00:00:00:102: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:57 gaivota kernel: [ 7196.186389] vivi: filled buffer ffff8100593fb000
Apr  8 15:30:57 gaivota kernel: [ 7196.186394] vivi: [ffff8100593fb000/3] wakeup
Apr  8 15:30:57 gaivota kernel: [ 7196.186425] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.186437] vbuf: dqbuf: state is done
Apr  8 15:30:57 gaivota kernel: [ 7196.186441] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:57 gaivota kernel: [ 7196.186448] vivi (0): 335466:30:57.00908320 index=3, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x001c2000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.186453] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.186474] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.186477] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.186480] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.186482] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.186485] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.186490] vivi (0): 335466:30:57.00908320 index=3, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x001c2000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.186501] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.186505] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.199856] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:57 gaivota kernel: [ 7196.199864] vivi: Thread tick
Apr  8 15:30:57 gaivota kernel: [ 7196.208030] vivi: vivifill at 00:00:00:135: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:57 gaivota kernel: [ 7196.208035] vivi: filled buffer ffff810076cc5600
Apr  8 15:30:57 gaivota kernel: [ 7196.208040] vivi: [ffff810076cc5600/0] wakeup
Apr  8 15:30:57 gaivota kernel: [ 7196.208232] vivi: vivi_poll
Apr  8 15:30:57 gaivota kernel: [ 7196.208244] vbuf: dqbuf: state is done
Apr  8 15:30:57 gaivota kernel: [ 7196.208247] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:57 gaivota kernel: [ 7196.208254] vivi (0): 335466:30:57.00951648 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=1, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.208259] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.208279] vbuf: qbuf: requesting next field
Apr  8 15:30:57 gaivota kernel: [ 7196.208282] vivi: buffer_prepare, field=4
Apr  8 15:30:57 gaivota kernel: [ 7196.208284] vivi: buffer_queue
Apr  8 15:30:57 gaivota kernel: [ 7196.208286] vbuf: qbuf: succeded
Apr  8 15:30:57 gaivota kernel: [ 7196.208289] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:57 gaivota kernel: [ 7196.208295] vivi (0): 335466:30:57.00951648 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=1, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.208300] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.208304] vivi (0): v4l2 ioctl VIDIOC_STREAMOFF, dir=-w (0x40045613)
Apr  8 15:30:57 gaivota kernel: [ 7196.208307] vivi (0): type=video-cap
Apr  8 15:30:57 gaivota kernel: [ 7196.208312] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208315] vivi: free_buffer, state: 5
Apr  8 15:30:57 gaivota kernel: [ 7196.208316] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208318] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208320] vivi: free_buffer, state: 5
Apr  8 15:30:57 gaivota kernel: [ 7196.208322] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208324] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208326] vivi: free_buffer, state: 5
Apr  8 15:30:57 gaivota kernel: [ 7196.208328] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208330] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208332] vivi: free_buffer, state: 5
Apr  8 15:30:57 gaivota kernel: [ 7196.208334] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208406] vbuf-vmalloc: munmap ffff81005b3eedc0 q=ffff8100729bcc18
Apr  8 15:30:57 gaivota kernel: [ 7196.208521] vbuf-vmalloc: munmap ffff81005b2f8640 q=ffff8100729bcc18
Apr  8 15:30:57 gaivota kernel: [ 7196.208616] vbuf-vmalloc: munmap ffff81005b2f8700 q=ffff8100729bcc18
Apr  8 15:30:57 gaivota kernel: [ 7196.208722] vbuf-vmalloc: munmap ffff81005b2f8720 q=ffff8100729bcc18
Apr  8 15:30:57 gaivota kernel: [ 7196.208784] vivi (0): v4l2 ioctl VIDIOC_QUERYCAP, dir=r- (0x80685600)
Apr  8 15:30:57 gaivota kernel: [ 7196.208789] vivi (0): driver=vivi, card=vivi, bus=, version=0x00000400, capabilities=0x05000001
Apr  8 15:30:57 gaivota kernel: [ 7196.208795] vivi (0): v4l2 ioctl VIDIOC_CROPCAP, dir=rw (0xc02c563a)
Apr  8 15:30:57 gaivota kernel: [ 7196.208801] vivi (0): v4l2 ioctl VIDIOC_S_FMT, dir=rw (0xc0d05605)
Apr  8 15:30:57 gaivota kernel: [ 7196.208805] vivi (0): type=video-cap
Apr  8 15:30:57 gaivota kernel: [ 7196.208808] vivi (0): width=640, height=480, format=YUYV, field=interlaced, bytesperline=0 sizeimage=0, colorspace=0
Apr  8 15:30:57 gaivota kernel: [ 7196.208815] vivi: buffer_setup, count=4, size=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.208818] vbuf: reqbufs: bufs=4, size=0x96000 [600 pages total]
Apr  8 15:30:57 gaivota kernel: [ 7196.208820] vbuf: __videobuf_mmap_setup called
Apr  8 15:30:57 gaivota kernel: [ 7196.208823] vbuf-vmalloc: __videobuf_mmap_free
Apr  8 15:30:57 gaivota kernel: [ 7196.208825] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208827] vivi: free_buffer, state: 0
Apr  8 15:30:57 gaivota kernel: [ 7196.208829] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208831] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208833] vivi: free_buffer, state: 0
Apr  8 15:30:57 gaivota kernel: [ 7196.208835] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208837] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208839] vivi: free_buffer, state: 0
Apr  8 15:30:57 gaivota kernel: [ 7196.208841] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208843] vivi: buffer_release
Apr  8 15:30:57 gaivota kernel: [ 7196.208844] vivi: free_buffer, state: 0
Apr  8 15:30:57 gaivota kernel: [ 7196.208846] vivi: free_buffer: freed
Apr  8 15:30:57 gaivota kernel: [ 7196.208850] vbuf-vmalloc: __videobuf_alloc: allocated at ffff8100593fb000(232+8) & ffff8100593fb0f0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.208855] vbuf-vmalloc: __videobuf_alloc: allocated at ffff8100771fac00(232+8) & ffff8100771facf0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.208859] vbuf-vmalloc: __videobuf_alloc: allocated at ffff810077012c00(232+8) & ffff810077012cf0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.208863] vbuf-vmalloc: __videobuf_alloc: allocated at ffff810076cc5600(232+8) & ffff810076cc56f0(24)
Apr  8 15:30:57 gaivota kernel: [ 7196.208867] vbuf: mmap setup: 4 buffers, 614400 bytes each
Apr  8 15:30:57 gaivota kernel: [ 7196.208869] vivi (0): v4l2 ioctl VIDIOC_REQBUFS, dir=rw (0xc0145608)
Apr  8 15:30:57 gaivota kernel: [ 7196.208872] vivi (0): count=4, type=video-cap, memory=mmap
Apr  8 15:30:57 gaivota kernel: [ 7196.208877] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:57 gaivota kernel: [ 7196.208882] vivi (0): 00:00:00.00000000 index=0, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:57 gaivota kernel: [ 7196.208887] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:57 gaivota kernel: [ 7196.208896] vivi: mmap called, vma=0xffff81006194dbb8
Apr  8 15:30:57 gaivota kernel: [ 7196.208899] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:57 gaivota kernel: [ 7196.209248] vbuf-vmalloc: vmalloc is at addr ffffc20001418000 (614400 pages)
Apr  8 15:30:58 gaivota kernel: [ 7196.209324] vbuf-vmalloc: mmap ffff81005b2f8720: q=ffff8100729bcc18 2b021bf6b000-2b021c001000 (96000) pgoff 00000000 buf 0
Apr  8 15:30:58 gaivota kernel: [ 7196.209329] vivi: vma start=0x2b021bf6b000, size=614400, ret=0
Apr  8 15:30:58 gaivota kernel: [ 7196.209339] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:58 gaivota kernel: [ 7196.209345] vivi (0): 00:00:00.00000000 index=1, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00096000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.209350] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.209356] vivi: mmap called, vma=0xffff810065068c60
Apr  8 15:30:58 gaivota kernel: [ 7196.209359] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:58 gaivota kernel: [ 7196.209783] vbuf-vmalloc: vmalloc is at addr ffffc200014af000 (614400 pages)
Apr  8 15:30:58 gaivota kernel: [ 7196.209882] vbuf-vmalloc: mmap ffff81005b2f8700: q=ffff8100729bcc18 2b021c001000-2b021c097000 (96000) pgoff 00000096 buf 1
Apr  8 15:30:58 gaivota kernel: [ 7196.209886] vivi: vma start=0x2b021c001000, size=614400, ret=0
Apr  8 15:30:58 gaivota kernel: [ 7196.209894] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:58 gaivota kernel: [ 7196.209900] vivi (0): 00:00:00.00000000 index=2, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x0012c000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.209905] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.209910] vivi: mmap called, vma=0xffff810061b463d8
Apr  8 15:30:58 gaivota kernel: [ 7196.209913] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:58 gaivota kernel: [ 7196.210310] vbuf-vmalloc: vmalloc is at addr ffffc20001546000 (614400 pages)
Apr  8 15:30:58 gaivota kernel: [ 7196.210387] vbuf-vmalloc: mmap ffff81005b2f8640: q=ffff8100729bcc18 2b021c097000-2b021c12d000 (96000) pgoff 0000012c buf 2
Apr  8 15:30:58 gaivota kernel: [ 7196.210391] vivi: vma start=0x2b021c097000, size=614400, ret=0
Apr  8 15:30:58 gaivota kernel: [ 7196.210399] vivi (0): v4l2 ioctl VIDIOC_QUERYBUF, dir=rw (0xc0585609)
Apr  8 15:30:58 gaivota kernel: [ 7196.210405] vivi (0): 00:00:00.00000000 index=3, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x001c2000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.210410] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.210418] vivi: mmap called, vma=0xffff81006180e288
Apr  8 15:30:58 gaivota kernel: [ 7196.210420] vbuf-vmalloc: __videobuf_mmap_mapper
Apr  8 15:30:58 gaivota kernel: [ 7196.210819] vbuf-vmalloc: vmalloc is at addr ffffc200015dd000 (614400 pages)
Apr  8 15:30:58 gaivota kernel: [ 7196.210898] vbuf-vmalloc: mmap ffff81005b3eedc0: q=ffff8100729bcc18 2b021c4bf000-2b021c555000 (96000) pgoff 000001c2 buf 3
Apr  8 15:30:58 gaivota kernel: [ 7196.210902] vivi: vma start=0x2b021c4bf000, size=614400, ret=0
Apr  8 15:30:58 gaivota kernel: [ 7196.210911] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.210914] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.210917] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:58 gaivota kernel: [ 7196.210919] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.210922] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.210928] vivi (0): 00:00:00.00000000 index=0, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:58 gaivota kernel: [ 7196.210933] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.210937] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.210940] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.210942] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:58 gaivota kernel: [ 7196.210944] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.210946] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.210951] vivi (0): 00:00:00.00000000 index=1, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:58 gaivota kernel: [ 7196.210956] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.210960] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.210962] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.210965] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:58 gaivota kernel: [ 7196.210967] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.210969] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.210974] vivi (0): 00:00:00.00000000 index=2, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:58 gaivota kernel: [ 7196.210979] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.210983] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.210985] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.210987] vbuf-vmalloc: __videobuf_iolock memory method MMAP
Apr  8 15:30:58 gaivota kernel: [ 7196.210989] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.210991] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.210996] vivi (0): 00:00:00.00000000 index=3, type=video-cap, bytesused=0, flags=0x00000000, field=0, sequence=0, memory=mmap, offset/userptr=0x00000000, length=0
Apr  8 15:30:58 gaivota kernel: [ 7196.211001] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.211005] vivi (0): v4l2 ioctl VIDIOC_STREAMON, dir=-w (0x40045612)
Apr  8 15:30:58 gaivota kernel: [ 7196.211009] vivi (0): type=video-cap
Apr  8 15:30:58 gaivota kernel: [ 7196.211011] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.211013] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.211015] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.211017] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.211022] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.221479] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:58 gaivota kernel: [ 7196.221483] vivi: Thread tick
Apr  8 15:30:58 gaivota kernel: [ 7196.229653] vivi: vivifill at 00:00:00:168: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:58 gaivota kernel: [ 7196.229659] vivi: filled buffer ffff8100593fb000
Apr  8 15:30:58 gaivota kernel: [ 7196.229665] vivi: [ffff8100593fb000/0] wakeup
Apr  8 15:30:58 gaivota kernel: [ 7196.230433] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.230447] vbuf: dqbuf: state is done
Apr  8 15:30:58 gaivota kernel: [ 7196.230450] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:58 gaivota kernel: [ 7196.230458] vivi (0): 335466:30:57.00994933 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.230463] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.230483] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.230485] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.230488] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.230490] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.230493] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.230499] vivi (0): 335466:30:57.00994933 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.230504] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.230509] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.243117] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:58 gaivota kernel: [ 7196.243122] vivi: Thread tick
Apr  8 15:30:58 gaivota kernel: [ 7196.251283] vivi: vivifill at 00:00:00:201: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:58 gaivota kernel: [ 7196.251287] vivi: filled buffer ffff8100771fac00
Apr  8 15:30:58 gaivota kernel: [ 7196.251293] vivi: [ffff8100771fac00/1] wakeup
Apr  8 15:30:58 gaivota kernel: [ 7196.251316] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.251517] vbuf: dqbuf: state is done
Apr  8 15:30:58 gaivota kernel: [ 7196.251520] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:58 gaivota kernel: [ 7196.251527] vivi (0): 335466:30:58.00038228 index=1, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00096000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.251532] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.251551] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.251553] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.251556] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.251558] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.251561] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.251566] vivi (0): 335466:30:58.00038228 index=1, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x00096000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.251571] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.251576] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.264846] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:58 gaivota kernel: [ 7196.264854] vivi: Thread tick
Apr  8 15:30:58 gaivota kernel: [ 7196.273023] vivi: vivifill at 00:00:00:234: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:58 gaivota kernel: [ 7196.273028] vivi: filled buffer ffff810077012c00
Apr  8 15:30:58 gaivota kernel: [ 7196.273034] vivi: [ffff810077012c00/2] wakeup
Apr  8 15:30:58 gaivota kernel: [ 7196.273878] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.273893] vbuf: dqbuf: state is done
Apr  8 15:30:58 gaivota kernel: [ 7196.273896] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:58 gaivota kernel: [ 7196.273904] vivi (0): 335466:30:58.00081747 index=2, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x0012c000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.273909] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.273929] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.273931] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.273934] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.273936] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.273939] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.273945] vivi (0): 335466:30:58.00081747 index=2, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x0012c000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.273950] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.273955] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.288073] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:58 gaivota kernel: [ 7196.288081] vivi: Thread tick
Apr  8 15:30:58 gaivota kernel: [ 7196.296246] vivi: vivifill at 00:00:00:267: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:58 gaivota kernel: [ 7196.296252] vivi: filled buffer ffff810076cc5600
Apr  8 15:30:58 gaivota kernel: [ 7196.296257] vivi: [ffff810076cc5600/3] wakeup
Apr  8 15:30:58 gaivota kernel: [ 7196.296452] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.296465] vbuf: dqbuf: state is done
Apr  8 15:30:58 gaivota kernel: [ 7196.296468] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:58 gaivota kernel: [ 7196.296475] vivi (0): 335466:30:58.00128232 index=3, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x001c2000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.296480] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.296501] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.296504] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.296506] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.296508] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.296511] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.296517] vivi (0): 335466:30:58.00128232 index=3, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=0, memory=mmap, offset/userptr=0x001c2000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.296522] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.296526] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.309725] vivi: vivi_sleep dma_q=0xffff81005b381ce0
Apr  8 15:30:58 gaivota kernel: [ 7196.309732] vivi: Thread tick
Apr  8 15:30:58 gaivota kernel: [ 7196.317897] vivi: vivifill at 00:00:00:300: Buffer 0xffff810021a7b000 size= 614400
Apr  8 15:30:58 gaivota kernel: [ 7196.317902] vivi: filled buffer ffff8100593fb000
Apr  8 15:30:58 gaivota kernel: [ 7196.317907] vivi: [ffff8100593fb000/0] wakeup
Apr  8 15:30:58 gaivota kernel: [ 7196.318045] vivi: vivi_poll
Apr  8 15:30:58 gaivota kernel: [ 7196.318060] vbuf: dqbuf: state is done
Apr  8 15:30:58 gaivota kernel: [ 7196.318063] vivi (0): v4l2 ioctl VIDIOC_DQBUF, dir=rw (0xc0585611)
Apr  8 15:30:58 gaivota kernel: [ 7196.318070] vivi (0): 335466:30:58.00171567 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=1, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.318076] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.318097] vbuf: qbuf: requesting next field
Apr  8 15:30:58 gaivota kernel: [ 7196.318100] vivi: buffer_prepare, field=4
Apr  8 15:30:58 gaivota kernel: [ 7196.318102] vivi: buffer_queue
Apr  8 15:30:58 gaivota kernel: [ 7196.318104] vbuf: qbuf: succeded
Apr  8 15:30:58 gaivota kernel: [ 7196.318107] vivi (0): v4l2 ioctl VIDIOC_QBUF, dir=rw (0xc058560f)
Apr  8 15:30:58 gaivota kernel: [ 7196.318113] vivi (0): 335466:30:58.00171567 index=0, type=video-cap, bytesused=614400, flags=0x00000001, field=4, sequence=1, memory=mmap, offset/userptr=0x00000000, length=614400
Apr  8 15:30:58 gaivota kernel: [ 7196.318118] vivi (0): timecode= 00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
Apr  8 15:30:58 gaivota kernel: [ 7196.318122] vivi (0): v4l2 ioctl VIDIOC_STREAMOFF, dir=-w (0x40045613)
Apr  8 15:30:58 gaivota kernel: [ 7196.318126] vivi (0): type=video-cap
Apr  8 15:30:58 gaivota kernel: [ 7196.318131] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318133] vivi: free_buffer, state: 5
Apr  8 15:30:58 gaivota kernel: [ 7196.318135] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318137] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318139] vivi: free_buffer, state: 5
Apr  8 15:30:58 gaivota kernel: [ 7196.318141] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318143] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318145] vivi: free_buffer, state: 5
Apr  8 15:30:58 gaivota kernel: [ 7196.318147] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318149] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318151] vivi: free_buffer, state: 5
Apr  8 15:30:58 gaivota kernel: [ 7196.318153] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318208] vbuf-vmalloc: munmap ffff81005b2f8720 q=ffff8100729bcc18
Apr  8 15:30:58 gaivota kernel: [ 7196.318310] vbuf-vmalloc: munmap ffff81005b2f8700 q=ffff8100729bcc18
Apr  8 15:30:58 gaivota kernel: [ 7196.318422] vbuf-vmalloc: munmap ffff81005b2f8640 q=ffff8100729bcc18
Apr  8 15:30:58 gaivota kernel: [ 7196.318525] vbuf-vmalloc: munmap ffff81005b3eedc0 q=ffff8100729bcc18
Apr  8 15:30:58 gaivota kernel: [ 7196.318587] vivi: vivi_stop_thread
Apr  8 15:30:58 gaivota kernel: [ 7196.318932] vivi: thread: exit
Apr  8 15:30:58 gaivota kernel: [ 7196.318958] vbuf: videobuf_mmap_free called
Apr  8 15:30:58 gaivota kernel: [ 7196.318962] vbuf-vmalloc: __videobuf_mmap_free
Apr  8 15:30:58 gaivota kernel: [ 7196.318964] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318966] vivi: free_buffer, state: 0
Apr  8 15:30:58 gaivota kernel: [ 7196.318968] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318970] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318972] vivi: free_buffer, state: 0
Apr  8 15:30:58 gaivota kernel: [ 7196.318974] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318976] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318978] vivi: free_buffer, state: 0
Apr  8 15:30:58 gaivota kernel: [ 7196.318980] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318982] vivi: buffer_release
Apr  8 15:30:58 gaivota kernel: [ 7196.318984] vivi: free_buffer, state: 0
Apr  8 15:30:58 gaivota kernel: [ 7196.318986] vivi: free_buffer: freed
Apr  8 15:30:58 gaivota kernel: [ 7196.318989] vivi: close called (minor=0, users=0)
Apr  8 15:30:57 gaivota kernel: [ 7196.208793] vivi (0): err:

[-- Attachment #3: diff_changes_for_vivi_testing.patch --]
[-- Type: text/x-patch, Size: 1374 bytes --]

diff -r 8ba4c2df2736 linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c	Tue Apr 08 13:36:56 2008 -0300
+++ b/linux/drivers/media/video/videobuf-core.c	Tue Apr 08 15:31:45 2008 -0300
@@ -314,6 +314,9 @@ int videobuf_mmap_free(struct videobuf_q
 int videobuf_mmap_free(struct videobuf_queue *q)
 {
 	int ret;
+
+	dprintk(1, "%s called\n", __func__);
+
 	mutex_lock(&q->vb_lock);
 	ret = __videobuf_mmap_free(q);
 	mutex_unlock(&q->vb_lock);
@@ -327,6 +330,8 @@ static int __videobuf_mmap_setup(struct 
 {
 	unsigned int i;
 	int err;
+
+	dprintk(1, "%s called\n", __func__);
 
 	MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS);
 
diff -r 8ba4c2df2736 v4l2-apps/test/capture_example.c
--- a/v4l2-apps/test/capture_example.c	Tue Apr 08 13:36:56 2008 -0300
+++ b/v4l2-apps/test/capture_example.c	Tue Apr 08 15:31:45 2008 -0300
@@ -178,12 +178,8 @@ read_frame                      (void)
 }
 
 static void
-mainloop                        (void)
+mainloop                        (int count)
 {
-	unsigned int count;
-
-	count = 1000;
-
 	while (count-- > 0) {
 		for (;;) {
 			fd_set fds;
@@ -670,7 +666,17 @@ main                            (int    
 
 	start_capturing ();
 
-	mainloop ();
+	mainloop (5);
+
+	stop_capturing ();
+
+	uninit_device ();
+
+	init_device ();
+
+	start_capturing ();
+
+	mainloop (5);
 
 	stop_capturing ();
 

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

[Mauro Carvalho Chehab]

> >  With 6/9 or with this patch, the allocation will happen when you try to use an
> >  mmap command. This can happen on streamon, reqbufs, dqbuf, qbuf or reqbuf.
> >
> >  Sorry, but I think I missed your point.
> 
> I think I agree with Brandon. Allocating the buffers in reqbufs is
> what the existing em28xx driver does. It saves a bit of complexity in
> that you just have to allocate the buffers from one place and it seems
> to be what the v4l2 API expects. (Apps have to call reqbufs first, but
> the API doesn't put any real restrictions on what order they
> mmap/munmap or queue/dequeue the buffers afterwards, and the API also
> forbids apps from calling reqbufs with the existing buffers mapped or
> streaming turned on which makes life easier). It's what I was going to
> suggest, actually.

I'm still missed. I don't see what's the difference on what patch 6/9 were
expecting to do and the proposed patch, in terms of adding a restriction of not
accepting other mmap commands, without getting a REQBUFS.

The current way that videobuf works is the one that userspace apps expect. If
we change videobuf behavior, for a given userspace API command, we risk to
break some userspace app.

> >  A fix could be to disable IRQ during that interval of time, and/or protecting
> >  with a spinlock.
> 
> What you're doing in the attached patch won't trigger the issue, since
> you're calling VIDIOC_STREAMOFF before munmap and that dequeues all
> buffers. Try removing the calls to stop_capturing and start_capturing
> around uninit_device / init_device. I haven't tried it, but you should
> be prepared to get a kernel panic.

The tests I did covers the issue of unmapping/remapping. As we've already
discussed, something else should be added to allow unmapping without streamoff.

The same kind of issue seems to apply also to videobuf-dma-sg. In fact, it is
even worse with dma: since buffers will be filled without CPU, just disabling
IRQ, or running a spinlock doesn't solve. You'll need to stop DMA before unmapping.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

[Mauro Carvalho Chehab]

On Tue, 8 Apr 2008 13:45:14 -0700
Brandon Philips <bphilips@suse.de> wrote:

> > Sorry, but I think I missed your point.
> 
> Wow, that got jumbled.  What I meant to say was:
> 
> This patch allocates the vmalloc area when mmap() is called.  6/9
> allocates vmalloc during reqbuf.

Ah, ok. I don't see any technical issue of postponing vmalloc to be done on
iolock (but see bellow). The code will just become a little bit more complex.
On the other hand, I don't see any advantage, since vmalloc_user() doesn't
really alloc memory, AFAIK.

> I read the spec in such a way that once reqbuf is made the application
> can qbuf immediately without mmap'ing.  I may be mistaken though.

If you don't call REQBUF, vb->memory and baddr will be 0, as if you were doing a read().
The end result is that QBUF won't work. The same behaviour will also occur with your patch.

I've already tested this, by accident. No OOPS. it just returns -EINVAL.

> > > > +	case V4L2_MEMORY_USERPTR:
> > > > +	{
> > > 
> > > Why are you adding braces here?
> > > 
> > > > +		int pages = PAGE_ALIGN(vb->size);
> > 
> > To declare pages var on above code. without braces, a warning is generated.
> 
> I think that declarations should just go at the top of the function to
> avoid that.

Ok, I'll change it on a next patch.

> > Probably, in this case, we may have some troubles, due to vfree() if we get an
> > interrupt between:
> > 	vfree(mem->vmalloc)
> > 		and
> > 	mem->vmalloc=NULL.
> > 
> > A fix could be to disable IRQ during that interval of time, and/or protecting
> > with a spinlock.
> 
> Yes, protecting with a spinlock is required to release these buffers.
> 
> > I can't see any other issues. Btw, the same kind of code is also used on
> > videobuf-dma-sg, cafe-ccic, and several other USB drivers.
> 
> cafe-ccic does not free it's vmalloc area in the vm_close method.

True. The lock is needed. 

I'm not quite sure on how to properly protect videobuf-vmalloc and
videobuf-dma-sg against this kind of threat. Any suggestions? 

A lock for vmalloc would be easy, but the worse case seems to be dma, since a
transfer may be in course, while unmap is happening. I couldn't find any place
where this is handled on videobuf-dma-sg. I think that some drivers try to
handle it, by calling videobuf_dma_sync(). Yet, this seems to be a feature that
should be inside videobuf, not externally handled.

> 
> > > Really, I think the allocation should happen in REQBUF as I did.
> > 
> > By looking on your code, it didn't work previously, due to a bug on this line:
> > 
> > 	retval=remap_vmalloc_range(vma, mem->vmalloc,0);
> 
> What is wrong with this?

Before my patch, mem->vmalloc were equal to NULL.

That's why this were failing with em28xx: it needs FIRST to alloc something,
THEN remap it. 

If we move vmalloc to iolock, we'll need to move also remap_vmalloc_range to there. 

Moving remap_vmalloc_range() to iolock will also work properly, but it doesn't
seem to be right to use mmap() callback just to store some things to be handled
inside iolock. That's the reason why I've opted to move just the vmalloc to
__videobuf_mmap_mapper().

What were happening before my and your patches is that the above line (remap)
were always failing for real devices. So, there was another
remap_vmalloc_range() inside iolock. The last one were the one who were really
working for tm6000 and em28xx.

I dunno why, but, for vivi, it seems that the first vmalloc were actually
working.

> > Also, all userspace clients already do something like this, on buffer_prepare:
> > 
> >         if (VIDEOBUF_NEEDS_INIT == buf->vb.state) {
> >                 rc = videobuf_iolock(vq, &buf->vb, NULL);
> >                 if (rc < 0)
> >                         goto fail;
> >         }
> 
> Huh?  How do userspace apps use videobuf_iolock?!
 
I was meaning to say "videobuf clients".

What I tried to say is that you've added a similar code to this inside patch
6/9. It would be interesting if we could remove the above code from videobuf
clients to be handled internally, and simplifying the logic inside the drivers,
but this seems to be complicated, since buffer should be filled inside
buffer_prepare.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

[Mauro Carvalho Chehab]

On Wed, 9 Apr 2008 14:26:46 +0100
"Aidan Thornton" <makosoft@googlemail.com> wrote:

> On Tue, Apr 8, 2008 at 9:50 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > > >  With 6/9 or with this patch, the allocation will happen when you try to use an
> >  > >  mmap command. This can happen on streamon, reqbufs, dqbuf, qbuf or reqbuf.
> >  > >
> >  > >  Sorry, but I think I missed your point.
> >  >
> >  > I think I agree with Brandon. Allocating the buffers in reqbufs is
> >  > what the existing em28xx driver does. It saves a bit of complexity in
> >  > that you just have to allocate the buffers from one place and it seems
> >  > to be what the v4l2 API expects. (Apps have to call reqbufs first, but
> >  > the API doesn't put any real restrictions on what order they
> >  > mmap/munmap or queue/dequeue the buffers afterwards, and the API also
> >  > forbids apps from calling reqbufs with the existing buffers mapped or
> >  > streaming turned on which makes life easier). It's what I was going to
> >  > suggest, actually.
> >
> >  I'm still missed. I don't see what's the difference on what patch 6/9 were
> >  expecting to do and the proposed patch, in terms of adding a restriction of not
> >  accepting other mmap commands, without getting a REQBUFS.
> >
> >  The current way that videobuf works is the one that userspace apps expect. If
> >  we change videobuf behavior, for a given userspace API command, we risk to
> >  break some userspace app.
> 
> Either way, mmap isn't allowed without a REQBUFS first, and videobuf
> enforces this. The question is, what orderings of mmap/munmap and
> streamon/streamoff are allowed once you've called REQBUFS - if I'm
> reading the docs correctly, you're allowed to interleave mmap/munmap
> and streamon/streamoff in whatever order you like, don't have to mmap
> buffers before queuing them, etc. In practice, apps don't, but the
> possible combinations at least need to be handled cleanly.

One patch that worked is this one:
	http://linuxtv.org/hg/~mchehab/tm6010/rev/e1a2b9e33bd2

I tried first to use spinlock before vfree(), but kernel complained. I suspect
that vfree() can sleep.

So, what the above patch does is to streamoff() before unmapping. This seems to
be correct to my eyes, since there's no sense of keeping streamon() if the
buffers are unmapped.

I didn't pushed it on em28xx yet, since I'm trying to fix another bug there.

> In what way do you expect userspace apps to break?
> 
> >
> >  > >  A fix could be to disable IRQ during that interval of time, and/or protecting
> >  > >  with a spinlock.
> >  >
> >  > What you're doing in the attached patch won't trigger the issue, since
> >  > you're calling VIDIOC_STREAMOFF before munmap and that dequeues all
> >  > buffers. Try removing the calls to stop_capturing and start_capturing
> >  > around uninit_device / init_device. I haven't tried it, but you should
> >  > be prepared to get a kernel panic.
> >
> >  The tests I did covers the issue of unmapping/remapping. As we've already
> >  discussed, something else should be added to allow unmapping without streamoff.
> >
> >  The same kind of issue seems to apply also to videobuf-dma-sg. In fact, it is
> >  even worse with dma: since buffers will be filled without CPU, just disabling
> >  IRQ, or running a spinlock doesn't solve. You'll need to stop DMA before unmapping.
> 
> Actually, videobuf-dma-sg works in a quite interesting way - it
> actually treats mmap'ed IO essentially the same as userptr IO, just
> with some additional code to allocate the user pages.

I've started to write a patch to add the same functionality. Didn't finished
yet. I'm not sure if it would be important to provide userspace mmapped IO. I
suspect that most apps are using read() or kernel mmap() interfaces.

> Shutting off DMA on munmap wouldn't help, since the buffer could be a userptr one in
> some anonymous mapping entirely unrelated to the device.  I'm not sure
> whether or not this is an issue; I'd have to check the small print on
> the code that pins the pages in RAM, and I can't find it.

I suspect that the issue exists with DMA, although there's a sync routine
there, that may help to avoid such issues. But I think that the same strategy of
doing a streamoff before unmap should be used for kernel mmapped memory.

> (There's also some code to allocate bounce buffers in the mmap case if
> it doesn't have a userland address for the buffer yet. I'm not
> convinced this actually works.)

It should work. you can test it with "capture_example -u". Unfortunately, I
can't test here right now, since the desktop I use here for testing PCI devices
is burned. I'll need to save some money to buy another motherboard or to
replace the machine.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure

[Mauro Carvalho Chehab]

> 
> Sorry for taking a while to get back to you.
> 
> With my patch and this little change it is possible to QBUF before
> running mmap().  This causes dma-sg devices to use a bounce buffer if
> QBUF is done before being mmap'd.

Interesting. However, I don't see much advantages of doing that, especially if
this behaviour will work only with dma-sg drivers. I think that the better is
to require mmap() before QBUF at V4L2 API.

We have a bad experience with V4L1 apps that were abusing on relaxed checks at
the API. Those apps (like vlc) first starts streaming, then changes the buffer
size, by altering the image size. This bad behaviour is still not supported by
V4L1 compat layer.

IMO, the V4L2 API should define the valid command order of ioctls for stream to
work.


> The current code on em28xx-vb is canceling the entire queue when one
> buffer is unmapped.

Yes.

> This is certainly not what an application would
> expect:
> 
> http://linuxtv.org/hg/~mchehab/em28xx-vb/rev/e1a2b9e33bd2

Hmm.. I think I got your point. It should be cancelling only the affected
buffer. I can't see any sense of continuing the stream for the cancelled
buffer.
 
> It is clear now that we need to do reference counting on the buffers.
> 
> Reference takers:
>  - reqbuf
>  - vm_open
>  - driver when it grabs buffer from queue
> 
> Reference releasers:
>  - streamoff
>  - vm_close
>  - driver when it finishes with buffer
> 
> Does that seem sane?  I will submit a patch tomorrow.

It seems sane.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list