Date: Thu, 25 May 2006 11:01:19 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: Stephan Uphoff <ups@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/nfsclient nfs_bio.c src/sys/fs/smbfs smbfs_io.c src/sys/fs/nwfs nwfs_io.c Message-ID: <1148569279.13356.10.camel@opus.cse.buffalo.edu> In-Reply-To: <200605250100.k4P10a3P002448@repoman.freebsd.org> References: <200605250100.k4P10a3P002448@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-9mEkVmxFDO2EHlvcs7NU
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Thu, 2006-05-25 at 01:00 +0000, Stephan Uphoff wrote:
> ups 2006-05-25 01:00:36 UTC
>=20
> FreeBSD src repository
>=20
> Modified files:
> sys/kern vfs_subr.c=20
> sys/nfsclient nfs_bio.c=20
> sys/fs/smbfs smbfs_io.c=20
> sys/fs/nwfs nwfs_io.c=20
> Log:
> Do not set B_NOCACHE on buffers when releasing them in flushbuflist().
> If B_NOCACHE is set the pages of vm backed buffers will be invalidated.
> However clean buffers can be backed by dirty VM pages so invalidating t=
hem
> can lead to data loss.
> Add support for flush dirty page in the data invalidation function
> of some network file systems.
> =20
> This fixes data losses during vnode recycling (and other code paths
> using invalbuf(*,V_SAVE,*,*)) for data written using an mmaped file.
> =20
> Collaborative effort by: jhb@,mohans@,peter@,ps@,ups@
> Reviewed by: tegge@
> MFC after: 7 days
> =20
> Revision Changes Path
> 1.43 +4 -0 src/sys/fs/nwfs/nwfs_io.c
> 1.35 +4 -0 src/sys/fs/smbfs/smbfs_io.c
> 1.673 +1 -1 src/sys/kern/vfs_subr.c
> 1.157 +11 -0 src/sys/nfsclient/nfs_bio.c
I'm just guessing but I think this is what's causing sledge (amd64
reference machine in the cluster) to panic whenever someone tries to log
in to it. Home directories come from the NetApp. It seems to do other
NFS stuff (e.g. it's able to get to the SSH keys which also reside on
the NetApp) but something about logging in causes this:
panic: mutex vm object not owned at ../../../vm/vm_object.c:695
cpuid =3D 0
KDB: stack backtrace:
kdb_backtrace() at kdb_backtrace+0x37
panic() at panic+0x1d1
_mtx_assert() at _mtx_assert+0x78
vm_object_page_clean() at vm_object_page_clean+0x3e
nfs_vinvalbuf() at nfs_vinvalbuf+0xc2
nfs_bioread() at nfs_bioread+0x43b
nfs_read() at nfs_read+0x33
VOP_READ_APV() at VOP_READ_APV+0xb1
vn_read() at vn_read+0x218
dofileread() at dofileread+0x9e
kern_readv() at kern_readv+0x4f
read() at read+0x4b
syscall() at syscall+0x350
Xfast_syscall() at Xfast_syscall+0xa8
--- syscall (3, FreeBSD ELF64, read), rip =3D 0x8009de68c, rsp =3D
0x7fffffff2798, rbp =3D 0x2000 ---
KDB: enter: panic
[thread pid 465 tid 100056 ]
Stopped at kdb_enter+0x31: leave
db>
--=20
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
--=-9mEkVmxFDO2EHlvcs7NU
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQBEdca//G14VSmup/YRAn2PAJ9h5ESN2RMExGAdBPSbhREKMHz+7wCfW+wq
UUuSnjD/2LrKi80wxfElkQE=
=6EFC
-----END PGP SIGNATURE-----
--=-9mEkVmxFDO2EHlvcs7NU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1148569279.13356.10.camel>