So it seems I have a SMP kernel working on my SS20, and it's running fine,
   compiling stuff four hours now:
   
     PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
       8 root     -18    0     0K   15M reaper/0   3:12  1.81%  1.81% [reaper]
     363 feyrer     2    0   524K 1748K select/0   0:36  0.88%  0.88% sshd
   23216 root      10    0   540K 1084K wait/1     0:00  0.89%  0.68% sh
   23273 feyrer    31    0   212K  932K CPU/1      0:00  2.26%  0.59% top
   23289 root      58    0    92K   68K CPU/0      0:00  0.00%  0.00% cc
   
   Not that I think this is a bad thing, but I really wonder why it works,
   because I'm using two mixed modules:
   
   	cpu0 at mainbus0: mid 8: TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU
   	cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
   	cpu1 at mainbus0: mid 10: TMS390Z50 v1 @ 40 MHz, on-chip FPU
   	cpu1: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
   	...
   	cpu0: booting secondary processors: cpu1
   
   I didn't expect mixing CPUs with different speeds to work, but obviously
   it does. Can anyone explain this?

you're about the Nth person to discover this recently :-)  there appears
to be nothing inherent that would cause this to fail and netbsd seems to
work just fine.. 40 vs 75 is the largest difference i've seen so far.
   
   While on the subject: when running with two SM40(?) modules, they were
   both recognized (cpu0 & cpu1), but the kernel didn't try to boot the
   secondary cpu for SMP operation. Maybe that'd be worth trying?

you mean that it probed 'cpu0: ... & cpu1: ...' but when it came to saying
'cpu0: booting secondary processors: cpu1' it didn't say cpu1?  that, from
what i read of the code, shouldn't be possible...


.mrg.