Hi Mark,
I'll be looking at this during the weekend. It's a very interesting result
and it will be an nice challenge to figure out how this deadlock can occur
:-)
Regards,
Hans
>
> And again :(
>
>
>
> ivtv67108864: dma_reg_lock already locked! Deadlocked...
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> [<c0142267>] __lock_acquire+0x4ac/0x10f7
> [<c0124d77>] wake_up_klogd+0x37/0x3b
> [<c012d4bf>] __mod_timer+0x94/0xa3
> [<c0142f2c>] lock_acquire+0x7a/0x94
> [<f500ed41>] ivtv_irq_handler+0x2b/0x107a [ivtv]
> [<c03ca38c>] _spin_lock+0x2c/0x55
> [<f500ed41>] ivtv_irq_handler+0x2b/0x107a [ivtv]
> [<f500ed41>] ivtv_irq_handler+0x2b/0x107a [ivtv]
> [<c014d493>] handle_IRQ_event+0x1e/0x48
> [<c014e6aa>] handle_fasteoi_irq+0x64/0xc9
> [<c0106120>] do_IRQ+0x3b/0x7b
> [<c010497e>] common_interrupt+0x2e/0x34
> [<f50100d8>] ivtv_api_call+0x231/0x54f [ivtv]
> [<f50104f0>] ivtv_buf_swap+0x10/0x25 [ivtv]
> [<f50080e6>] ivtv_v4l2_read+0xa89/0xadd [ivtv]
> [<c0141887>] trace_hardirqs_on+0xb6/0x156
> [<c016f51a>] fget_light+0xae/0xb6
> [<c0136eb2>] autoremove_wake_function+0x0/0x37
> [<c016e98c>] vfs_read+0x89/0x117
> [<f500765d>] ivtv_v4l2_read+0x0/0xadd [ivtv]
> [<c016eddf>] sys_read+0x41/0x6a
> [<c0103f6e>] syscall_call+0x7/0xb
> =======================
> BUG: spinlock lockup on CPU#0, hsp/1457, c8500c08
> [<c01d6c4e>] _raw_spin_lock+0x108/0x13c
> [<c03ca3a9>] _spin_lock+0x49/0x55
> [<f500ed41>] ivtv_irq_handler+0x2b/0x107a [ivtv]
> [<f500ed41>] ivtv_irq_handler+0x2b/0x107a [ivtv]
> [<c014d493>] handle_IRQ_event+0x1e/0x48
> [<c014e6aa>] handle_fasteoi_irq+0x64/0xc9
> [<c0106120>] do_IRQ+0x3b/0x7b
> [<c010497e>] common_interrupt+0x2e/0x34
> [<f50100d8>] ivtv_api_call+0x231/0x54f [ivtv]
> [<f50104f0>] ivtv_buf_swap+0x10/0x25 [ivtv]
> [<f50080e6>] ivtv_v4l2_read+0xa89/0xadd [ivtv]
> [<c0141887>] trace_hardirqs_on+0xb6/0x156
> [<c016f51a>] fget_light+0xae/0xb6
> [<c0136eb2>] autoremove_wake_function+0x0/0x37
> [<c016e98c>] vfs_read+0x89/0x117
> [<f500765d>] ivtv_v4l2_read+0x0/0xadd [ivtv]
> [<c016eddf>] sys_read+0x41/0x6a
> [<c0103f6e>] syscall_call+0x7/0xb
> =======================
>
>
>
>
> Hans Verkuil wrote:
>> On Wednesday 12 December 2007 11:05:30 Mark Bryars wrote:
>>
>>> Got a slightly different type of crash over the last two days.
>>>
>>> Any suggestions of what to try to help fix this would be appreciated.
>>>
>>> Regards,
>>> Mark
>>>
>>
>> Hi Mark,
>>
>> Looking at the traces you've provided I'm beginning to suspect that some
>> interrupt handler locks up. Especially the EIP at _spin_lock is
>> suspicious. I went over the ivtv interrupt code again and I simply
>> cannot find anything wrong.
>>
>> There are a few things you can try: first turn on all the
>> spinlock-related debug options inside the Kernel hacking / Kernel
>> debugging config menu. See if that turns up anything interesting.
>>
>> At the same time you can also add the following code to the
>> ivtv_irq_handler() function before the spin_lock line at the start:
>>
>> if (spin_is_locked(&itv->dma_reg_lock))
>> IVTV_ERR("dma_reg_lock already locked! Deadlocked...\n");
>>
>> This assumes that you do not have an PVR-350, or if you do that you do
>> not use any of the decoding facilities of the PVR-350. The lock is only
>> there to protect against MPEG encoding/decoding interactions. If you do
>> no hardware decoding then this lock should never be held at the start
>> of the interrupt function. So if you ever see the Deadlocked message,
>> then we know that there is a race condition.
>>
>> The other spin_lock that is used in interrupt context is qlock. You can
>> add the following code in ivtv-queue.c before each
>> spin_lock_irqsave(&s->qlock, flags) line (it's used three times):
>>
>> if (in_interrupt() && spin_is_locked(&s->qlock))
>> printk("qlock deadlock!\n");
>>
>> Basically this lock should never be held when called from interrupt
>> context.
>>
>> As far as I can see neither of these two locks can ever fail, but it
>> can't hurt to put in these checks regardless.
>>
>> Let's see what happens...
>>
>> Regards,
>>
>> Hans
>>
>
>
> --
> Mark Bryars
> Senior Software Developer
> ETV Interactive Ltd
> Logie Court
> Stirling University Innovation Park
> Stirling
> Scotland, UK
> FK9 4NF
> T: +44 (0) 1786 455150
> F: +44 (0) 1786 455179
> W: www.etvinteractive.com
>
>
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
