From owner-freebsd-current@FreeBSD.ORG Thu Nov 27 11:47:54 2003 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 BC15416A4CE for ; Thu, 27 Nov 2003 11:47:54 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id C45FF43FCB for ; Thu, 27 Nov 2003 11:47:53 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hARJlkHQ078929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 27 Nov 2003 11:47:48 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: "Bjoern A. Zeeb" , Yuriy Tsibizov Date: Thu, 27 Nov 2003 11:50:27 -0800 User-Agent: KMail/1.5.3 References: <20031127110256.H711@free.home.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311271150.27841.sam@errno.com> cc: freebsd-current@freebsd.org Subject: Re: recent current panic 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: Thu, 27 Nov 2003 19:47:54 -0000 On Thursday 27 November 2003 06:38 am, Bjoern A. Zeeb wrote: > On Thu, 27 Nov 2003, Yuriy Tsibizov wrote: > > Hi, > > > >i got a panic on recent -CURRENT: > > > > > ># tcpdump -i lo0 port 23 & > > >[1] 507 > > >listening on lo0 > > > > > ># telnet localhost > > >Trying ::1... > > > > > >Wed Nov 26 14:51:23 MSK 2003 > > >Debugger+0x55: xchgl %ebx,in_Debugger.0 > > > > [....] > > > > It looks very similar to > > http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to > > version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc > > or gif interface right now. > > just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o > problems two days ago (with a recent world) while debugging and > testing other net related things. As was noted earlier, the issue is the addition of M_ASSERTVALID to the BPF_MTAP macro. This fails in numerous cases because existing practice was to allocate a "fake mbuf" on the stack for passing local data in to bpf. If this mbuf is not zero'd (or at least m_flags) then the assertion may trip. It's arguable what the correct solution is for these problems but you should be able to safely remove the assert until we can make a sweep over the drivers as the existing code has been around for a while (not to imply this makes it right :)). Sam