From owner-cvs-src@FreeBSD.ORG Tue Mar 25 14:20:17 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 B03DD37B401; Tue, 25 Mar 2003 14:20:17 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C7743F93; Tue, 25 Mar 2003 14:20:16 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id C86552ED419; Tue, 25 Mar 2003 14:20:16 -0800 (PST) Date: Tue, 25 Mar 2003 23:20:16 +0100 From: Maxime Henrion To: Mike Silbersack Message-ID: <20030325222016.GF57674@elvis.mu.org> References: <200303250545.h2P5j5PM008552@repoman.freebsd.org> <20030324234234.T6129@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030324234234.T6129@odysseus.silby.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT 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:20:26 -0000 Mike Silbersack 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. Looks like there is a bug in this code. I tried to understand what's wrong in the if_xl code that tries to deal with mbuf chains containing more than XL_MAXFRAGS mbufs, and noticed that m_head->m_pkthdr.len isn't set properly. The length of an mbuf chain shouldn't change when we're just splitting it into more mbufs, so this is kinda weird. Using m_fixhdr() just after the splitting code solves it, but that's probably just a workaround, and either m_split() or the MBUF_FRAG_TEST code needs to be fixed. That would be a very sufficient reason for this code to not work, but unfortunately, it seems there are more bugs to fix. However, I couldn't even see the packet in tcpdump before, and I now can. That means the card has successfully queued the packet, otherwise it would not get passed to BPF_MTAP() and it wouldn't show up in tcpdump. Moreover, it looks like the packet is valid, yet it seems it's not sent by the card for some reason. I couldn't figure out why yet. I think we should have some code like this before handing a packet to a network driver : KASSERT(m0->m_pkthdr.len == m_length(m0, NULL), ("Bad packet header")); Cheers, Maxime