My hypersparc is still not booting...  I still get the famous

panic: lockmgr: no context

however, I'm wondering if I've been chasing the wrong thing...

I added a cpu_semaphore, which cpus other than the boot cpu will spin
on until the boot cpu calls cpu_boot_secondary_processors().
From my dmesg output, cpu1 should still be madly spinning on that at
the time we get the panic:

NetBSD 1.5S (TOO.MP) #52: Thu Mar 15 01:10:06 PST 2001
    root@too:/l0/NetBSD/obj/sys/compile/TOO.MP
total memory = 159 MB
avail memory = 144 MB
using 896 buffers containing 8264 KB of memory
bootpath: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0
mainbus0 (root): SUNW,SPARCstation-20
cpu0 at mainbus0
{0}sema_init(0xf02b136c, 1, semcpu)
: mid 8
{0}sema_spinwait(0xf02b136c,1) == 1
: RT620/625 @ 100 MHz, on-chip FPU
cpu0: 256K byte write-back, 64 bytes/line, sw flush: cache enabled
cpu1 at mainbus0: mid 9
{1}sema_spinwait(0xf02b136c,1) == 0

sema_spinwait() prints the sem_count on entry, so cpu1 is going to be
spinning from here on.  We never get to the call to sema_signal for
that semaphore.  The call to sema_spinwait() is the last thing in
cpu_setup().

: RT620/625 @ 100 MHz, on-chip FPU
cpu1: 256K byte write-back, 64 bytes/line, sw flush: cache enabled
obio0 at mainbus0
clock0 at obio0 slot 0 offset 0x200000: mk48t08: hostid 72725820
timer0 at obio0 slot 0 offset 0x300000 delay constant 48
zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6
kbd0 at zs1 channel 0
ms0 at zs1 channel 1
fdc0 at obio0 slot 0 offset 0x700000 level 11: no drives attached
auxreg0 at obio0 slot 0 offset 0x800000
power0 at obio0 slot 0 offset 0xa01000 level 2
iommu0 at mainbus0 ioaddr 0xe0000000: version 0x3/0x1, page-size 4096, range 64MB
sbus0 at iommu0: clock = 25 MHz
dma0 at sbus0 slot 15 offset 0x400000: rev 2
esp0 at dma0 slot 15 offset 0x800000 level 4: ESP100A, 40MHz, SCSI ID 7
scsibus0 at esp0: 8 targets, 8 luns per target
ledma0 at sbus0 slot 15 offset 0x400010: rev 2
le0 at ledma0 slot 15 offset 0xc00000 level 6
{0}sema_init(0xf02b1634, 0, semvsegment)
{0}sema_signal(0xf02b1634,1) == 1
{0}sema_wait(0xf02b1634) == 0
{1}sema_signal(0xf02b1634,1) == 1
{0}sema_wait(0xf02b1634) == 0
{0}sema_clear(0xf02b1634) count==0, sleepers==0
{0}sema_init(0xf02b1634, 0, semcflush)
{0}sema_signal(0xf02b1634,1) == 1
{0}sema_wait(0xf02b1634) == 0
{1}sema_signal(0xf02b1634,1) == 1
{0}sema_wait(0xf02b1634) == 0
{0}sema_clear(0xf02b1634) count==0, sleepers==0
: address 08:00:20:72:58:20
le0: 8 receive buffers, 2 transmit buffers
bpp0 at sbus0 slot 15 offset 0x4800000 level 2 (ipl 3): rev 2
SUNW,DBRIe at sbus0 slot 14 offset 0x10000 level 9 not configured
qec0 at sbus0 slot 2 offset 0x20000 level 4 (ipl 7): 128K memory
qe0 at qec0 slot 0 offset 0x0 rev 1 address 08:00:20:72:58:20
qe1 at qec0 slot 1 offset 0x0 rev 1 address 08:00:20:72:58:20
qe2 at qec0 slot 2 offset 0x0 rev 1 address 08:00:20:72:58:20
qe3 at qec0 slot 3 offset 0x0 rev 1 address 08:00:20:72:58:20
eccmemctl0 at mainbus0: version 0x0/0x2
scsibus0: waiting 2 seconds for devices to settle...
panic: lockmgr: no context

Unfortunately, the machine locks solid at this point so I can't gather
any more info.

BTW the reduced noise from the cache semaphore is due to only enabling
debug for the first use of it in each smp_*flush*() routine.
If I turn them on all the time, things look better, but I suspect that
has too much to do with the printfs...  maybe the cache semaphore is
not helping at all.  I'll take it out again...


--sjg