Re: CVS commit: src/sys

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

Hi,

For alpha, I've observed similar failure with rev 1.104; savecore fails and
panic occurs in pagedaemon after that.

Thanks,
rin
----
# /etc/rc.d/savecore onestart
Checking for core dump...
savecore: (null): kvm_nlist: bad namelist
savecore: (null): _dumpdev not in namelist
# dd if=/dev/zero of=/dev/null bs=2g
[ 727.7471213] CPU 0: fatal kernel trap:
^
[ 727.7946544] CPU 0    trap entry = 0x2 (memory management fault)
[ 727.8653781] CPU 0    a0         = 0x73
[ 727.9101025] CPU 0    a1         = 0x1
[ 727.9537858] CPU 0    a2         = 0x0
[ 727.9974700] CPU 0    pc         = 0xfffffc0000a68898
[ 728.0567529] CPU 0    ra         = 0xfffffc00010b9598
[ 728.1160375] CPU 0    pv         = 0xfffffc0000a68864
[ 728.1753220] CPU 0    curlwp     = 0xfffffc007f58e5c0
[ 728.2346053] CPU 0        pid = 0, comm = system

[ 728.2907705] panic: trap
[ 728.3198911] cpu0: Begin traceback...
[ 728.3625359] alpha trace requires known PC =eject=
[ 728.4187019] cpu0: End traceback...
Stopped in pid 0.111 (system) at        netbsd:cpu_Debugger+0x4:        ret
zero,(ra)
db{0}> bt
cpu_Debugger() at netbsd:cpu_Debugger+0x4
db_panic() at netbsd:db_panic+0xc8
vpanic() at netbsd:vpanic+0x108
panic() at netbsd:panic+0x58
trap() at netbsd:trap+0xb00
XentMM() at netbsd:XentMM+0x20
--- memory management fault (from ipl 0) ---
rw_tryenter() at netbsd:rw_tryenter+0x34
uvmpd_trylockowner() at netbsd:uvmpd_trylockowner+0x68
uvmpdpol_balancequeue() at netbsd:uvmpdpol_balancequeue+0x1b4
uvm_pageout() at netbsd:uvm_pageout+0x714
--- kernel thread backstop ---
db{0}>

On 2021/09/15 22:12, Rin Okuyama wrote:
> On 2021/09/15 21:55, Taylor R Campbell wrote:
> > > Date: Wed, 15 Sep 2021 19:58:20 +0900
> > > From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
> > >
> > > login: [  95.5000696] panic: kernel diagnostic assertion "slock != NULL" failed: file "../../../../uvm/uvm_pdaemon.c", line 398 pg 0x8c66bd88 uobj 0x8fa7e400, NULL lock
> > > [...]
> > >
> > > It seems that I can avoid this panic if
> > >
> > > - revert kern_ksyms.c to rev 1.98 (*), *or*
> > > - set savecore=NO in rc.conf.
> > >
> > > (*) I've not tested revs 1.99--1.103.
> > >
> > > Can you please take a look into?
> >
> > Interesting.  I'm not sure what's going on here.  The uvm panic looks
> > like a compounded symptom rather than the original problem.
> >
> > Can you try booting with savecore=NO and see if `cat /dev/ksyms' or
> > `nm /dev/ksyms' works?
> >
> > Can you also try rev. 1.103 and see if that makes a difference, just
> > to narrow it down?  (No point in trying the other revisions.  Unlikely
> > that 1.103 will work if 1.104 doesn't, but will help to confidently
> > narrow it down.)
>
> 'nm /dev/ksyms' works fine for 1.104. Also, panic does not occur after that,
> as far as I can see.
>
> For 1.103, savecore does not work and panic occurs during multiuser boot with
> savecore=YES in the same manner as for 1.104. On the other hand,
> 'nm /dev/ksyms' works fine.
>
> For 1.102 (== 1.98), whereas savecore works, nm complains as:
>
> ----
> # nm /dev/ksyms
> nm: warning: /dev/ksyms has a corrupt section with a size (18) larger than the file size
> nm: warning: /dev/ksyms has a corrupt section with a size (4a560) larger than the file size
> nm: warning: /dev/ksyms has a corrupt section with a size (46de5) larger than the file size
> nm: warning: /dev/ksyms has a corrupt section with a size (40) larger than the file size
> 8c38fec8 t C.7
> 8c3e5b08 t CSWTCH.118
> ...
> ----
>
> Thanks,
> rin