Date: Sun, 18 Jan 2009 23:24:56 +0100 From: Peter Holm <peter@holm.cc> To: Bakul Shah <bakul@bitblocks.com> Cc: Kostik Belousov <kostikbel@gmail.com>, Dag-Erling Sm?rgrav <des@des.no>, freebsd-arch@freebsd.org Subject: Re: stress2 is now in projects Message-ID: <20090118222456.GA42363@x2.osted.lan> In-Reply-To: <20090118201202.674665B61@mail.bitblocks.com> References: <20090118082145.GA18067@x2.osted.lan> <86iqocstjm.fsf@ds4.des.no> <20090118131028.GA26179@x2.osted.lan> <20090118132819.GS48057@deviant.kiev.zoral.com.ua> <20090118140924.GA27264@x2.osted.lan> <20090118201202.674665B61@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 18, 2009 at 12:12:02PM -0800, Bakul Shah wrote: > On Sun, 18 Jan 2009 15:09:24 +0100 Peter Holm <pho@freebsd.org> wrote: > > On Sun, Jan 18, 2009 at 03:28:19PM +0200, Kostik Belousov wrote: > > > On Sun, Jan 18, 2009 at 02:10:28PM +0100, Peter Holm wrote: > > > > On Sun, Jan 18, 2009 at 01:11:25PM +0100, Dag-Erling Sm?rgrav wrote: > > > > > Peter Holm <pho@freebsd.org> writes: > > > > > > The key functionality of this test suite is that it runs a random > > > > > > number of test programs for a random period, in random incarnations > > > > > > and in random sequence. > > > > > > > > > > In other words, it's non-deterministic and non-reproducable. > > > > > > > > > > > > > Yes, by design. > > > > > > > > > You should at the very least allow the user to specify the random seed. > > > > > > > > > > > > > Yes, it would be interesting to see if this is enough to reproduce a > > > > problem in a deterministic way. I'll look into this. > > > > > > I shall state from my experience using it (or, rather, inspecting bug > > > reports generated by stress2), that in fact it is quite repeatable. > > > I.e., when looking into one area, you almost always get _that_ problem, > > > together with 2-3 related issues. > > > > > > Due to the nature of the tests and kernel undeterministic operations, > > > I think that use of the same random seed gains nothing in regard with > > > repeatability of the tests. > > > > It is an old issue that has come up many times: It would be so great > > if it was possible to some how record the exact sequence that lead up > > to a panic and play it back. > > > > But on the other hand, as you say, it *is* repeatable. The only > > issue is that it may take 5 minutes or 5 hours. > > > > But I'm still game to see if it is possible at all (in single user > > mode with no network activity etc.) > > Allowing a user to specify the random seed (and *always* > reporting the random seed of every test) can't hurt and it > may actually gain you repeatability in some cases. Most bugs > are typically of garden variety, not dependent on some Ah, yes if that was the case. But most of the problems I encounter are typically lock related. > complex interactions between parallel programs (or worse, on > processor heisenbugs). You can always try repeating a failing > test on a more deterministic set up like qemu etc. > Different hardware also seems to play a big role in finding bugs: Number of CPUs etc. > One trick I have used in the past is to record "significant" > events in one or more ring buffers using some cheap encoding. > You have then access to past N events during any post kernel > crash analysis. This has far less of an overhead than debug > printfs and you can even leave it enabled in production use. -- Peter Holm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090118222456.GA42363>