I stopped getting oopses from the dbench 64 on a small partition, and
started getting these BUG()s instead.
The oopses I _was_ getting were because create_buffers() was returning a
buffer chain with one of the bh->b_this_page entries set to 0x01010101.
The funny part was that it was always the same number, not a memory
address, or NULL, it was always 0x01010101! The next time through the
loop, "bh->b_end_io = NULL;" was blowing up. (no surprise there :)
I put some code into create_buffers() to look for that magic number, but
stopped getting the oopses after I added a couple of if( XX == 0x0101010
) panic("foo"). I now can't recreate the original oopses. The
disassembly of create_empty_buffers() looked screwy the first time I
looked, so I'm guessing that I just encountered a transient gcc bug or
something. But, I'm still getting those damn "__block_prepare_write:
zeroing uptodate buffer!" messages, in addition to the new BUG(), which
never happened before. The hardware is extremely stable, and 2.4
doesn't show any of these problems.
Have you had anyone else try the dbench torture test on other SMP machines?
-- Dave Hansen haveblue@us.ibm.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/