Hi Matt,
I'm delighted to report it works brilliantly on my system.
For the test I ran NetBSD 7.1 as that's what I had installed, and built the kernel from the 7 stable branch in CVS that includes your patch.
I have a Sparcstation 20 with dual 50Mhz supersparc, 60Mhz supersparc, CG6 frame buffer, and IBM HDD installed for the test.
I've been running my system for about 20 hours and have thrown a variety of different loads at it with no problems at all.
I'm not sure, but it may have also boosted the performance a smidge as well.
I was surprised to note that this kinda fixed the dbri driver, as programs that play sounds can now do so without hanging the system.
(previously MP kernels would hang when this was attempted)
Audio quality is still poor and there is a lag before audio is played, but that is probably unrelated to any SMP issues and has been an problem
for as long as I can remember.
So far it's looking pretty good.
- Andrew
... reviving old thread.
anyone who has has problems with sparc SMP on >2 cpu systems
should try out -current, or the latest netbsd-8 and netbsd-7*
branches. thanks to macallan (who sent me some dual module
hypersparc cpus so i could have more than 2 cpus), and
finally seeing a stack trace i understood, i've fixed the
hang seen when running with more than 2 cpus.
http://mail-index.netbsd.org/source-changes/2019/01/13/msg102344.html
in the end, the problem was fairly simple. there are two
basic operations related to handling of user thread context:
pmap_activate() and pmap_deactivate(). since they run while
performing a context switch, they must not block themselves.
however, the pmap was using the global kernel lock for
protection and this can sleep, which leads to the hang.
i've updated the pmap(9) manual to be explicit about this
requirement.
please let me know if you test and the result -- success
or failure. thanks!
.mrg.