> 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.
A thought occurs, which compiler are you using, I seem to remember people
with things like VIA chipsets needing to use kgcc to get a stable kernel.
Also, if you can repeat this I can probably come up with some other
kdb commands you can run which may help me work it out, but only if
you can get a serial console, otherwise it will HURT!
Steve
>
>
> --
> 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.
> >
> >
|