> > --SpFw69Q4vVW19Q1W > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, Apr 18, 2010 at 01:21:26PM +0300, Daniel Braniss wrote: > > > > >=20 > > > > > --QA3RSaXxDkY7tjDy > > > > > Content-Type: text/plain; charset=3Dus-ascii > > > > > Content-Disposition: inline > > > > > Content-Transfer-Encoding: quoted-printable > > > > >=20 > > > > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote: > > > > > >=3D20 > > > > > > > Take NFS out of the picture if you can... > > > > > > >=3D20 > > > > > > 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. > > > > >=20 > > > > > Better solution is to remove mlock()/mlockall(). > > > >=20 > > > > without binaries via NFS there is no panic. > > > >=20 > > > > I can't remove mlock()/mlockall() since it's not my program, it's apa= > che=20 > > > > 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 u= > serland. > > > >=20 > > > > so, it seems the problem is nfs related, calling in the heavy-weights, > > > > hi rick! > > >=20 > > > 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, an= > d the > > > system is not panicking. > > >=20 > > > so there is a problem with mlock and nfs, can this be fixed? is there a= > pr? > > >=20 > > > anyways, thank you all! > > >=20 > > > danny > >=20 > > I placed amd(am-utils) on local disc, and it still panics - slightly=20 > > differently: > >=20 > > KDB: enter: panic > > [thread pid 1029 tid 100098 ] > > Stopped at kdb_enter+0x3d: movq $0,0x68f7a0(%rip) > > db> tr > > 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 =3D 0x8009f41ac, rsp =3D 0x7fff= > ffffe788,=20 > > rbp =3D 0 --- > >=20 > > so IMHO, the problem is somewhere in the fact that root is diskless. > > Root on nfs means that e.g. libc is still mapped from nfs mount.
argh, forgot about shared libs, so I linked amd static, and it's not panicking, yet ... [amd is in the root nfs]. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
