From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 20:46:40 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 683471065672; Wed, 13 Aug 2008 20:46:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 41D3C8FC1C; Wed, 13 Aug 2008 20:46:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7DKkcK0043138; Wed, 13 Aug 2008 16:46:38 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7DKkb47039033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 16:46:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808132046.m7DKkb47039033@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2008 16:46:30 -0400 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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 20:46:40 -0000 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? Hi Robert, 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 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]