From owner-freebsd-stable@FreeBSD.ORG Tue Jan 11 07:40:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48ED21065670 for ; Tue, 11 Jan 2011 07:40:41 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [168.103.150.6]) by mx1.freebsd.org (Postfix) with ESMTP id E74878FC14 for ; Tue, 11 Jan 2011 07:40:40 +0000 (UTC) Received: from webmail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id p0B7duII057684; Mon, 10 Jan 2011 23:40:07 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (Local authenticated user inf0s) by webmail.1command.com with HTTP; Mon, 10 Jan 2011 23:40:37 -0800 (PST) Message-ID: <6bb74cb2fa23167e22f88b716d18510e.HRCIM@webmail.1command.com> In-Reply-To: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> References: <717625949.112359.1294698176010.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 10 Jan 2011 23:40:37 -0800 (PST) From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: HRC Internet Messaging/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Rick Macklem Subject: Re: important NFS client patch for FreeBSD8.n X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:40:41 -0000 Greetings, and thank you for the "heads up". On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: > I just commited a patch (r217242) to head. Anyone who is using client > side NFS on FreeBSD8.n should apply this patch. It is also available at: > http://people.freebsd.org/~rmacklem/krpc.patch > > > It fixes a problem where the kernel rpc assumes that 4 bytes of data > exists in the first mbuf without checking. If the data straddles multiple mbufs, > it uses garbage and then a typical case will wedge for a minute or so until it > times out and establishes a new TCP connection. It also replaces m_pullup() with > m_copydata(), since m_pullup() can fail for rare cases when there is data > available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail when mbuf > allocation is constrainted, for example.) > > Thanks to john.gemignani at isilon.com for spotting this problem, rick I just fired a message off to @amd64 && @net because I am seeing messages like: nfe0: tx v2 error 0x6204 on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. They both run NFS client && server, and they both utilize mount points on each other. They are only 2 of several interconnected servers. The others are all 7x/i386. But I only see these messages on the 8.1/amd64, and only when connected to, and utilizing mounts on the 8.0/i386, and even then, only when the data exceeds ~1.5Mb. I guess I'm asking if the messages I'm receiving are related to the corrections your patch provides. Or should I keep looking for the answer for the messages I am seeing. Thank you for all your time and consideration. --Chris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > --