Date: Tue, 12 Oct 2004 00:11:36 +0200 From: Benjamin Lutz <benlutz@datacomm.ch> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: NFS trouble Message-ID: <200410120011.40517.benlutz@datacomm.ch> In-Reply-To: <Pine.NEB.3.96L.1041011174418.55701C-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1041011174418.55701C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1477122.69Bzvg1lYO
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Ugh. While writing this mail I've noticed Sean McNeils mail. I suppose=20
thats the answer right there. Damn, I even read about the problem several=20
times right here on this mailing list, it just didn't occur to me that it=20
could be the NIC...
Well. For completeness' sake I'll still include the response to rwatson@=20
below. There's some hardware info included as well.
Thanks a lot for answering, all of you.
Benjamin
> When you're experiencing this problem, can the NFS client ping the NFS
> server?
Yes.
> Are other NFS clients able to continue to access the NFS=20
> server without problems?
Partially. Other clients can access parts of the exported share. It=20
appears that as soon as they access the directory in which the first=20
program froze, they freeze as well.
> It might be interesting to use tcpdump to see if the client stops
> sending RPCs or not, and if not, whether the server responds to them. =20
I'll try the next time I see the problem. It's not easily reproducable,=20
sometimes it freezes when I try to store a 2KB text file, sometimes after=20
being able to copy a few hundred MB. I tried to reproduce it just now by=20
copying random stuff around, of course that didn't work. Seems the=20
problem only appears when I'm using valuable files... *sigh*.
> If you set debug.mpsafenet=3D0 in loader.conf, does the problem go away?=
=20
I'll try it and report.
> Also, finally, what ethernet device(s) are you using, and are there any
> notes about those devices in the dmesg output?=20
I'm using the Realtek onboard Gigabit NIC on my MSI K8N Neo2 Platinum=20
mainboard. Ooooh... wait... could it be that Realtek once again manages=20
to fuck a machine of mine up in a weird way? Either way, the adapter is=20
described in the manual as Realtek 8110S chip. FreeBSD reports it as:
re0: <RealTek 8169S Single-chip Gigabit Ethernet> port 0xac00-0xacff mem
0xf3000000-0xf30000ff irq 16 at device 13.0 on pci2
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S media interface> on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,=20
1000baseTX-FDX, auto
re0: Ethernet address: 00:11:09:65:fc:0e
Another bit of information: Last time this happened, the freeze was=20
reproducable. I did the following:
=2D Try to save a text file in kate to the NFS share, notice that kate was=
=20
frozen in nfsfsync state.=20
=2D umount -f the share
=2D See that kate is unfrozen, and that it displays an error message about
not being able to write the file.
=2D remount it
=2D Try to save the still open file again, notice that kate freezes again.
=2D After changing the text file, saving worked.
So I think this is triggered by a certain bytestream, it appears to not be=
=20
totally random.=20
--nextPart1477122.69Bzvg1lYO
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQBBawUcgShs4qbRdeQRAuVbAJ44TmNuUvbdmrLUHSN0iRBp40cK8QCeP9Ab
jMKxMSiKLbzN4yMbH21BZXI=
=44GN
-----END PGP SIGNATURE-----
--nextPart1477122.69Bzvg1lYO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410120011.40517.benlutz>