Description of problem: While trying to use dvgrab to input DV from an ADVC-100 Firewire device on my DELL Inspiron 8600 laptop, I got the following console message: ============================================= [ INFO: possible recursive locking detected ] 2.6.23-0.222.rc9.git4.fc8 #1 --------------------------------------------- X/2522 is trying to acquire lock: (&q->lock){++..}, at: [<c042671c>] __wake_up+0x15/0x42 but task is already holding lock: (&q->lock){++..}, at: [<c042671c>] __wake_up+0x15/0x42 other info that might help us debug this: 2 locks held by X/2522: #0: (&client->lock){.+..}, at: [<e0993f51>] queue_event+0x2b/0x68 [firewire_ core] #1: (&q->lock){++..}, at: [<c042671c>] __wake_up+0x15/0x42 stack backtrace: [<c0406463>] show_trace_log_lvl+0x1a/0x2f [<c0406463>] show_trace_log_lvl+0x1a/0x2f [<c0406e4d>] show_trace+0x12/0x14 [<c0406e65>] dump_stack+0x16/0x18 [<c0449c56>] __lock_acquire+0x189/0xc67 [<c044abae>] lock_acquire+0x7b/0x9e [<c0634712>] _spin_lock_irqsave+0x4a/0x77 [<c042671c>] __wake_up+0x15/0x42 [<c04aed7e>] ep_poll_safewake+0x86/0xa8 [<c04afa05>] ep_poll_callback+0x9f/0xaa [<c042483e>] __wake_up_common+0x32/0x55 [<c0426738>] __wake_up+0x31/0x42 [<e0993f7d>] queue_event+0x57/0x68 [firewire_core] [<e0994a5a>] handle_request+0xd8/0xe0 [firewire_core] [<e099269a>] fw_core_handle_request+0x215/0x23c [firewire_core] [<e0961c42>] handle_ar_packet+0xd7/0xeb [firewire_ohci] [<e0962bac>] ar_context_tasklet+0xb6/0xc4 [firewire_ohci] [<c0432b5b>] tasklet_action+0x68/0xd3 [<c0432a39>] __do_softirq+0x78/0xff [<c04075d4>] do_softirq+0x74/0xf7 ======================= full dmesg is attached Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 219951 [details] dmesg output
Patch proposed by Jay: http://marc.info/?l=linux1394-devel&m=119187724402499 But I think the issue is somewhere else: http://marc.info/?l=linux1394-devel&m=119188254809728
I installed the latest Koji kernel build, re-ran my test and I now get this: ============================================= [ INFO: possible recursive locking detected ] 2.6.23-1.fc8 #1 --------------------------------------------- swapper/0 is trying to acquire lock: (&q->lock){++..}, at: [<c042671c>] __wake_up+0x15/0x42 but task is already holding lock: (&q->lock){++..}, at: [<c042671c>] __wake_up+0x15/0x42 other info that might help us debug this: 1 lock held by swapper/0: #0: (&q->lock){++..}, at: [<c042671c>] __wake_up+0x15/0x42 stack backtrace: [<c0406463>] show_trace_log_lvl+0x1a/0x2f [<c0406e4d>] show_trace+0x12/0x14 [<c0406e65>] dump_stack+0x16/0x18 [<c0449c6a>] __lock_acquire+0x189/0xc67 [<c044abc2>] lock_acquire+0x7b/0x9e [<c063476a>] _spin_lock_irqsave+0x4a/0x77 [<c042671c>] __wake_up+0x15/0x42 [<c04aedee>] ep_poll_safewake+0x86/0xa8 [<c04afa75>] ep_poll_callback+0x9f/0xaa [<c042483e>] __wake_up_common+0x32/0x55 [<c0426738>] __wake_up+0x31/0x42 [<e093af90>] queue_event+0x6a/0x72 [firewire_core] [<e093ba64>] handle_request+0xd8/0xe0 [firewire_core] [<e093969a>] fw_core_handle_request+0x215/0x23c [firewire_core] [<e0953c42>] handle_ar_packet+0xd7/0xeb [firewire_ohci] [<e0954bac>] ar_context_tasklet+0xb6/0xc4 [firewire_ohci] [<c0432b5b>] tasklet_action+0x68/0xd3 [<c0432a39>] __do_softirq+0x78/0xff [<c04075d4>] do_softirq+0x74/0xf7 =======================
Created attachment 222131 [details] full dmesg output for 2.6.23-1.fc8 kernel
BTW, I only see that msg the first time (after a boot) I used the firewire device. The captured video looks okay in any case. So maybe this is just an initialization problem.
To the Fedora kernel maintainers: Does this kernel's __wake_up() or its lockdep code differ from mainline?
__wake_up is identical to 2.6.23 kernel/lockdep.c is also identical in both.
Jarod pointed me to this discussion: http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/536c547f11b2fbfd/2d9f8844428cda6c?lnk=raot It's an upstream problem with epoll.
> It's an upstream problem with epoll. Another discussion thread, including a proposed patch which adds lockdep annotation: http://lkml.org/lkml/2008/1/13/47
Bug status: Andrew Morton picked up the lockdep annotation patch, but it didn't appear in Linus' tree yet.
Added to rawhide, should be in 2.6.24-5.fc9 and later...
Re-assinging as per triage page. Please could all reporters test with a rawhide kernel.
lockdep annotation is now also in upstream, commit 0ccf831cbee94df9c5006dd46248c0f07847dd7c
Haven't been able to reproduce anytime lately, closing bug. Please reopen if this still happens w/the latest rawhide kernels.