Bug 323411
| Summary: | 2.6.23-rc9-git4: Firewire: possible recursive locking detected | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pat Kane <pekane52> | ||||||
| Component: | kernel | Assignee: | Jarod Wilson <jarod> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 8 | CC: | cebbert, chris.brown, davej, dcantrell, jarod, krh, pekane52, stefan-r-rhbz | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-02-25 20:07:38 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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. |
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: