Bug in lxv4l2?

Oliver Urbann ciVic at web.de
Mon May 19 15:58:51 EDT 2008


Hi,

i am using an AMD Geode with a cam (with v4l driver). In some cases the
kernel shows the following when i am reading from /dev/video0:

------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:682!
invalid opcode: 0000 [#1]
PREEMPT
Modules linked in: lxv4l2 i2c_serial zd1211rw
CPU:    0
EIP:    0060:[<c0344c23>]    Not tainted VLI
EFLAGS: 00010046   (2.6.22.9-aldebaran-rt #1)
EIP is at rt_spin_lock_slowlock+0x5e/0x176
eax: ceb92bf0   ebx: 00000282   ecx: c13d8414   edx: ceb92bf0
esi: c13d8404   edi: c13d8404   ebp: ce06001c   esp: ca467e80
ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068  preempt:00000002
Process naoqi (pid: 2992, ti=ca466000 task=ceb92bf0 task.ti=ca466000)
Stack: 00000086 307f4268 00000026 00000046 c0403998 ceb92bf0 307f4268
00000026
       ffffffff ca466000 ceb92bf0 ca467ec0 c034462d 00000000 d03d547c
ce06001c
       c13d8400 c13d8404 ce06001c d08d9f39 d0342000 d03d547c 086261bc
d0342000
Call Trace:
 [<c034462d>] preempt_schedule_irq+0x3b/0x53
 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2]
 [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2]
 [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2]
 [<d08dc7bd>] vid_read+0x130/0x13c [lxv4l2]
 [<d08dc68d>] vid_read+0x0/0x13c [lxv4l2]
 [<c01588f2>] vfs_read+0x88/0x110
 [<c0158c33>] sys_read+0x41/0x67
 [<c0103d1a>] syscall_call+0x7/0xb
 =======================
Code: f0 e8 8a 08 df ff 85 c0 74 11 53 9d 89 e0 25 00 e0 ff ff ff 48 14 e9
14 01 00 00 8b 15 00 f0 3f c0 8b 46 10 83 e0 fc 39 d0 75 04 <0f> 0b eb fe b8
04 00 00 00 87 02 89 44 24 04 89 e5 81 e5 00 e0
EIP: [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176 SS:ESP 0068:ca467e80
note: naoqi[2992] exited with preempt_count 1
BUG: scheduling while atomic: naoqi/0x00000002/2992, CPU#0
 [<c0343ec0>] __schedule+0x85/0x383
 [<c012ef0b>] hrtimer_interrupt+0x16e/0x196
 [<c034442a>] schedule+0xe5/0xfb
 [<c0344f37>] rt_mutex_slowlock+0x193/0x237
 [<c0344bc2>] rt_mutex_lock+0x2b/0x2e
 [<c01342dd>] futex_wake+0x22/0xc2
 [<c0130000>] timekeeping_resume+0x30/0xc2
 [<c01343fe>] do_futex+0x81/0x9d3
 [<c02563ab>] serial8250_console_putchar+0x33/0x76
 [<c0251c9e>] uart_console_write+0x29/0x33
 [<c0256378>] serial8250_console_putchar+0x0/0x76
 [<c011da98>] release_console_sem+0x180/0x1b0
 [<c0134e35>] sys_futex+0xe5/0xf7
 [<c010609a>] do_IRQ+0x67/0x7d
 [<c011b96e>] mm_release+0x81/0x87
 [<c011ea46>] exit_mm+0x12/0xd3
 [<c011fec1>] do_exit+0x1ba/0x722
 [<c01050a5>] die+0x1d3/0x1db
 [<c010542a>] do_invalid_op+0x0/0x8a
 [<c01054ab>] do_invalid_op+0x81/0x8a
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c0108ee7>] pit_next_event+0x2f/0x34
 [<c0131f96>] clockevents_program_event+0xb5/0xbc
 [<c0132cf6>] tick_program_event+0x2a/0x49
 [<c0119251>] update_curr+0x235/0x256
 [<c0345612>] error_code+0x6a/0x70
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c034462d>] preempt_schedule_irq+0x3b/0x53
 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2]
 [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2]
 [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2]
 [<d08dc7bd>] vid_read+0x130/0x13c [lxv4l2]
 [<d08dc68d>] vid_read+0x0/0x13c [lxv4l2]
 [<c01588f2>] vfs_read+0x88/0x110
 [<c0158c33>] sys_read+0x41/0x67
 [<c0103d1a>] syscall_call+0x7/0xb
 =======================
BUG: scheduling while atomic: naoqi/0x00000002/2992, CPU#0
 [<c0343ec0>] __schedule+0x85/0x383
 [<c034442a>] schedule+0xe5/0xfb
 [<c0344f37>] rt_mutex_slowlock+0x193/0x237
 [<c0344bc2>] rt_mutex_lock+0x2b/0x2e
 [<c011ea58>] exit_mm+0x24/0xd3
 [<c011fec1>] do_exit+0x1ba/0x722
 [<c01050a5>] die+0x1d3/0x1db
 [<c010542a>] do_invalid_op+0x0/0x8a
 [<c01054ab>] do_invalid_op+0x81/0x8a
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c0108ee7>] pit_next_event+0x2f/0x34
 [<c0131f96>] clockevents_program_event+0xb5/0xbc
 [<c0132cf6>] tick_program_event+0x2a/0x49
 [<c0119251>] update_curr+0x235/0x256
 [<c0345612>] error_code+0x6a/0x70
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c034462d>] preempt_schedule_irq+0x3b/0x53
 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2]
 [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2]
 [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2]
 [<d08dc7bd>] vid_read+0x130/0x13c [lxv4l2]
 [<d08dc68d>] vid_read+0x0/0x13c [lxv4l2]
 [<c01588f2>] vfs_read+0x88/0x110
 [<c0158c33>] sys_read+0x41/0x67
 [<c0103d1a>] syscall_call+0x7/0xb
 =======================


On the call stack i found the function v4l_capt_unstall() just before
preempt_schedule_irq and so i took a look into the lxv4l2 driver. I
found the following function, which calls v4l_capt_unstall(), in v4l.c:

int v4l_qbfr(VidDevice *dp,struct list_head *lp,io_buf *bp,int capt)
{
   unsigned long flags;
   FilePriv *fp = &dp->fp;
   io_queue *io = fp->io;
   spin_lock_irqsave(&io->lock, flags);
   list_move_tail(&bp->bfrq,lp);
   bp->sequence = io->sequence++;
   bp->flags &= ~V4L2_BUF_FLAG_DONE;
   bp->flags |= V4L2_BUF_FLAG_QUEUED;
   if( capt != 0 && dp->capt_stalled != 0 )
      v4l_capt_unstall(dp);
   spin_unlock_irqrestore(&io->lock, flags);
}


And here is v4l_capt_unstall():

int v4l_capt_unstall(VidDevice *dp)
{
   unsigned long flags;
   int ret = 0;
   FilePriv *fp = &dp->fp;
   io_queue *io = fp->io;
   spin_lock_irqsave(&io->lock, flags);
   if( dp->capt_state == capt_state_run ) {
      if( io != NULL ) {
         if( dp->capt_stalled != 0 )
            DMSG(4,"capt resumed\n");
         ret = lx_capt_resume(dp,io);
      }
   }
   spin_unlock_irqrestore(&io->lock, flags);
   return ret;
}

I was wondering about the spin lock. The function v4l_capt_unstall() already
locks io->lock, calls v4l_capt_unstall() and there again it tries to lock
io->lock. I think this should end in a deadlock?

Oliver Urbann
 




More information about the Linux-geode mailing list