On Wednesday, March 12, 2003 7:17 PM [GMT+1=CET],
Gary Duzan <gary@duzan.org> wrote:

>
===========================================================================
> panic: dirty blocks
> Stopped in pid 11.1 (ioflush) at        cpu_Debugger+0x4:       leave
> db> trace
> cpu_Debugger(0,e34fa000,0,c01ac492,c03339ce) at cpu_Debugger+0x4
> panic(c03339ec,e3669000,e34fa000,1,c0df1000) at panic+0xb8
> lfs_segwrite(c0defa00,5,e2fc2f68,c01e986b,0) at lfs_segwrite+0x5d7
> lfs_sync(c0defa00,3,c0c55f00,e2fbe1a8,e34fe01c) at lfs_sync+0x74
> sync_fsync(e2fc2f68,12,0,0,e2f7a500) at sync_fsync+0x5c
> sched_sync(e2f7a500,e2fb05a0,0,0,c010030c) at sched_sync+0x11e
> db>
>
===========================================================================
>
>    I seem to be able to recreate this with a fair amount of disk
> activity, like a "build.sh install=/" or a "build.sh release" with
> DESTDIR/obj/tools/release all on the same LFS. "reboot 100" locks
> up the machine, so I don't have a good crash dump. I was seeing
> something similar before the UBC support became the default, so I
> don't think it is related.


I see similar things here, reported as kern/20653. ;-(