Subject: the panics on netbsd/sparc64
To: None <port-sparc64@netbsd.org>
From: Eiji Ota <eiji@fs.fujitsu.com>
List: port-sparc64
Date: 04/26/2000 13:36:29
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
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/sys/vm/vm_prot.h
src/sys/vm/vm_swap.h
karma# panic: vref used where vget required
kdb breakpoint at 0xf8162490
Stopped in find at      Debugger+0x4:   nop

db> trace
vref(fad3e000, f8500400, fad3e000, fb789748, f8256400, 2a8) at vref+0x1c
ffs_vget(0, 3f4f4, fb789870, f81cb9d8, f80fcd08, 0) at ffs_vget+0x248
ufs_lookup(0, 2, ffffffffffffffff, c00, f8193b18, f81ccfd8) at ufs_lookup+0xd40

lookup(4000400, f8563400, fae3c970, fb789be0, fb786000, f8563400) at lookup+0x3
4c
namei(fc4e8610, 27f860, fffffffffffffff8, fb786000, f800c130, fae3c970) at name
i+0x37c
sys___lstat13(fae3c970, fb789dd0, fb789dc0, f8059f0c, fb789de0, 2) at sys___lst
at13+0x24
syscall(518, fb789ed0, f81d3000, fb789ed0, 118, 400) at syscall+0x7ec
syscall_setup(27f860, 27f870, 8, 27f860, 0, 0) at syscall_setup+0x148
db> 


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> 

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>