Re: 2.6.23-rc2-mm2 -- When suspending, "INFO: inconsistent lock state" -- 8139too issue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 10 Aug 2007 14:32:27 -0400
"Miles Lane" <[email protected]> wrote:

> [ INFO: inconsistent lock state ]
> 2.6.23-rc2-mm2 #10
> ---------------------------------
> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> ifconfig/8425 [HC0[0]:SC0[0]:HE1:SE1] takes:
>  (&tp->lock){++..}, at: [<f882f65a>] rtl8139_interrupt+0x22/0x37e [8139too]
> {in-hardirq-W} state was registered at:
>   [<c0133ede>] __lock_acquire+0x3f0/0xb6f
>   [<c01346be>] lock_acquire+0x61/0x7d
>   [<c03127b4>] _spin_lock+0x23/0x32
>   [<f882f65a>] rtl8139_interrupt+0x22/0x37e [8139too]
>   [<c0143f96>] handle_IRQ_event+0x1a/0x46
>   [<c0144f2f>] handle_fasteoi_irq+0x72/0xab
>   [<c0105b82>] do_IRQ+0xab/0xd5
>   [<ffffffff>] 0xffffffff
> irq event stamp: 1551
> hardirqs last  enabled at (1551): [<c0161db2>] kfree+0xb9/0xc3
> hardirqs last disabled at (1550): [<c0161d5c>] kfree+0x63/0xc3
> softirqs last  enabled at (1530): [<c02a6510>] dev_deactivate+0x86/0x9f
> softirqs last disabled at (1528): [<c03127ce>] _spin_lock_bh+0xb/0x37
> 
> other info that might help us debug this:
> 1 lock held by ifconfig/8425:
>  #0:  (rtnl_mutex){--..}, at: [<c03116b7>] mutex_lock+0x1c/0x1f
> 
> stack backtrace:
>  [<c0104c92>] show_trace_log_lvl+0x12/0x25
>  [<c0105476>] show_trace+0xd/0x10
>  [<c010557a>] dump_stack+0x15/0x17
>  [<c0132af2>] print_usage_bug+0x10a/0x117
>  [<c01332fc>] mark_lock+0x1e0/0x3fa
>  [<c0133f59>] __lock_acquire+0x46b/0xb6f
>  [<c01346be>] lock_acquire+0x61/0x7d
>  [<c03127b4>] _spin_lock+0x23/0x32
>  [<f882f65a>] rtl8139_interrupt+0x22/0x37e [8139too]
>  [<c0144453>] free_irq+0xc0/0xe9
>  [<f88308f0>] rtl8139_close+0xa0/0x130 [8139too]
>  [<c0299767>] dev_close+0x4d/0x6a
>  [<c0298a70>] dev_change_flags+0x9f/0x152
>  [<c02d057d>] devinet_ioctl+0x209/0x505
>  [<c02d0e9a>] inet_ioctl+0x86/0xa4
>  [<c028fa47>] sock_ioctl+0x1a6/0x1c4
>  [<c016e532>] do_ioctl+0x22/0x67
>  [<c016e7c9>] vfs_ioctl+0x252/0x265
>  [<c016e808>] sys_ioctl+0x2c/0x48
>  [<c0103cea>] sysenter_past_esp+0x5f/0x99
>  =======================
> ACPI: PCI interrupt for device 0000:01:00.0 disabled
> ACPI: PCI interrupt for device 0000:01:06.0 disabled
> ieee80211_crypt: unregistered algorithm 'NULL'
> Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> 

OK, what's happened here is that lockdep has decided that 8139too's
tp->lock is a taken-from-interrupts lock.  Then it sees that lock being
taken from regular old process context and it says "hey, if an interrupt
were to happen now, you'd deadlock".

The offending callsite is free_irq():

#ifdef CONFIG_DEBUG_SHIRQ
	if (handler) {
		/*
		 * It's a shared IRQ -- the driver ought to be prepared for it
		 * to happen even now it's being freed, so let's make sure....
		 * We do this after actually deregistering it, to make sure that
		 * a 'real' IRQ doesn't run in parallel with our fake
		 */
		handler(irq, dev_id);
	}
#endif

Ingo: recommendations, please?  Put a local_irq_save() around it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux