Re: [NetBSD 5.99.23] kern_lwp cannot allocate memory

[BERTRAND Joel <joel.bertrand%systella.fr@localhost>]

BERTRAND Joel a écrit :
> BERTRAND Joel a écrit :
> > matthew green a écrit :
> > > i've noticed that my ss20 can't run the regress/lib/libpthread/find
> > > test without lowering my stack size.
> > >
> > > this test gets the current stacksize and allocates it approximately
> > > 350 times:
> > >
> > > #define NUM 100
> > > for (i = 0; i< NUM; i++) {
> > > ...
> > > malloc((random()& 7) * sl.rlim_cur);
> > > }
> > >
> > > by default for me, it fails on the last iteration. if i lower
> > > my stacksize limit from 8MB to 6MB it does not fail. if i raise
> > > my stackszie limit to the maximum, it fails after 23 iterations.
> > >
> > > i can't get the t_lwpctl test to fail though.
> >
> > It's a strange bug. When this bug occurs, it is reproductible until I
> > reboot my SS20. I think there is a kernel stack corruption somewhere in
> > kernel but I can not invetigate. My SS20 is not stable enough :-(
>
> I have built a 5.99.24 MP-kernel. With only one processor (RT626), it is
> stable and I shall try to reproduce your bug. With two processors, I
> have tried to rebuild userland with -j2, and kernel enters in deadlock.
> I don't have information even if DIAGNOSTIC and DEBUG flags are set.
>
> I have tried to reproduced this deadlock, and I've seen (probably) the
> same with two SM71 (during fsck on boot).

        Some news.

	With the last kernel patches, my SS20 seems to be stable enough to 
build userland with -j2 and runs some tests. Some programs return 
segmentation fault or lwpctl allocation error (and these errors are 
reproductible).

        On console, kernel prints :

xcall(cpu1,0xf0008cd4): couln't ping cpu:

but without any cpu number. sys/arch/sparc/sparc/cpu.c should write CPU 
number. Thus, as I have installed two RT626 modules, cpi->msg.complete 
is not null for all cpus. I don't understand why this loop is made more 
than 100000 times and ends without printing cpu number. Only solution I 
see is a modification of cpi->msg.complete after exactly 100000 
iterations, but it's improbable.

        Any idea ?

        JKB