This is probably all old news, but just in case...

I finally got to ddb from my sparc MP kernel after it panics.
I'd put a bit of bleating into main to see how far we get.
Result is below.

Resetting ...

SPARCstation 20 MP (2 X RT625), No Keyboard
ROM Rev. 2.25R hyperSPARC, 160 MB memory installed, Serial #7493664.
Ethernet address 8:0:20:72:58:20, Host ID: 72725820.



Rebooting with command: netbsd.mp -s
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0  File and args: netbsd.mp -s
>> NetBSD/sparc Secondary Boot, Revision 1.9
>> (root@flambard, Thu Nov 23 03:02:02 MET 2000)
Booting netbsd.mp
2513472+91392+309880 [68+150272+114600]=0x318668
OBP version 3, revision 2.25 (plugin rev 2)
[ using 265392 bytes of netbsd ELF symbol table ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.5ZA (TOO.MP) #6: Fri Jan  4 23:03:27 PST 2002
    root@too.crufty.net:/l0/sys/compile/TOO.MP
total memory = 159 MB
avail memory = 143 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: mid 8: RT620/625 @ 100 MHz, on-chip FPU
cpu0: 256K byte write-back, 64 bytes/line, sw flush: cache enabled
cpu1 at mainbus0: mid 9: 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: baud rate 1200
ms0 at zs1 channel 1: baud rate 1200
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: dma rev 2
esp0 at dma0 slot 15 offset 0x800000 level 4: ESP200, 40MHz, SCSI ID 7
scsibus0 at esp0: 8 targets, 8 luns per target
ledma0 at sbus0 slot 15 offset 0x400010: dma rev 2
le0 at ledma0 slot 15 offset 0xc00000 level 6: 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): dma 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
cgsix0 at sbus0 slot 3 offset 0x0 level 9: SUNW,501-2325, 1152 x 900, rev 11
cgsix0: attached to /dev/fb
eccmemctl0 at mainbus0: version 0x0/0x2
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 3 lun 0: <SEAGATE, ST34371W SUN4.2G, 7462> SCSI2 0/direct fixed
sd0: 4094 MB, 3882 cyl, 16 head, 135 sec, 512 bytes/sect x 8385121 sectors
sd0: sync (100.0ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 6 lun 0: <TOSHIBA, XM-4101TASUNSLCD, 1084> SCSI2 5/cdrom removable
cd0: sync (248.0ns offset 15), 8-bit (4.032MB/s) transfers
IPsec: Initialized Security Association Processing.
root on sd0a dumps on sd0b
root file system type: ffs
calling: cpu_boot_secondary_processors()
cpu0: booting secondary processors: cpu1
cpu0, curproc=0xf02c0850
calling: exec_init(1)
wakeup start_init_exec
calling: uvm_scheduler()
raise_ipi_wait_and_unlock(cpu0): couldn't ping cpu1
panic: cpu1: lockmgr: no context: lkp=0xf029810c interlkp=0x0 flags=0x1
Stopped at      cpu_Debugger+0x4:       jmpl            [%o7 + 0x8], %g0
db{1}> trace
_lockmgr(0xf029810c, 0x1, 0x0, 0xfffffffe, 0x92, 0xf024f170) at _lockmgr+0xf0
uvm_fault(0xf0298108, 0xf61c9000, 0x0, 0x2, 0x3de, 0x0) at uvm_fault+0x80
mem_access_fault4m(0x9, 0x3a6, 0xf61c9000, 0xf61c8f00, 0x0, 0x12) at mem_access_
fault4m+0x2d8
memfault_sun4m(0xf61c8fb0, 0x80000000, 0xffffffff, 0xf01fa280, 0xedfe200, 0x6006
06) at memfault_sun4m+0xe4
sparc_interrupt44c(0xf0653f40, 0x0, 0x0, 0x0, 0x0, 0x0) at sparc_interrupt44c+0x
164
cpu_hatch(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) at cpu_hatch+0x88
db{1}> 

The raise_ipi_wait_and_unlock is a result of trying to use
smp_tlb_flush_* which results in the nmi which cpu1 is fielding when
it panics.

--sjg