Re: pmap assertion failure on booke (RB800)
Rin Okuyama <[email protected]> Sun, 11 Sep 2016 15:20:09 +0900
| Newsgroups | gmane.os.netbsd.ports.powerpc |
|---|---|
| Message-ID | <[email protected]> |
Sorry, this is for current (20160910). On 2016/09/11 13:11, Rin Okuyama wrote: > I observe reproducible pmap assertion failure on booke (RB800). > I don't know the exact condition for it, but I always encounter > kernel panic when I try to build pkgsrc/lang/perl5 (NFS root): > > % cd /usr/pkgsrc/lang/perl5; sudo make > (snip) > => Checking for portability problems in extracted files > (snip) > Use which C compiler? [gcc] > execve_loadvm: check exec failed 8 > execve_loadvm: check exec failed 8 > execve_loadvm: check exec failed 8 > execve_loadvm: check exec failed 8 > Checking for GNU cc in disguise and/or its version number... > panic: kernel diagnostic assertion "!VM_PAGEMD_EXECPAGE_P(VM_PAGE_TO_MD(PHYS_TO_VM_PAGE(dst)))" failed: file "/var/build/src/sys/arch/powerpc/booke/booke_pmap.c", line 380 > Stopped in pid 1679.1 (sed) at netbsd:cpu_Debugger+0xc: tw 0, r1, r1 > > The followings are bt and ps in the DDB session: > > db> bt > 0x00951be0: at vpanic+0x13c > 0x00951c10: at kern_assert+0x68 > 0x00951c50: at uvmfault_promote+0x16c > 0x00951ca0: at uvm_fault_lower+0x3d8 > 0x00951d20: at uvm_fault_internal+0x7f4 > 0x00951e50: at pagefault+0x3c > 0x00951e90: at trap+0x470 > 0x00951f20: user 0xeffe2730: srr1=0x2d230 > r1=0xffff6220 cr=0x24002208 xer=0 ctr=0xeffe2720 > db> ps > PID LID S CPU FLAGS STRUCT LWP * NAME WAIT > 1679 > 1 7 0 0 fb7d3a0 sed > 1963 1 3 0 80 f143960 sh wait > 753 1 3 0 80 f4853c0 sh pipe_rd > 1016 1 3 0 80 fc64bc0 sh wait > 762 1 3 0 80 fc64900 make wait > 717 1 3 0 80 fb7d660 sh wait > 483 1 3 0 80 fb7dbe0 make wait > 500 1 3 0 80 fc640c0 zsh pause > 542 1 3 0 80 fe30ba0 login wait > 349 1 3 0 80 f485100 cron nanoslp > 432 1 3 0 80 f485680 qmgr kqueue > 492 1 3 0 80 fb7d920 pickup kqueue > 502 1 3 0 80 f485c00 master kqueue > 330 1 3 0 80 f485940 sshd select > 146 1 2 0 0 fb7d0e0 syslogd > 1 1 3 0 80 fe998c0 init wait > 0 40 3 0 200 fe308e0 swapiod swapiod > 0 39 3 0 200 fe300a0 aiodoned aiodoned > 0 38 3 0 200 fe30360 ioflush syncer > 0 37 3 0 200 fe30620 pgdaemon pgdaemon > 0 34 3 0 200 fef55e0 nfsio nfsiod > 0 33 3 0 200 fef5320 nfsio nfsiod > 0 32 3 0 200 fef5060 nfsio nfsiod > 0 31 3 0 200 fe99b80 nfsio nfsiod > 0 29 3 0 200 fe99600 unpgc unpgc > 0 28 3 0 200 fe99340 rt_timer rt_timer > 0 27 3 0 200 fe99080 vmem_rehash vmem_rehash > 0 18 3 0 200 fef58a0 atabus0 atath > 0 17 3 0 200 fef5b60 iic1 iicintr > 0 16 3 0 200 ff2a040 iic0 iicintr > 0 15 3 0 200 ff2a300 pmfsuspend pmfsuspend > 0 14 3 0 200 ff2a5c0 pmfevent pmfevent > 0 13 3 0 200 ff2a880 sopendfree sopendfr > 0 12 3 0 200 ff2ab40 nfssilly nfssilly > 0 11 3 0 200 ff66020 cachegc cachegc > 0 10 3 0 200 ff662e0 vrele vrele > 0 9 3 0 200 ff665a0 vdrain vdrain > 0 8 3 0 200 ff66860 modunload mod_unld > 0 7 3 0 200 ff66b20 xcall/0 xcall > 0 6 1 0 200 ff6a000 softser/0 > 0 5 1 0 200 ff6a2c0 softclk/0 > 0 4 1 0 200 ff6a580 softbio/0 > 0 3 1 0 200 ff6a840 softnet/0 > 0 2 1 0 201 ff6ab00 idle/0 > 0 1 3 0 200 343600 swapper uvm > > I guess that this is due to the recent changes in MI parts of pmap. > Would it be better to send-pr? > > Thanks, > Rin >