Messages in this thread | | | From | "Michael S. Zick" <> | Subject | Re: [BUG FIX] Make x86_32 uni-processor Atomic ops, Atomic | Date | Wed, 27 May 2009 17:33:37 -0500 |
| |
On Wed May 27 2009, Roland Dreier wrote: > > > The only objective information is posted here: > > http://lkml.org/lkml/2009/5/20/342 > > Not sure if you've looked at this, but it's a lockdep trace that looks > to be a valid lockdep report due to non-annotated code (I don't *think* > it's a bug). To summarize, there is the code path in > kernel/irq/spurious.c that does: >
I haven't looked at it - beyond my skill level.
Still trying to deal with a machine where the only symptom is a deadlock. So I post these for someone else's eyes until I figure out the deadlock.
Mike
> poll_spurious_irq_timer -> > poll_spurious_irqs() [from timer, with hard IRQs on] -> > poll_all_shared_irqs() [if we think an IRQ got stuck] -> > try_one_irq() -> > spin_lock(&desc->lock) [as above -- hard IRQs on] > > while kernel/irq/chip.c has: > > handle_level_irq() [called with hard IRQs off] -> > spin_lock(&desc->lock) [as above -- hard IRQs off] > > and lockdep can't tell that the interrupt corresponding to desc has been > disabled if we ever actually reach try_one_irq(), so there's no risk of > the interrupt coming in and deadlocking while the try_one_irq() code > holds desc->lock. > > Unfortunately I don't know how to annotate this... > >
| |