From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 22:11:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A25D16A4CE; Mon, 11 Oct 2004 22:11:43 +0000 (GMT) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D853843D41; Mon, 11 Oct 2004 22:11:42 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 03DC926A; Tue, 12 Oct 2004 00:11:41 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87022-07; Tue, 12 Oct 2004 00:11:40 +0200 (CEST) Received: from merlin.intranet (merlin.intranet [10.0.0.16]) by maxlor.mine.nu (Postfix) with ESMTP id D9D9DCF; Tue, 12 Oct 2004 00:11:39 +0200 (CEST) From: Benjamin Lutz To: Robert Watson Date: Tue, 12 Oct 2004 00:11:36 +0200 User-Agent: KMail/1.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1477122.69Bzvg1lYO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410120011.40517.benlutz@datacomm.ch> X-Virus-Scanned: by amavisd-new at maxlor.mine.nu cc: freebsd-current@freebsd.org Subject: Re: NFS trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 22:11:43 -0000 --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: port 0xac00-0xacff mem 0xf3000000-0xf30000ff irq 16 at device 13.0 on pci2 miibus0: on re0 rgephy0: 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--