Subject: Re: 1.5S vs sparc
To: None <firstname.lastname@example.org>
From: Simon J. Gerraty <email@example.com>
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" <firstname.lastname@example.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...