On Thu, Jun 19, 2008 at 04:40:00PM +1000, Brian May wrote:
> Does the following help? I still have the logs of the other processes, if
> required (just in case it is some weird interaction between multiple
> processes?)
>
> It seems to be pretty consistent with lock_timer_base, every time I look
> (assuming I haven't read the stack trace upside down...).
>
> Jun 19 16:33:30 hq kernel: grep S 00000000 0 12793 12567
> (NOTLB)
>
> Jun 19 16:33:30 hq kernel: f0c23e7c 00200082 000a1089 00000000
> 00000010 00000008 cd0db550 dfa97550
> Jun 19 16:33:30 hq kernel: 34f84262 00273db2 0008a1dc 00000001
> cd0db660 c20140a0 dfe1cbe8 00200286
> Jun 19 16:33:30 hq kernel: c0125380 a4dbf26b dfa6a000 00200286
> 000000ff 00000000 00000000 a4dbf26b
> Jun 19 16:33:30 hq kernel: Call Trace:
>
> Jun 19 16:33:30 hq kernel: [<c0125380>] lock_timer_base+0x15/0x2f
>
> Jun 19 16:33:30 hq kernel: [<c027f960>] schedule_timeout+0x71/0x8c
>
> Jun 19 16:33:30 hq kernel: [<c0124a81>] process_timeout+0x0/0x5
>
> Jun 19 16:33:30 hq kernel: [<c016c801>] __break_lease+0x2a8/0x2b9
That's the lease breaking code in the VFS, long before we call
into XFS. Looks like someone (samba?) has a least on this file and
we're having trouble having it broken. Try sending a report about
this to linux-fsdevel@xxxxxxxxxxxxxxx
|