Hi Andrew,
Bit more testing here...
I'm able to oops the box by simply attempting to log in, either locally or
remotely (through ssh). This is without f/s activity, so that was just a
red herring.
Need to run Russell's script next.
--
Regards,
Juha
PGP fingerprint:
B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544
On Tue, 19 Jun 2001, Andrew Morton wrote:
>
> Ah. ll_rw_blk.c:700. I know it well.
>
> My bet: A buffer was unmapped in block_flushpage() but somehow
> somebody set it dirty again, and bdflush/kupdate tried to write
> the thing out.
>
> For ext3 I have implemented a "buffer tracing" mechanism. At
> any interesting pointin the lifecycle of a buffer_head you
> call
>
> BUFFER_TRACE(bh, "some descriptive text")
>
> then, thoughout the code I've added things like:
>
> J_ASSERT_BH(bh, some_expression);
>
> If the assertion fails you get a 64-slot backtrace of
> all the buffer's state transitions. There's an example
> output trace from when I was hitting exactly this same BUG()
> at http://www.zip.com.au/~akpm/buffer-trace.txt - it's great.
> See how journal_commit_transaction incorrectly sets the
> buffer dirty and then flush_dirty_buffers grabs it.
>
> I guess it's a bit late in XFS's development cycle to incorporate
> something like this though.
>
>
|