[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20060919111448.9274c699.akpm@osdl.org>
Date: Tue, 19 Sep 2006 11:14:48 -0700
From: Andrew Morton <akpm@...l.org>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ayaz Abdulla <aabdulla@...dia.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Jeff Garzik <jeff@...zik.org>, Ingo Molnar <mingo@...e.hu>,
Arjan van de Ven <arjan@...ux.intel.com>,
Dave Jones <davej@...hat.com>
Subject: Re: [PATCH] forcedeth: hardirq lockdep warning
On Tue, 19 Sep 2006 14:55:22 +0200
Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted)
I wonder what line that was. DEBUG_LOCKS_WARN_ON(current->hardirq_context),
I suppose.
> Call Trace:
> show_trace
> dump_stack
> trace_hardirqs_on
> :forcedeth:nv_nic_irq_other
> handle_IRQ_event
> __do_IRQ
> do_IRQ
> ret_from_intr
> DWARF2 barf
It's good, isn't it?
> default_idle
> cpu_idle
> rest_init
> start_kernel
> _sinittext
>
> These 3 functions nv_nic_irq_tx(), nv_nic_irq_rx() and nv_nic_irq_other()
> are reachable from IRQ context and process context.
That's "fix deadlock", not "fix lockdep warning". However it's often the
case that it's not really deadlockable because (often) the card's IRQ line
has been disabled. That appears to be the case in nv_do_nic_poll()'s call
to nv_nic_irq_tx, for example.
> Make use of the
> irq-save/restore spinlock variant.
So this perhaps is another lockdep workaround..
-
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