Re: SMP status ?

[Andrew Doran <ad%netbsd.org@localhost>]

My general sense is that it's a bad idea to call printf() above IPL_VM
everywhere, since the synchronization around that is still unclear
(what happens in the drivers in particular).

On Sun, Jan 16, 2011 at 08:47:08PM +1100, matthew green wrote:
> 
> > matthew green a écrit :
> > > yeah, i've seen a couple of crashes, i won't have time to
> > > look at this for a few days, i'll see what happens then.
> > 
> >     I don't know if it shall help you, but I'm unable to reproduce crashes 
> > with dual SM71 configuration even with high load average. Are your 
> > crashes NMI related ?
> 
> they only appear with LOCKDEBUG enabled.  a normal kernel runs very
> well for me now, i haven't seen a problem.
> 
> i have a hack to not print strayintr messages for zs in MP, which
> should avoid that problem.
> 
> 
> .mrg.
> 
> 
> Index: intr.c
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/sparc/sparc/intr.c,v
> retrieving revision 1.108
> diff -p -r1.108 intr.c
> *** intr.c    5 Jan 2010 21:38:50 -0000       1.108
> --- intr.c    16 Jan 2011 09:46:41 -0000
> *************** strayintr(struct clockframe *fp)
> *** 133,138 ****
> --- 133,151 ----
>       char bits[64];
>       int timesince;
>   
> + #if defined(MULTIPROCESSOR)
> +     /*
> +      * XXX
> +      *
> +      * Don't whine about zs interrupts on MP.  We sometimes get
> +      * stray interrupts when polled kernel output on cpu>0 eats
> +      * the interrupt and cpu0 sees it.
> +      */
> + #define ZS_INTR_IPL 12
> +     if (fp->ipl == ZS_INTR_IPL)
> +             return;
> + #endif
> + 
>       snprintb(bits, sizeof(bits), PSR_BITS, fp->psr);
>       printf("stray interrupt cpu%d ipl 0x%x pc=0x%x npc=0x%x psr=%s\n",
>           cpu_number(), fp->ipl, fp->pc, fp->npc, bits);