re: mostly working SMP again

[matthew green <mrg%eterna.com.au@localhost>]

   > FWIW, with a simple hack to the zs driver (zshard() always returns 1)
   > my dual SS20 boots fine from the internal sd0.
   
   It looks the problem is that ZS_HWFLAG_USE_CONSDEV is never set
   in !(NWSKBD == 0) case then default consdev_prom via ttya mangles
   zs interrupts.

nice work.
   
   sd0: sync (100.00ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing
   
    :
   
   IPv6 mode: host
   stray interrupt cpu0 ipl 0x7 pc=0xf014765c npc=0xf0134530 
psr=0x1e4000c5<S,PS>
   xcall(cpu2,0xf0027f0c): couldn't ping cpus:
   Configuring network interfaces: hme0.


i remember seeing these in the old days, so this isn't a new
problem...


i'll test this patch at some point in the future, but feel free
to commit it before i get to that.  i gusess we can call this one
a wsconsifcation bug? :-)


BTW, the xcall() failure message itself wouldn't occur if the
strayintr didn't.  it's because the cpu writing the stray intr
message (cpu0) is busy while cpu2 is doing the xcall.. but by
the time cpu2 is done writing:

        xcall(cpu2,0xf0027f0c): couldn't ping cpus:

cpu0 is done doing what it was doing, and so we have an empty
list of cpus ...

ie, we still need a better way of handling kernel console
output ....



.mrg.