Date: Tue, 4 Oct 2005 03:28:35 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Don Lewis <truckman@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, rwatson@freebsd.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_alloc.c Message-ID: <20051004032213.R11746@odysseus.silby.com> In-Reply-To: <200510040452.j944q0rI020011@gw.catspoiler.org> References: <200510040452.j944q0rI020011@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Oct 2005, Don Lewis wrote: > Most of these problems are pretty nondeterministic. I'd estimate that > this particular bug was hit about once an hour while running Peter > Holm's kernel stress test. The snaplk deadlock problem happened more > often, but there is no way to diagnose the problem and distinguish it > from some of the other deadlocks other than in the debugger. > > The background fsck directory link count fixup botch that I fixed in > ffs_softdep.c 1.185 is very deterministic. It shouldn't be too hard to > write a non-destructive regression test for it. Perhaps this is a weird idea, but would it be good policy for people to write up regression test ideas and put them into src/sys/tools/regression - even if they don't have time to write the regression test itself? In the long run this could pay off - maybe if google has another SoC a project could be to implement the various regression tests. The format I'm envisioning is something like: Revision that fixed bug: Bug description: How to reproduce: Pretty simple format, info that could be extracted from commit logs of course, but much easier to access this way; the bug fixer can probably write up that info in 5 minutes, whereas someone trying to figure it out later will take much longer. I've cc'd rwatson, since he seems to be the regression test king, and may have some input on this idea. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051004032213.R11746>