From owner-cvs-src@FreeBSD.ORG Tue Mar 25 14:09:44 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D9A37B405 for ; Tue, 25 Mar 2003 14:09:44 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 45CFC43F75 for ; Tue, 25 Mar 2003 14:09:42 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 2247 invoked from network); 25 Mar 2003 22:09:41 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 25 Mar 2003 22:09:41 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 25 Mar 2003 16:06:19 -0600 (CST) From: Mike Silbersack To: Bill Paul In-Reply-To: <20030325220044.DA39F37B401@hub.freebsd.org> Message-ID: <20030325160051.H580@odysseus.silby.com> References: <20030325220044.DA39F37B401@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-26.5 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_output.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2003 22:09:47 -0000 On Tue, 25 Mar 2003, Bill Paul wrote: > > > > FWIW, the two drivers I tested this with (if_xl and if_sis) both flunk. > > if_xl tries to fix the situation, but fails, and if_sis goes totally > > weird, eating mbufs and rendering the interface unuseable. > > > > I'll test more interfaces once I have these two fixed. > > Just how long did you make the fragment chain in your tests anyway? > > -Bill Well over 63 fragments. I'm not sure what the worst case chain that could be created by an application is, but it seems wise to make sure the drivers can handle whatever you throw at them. One of the reasons if_xl fails, even though it tries to recover is probably because m_copypacket doesn't copy fragments resident inside mbuf clusters, thereby defeating the attempt at defragmentation. I'm going to whip up a m_defragment function we can use in all drivers on long chains soon. This started out as code to test whether old versions of if_xl which did not check for the > 63 condition could cause the mbuf free list corruption described in a bunch of PRs. I never figured that even the fixed code could still be broken. :) Mike "Silby" Silbersack