Bug 323411 - 2.6.23-rc9-git4: Firewire: possible recursive locking detected
2.6.23-rc9-git4: Firewire: possible recursive locking detected
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-08 13:34 EDT by Pat Kane
Modified: 2008-02-25 15:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-25 15:07:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (23.87 KB, text/plain)
2007-10-08 13:34 EDT, Pat Kane
no flags Details
full dmesg output for 2.6.23-1.fc8 kernel (23.64 KB, text/plain)
2007-10-09 23:18 EDT, Pat Kane
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 9786 None None None Never

  None (edit)
Description Pat Kane 2007-10-08 13:34:48 EDT
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:
Comment 1 Pat Kane 2007-10-08 13:34:48 EDT
Created attachment 219951 [details]
dmesg output
Comment 2 Stefan Richter 2007-10-08 18:34:13 EDT
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
Comment 3 Pat Kane 2007-10-09 23:17:28 EDT
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
   =======================
Comment 4 Pat Kane 2007-10-09 23:18:59 EDT
Created attachment 222131 [details]
full dmesg output for 2.6.23-1.fc8 kernel
Comment 5 Pat Kane 2007-10-10 01:03:34 EDT
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.
Comment 6 Stefan Richter 2007-10-11 17:30:19 EDT
To the Fedora kernel maintainers:  Does this kernel's __wake_up() or its lockdep
code differ from mainline?
Comment 7 Dave Jones 2007-10-12 19:56:43 EDT
__wake_up is identical to 2.6.23
kernel/lockdep.c is also identical in both.
Comment 8 Stefan Richter 2008-01-11 14:50:23 EST
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.
Comment 9 Stefan Richter 2008-01-14 13:09:48 EST
> 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
Comment 10 Stefan Richter 2008-01-28 14:22:04 EST
Bug status:  Andrew Morton picked up the lockdep annotation patch, but it didn't
appear in Linus' tree yet.
Comment 11 Jarod Wilson 2008-01-28 17:38:50 EST
Added to rawhide, should be in 2.6.24-5.fc9 and later...
Comment 12 Christopher Brown 2008-02-03 17:44:45 EST
Re-assinging as per triage page. Please could all reporters test with a rawhide
kernel.
Comment 13 Stefan Richter 2008-02-05 17:39:07 EST
lockdep annotation is now also in upstream, commit
0ccf831cbee94df9c5006dd46248c0f07847dd7c
Comment 14 Jarod Wilson 2008-02-25 15:07:38 EST
Haven't been able to reproduce anytime lately, closing bug. Please reopen if
this still happens w/the latest rawhide kernels.

Note You need to log in before you can comment on or make changes to this bug.