Yes, that problem is related to the wapbl change. I've committed a bug fix, so newer kernel shouldn't trigger the panic any more.
There are some further changes needed to cover a possible dup alloc , and to keep the !wapbl case recoverable by fsck. There is ongoing discussion on source-changes about that, hope we finalise fix later in the week. Jaromir 2016-11-07 23:07 GMT+01:00 Andreas Gustafsson <g...@gson.org>: > Earlier, I wrote: >> Also, I have now narrowed down the appearance of the problem on the >> testbed to the following commit: >> >> 2016.10.30.15.01.46 christos src/sys/ufs/ffs/ffs_alloc.c 1.154 >> >> The mystery remains because the commit message says there should be no >> functional change, and I also did a quick review of the diff and did >> not spot anything that could be a cause of the panic. > > I have now also run a bisection of this on my own testbed, and it > identified a different commits than the TNF testbed did: > > 2016.10.28.20.38.12 jdolecek src/sys/kern/vfs_wapbl.c 1.85 > 2016.10.28.20.38.12 jdolecek src/sys/sys/wapbl.h 1.19 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ffs/ffs_alloc.c 1.153 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ffs/ffs_inode.c 1.118 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ffs/ffs_snapshot.c 1.143 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_extern.h 1.83 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_inode.c 1.97 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_rename.c 1.13 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_vnops.c 1.233 > 2016.10.28.20.38.12 jdolecek src/sys/ufs/ufs/ufs_wapbl.h 1.12 > > More data at: > > > http://releng.netbsd.org/b5reports/sparc/commits-2016.10.html#2016.10.30.15.01.46 > > http://www.gson.org/netbsd/bugs/build/sparc/commits-2016.10.html#2016.10.28.20.38.12 > > -- > Andreas Gustafsson, g...@gson.org