Hi Stephen,

I had today's next tree compiled and booted on a powerpc box.
While compiling a kernel on the same box saw the following trace
on console.

=================================
[ INFO: inconsistent lock state ]
2.6.29-next-20090324 #3
---------------------------------
inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
yum-updatesd-he/24903 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&inode->inotify_mutex){+.+.?.}, at: [<c000000000152678>] .inotify_inode_queue_event+0x6c/0x160
{IN-RECLAIM_FS-W} state was registered at:
  [<c000000000097634>] .lock_acquire+0x108/0x154
  [<c00000000058a308>] .mutex_lock_nested+0x78/0x460
  [<c000000000152824>] .inotify_inode_is_dead+0x38/0xcc
  [<c00000000012f970>] .dentry_iput+0xa8/0x134
  [<c00000000012fb90>] .d_kill+0x68/0xac
  [<c00000000012fec0>] .__shrink_dcache_sb+0x2ec/0x3b4
  [<c000000000130254>] .shrink_dcache_memory+0x134/0x214
  [<c0000000000e9810>] .shrink_slab+0x144/0x20c
  [<c0000000000e9b50>] .try_to_free_pages+0x278/0x3d4
  [<c0000000000e1eb0>] .__alloc_pages_internal+0x2c8/0x498
  [<c00000000010bc40>] .alloc_page_vma+0x120/0x14c
  [<c0000000000f4e20>] .handle_mm_fault+0x1b8/0x888
  [<c00000000058e564>] .do_page_fault+0x394/0x5b0
  [<c000000000005330>] handle_page_fault+0x20/0x5c
irq event stamp: 182173
hardirqs last  enabled at (182173): [<c000000000111fec>] .kmem_cache_alloc+0xe8/0x14c
hardirqs last disabled at (182172): [<c000000000111b18>] .__slab_alloc+0x298/0x518
softirqs last  enabled at (181818): [<c00000000002bab4>] .call_do_softirq+0x14/0x24
softirqs last disabled at (181803): [<c00000000002bab4>] .call_do_softirq+0x14/0x24

other info that might help us debug this:
4 locks held by yum-updatesd-he/24903:
 #0:  (&type->i_mutex_dir_key#4){+.+.+.}, at: [<c00000000012a6cc>] .do_filp_open+0x188/0x874
 #1:  (&inode->inotify_mutex){+.+.?.}, at: [<c000000000152678>] .inotify_inode_queue_event+0x6c/0x160
 #2:  (&ih->mutex){+.+...}, at: [<c0000000001526a8>] .inotify_inode_queue_event+0x9c/0x160
 #3:  (&dev->ev_mutex){+.+...}, at: [<c000000000153f98>] .inotify_dev_queue_event+0x50/0x1d8

stack backtrace:
Call Trace:
[c000000044c1b560] [c0000000000115f4] .show_stack+0x70/0x184 (unreliable)
[c000000044c1b610] [c000000000093cd4] .print_usage_bug+0x1bc/0x1ec
[c000000044c1b6c0] [c000000000094080] .mark_lock+0x37c/0x6c0
[c000000044c1b770] [c00000000009441c] .mark_held_locks+0x58/0xac
[c000000044c1b800] [c0000000001141ec] .__kmalloc+0x88/0x194
[c000000044c1b8b0] [c000000000153eac] .kernel_event+0xbc/0x158
[c000000044c1b950] [c000000000154068] .inotify_dev_queue_event+0x120/0x1d8
[c000000044c1ba00] [c0000000001526f8] .inotify_inode_queue_event+0xec/0x160
[c000000044c1bad0] [c000000000127d28] .vfs_create+0x168/0x1e4
[c000000044c1bb70] [c00000000012a780] .do_filp_open+0x23c/0x874
[c000000044c1bd10] [c000000000119124] .do_sys_open+0x80/0x140
[c000000044c1bdc0] [c00000000015f0f0] .compat_sys_open+0x24/0x38
[c000000044c1be30] [c000000000008554] syscall_exit+0x0/0x40
==============================

Not too sure what to infer from the above trace :-(
Haven't seen this trace with previous next tree's.

Have attached .config here, just in case it helps.

Thanks
-Sachin


-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------