[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ATF tests still failing to complete within 2 hours on amd64
On Thu, Dec 01, 2011 at 07:24:09PM +0100, Nicolas Joly wrote:
> On Thu, Dec 01, 2011 at 11:44:56AM -0500, Thor Lancelot Simon wrote:
> > On Thu, Dec 01, 2011 at 06:15:43PM +0200, Andreas Gustafsson wrote:
> > > Thor Lancelot Simon wrote:
> > > > I guess the question at this point is, how do we debug this? I'm
> > > > willing
> > > > to accept that my rnd/entropy changes may have somehow triggered the
> > > > problem, but since I've come as close as I can to simply isolating rump
> > > > from the entropy subsystem and the problem persists -- I don't really
> > > > know
> > > > where to look.
> > >
> > > I think the general principle would be to choose a test that is
> > > failing consistently when run in isolation, and then poke it with a
> > > debugger to it to see why it is failing.
> > >
> > > For example, if I do the following on i386:
> > >
> > > cd /usr/tests/lib/librumphijack
> > > ./t_tcpip http
> > >
> > > I get a core file, and gdb tells me:
> > Thanks!
> > I will set up an i386 VM and try to see what's wrong with the mutex
> > handling in question. Or whether the cprng_strong is corrupt. Or
> > whether I'm stumped again.
> If this helps, this looks like an uninitialised lock, according to
> following backtrace (MKDEBUG=yes, RUMP_LOCKDEBUG=yes) on amd64 :
Rump does not call cprng_strong_create() ... leading indeed to an
The attached patch solve the problem for me.
Projects and Developments in Bioinformatics
Institut Pasteur, Paris.
RCS file: /cvsroot/src/sys/rump/librump/rumpkern/rump.c,v
retrieving revision 1.236
diff -u -p -r1.236 rump.c
--- librump/rumpkern/rump.c 26 Nov 2011 21:41:02 -0000 1.236
+++ librump/rumpkern/rump.c 1 Dec 2011 19:01:22 -0000
@@ -334,6 +334,7 @@ rump__init(int rump_version)
+ kern_cprng = cprng_strong_create("kernel", IPL_VM,
Main Index |
Thread Index |