On Wed, 26 Apr 2000, Eiji Ota wrote:

> I finally use netbsd/sparc64(thank you, Eduardo, for
> your advice).
> 
> However, I sometimes face panics on it.
> These seem three patterns. Are they already fixed ?
> 
> Eiji
> 
> 
> 1. panic: vref used where vget required
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a known problem associated with DIAGNOSTIC kernels.  It occurs
when the system starts paging.  I have been unable to determine the root
cause, but then I'm not a UVM expert.  If you compile non-DIAGNOSIC 
kernels this should go away.

> 2. panic with alignment error
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~
> NetBSD/sparc64 (karma) (console)
> 
> login: Alignment error: dsfsr=00000000:00800001 dsfar=0:f7ffe7e1 isfsr=00000000:00000000 pc=0x102cc8
> kernel trap 34: mem address not aligned
> Stopped in routed at    0x102cc8:       ld              [%l2 + %g0], %o0
> db> 
> db> trace
> data fault: pc=f8163580 addr=f7ffe000
> kernel trap 68: +fast data access MMU miss
> Faulted in DDB; continuing...
> db> 
> db> machine tf
> Trapframe 0xf82386b8:   tstate: 0x8800008a01    pc: 0x102cc8    npc: 0x102ccc
> y: 0    pil: 0  oldpil: 0       fault: 0x8800008a01     kstack: 0x0     tt: 34  G
> lobals:
> 0000000000000000 00000000001329e8 0000000000102cb0 00000000000000ff
> 0000000000000000 00000000f7ffeb8c 0000000000000000 0000000000000000
> outs:
> ffffffffffffffff ffffffffffffffff 0000000000000010 0000000000000000
> 00000000f7fff4f0 00000000f7fff09c 00000000f7ffe7e1 0000000000102ca8
> locals:
> ffffffffffffffff 00000000f7fff09c 00000000f7ffe7e1 0000000000102ca8
> 0000000000000010 0000000000000000 0000000000000000 0000000000000000
> ins:
> 0000000000000005 0000000000252000 0000000000000005 0000000000000000
> 00000000f7fff770 000000000023b1a0 00000000f7ffed11 00000000001056fc
> db> 

You seem to have some sort of 32-bit/64-bit stack confusion here.  What
are you running?  How is your kernel configured?

> 3. panic: unmount: dangling vnode
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> login: syncing disks... 7 7 5 1 done
> unmounting / (/dev/sd0d)...
> uvm_vnp_terminate(0xfaebcf60): terminating active vnode (refs=2)
> uvm_vnp_terminate(0xfad5a6d0): terminating active vnode (refs=2)
> uvm_vnp_terminate(0xfad3e880): terminating active vnode (refs=4)
> panic: unmount: dangling vnode
> kdb breakpoint at 0xf8162490
> Stopped in halt at      Debugger+0x4:   nop
> 
> db> trace
> dounmount(f8529800, 80000, fad5c010, 0, faebba98, f) at dounmount+0x190
> vfs_unmountall(0, f823e400, f8f103b0, 2010, 0, 0) at vfs_unmountall+0xa0
> vfs_shutdown(f823b000, fad5c010, f81c2858, f81d30e8, 0, 0) at vfs_shutdown+0x15
> 8
> cpu_reboot(8, 0, fad48060, 0, 0, 0) at cpu_reboot+0x78
> sys_reboot(faebbc40, faebbdd0, faebbdc0, f8036154, faebbde0, 2) at sys_reboot+0
> x64
> syscall(4d0, faebbed0, f81d3000, faebbed0, d0, 400) at syscall+0x7ec
> syscall_setup(8, 0, 121608, 225f00, 0, 0) at syscall_setup+0x148
> db> 

This may be related to #1.

Eduardo Horvath