Re: port-sparc/51516: kernel trap 34: mem address not aligned in pmap_page_protect

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Sep 28, 2016 at 07:05:00PM +0000, matthew green wrote:
>  > Stopped in pid 0.9 (system) at  netbsd:pmap_page_protect+0x250: ld [%l5 =
>  + 0x8], %i4
>  
>  from ddb please "p $l5".  can you map pmap_page_protect+0x250
>  back to a specific line number?

Well, after rebuilding a kernel with -g, another emacs24 build would hang
with  100% kernel in top, but I could kill it without triggering a panic.

Another run, this time, paniced while building emacs24 without
intervention from my part:
login: cpu0: data fault: pc=131f4c8 rpc=57f3a7ec addr=65206000
kernel trap 30: data access exception
Stopped in pid 0.38 (system) at netbsd:mutex_oncpu.part.0+0x8:  ld              [
%g1 + 0xc], %g2
db{0}> p %g1
         131f4c8
 db{0}> p %g2
	 131f4c8
db{0}> tr
vfs_vnode_iterator_next(5866b28, 1169a20, 30283c68, 1000, 8000, 4b75210) at netbsd:vfs_vnode_iterator_next+0x4c
ffs_sync(11, 3, 3a47ec0, 0, 0, 5c20458) at netbsd:ffs_sync+0xfc
VFS_SYNC(3da5000, 3, 3a47ec0, 1ca8338, 3da5024, 3da5000) at netbsd:VFS_SYNC+0x24
sync_fsync(0, 12, 3d5f2a0, 1, 3da5000, 3f23c50) at netbsd:sync_fsync+0x6c
VOP_FSYNC(3f23c50, 3a47ec0, 8, 0, 0, 0) at netbsd:VOP_FSYNC+0x48
sched_sync(1c6b208, 1cba124, 3a35c70, 1, 0, 57f3a7eb) at netbsd:sched_sync+0x148
lwp_trampoline(f0075db8, fffa3cf8, 111800, 1106c8, fffa3df8, 1) at netbsd:lwp_trampoline+0x8
db{0}> ps
PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
20234    2 3   0        80            6d052a0    bootstrap-emacs select
20234    1 2   0     40000            4628aa0    bootstrap-emacs
20083    1 3   0        80            4628020                 sh wait
1187     1 3   0        80            6d057e0              gmake wait
[...]
0       40 3   0       200            3a6a560            physiod physiod
0       39 3   0       200            3d5f000           aiodoned aiodoned
0    >  38 7   0       200            3d5f2a0            ioflush
0       37 3   0       200            3a6a800           pgdaemon pgdaemon
0       34 3   0       200            3a6a2c0          atapibus0 sccomp
[...]
db{0}> tr/a 4628aa0
trace: pid 20234 lid 1 at 0x302c3c80
preempt(1888800, 1000000, 20000, 4628aa0, 0, fb5) at netbsd:preempt+0x48
trap(302c3ed0, fffffffe, ff7d739c, ff82000a, 42dc1b8, b188) at netbsd:trap+0x724

?(fe351e74, 7fff, ff7afc00, 0, 0, 138) at 1010be0

From gdb on netbsd.gdb I could get:
(gdb) x/i vfs_vnode_iterator_next+0x40
   0x15efca0 <vfs_vnode_iterator_next+64>:      ld  [ %i0 + 0x78 ], %g2
(gdb) 
   0x15efca4 <vfs_vnode_iterator_next+68>:      st  %g2, [ %g1 ]
(gdb) 
   0x15efca8 <vfs_vnode_iterator_next+72>:      clr  [ %i0 + 0x14 ]
(gdb) 
   0x15efcac <vfs_vnode_iterator_next+76>:      call  0x13673e0 <mutex_enter>
   0x15efcb0 <vfs_vnode_iterator_next+80>:      ld  [ %i5 ], %o0
(gdb) 
   0x15efcb4 <vfs_vnode_iterator_next+84>:      ld  [ %i5 + 0x48 ], %g1
(gdb) 
   0x15efcb8 <vfs_vnode_iterator_next+88>:      mov  %i5, %o1

(vfs_vnode_iterator_next+0x4c is the call to mutex_enter, as expected).

but gdb couldn't find a matching line number:
(gdb) l *(vfs_vnode_iterator_next+0x4c)
(gdb) 

maybe because it's a sparc gdb on a GENERIC_SUN4U kernel ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--