>Number:         33406
>Category:       kern
>Synopsis:       softdeps get stuck in endless loop
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 01 14:20:00 +0000 2006
>Originator:     Simon Burge <simonb@wasabisystems.com>
>Release:        NetBSD 3.99.18, sources from around Apr 30, 2006.
>Organization:
Wasabi Systems
>Environment:
System: NetBSD iq80321 3.99.18 NetBSD 3.99.18 (IQ80321) #6: Fri Apr 28 14:06:50 EST 2006 simonb@bigkev:/home/simonb/netbsd/src-virgin/sys/arch/evbarm/compile/IQ80321
Architecture: arm
Machine: evbarm
 and
System: NetBSD athlon 3.99.18 NetBSD 3.99.18 (GENERIC) #4: Mon May 1 12:54:17 EST 2006 simonb@bigkev:/home/simonb/netbsd/src-virgin/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:

        Copying lots of files on to a filesystem with softdeps enabled
        on an ARM architecture with a modernish disk results in
        vflusbuf() getting stuck in a loop writing out the same two
        blocks over and over.  The lat_fs test from lmbench is also a
        reliable way to reproduce the problem.

        Adding a printf to bwrite() and softdep_disk_write_complete()
        and using a serial console also makes an i386 and a evbmips
        machine fail in the same way.  I'll send a patch to the PR
        separately.

        What I think appears to be happening is that vflushbuf() is
        calling bwrite() for a dirty buffer.  I think when vflushbuf()
        is does the splx(s) just before calling bwrite() for the next
        dirty buffer, the biodone() comes through for the IO that has
        just completed, and for some reason the softdep code decides
        that there is a rollback in the inode block, and calls bdirty()
        to reinsert the previous block back on to the dirty list.  The
        next buffer writen goes through the same process, except that
        the rollback is because the bitmap is incomplete, and we end up
        writing the same two blocks out one after another in an endless
        loop

        In twist, Steve Woodford reports that he can reproduce the
        problem on an IQ31244 with a fast modern disk, but that the
        problem goes away when he uses an ancient 400MB non-DMA disk.

	This also appears to be the cause of kern/32330.

>How-To-Repeat:

        The easiest way I've found to reproduce the problem is to use
        the following recipe.  Sometimes more than one invocation of
        lat_fs may be needed.

        newfs -I -i 524288 /dev/rwd0d
        mount -o softdep -t ffs /dev/wd0d /mnt
	cd /mnt
	.../lmbench/bin/.../lat_fs

>Fix:

	None given.  This seems to be timing related somehow though.