[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tkrat.fcd947ba88aa56a8@s5r6.in-berlin.de>
Date: Tue, 22 Jan 2008 23:51:27 +0100 (CET)
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: Peter Zijlstra <peterz@...radead.org>
cc: Denys Fedoryshchenko <denys@...p.net.lb>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Davide Libenzi <davidel@...ilserver.org>
Subject: Re: 2.6.24-rc7 to 2.6.24-rc8 possible regression
(adding Cc: Davide and akpm)
On 22 Jan, Peter Zijlstra wrote:
>
> On Tue, 2008-01-22 at 17:23 +0100, Stefan Richter wrote:
>> Denys Fedoryshchenko wrote:
>> > No, i am using vanilla kernel. It is one of production machines, and as i
>> > know screen is not using epoll.
>>
>> OK, but the trace shows that it is the epoll recursion again.
>>
>> > I will try to apply on all my production machines this patch. Sorry if it is
>> > related.
>>
>> Well, let's hope that the lockdep annotation or whatever other fix gets
>> into mainline sooner than later. Which reminds me to test my setup
>> again which appeared to be able to reproduce the __wake_up recursion on
>> my command...
>
> Would be appreciated, I have been waiting on testing feedback because
> I'm not fully certain here.
>
> Curious though that this gets reported frequently the last few weeks,
> afaics this problem is way old.
Here is a report against Fedora's 2.6.23-0.222.rc9.git4.fc8, filed in
October: https://bugzilla.redhat.com/show_bug.cgi?id=323411
I did several tests with a pristine 2.6.24-rc8 now. The lockdep warning
below is 100% reliably triggered by grabbing video from a DV camcorder
with dvgrab v3 via firewire-core's character device file ABI.
Also, this warning is 100% reliably suppressed by your annotation patch.
I will reply to this message with this patch for kind consideration by
those concerned. :-)
=============================================
[ INFO: possible recursive locking detected ]
2.6.24-rc8 #1
---------------------------------------------
swapper/0 is trying to acquire lock:
(&q->lock){++..}, at: [<ffffffff8022aef7>] __wake_up+0x22/0x4e
but task is already holding lock:
(&q->lock){++..}, at: [<ffffffff8022aef7>] __wake_up+0x22/0x4e
other info that might help us debug this:
1 lock held by swapper/0:
#0: (&q->lock){++..}, at: [<ffffffff8022aef7>] __wake_up+0x22/0x4e
stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc8 #1
Call Trace:
<IRQ> [<ffffffff8024ec38>] __lock_acquire+0x1c5/0xc68
[<ffffffff8024faa1>] lock_acquire+0x51/0x6c
[<ffffffff8022aef7>] __wake_up+0x22/0x4e
[<ffffffff8041499b>] _spin_lock_irqsave+0x37/0x47
[<ffffffff8022aef7>] __wake_up+0x22/0x4e
[<ffffffff802a926e>] ep_poll_safewake+0x86/0xc5
[<ffffffff802aa15a>] ep_poll_callback+0xc1/0xcb
[<ffffffff80228d4d>] __wake_up_common+0x41/0x74
[<ffffffff8022af0d>] __wake_up+0x38/0x4e
[<ffffffff8806888c>] :firewire_core:fw_core_handle_request+0x1b0/0x1eb
[<ffffffff8807301f>] :firewire_ohci:handle_ar_packet+0xfb/0x10f
[<ffffffff88073f01>] :firewire_ohci:ar_context_tasklet+0xd6/0xe7
[<ffffffff80236328>] tasklet_action+0x5d/0xb0
[<ffffffff80236229>] __do_softirq+0x5d/0xe0
[<ffffffff8021dc2f>] ack_apic_level+0x10/0xdc
[<ffffffff8020c9fc>] call_softirq+0x1c/0x28
[<ffffffff8020e839>] do_softirq+0x31/0x94
[<ffffffff8023616c>] irq_exit+0x45/0x51
[<ffffffff8020e954>] do_IRQ+0xb8/0xd8
[<ffffffff8020bcc6>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff8021c2da>] lapic_next_event+0x0/0xa
[<ffffffff8022cde9>] sched_clock_idle_wakeup_event+0x46/0x63
[<ffffffff8805a746>] :processor:acpi_idle_enter_simple+0x179/0x1df
[<ffffffff8805a73c>] :processor:acpi_idle_enter_simple+0x16f/0x1df
[<ffffffff803b4608>] cpuidle_idle_call+0x79/0xad
[<ffffffff803b458f>] cpuidle_idle_call+0x0/0xad
[<ffffffff8020a5e4>] cpu_idle+0x95/0xcc
[<ffffffff80571a8a>] start_kernel+0x2d3/0x2df
[<ffffffff80571115>] _sinittext+0x115/0x11c
--
Stefan Richter
-=====-==--- ---= =-==-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists