> Rats.  While its great that I didn't bust any locking protocols,
> this means that we still have a problem with the hypersparcs.

So as an experiment, I commented out the ltsleep and wakeup calls, in
the semaphore routines - to see where we blow-up.  We get to about
the same point:

root file system type: ffs
panic: lockmgr: no context
Stopped at      cpu_Debugger+0x4:       jmpl            [%o7 + 0x8], %g0
db{1}> ps
 5                  0          0          0 3 0xa0204         aiodoned aiodone
 4                  0          0          0 3 0xa0204          ioflush  syncer
 3                  0          0          0 3 0x20204           reaper  reaper
 2                  0          0          0 3 0xa0204       pagedaemon pgdaemo
 1                  0          0          0 7 0x80004             init
 0                 -1          0          0 3 0xa0204          swapper schedul
db{1}> trace
lockmgr(0xf0269a14, 0x1, 0xfffffffe, 0x0, 0xf02b0800, 0x66) at lockmgr+0xd4
uvm_fault(0x5, 0xf6645000, 0x0, 0x2, 0xf60c8e70, 0x0) at uvm_fault+0x15c
mem_access_fault4m(0x9, 0x3a6, 0xf6645000, 0xf60c8e30, 0x1, 0x40000) at mem_acce
ss_fault4m+0x288
memfault_sun4m(0x58, 0xf0002000, 0x6, 0x3f, 0xf02b1400, 0x40) at memfault_sun4m+
0xe4
srmmu_vcache_flush_page(0xf6645000, 0xf0002000, 0xf00021f0, 0xf01d3aa0, 0x0, 0x2
00) at srmmu_vcache_flush_page+0x4c
nmi_soft(0x0, 0x80000000, 0xf0259c00, 0xf01d5608, 0xedfe200, 0x600606) at nmi_so
ft+0x158
nmi_sun4m(0xf0617f40, 0x0, 0x0, 0x0, 0x0, 0x0) at nmi_sun4m+0x128
cpu_hatch(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) at cpu_hatch+0x88

Not a very conclusive experiment.  There's probably enough delays and
interlocking provided by the prints and sem_interlock, to have the
same effect as with the sleep/wakeups.

Will keep looking.
--sjg