anyone else seeing cpu_in_cksum() panics?

[matthew green <mrg%eterna.com.au@localhost>]

with both -current and the latest netbsd-7 branch, i'm seeing a
fairly consistent crash in cpu_in_cksum(), and it leaves a broken
stack as 'bt' in ddb doesn't give anything, but i found that
sparc64 ddb has "mach stack", which probes the register windows
and thus is able to recover the stack anyway.  actually serial
console session below.  it seems to be consistent with nfs_send.

i've started searching to see if this problem was introduced
recently, but i'm curious if anyone else has seen it.


.mrg.


login: cpu0: data fault: pc=10dda40 rpc=101dbd000 addr=2578c2000
kernel trap 30: data access exception
Stopped in pid 0.62 (system) at netbsd:cpu_in_cksum+0x120:      ld              [%o5 + 0x0], %o4
db{0}> bt
db{0}> mach stack
Window 0 frame64 0x15a0a33c0 locals, ins:
1 15a0a0000 e00474c1 15a0a3ed0 1c6fca8 1588a4000 e0048000 e0048000
10314ae10 14 101daf008 2 2 14 15a0a2c81=sp 1269e10=pc:netbsd:ip_output+0xd30
Window 1 frame64 0x15a0a3480 locals, ins:
102fec220 102844a90 0 102fe8de0 5dc 101daf008 1 e0048000
0 10314aef0 102febb60 0 15a0a3558 10314aef0 15a0a2d81=sp 14ebf80=pc:netbsd:udp_output+0x2e0
Window 2 frame64 0x15a0a3580 locals, ins:
102febb60 0 ffffffffffffffff 0 e0048000 1 1 0
10314ae10 102febb00 ac100000 ac10 1ce0c00 20 15a0a2e41=sp 14ec0c4=pc:netbsd:udp_send_wrapper+0x124
Window 3 frame64 0x15a0a3640 locals, ins:
0 0 0 104f4e800 10 102f96c00 15a57fc20 0
102fe8de0 101dbd400 0 1 1031435c0 102febb00 15a0a2f01=sp 150fa84=pc:netbsd:sosend+0x6a4
Window 4 frame64 0x15a0a3700 locals, ins:
101dbd068 10314ab7c 0 0 1 1 102fe8de0 1
0 0 0 1c7cdf8 15a0a3888 64bc 15a0a2ff1=sp 135d7a4=pc:netbsd:nfs_send+0x84
Window 5 frame64 0x15a0a37f0 locals, ins:
0 1ce1400 101 9000001 fffffe 7ff6 0 1039bf320
102fe8de0 0 101dbd400 103a65088 1031435c0 0 15a0a30b1=sp 1349768=pc:netbsd:nfs_request+0x2a8
Window 6 frame64 0x15a0a38b0 locals, ins:
105589aa0 5478715d 1ccaab8 102f96c00 1031435c0 2034 103a65088 103a65088
104f4e800 101dbd000 7 1031435c0 1ccc8b0 0 15a0a32a1=sp 136e030=pc:netbsd:nfs_writerpc+0x350
Window 7 frame64 0x15a0a3aa0 locals, ins:
15a0a3cf0 2000 15a0a3ba8 1ccc8b0 101dbd000 101dbd058 15a0a3bb8 1
105589aa0 15a0a3d00 102f96c00 21f0 104f4e800 2000 15a0a3421=sp 1346190=pc:netbsd:nfs_doio+0x410
Window 8 frame64 0x15a0a3c20 locals, ins:
102f96ce8 21f0 0 15a0a3d40 104f4e800 e0048000 7531 2000
1039b0b50 15a0a3d30 0 1 2 105589aa0 15a0a3571=sp 134c69c=pc:netbsd:nfssvc_iod+0x15c
Window 9 frame64 0x15a0a3d70 locals, ins:
1cca550 102f2fbf8 1cca400 1cca550 102f96f20 15a01c000 e0048000 e0048000
1cca548 1c74800 102f2fbe0 102f2fbd8 1039b0b50 102f96c00 15a0a3621=sp 1011ec0=pc:netbsd:lwp_trampoline+0x8
Window a frame64 0x15a0a3e20 locals, ins:
134c540 1031435c0 1031435c0 1fff 28 30 3 2014000
f005dfd0 fedbfcb8 112c00 111fe8 fedbfdb8 0 fedbf651=sp 100030=pc:100030
Window b frame64 0xfedbfe50 locals, ins:
fff72820 1170 0 f0067370 10000 1001f57e0 0 7fff0019acc
0 0 0 0 f005dfd0 0 fedbf701=sp 0=pc:0
Window c frame64 0xfedbff00 locals, ins:
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0=sp 0=pc:0
db{0}>