Date: Wed, 21 Jan 2009 09:00:28 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Kostik Belousov <kostikbel@gmail.com>, Dag-Erling Sm?rgrav <des@des.no> Subject: Re: stress2 is now in projects Message-ID: <200901210900.29226.jhb@freebsd.org> In-Reply-To: <20090118201202.674665B61@mail.bitblocks.com> References: <20090118082145.GA18067@x2.osted.lan> <20090118140924.GA27264@x2.osted.lan> <20090118201202.674665B61@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 18 January 2009 3:12:02 pm Bakul Shah wrote: > 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 > 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. Actually, all the bugs I've used stress2 for were race conditions and locking bugs for which having a set random seed would not have helped. > 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. man ktr -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901210900.29226.jhb>