Re: another one: panic: ffs_blkfree: freeing free block

On Fri, May 02, 2003 at 09:01:33PM +0200, Poul-Henning Kamp wrote:
> In message <20030502185545.3CB4E2A7EA_at_canning.wemm.org>, Peter Wemm writes:
> >"M. Warner Losh" wrote:
> >> In message: <20030502035426.GA65366_at_athlon.pn.xcllnt.net>
> >>             Marcel Moolenaar <marcel_at_xcllnt.net> writes:
> >> : login: dev = da0p7, block = 600688, fs = /q
> >> : panic: ffs_blkfree: freeing free block
> >> 
> >> I get this all the time on my laptop, and have on and off, for the
> >> past two weeks.  I posted a traceback, and a me too on a couple of
> >> other tracebacks that matched mine.  This is the first bug to get me
> >> really annoyed in quite some time because it is a random killer.
> >
> >For what its worth, I've been getting it on amd64 kernels too.
> 
> Has anybody actually gone out of their way and reported this to Kirk ?

I CC'd him now. There wasn't much to report other than the
panic itself, but I can reliably reproduce it and have
stacktraces of both times the block gets freed:

XXX: 600688: size=16384, inum=141316
Stopped at      ffs_blkfree+0x61:             nop.f 0x0
db> trace
ffs_blkfree(0xe00000001519c000, 0xe000000025082c90, 0x92a70, 0x4000, 0x22804) at ffs_blkfree+0x61
handle_workitem_freefrag(0xe0000000022896c0, 0xe0000000008eb150, 0x610, 0xe00000001519c000, 0xe000000025082c90) at handle_workitem_freefrag+0x70
process_worklist_item(0x0, 0x0, 0xe00000000284f400, 0xe0000000022896c0) at process_worklist_item+0x510
softdep_process_worklist(0x0, 0xe000000000b5f304) at softdep_process_worklist+0x230
sched_sync(0xe000000000d0e000, 0x0, 0xe000000025082e30, 0xe000000000b5b570, 0xe000000000b5b570) at sched_sync+0x7e0
fork_exit(0xe000000000a188f8, 0x0, 0xe000000001f75580, 0xe000000000d0e000) at fork_exit+0x1b0
fork_trampoline(0xe000000000a188f8, 0x0, 0xe000000001f75580) at fork_trampoline+0x30

XXX: 600688: size=16384, inum=141316
Stopped at      ffs_blkfree+0x61:             nop.f 0x0
db> trace
ffs_blkfree(0xe00000001519c000, 0xe000000025082c90, 0x92a70, 0x4000, 0x22804) at ffs_blkfree+0x61
indir_trunc(0xe00000003a7ee300, 0x92a70, 0x0, 0x2, 0xe000000001f754e0) at indir_trunc+0x5a0
handle_workitem_freeblocks(0xe00000003a7ee300, 0x0, 0x0, 0x8cc50, 0xe00000003a7ee308) at handle_workitem_freeblocks+0x3a0
process_worklist_item(0x0, 0x0, 0xe00000000284f400, 0xe00000003a7ee300) at process_worklist_item+0x4a0
softdep_process_worklist(0x0, 0xe000000000b5f304) at softdep_process_worklist+0x230
sched_sync(0xe000000000d0e000, 0x0, 0xe000000025082e30, 0xe000000000b5b570, 0xe000000000b5b570) at sched_sync+0x7e0
fork_exit(0xe000000000a188f8, 0x0, 0xe000000001f75580, 0xe000000000d0e000) at fork_exit+0x1b0
fork_trampoline(0xe000000000a188f8, 0x0, 0xe000000001f75580) at fork_trampoline+0x30

Of course the second trace corresponds to the call that panics.
More details can be found elsewhere in this thread.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net