From owner-freebsd-current Thu Jul 29 10:28: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7A63D14C06 for ; Thu, 29 Jul 1999 10:26:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA76001; Thu, 29 Jul 1999 10:25:46 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 10:25:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291725.KAA76001@apollo.backplane.com> To: Peter Wemm Cc: Bill Paul , crossd@cs.rpi.edu, current@FreeBSD.ORG Subject: Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm References: <19990729054844.2C49C1C9E@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Yes, we do. I've run into this problem elsewhere but a quick fix was needed :so it just got hacked. NT NFS clients tend to trigger it too. : :The problem is that the sanity check is a fair way away from where the problem :packet is generated. The bad reply is generated in the readdirplus routine, :gets replied (without checking) and cached. The client drops the (oversize) :packet, resends, and the nfsd replies from the cache and this time hits :the sanity check and panics. : :... : :I will have another look shortly. Anyway, the clue is that the server :readdirplus routine is the apparent culprit. : :Cheers, :-Peter This makes a lot of sense. A report of du causing the panic, and the good possibility that readdirplus is caching an oversized response packet. Tell me what you come up with! I'll take a crack at it if you don't find anything. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message