panic "ffs_checkblk: bad block" on recent -head kernels

Hi,

I get a fairly reproducible panic when doing a full kernel build
on a 256Mbyte single core i386 when running recent kernels from -head.

The panic is "ffs_checkblk: bad block ..". I don't actually have the
block # (although I think it's just 0xfffffffffffffff, given the backtrace),
because it runs off the screen. (I looked up the message via the debugger
from the first arg. to panic.)

Here's the backtrace without all the numbers:
panic(c14f4b55, ffffffff, ffffffff, 0, 64,...)
ffs_checkblk(ffffffff, 8000, fffffff9c, ffffffff, c4a02454,...)
ffs_reallocblks
VOP_REALLOCBLKS_APV
cluster_write
ffs_write
VOP_WRITE_APV
vn_write
vn_io_fault_doio
vn_io_fault1
vn_io_fault
dofilewrite
kern_writev
sys_write
syscall

It doesn't happen on a kernel dated Sep. 30, but does happen on a Nov. 30 one.
(I was away from home, so I didn't upgrade kernels for 2 months.)

I am slowly doing a binary search for the first kernel rev. where it occurs,
but since each build takes hours, it's going to take a while;-).

At this point, it doesn't appear to happen on r289278 (just before jeff_at_'s buffer
cache patch).
With kernels between r289279-->r290480, I get into the "R" state that
was fixed by r290481 before I get a crash.
I tried reverting r289405 and r290047 from a recent kernel and the crashes still
occurred, so it doesn't appear to be these commits.

I am currently testing r290481 to see if the crash occurs for this rev.

If anyone has some insight into which commit might cause this, please let me know.

Also, if you want more info about if from "db", just let me know what you want,
because I can reproduce it in a few hours.

rick