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

Mateusz Guzik wrote:
> On Thu, Dec 03, 2015 at 03:07:48PM -0800, Kirk McKusick wrote:
> > > Date: Thu, 3 Dec 2015 23:47:52 +0100
> > > From: Mateusz Guzik <mjguzik_at_gmail.com>
> > > To: Rick Macklem <rmacklem_at_uoguelph.ca>
> > > Cc: FreeBSD Current <freebsd-current_at_freebsd.org>
> > > Subject: Re: panic "ffs_checkblk: bad block" on recent -head kernels
> > > 
> > > On Thu, Dec 03, 2015 at 05:08:27PM -0500, Rick Macklem wrote:
> > >> 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.
> > > 
> > > Well, did it crash with r291460 or later?
> > > 
> > > If so, try the kernel just before that and if that helps, try:
> > > 
> > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
> > > index ff37de8..0ad6ef7 100644
> > > --- a/sys/kern/vfs_subr.c
> > > +++ b/sys/kern/vfs_subr.c
> > > _at__at_ -2783,6 +2783,7 _at__at_ _vdrop(struct vnode *vp, bool locked)
> > >         vp->v_op = NULL;
> > >  #endif
> > >         bzero(&vp->v_un, sizeof(vp->v_un));
> > > +       vp->v_lasta = vp->v_clen = vp->v_cstart = vp->v_lastw = 0;
> > >         vp->v_iflag = 0;
> > >         vp->v_vflag = 0;
> > >         bo->bo_flag = 0;
> > > 
> > > --
> > > Mateusz Guzik <mjguzik gmail.com>
> > 
> > I concur with trying this suggestion. starting with r291460 these
> > fields were no longer zero'ed when allocating the vnode. So you may
> > have some residual values in there that are causing trouble.
> 
Good work. This does seem to fix the problem. Without this patch, the crash
would occur on pretty well every full kernel build attaempt.
With the patch, I've done 3 full kernel builds without a crash.

I see the fix has already hit head.

Thanks guys, rick

> I reviewed the rest of the structure, looks like this is the rest of the
> fallout.
> 
> --
> Mateusz Guzik <mjguzik gmail.com>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>