Subject: Re: 1.5S vs sparc
To: None <pk@cs.few.eur.nl>
From: Simon J. Gerraty <sjg@quick.com.au>
List: tech-smp
Date: 02/21/2001 10:26:07
> This is a known issue with MP kernels on hypersparc machines. Here's a
> previous message on the subject:

Thanks Paul.  Is the idea I suggested back in June (below) a valid
approach to solving this?  If so, I might try and implement it.  I can
see there being issues as to what cpu count to use, since we are
seeing this even while attempting to hatch cpu's  I guess you could
increment the cpu count on entry to cpu_spinup and decrement it again
if the cpu fails to spin up.

Of course the first thing we'd need is the semaphore semantics in the
kernel - or is there a suitable/equiv mechanism already available?

> >> I get the same thing on a SS10 with a dual Ross 100 MHZ module.  It didn't
> >> happen, however, when I had two TMS390Z50 in the machine.
> >>
> >> I presumed that something is not quite ready.
> >
> >True. MP hypersparc machines all do this. The problem is in the smp
> >version of the cache flush routines: pages must remain mapped in the
> >MMU until the page cache flushes are done on all CPUs. Currently,
> >the primary CPU races ahead and unmaps a page before the other CPUs
> >get around to flushing it from their caches.

}Subject: Re: NetBSD-1.5A on dual cpu SS20: panic: lockmgr: no context
}From: "Simon J. Gerraty" <sjg@quick.com.au>
}To: pk@cs.few.eur.nl
}Cc: tech-smp@netbsd.org
}Date: Thu, 29 Jun 2000 23:16:59 +1000
}X-Mailer: Mew version 1.94.1 on Emacs 19.31 
}Delivery-Date: Thu, 29 Jun 2000 23:18:58 +1000
}
}> I assume there is an inter cpu message to cause the flush to happen,
}> so cpu's which don't have a cache entry, still get a chance to
}> decrement the ref count.
}
}So, I had a quick look... 
}
}If smp_cache_flush() were to initialize a semaphore before
}entering the for() loop, and each cpu did a V(sem) when they
}had flushed, then at the end of the loop, do another for() loop doing
}P(sem), and it would wait for the last cpu to flush.
}
}Of course you'd need a semaphore for each cache line to avoid the
}above creating a big bottleneck for cache flushing.  And of course the
}semaphores would need to be in uncached memory.

Hmm given that you are wanting the cpu's to interlock, is it necessary
to have a semaphore per cache line?

}And can you have two cpu's wanting to initiate a flush of the same
}line(s) at the same time?
}
}I expect there's a much better alternative... 
}
}--sjg