From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 21:12:19 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4268A106566B for ; Wed, 13 Aug 2008 21:12:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F067C8FC16 for ; Wed, 13 Aug 2008 21:12:18 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 834A846C0B; Wed, 13 Aug 2008 17:12:18 -0400 (EDT) Date: Wed, 13 Aug 2008 22:12:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200808132046.m7DKkb47039033@lava.sentex.ca> Message-ID: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <200808132046.m7DKkb47039033@lava.sentex.ca> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you 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: Wed, 13 Aug 2008 21:12:19 -0000 On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 04:41 PM 8/13/2008, Robert Watson wrote: > >> Well, it shouldn't be related, but sometimes things get tricky with locking >> if it turns out that extra locking at one layer was masking a lack of >> locking at another. Let's try to diagnose this one a bit more before >> concluding that is the case, though. I take that the same problems don't >> happen if you boot a vanilla version of the same rev of the kernel? What >> command did you use to generate the list at the bottom of your e-mail? > > the arp messages were a snippet from just arp -na. All of those IP > addresses are local to the box. I am just doing a cvsup to the same point > in time and am rebuilding the kernel. > > Also odd, is that if I do a arp -nda it seems to want to delete more than it > should. Here is a snippet It's concerning also that there is more than one entry for any particular IP address. I'll have to go reread the ARP code. Confirming that this doesn't happen with vanilla head is definitely the next step. I'll be fairly busy for the next few days with things in Cambridge; if we can't rule out the inpcb patches as the source of the problem, I'll defer committing them until next week when I have a chance to work through this more. Robert N M Watson Computer Laboratory University of Cambridge > > > 199.212.134.2 (199.212.134.2) deleted > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > > > After doing arp -nda, I am back to a very large arp cache again right away > > 0[smtp2]# arp -na | wc > 27818 228335 1679120 > 0[smtp2]# > > 0[smtp2]# netstat -na | wc > 762 4920 59057 > 0[smtp2]# netstat -nr | wc > 27853 167097 1893894 > 0[smtp2]# > > > > > >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> 0[smtp2]# sysctl -a | grep prox >>> net.link.ether.inet.proxyall: 0 >>> 0[smtp2]# >>> >>> >>> 0[smtp2]# arp -na | wc >>> 27665 227053 1669734 >>> 0[smtp2]# >>> >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] > >