Possible bug on libv4l read() emulation

2009-10-15 Thread Pablo Baena
I have a program where I use libv4l's read() emulation for simplicity.
But with most v4l2 webcams I've tried, I get kernel panics.

I have pics of the message if anyone cares to see them, I don't want
to flood the mailing list.

Basically, the names I see in the kernel panic from a uvcvideo card is:

uvc_queue_next_buffer
__bad_area_no_semaphore
do_page_fault

And a lot more.

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


Re: Possible bug on libv4l read() emulation

2009-10-16 Thread Pablo Baena
I think I identified the problem, I used code extracted from:
http://www.saillard.org/linux/pwc/files/capture.c, and the code was
like:

  total_read_bytes = 0;
  do {
read_bytes = read(fd, buffers[0].start, buffers[0].length);
if (read_bytes  0)
{
switch (errno)
{
case EIO:
case EAGAIN:
continue;
default:
errno_exit(read);
}
}
total_read_bytes += read_bytes;
} while (total_read_bytes  buffers[0].length);

I changed the read() call to a v4l2_read() and used libv4l, and that
piece of code was triggering the kernel panic.

To fix it, I just removed the do..while loop. I'm still trying to
figure out what's the problem with that though.

Thanks for the reply.

On Fri, Oct 16, 2009 at 2:42 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 10/16/2009 12:00 AM, Pablo Baena wrote:

 I have a program where I use libv4l's read() emulation for simplicity.
 But with most v4l2 webcams I've tried, I get kernel panics.

 I have pics of the message if anyone cares to see them, I don't want
 to flood the mailing list.

 Basically, the names I see in the kernel panic from a uvcvideo card is:

 uvc_queue_next_buffer
 __bad_area_no_semaphore
 do_page_fault

 And a lot more.


 A panic should never happen, no matter what libv4l does (as libv4l is 100%
 userspace). Please submit a bug report with as much detail as possible to
 the
 driver author.

 Regards,

 Hans




-- 
Not possessing the gift of reflection, a dog does not know that he
does not know, and does not understand that he understands nothing;
we, on the other hand, are aware of both. If we behave otherwise, it
is from stupidity, or else from self-deception, to preserve our peace
of mind.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: uvcvideo kernel panic when using libv4l

2009-12-10 Thread Pablo Baena
Can you tell me how to obtain such backtrace? This is a hard panic and
I don't know how to obtain a backtrace, since the keyboard gets
unresponsive.

On Thu, Dec 10, 2009 at 11:19 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Pablo,

 On Monday 07 December 2009 18:18:11 Pablo Baena wrote:
 I get a kernel panic when running the attached sample code.

 I run it as:

 $ gcc capture.c -o capture
 $ export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so
 $ ./capture -d/dev/video0 -c1000 -r

 -r tells it to capture using read(), which libv4l emulates.

 In the example code, I use read() to fetch from the webcam directly,
 without using select() to wait for a frame. In the v4l documentation,
 it states that read() should block until it has a new frame available.

 This is a Bus 002 Device 005: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera.

 I can't capture the kernel panic because everything hangs and I have
 no kernel debugger to try to get that info. I attach a poor quality
 image taken with a webcam from the screen. I even tried having a
 vmware virtual machine to try to better capture the panic, but in the
 virtual machine it doesn't hang.

 This is Ubuntu 9.10, Linux pablo-laptop 2.6.31-16-generic #52-Ubuntu
 SMP Thu Dec 3 22:00:22 UTC 2009 i686 GNU/Linux.

 But I got reports that the same camera on Debian 5.3 is also panicking.

 Please advice if you need more information to solve this problem.

 I can't reproduce the problem here (with another camera).

 To investigate I will need a copy of the source code and binary kernel module
 for the uvcvideo driver running on your system as well as a complete complete
 backtrace.

 --
 Regards,

 Laurent Pinchart




-- 
Not possessing the gift of reflection, a dog does not know that he
does not know, and does not understand that he understands nothing;
we, on the other hand, are aware of both. If we behave otherwise, it
is from stupidity, or else from self-deception, to preserve our peace
of mind.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: uvcvideo kernel panic when using libv4l

2009-12-15 Thread Pablo Baena
With that patch, libv4l throws an error at some point, no crashes so far though:

libv4l2: error dequeuing buf: Invalid argument
read error 22, Invalid argument

On Tue, Dec 15, 2009 at 9:12 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Leandro and Pablo,

 could you please try the following patch ? It closes a race window that I
 believe could be at the core of your kernel panic.

 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_queue.c
 --- a/linux/drivers/media/video/uvc/uvc_queue.c Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvc_queue.c Wed Dec 16 01:10:21 2009 +0100
 @@ -59,7 +59,7 @@
  *    returns immediately.
  *
  *    When the buffer is full, the completion handler removes it from the irq
 - *    queue, marks it as ready (UVC_BUF_STATE_DONE) and wakes its wait queue.
 + *    queue, marks it as ready (UVC_BUF_STATE_READY) and wakes its wait 
 queue.
  *    At that point, any process waiting on the buffer will be woken up. If a
  *    process tries to dequeue a buffer after it has been marked ready, the
  *    dequeing will succeed immediately.
 @@ -196,11 +196,12 @@

        switch (buf-state) {
        case UVC_BUF_STATE_ERROR:
 -       case UVC_BUF_STATE_DONE:
 +       case UVC_BUF_STATE_READY:
                v4l2_buf-flags |= V4L2_BUF_FLAG_DONE;
                break;
        case UVC_BUF_STATE_QUEUED:
        case UVC_BUF_STATE_ACTIVE:
 +       case UVC_BUF_STATE_DONE:
                v4l2_buf-flags |= V4L2_BUF_FLAG_QUEUED;
                break;
        case UVC_BUF_STATE_IDLE:
 @@ -341,13 +342,14 @@
                uvc_trace(UVC_TRACE_CAPTURE, [W] Corrupted data 
                        (transmission error).\n);
                ret = -EIO;
 -       case UVC_BUF_STATE_DONE:
 +       case UVC_BUF_STATE_READY:
                buf-state = UVC_BUF_STATE_IDLE;
                break;

        case UVC_BUF_STATE_IDLE:
        case UVC_BUF_STATE_QUEUED:
        case UVC_BUF_STATE_ACTIVE:
 +       case UVC_BUF_STATE_DONE:
        default:
                uvc_trace(UVC_TRACE_CAPTURE, [E] Invalid buffer state %u 
                        (driver bug?).\n, buf-state);
 @@ -383,7 +385,7 @@
        buf = list_first_entry(queue-mainqueue, struct uvc_buffer, stream);

        poll_wait(file, buf-wait, wait);
 -       if (buf-state == UVC_BUF_STATE_DONE ||
 +       if (buf-state == UVC_BUF_STATE_READY ||
            buf-state == UVC_BUF_STATE_ERROR)
                mask |= POLLIN | POLLRDNORM;

 @@ -489,6 +491,7 @@

        spin_lock_irqsave(queue-irqlock, flags);
        list_del(buf-queue);
 +       buf-state = UVC_BUF_STATE_READY;
        if (!list_empty(queue-irqqueue))
                nextbuf = list_first_entry(queue-irqqueue, struct uvc_buffer,
                                           queue);
 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_video.c
 --- a/linux/drivers/media/video/uvc/uvc_video.c Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvc_video.c Wed Dec 16 01:10:21 2009 +0100
 @@ -578,8 +578,7 @@
                uvc_video_decode_end(stream, buf, mem,
                        urb-iso_frame_desc[i].actual_length);

 -               if (buf-state == UVC_BUF_STATE_DONE ||
 -                   buf-state == UVC_BUF_STATE_ERROR)
 +               if (buf-state == UVC_BUF_STATE_DONE)
                        buf = uvc_queue_next_buffer(stream-queue, buf);
        }
  }
 @@ -637,8 +636,7 @@
                if (!stream-bulk.skip_payload  buf != NULL) {
                        uvc_video_decode_end(stream, buf, stream-bulk.header,
                                stream-bulk.payload_size);
 -                       if (buf-state == UVC_BUF_STATE_DONE ||
 -                           buf-state == UVC_BUF_STATE_ERROR)
 +                       if (buf-state == UVC_BUF_STATE_DONE)
                                buf = uvc_queue_next_buffer(stream-queue,
                                                            buf);
                }
 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvcvideo.h
 --- a/linux/drivers/media/video/uvc/uvcvideo.h  Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvcvideo.h  Wed Dec 16 01:10:21 2009 +0100
 @@ -370,7 +370,8 @@
        UVC_BUF_STATE_QUEUED    = 1,
        UVC_BUF_STATE_ACTIVE    = 2,
        UVC_BUF_STATE_DONE      = 3,
 -       UVC_BUF_STATE_ERROR     = 4,
 +       UVC_BUF_STATE_READY     = 4,
 +       UVC_BUF_STATE_ERROR     = 5,
  };

  struct uvc_buffer {

 --
 Regards,

 Laurent Pinchart




-- 
Not possessing the gift of reflection, a dog does not know that he
does not know, and does not understand that he understands nothing;
we, on the other hand, are aware of both. If we behave otherwise, it
is from stupidity, or else from self-deception, to preserve our peace
of mind.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: uvcvideo kernel panic when using libv4l

2009-12-16 Thread Pablo Baena
Yes! This patch worked. So far I got no kernel panic, and image is
correct. Will be testing today to see if something comes up, but so
far it's doing great. Thank you!

On Wed, Dec 16, 2009 at 7:49 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Pablo,

 On Wednesday 16 December 2009 07:51:20 Pablo Baena wrote:
 With that patch, libv4l throws an error at some point, no crashes so far
  though:

 libv4l2: error dequeuing buf: Invalid argument
 read error 22, Invalid argument

 Could you please try this updated patch ?

 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_queue.c
 --- a/linux/drivers/media/video/uvc/uvc_queue.c Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvc_queue.c Wed Dec 16 11:47:40 2009 +0100
 @@ -59,7 +59,7 @@
  *    returns immediately.
  *
  *    When the buffer is full, the completion handler removes it from the irq
 - *    queue, marks it as ready (UVC_BUF_STATE_DONE) and wakes its wait queue.
 + *    queue, marks it as ready (UVC_BUF_STATE_READY) and wakes its wait 
 queue.
  *    At that point, any process waiting on the buffer will be woken up. If a
  *    process tries to dequeue a buffer after it has been marked ready, the
  *    dequeing will succeed immediately.
 @@ -196,11 +196,12 @@

        switch (buf-state) {
        case UVC_BUF_STATE_ERROR:
 -       case UVC_BUF_STATE_DONE:
 +       case UVC_BUF_STATE_READY:
                v4l2_buf-flags |= V4L2_BUF_FLAG_DONE;
                break;
        case UVC_BUF_STATE_QUEUED:
        case UVC_BUF_STATE_ACTIVE:
 +       case UVC_BUF_STATE_DONE:
                v4l2_buf-flags |= V4L2_BUF_FLAG_QUEUED;
                break;
        case UVC_BUF_STATE_IDLE:
 @@ -295,13 +296,15 @@
  {
        if (nonblocking) {
                return (buf-state != UVC_BUF_STATE_QUEUED 
 -                       buf-state != UVC_BUF_STATE_ACTIVE)
 +                       buf-state != UVC_BUF_STATE_ACTIVE 
 +                       buf-state != UVC_BUF_STATE_DONE)
                        ? 0 : -EAGAIN;
        }

        return wait_event_interruptible(buf-wait,
                buf-state != UVC_BUF_STATE_QUEUED 
 -               buf-state != UVC_BUF_STATE_ACTIVE);
 +               buf-state != UVC_BUF_STATE_ACTIVE 
 +               buf-state != UVC_BUF_STATE_DONE);
  }

  /*
 @@ -341,13 +344,14 @@
                uvc_trace(UVC_TRACE_CAPTURE, [W] Corrupted data 
                        (transmission error).\n);
                ret = -EIO;
 -       case UVC_BUF_STATE_DONE:
 +       case UVC_BUF_STATE_READY:
                buf-state = UVC_BUF_STATE_IDLE;
                break;

        case UVC_BUF_STATE_IDLE:
        case UVC_BUF_STATE_QUEUED:
        case UVC_BUF_STATE_ACTIVE:
 +       case UVC_BUF_STATE_DONE:
        default:
                uvc_trace(UVC_TRACE_CAPTURE, [E] Invalid buffer state %u 
                        (driver bug?).\n, buf-state);
 @@ -383,7 +387,7 @@
        buf = list_first_entry(queue-mainqueue, struct uvc_buffer, stream);

        poll_wait(file, buf-wait, wait);
 -       if (buf-state == UVC_BUF_STATE_DONE ||
 +       if (buf-state == UVC_BUF_STATE_READY ||
            buf-state == UVC_BUF_STATE_ERROR)
                mask |= POLLIN | POLLRDNORM;

 @@ -489,6 +493,7 @@

        spin_lock_irqsave(queue-irqlock, flags);
        list_del(buf-queue);
 +       buf-state = UVC_BUF_STATE_READY;
        if (!list_empty(queue-irqqueue))
                nextbuf = list_first_entry(queue-irqqueue, struct uvc_buffer,
                                           queue);
 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_video.c
 --- a/linux/drivers/media/video/uvc/uvc_video.c Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvc_video.c Wed Dec 16 11:47:40 2009 +0100
 @@ -578,8 +578,7 @@
                uvc_video_decode_end(stream, buf, mem,
                        urb-iso_frame_desc[i].actual_length);

 -               if (buf-state == UVC_BUF_STATE_DONE ||
 -                   buf-state == UVC_BUF_STATE_ERROR)
 +               if (buf-state == UVC_BUF_STATE_DONE)
                        buf = uvc_queue_next_buffer(stream-queue, buf);
        }
  }
 @@ -637,8 +636,7 @@
                if (!stream-bulk.skip_payload  buf != NULL) {
                        uvc_video_decode_end(stream, buf, stream-bulk.header,
                                stream-bulk.payload_size);
 -                       if (buf-state == UVC_BUF_STATE_DONE ||
 -                           buf-state == UVC_BUF_STATE_ERROR)
 +                       if (buf-state == UVC_BUF_STATE_DONE)
                                buf = uvc_queue_next_buffer(stream-queue,
                                                            buf);
                }
 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvcvideo.h
 --- a/linux/drivers/media/video/uvc/uvcvideo.h  Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvcvideo.h  Wed Dec 16 11:47:40 2009 +0100
 @@ -370,7 +370,8 @@
        UVC_BUF_STATE_QUEUED

Capturing errors when doing v4l2_read

2010-04-08 Thread Pablo Baena
I'm trying to detect when a user unplugs a camera while I'm doing
v4l2_read, but even when I get logs like this:

libv4l2: error queuing buf 0: No such device
libv4l2: error queuing buf 1: No such device
libv4l2: error queuing buf 2: No such device
libv4l2: error dequeuing buf: Input/output error

errno is not containing any errors, and I get a previously retrieved
buffer anyway.

Is this correct behaviour? Shouldn't it return an error? For the
moment, can I do something to workaround this?

-- 
The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong
One. 'Do it yourself'. Yes, that's it.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html