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

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

The following reply was made to PR port-sparc/51516; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-sparc-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: port-sparc/51516: kernel trap 34: mem address not aligned in
 pmap_page_protect
Date: Tue, 4 Oct 2016 15:30:23 +0200

 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
 --