On Fri, Jun 20, 2008 at 11:11:54AM +1000, Brian May wrote: > Brian May wrote: >> Stephen Rothwell wrote: >>> Its what samba calls an oplock. Its like a kernel file lock but it >>> blocks opens and notifies the holder (who is supposed to clean up and >>> release the lease). If the lease is not released in 45 seconds (by >>> default) then the kernel assumes that the holder is broken and breaks >>> the >>> lease and allows the open to proceed. >>> >> Ok, so I guess it is most likely Samba's fault then. Most likely this >> is the only application that uses leases/oplocks on this computer >> anyway. I will keep investigating... > Maybe I spoke too soon when I ruled XFS out :-(. .... > hq:~# echo t > /proc/sysrq-trigger > Gives a stack trace of: > > Jun 20 10:54:37 hq kernel: Call Trace: > > Jun 20 10:54:37 hq kernel: [<c0125380>] lock_timer_base+0x15/0x2f > Jun 20 10:54:37 hq kernel: [<c027f960>] schedule_timeout+0x71/0x8c > Jun 20 10:54:37 hq kernel: [<c0124a81>] process_timeout+0x0/0x5 > Jun 20 10:54:37 hq kernel: [<c016a115>] do_select+0x37a/0x3d4 > Jun 20 10:54:37 hq kernel: [<c016a677>] __pollwait+0x0/0xb2 > Jun 20 10:54:37 hq kernel: [<c0117778>] default_wake_function+0x0/0xc > Jun 20 10:54:37 hq kernel: [<c0117778>] default_wake_function+0x0/0xc > Jun 20 10:54:37 hq kernel: [<f88e998f>] e1000_xmit_frame+0x928/0x958 [e1000] > Jun 20 10:54:37 hq kernel: [<c0121c24>] tasklet_action+0x55/0xaf > Jun 20 10:54:37 hq kernel: [<c022950a>] dev_hard_start_xmit+0x19a/0x1f0 > Jun 20 10:54:37 hq kernel: [<f8ae3e6d>] xfs_iext_bno_to_ext+0xd8/0x191 [xfs] > Jun 20 10:54:37 hq kernel: [<f8ac7aec>] xfs_bmap_search_multi_extents+0xa8/0xc5 [xfs] > Jun 20 10:54:37 hq kernel: [<f8ac7b52>] xfs_bmap_search_extents+0x49/0xbe [xfs] > Jun 20 10:54:37 hq kernel: [<f8ac7e35>] xfs_bmapi+0x26e/0x20ce [xfs] > Jun 20 10:54:37 hq kernel: [<f8ac7e35>] xfs_bmapi+0x26e/0x20ce [xfs] > Jun 20 10:54:37 hq kernel: [<c02547e4>] tcp_transmit_skb+0x604/0x632 > Jun 20 10:54:37 hq kernel: [<c02560d3>] __tcp_push_pending_frames+0x6a2/0x758 > Jun 20 10:54:37 hq kernel: [<c016d84e>] __d_lookup+0x98/0xdb > Jun 20 10:54:37 hq kernel: [<c016d84e>] __d_lookup+0x98/0xdb > Jun 20 10:54:37 hq kernel: [<c0165370>] do_lookup+0x4f/0x135 > Jun 20 10:54:37 hq kernel: [<c016dbc4>] dput+0x1a/0x11b > Jun 20 10:54:37 hq kernel: [<c0167312>] __link_path_walk+0xbe4/0xd1d > Jun 20 10:54:37 hq kernel: [<c016a3fb>] core_sys_select+0x28c/0x2a9 > Jun 20 10:54:37 hq kernel: [<c01674fe>] link_path_walk+0xb3/0xbd > Jun 20 10:54:37 hq kernel: [<f8afbea1>] xfs_inactive_free_eofblocks+0xdf/0x23f [xfs] > Jun 20 10:54:37 hq kernel: [<c016785d>] do_path_lookup+0x20a/0x225 > Jun 20 10:54:37 hq kernel: [<f8b07de5>] xfs_vn_getattr+0x27/0x2f [xfs] > Jun 20 10:54:37 hq kernel: [<c0161b28>] cp_new_stat64+0xfd/0x10f > Jun 20 10:54:37 hq kernel: [<c016a9c1>] sys_select+0x9f/0x182 > Jun 20 10:54:37 hq kernel: [<c0102c11>] sysenter_past_esp+0x56/0x79 This is just the stupid (broken) ia32 stack tracing - it outputs every single object it sees in the stack that may be function call. Hence you see some stuff that is from past stack traversals. I'd say this is sleeping in a select() call, not doing anything related to xfs or networking.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
