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 19:51:20 +0200

 On Tue, Oct 04, 2016 at 03:30:23PM +0200, Manuel Bouyer wrote:
 > 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:
 
 another one. I had to kill the bootstrap-emacs process, and
 after some time I got (pbulk already had moved to the next package):
 cpu0: data fault: pc=15de7a4 rpc=3fff00000000 addr=10474000
 kernel trap 30: data access exception
 Stopped in pid 6194.1 (rm) at   netbsd:uvm_pagefree+0x1e4:      ld              [
 %g1 + %o0], %g2
 db{0}> p %g1
          15de7a4
 db{0}> p %g2
          15de7a4
 db{0}> p %o0
          15de7a4
 db{0}> p $o0
          e7b8000
 db{0}> p $g1
          1cbd590
 db{0}> p $g2
                0
 db{0}> tr
 genfs_do_putpages(0, 0, 7fffffff, ffffe000, 317b36e0, 1) at netbsd:genfs_do_putp
 ages+0xc88
 genfs_putpages(317b3868, 500d5a0, 501b720, 317b3cb0, 0, 0) at netbsd:genfs_putpa
 ges+0x24
 VOP_PUTPAGES(50162c0, 0, 0, 0, 0, a) at netbsd:VOP_PUTPAGES+0x44
 uvm_vnp_setsize(50162c0, 0, 0, 0, 0, 0) at netbsd:uvm_vnp_setsize+0x8c
 ffs_truncate(50162c0, 0, 0, 0, ffffffff, 0) at netbsd:ffs_truncate+0x574
 ufs_truncate(50162c0, ffffffff, 0, ffffffff, 3a5f5c0, 3da5000) at netbsd:ufs_tru
 ncate+0x1cc
 ufs_inactive(0, 20012, 317b3b7c, 3da5000, 501b720, 50162c0) at netbsd:ufs_inacti
 ve+0x1c8
 VOP_INACTIVE(50162c0, 317b3bef, 45d4560, 3a2cdf8, 317b3bec, ffffffff) at netbsd:
 VOP_INACTIVE+0x2c
 vrelel(50162c0, 0, 45d4560, 0, 50162d4, 1) at netbsd:vrelel+0x380
 ufs_remove(0, 500d5a0, 501b720, 317b3cb0, 50162c0, 5011e80) at netbsd:ufs_remove
 +0xac
 VOP_REMOVE(5011e80, 50162c0, 317b3d50, 0, 0, 2) at netbsd:VOP_REMOVE+0x30
 do_sys_unlinkat.isra.3(0, ff40f5dc, 0, 0, 3daf000, 50162c0) at netbsd:do_sys_unl
 inkat.isra.3+0x18c
 syscall(317b3ed0, 317b3f48, ff7049f8, 45d4560, 0, ff7049fc) at netbsd:syscall+0x
 380
 ?(ff40f5dc, 0, 3, ff402050, ff40f580, ff40f580) at 1010d40
 
 (gdb) l *(genfs_do_putpages+0xc88)
 (gdb) x/i *(genfs_do_putpages+0xc88)
    0x119c7c8 <genfs_do_putpages+3208>:  call  0x15de5c0 <uvm_pagefree>
    0x119c7cc <genfs_do_putpages+3212>:  st  %i0, [ %fp + -260 ]
 
 As the box doesn't panic when building other packages, I guess it's related
 to what's happening in this emacs process stuck in a kernel loop ...
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --