panic: vm_fault_copy_wired: page missing
danny at cs.huji.ac.il
Sun Apr 18 10:21:29 UTC 2010
> > >
> > > --QA3RSaXxDkY7tjDy
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote:
> > > >=20
> > > > > Take NFS out of the picture if you can...
> > > > >=20
> > > > I've been thinking along those lines, and Kostic is convinced
> > > > that the problem lies there, so I guess I'll give it a try, but
> > > > it's no realy a solution.
> > >
> > > Better solution is to remove mlock()/mlockall().
> > without binaries via NFS there is no panic.
> > I can't remove mlock()/mlockall() since it's not my program, it's apache
> > et.all.
> > but, while my knowledge of dtrace is almost zero, I did the next best thing
> > and put a printf in mlock/mlockall and they are not being called by userland.
> > so, it seems the problem is nfs related, calling in the heavy-weights,
> > hi rick!
> well, Kostic was right after all. It was am-utils that called mlockall(),
> I missed the message first time, commented out the call to mlockall, and the
> system is not panicking.
> so there is a problem with mlock and nfs, can this be fixed? is there a pr?
> anyways, thank you all!
I placed amd(am-utils) on local disc, and it still panics - slightly
KDB: enter: panic
[thread pid 1029 tid 100098 ]
Stopped at kdb_enter+0x3d: movq $0,0x68f7a0(%rip)
Tracing pid 1029 tid 100098 td 0xffffff0007502000
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x17b
vm_fault_copy_entry() at vm_fault_copy_entry+0x283
vmspace_fork() at vmspace_fork+0x4d0
fork1() at fork1+0x35f
fork() at fork+0x1c
syscall() at syscall+0x1e7
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (2, FreeBSD ELF64, fork), rip = 0x8009f41ac, rsp = 0x7fffffffe788,
rbp = 0 ---
so IMHO, the problem is somewhere in the fact that root is diskless.
More information about the freebsd-stable