Rahul Jain wrote:
>
> On Sun, Feb 25, 2001 at 05:04:07AM -0600, Rahul Jain wrote:
> >
> > I'm using version 2.4.1 from cvs (I had just completed cvs updating the xfs
> > tree before this happened.)
> >
>
> It looks like the same hang occurs with the latest CVS version, as well,
> giving
> a nearly identical backtrace. I'll look through do_buffer_fdatasync to see if
> there is any obvious place to put printks for debugging.
Hi,
There are 6 calls to do_buffer_fdatasync() from generic_buffer_fdatasync().
I think it is the third that's in your backtrace. You can disassemble
in kdb by "id generic_buffer_fdatasync" and keep issuing "id" at the
kdb prompt to get more lines of dissassembled code.
It's not clear if the do_buffer_fdatasync() is spinning on
the same page of the locked_pages list (i.e, not making forward progress)
or is it stuck in aquiring the pagecache_lock(). One way to find out,
is to install a breakpoint in writeout_one_page() ... this is the fn() passed
in.
"bpa write_one_page+0x4" would do the trick; the 0x4 is so stack is
setup correctly. If you repeatedly hit this breakpoint then its not
the pagecache_lock. Another thing to check the argument to writeout_one_page,
which is displayed in the "bt".
A second note: we are reworking the way sync is performed as an extension
of the delay-buffer patch that i've been sending out, although the sync
changes are not there yet. Still, it'll be interesting to know the effect
of the patch in your test system.
Thanks for your feedback,
ananth.
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------
|