From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:15:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AE75106564A for ; Fri, 14 Oct 2011 19:15:38 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ixe-mta-27.emailfiltering.com (ixe-mta-27-tx.emailfiltering.com [194.116.199.158]) by mx1.freebsd.org (Postfix) with ESMTP id DDA098FC17 for ; Fri, 14 Oct 2011 19:15:37 +0000 (UTC) Received: from mail-gw5.york.ac.uk ([144.32.129.29]) by ixe-mta-27.emailfiltering.com with emfmta (version 4.8.5.33) by TLS id 1332817118 for ianf@clue.co.za;292b0507c9607bb3; Fri, 14 Oct 2011 19:58:10 +0100 Received: from ury.york.ac.uk ([144.32.108.81]:45018) by mail-gw5.york.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1REmxM-0007O6-6J; Fri, 14 Oct 2011 19:58:08 +0100 Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1REmxM-0004SP-1a; Fri, 14 Oct 2011 19:58:08 +0100 Date: Fri, 14 Oct 2011 19:58:08 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Ian FREISLICH In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Cc: current@freebsd.org Subject: Re: 3 show-stopper issues with 9-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 14 Oct 2011 19:15:38 -0000 On Wed, 5 Oct 2011, Ian FREISLICH wrote: > > In no particular order: It's a shame that nobody has yet picked up on this, it is a very useful list of bugs in 9.0. Is there any chance you could log these three issues as three separate PRs so that they don't get lost? Please tag them with [regression] in the subject if they are indeed regressions from a previous version (they sound like they are) so that they hopefully get onto the release engineering radar. > 1. bce(4) transmit and recieve ring buffer overruns > On a moderately busy router with a full BGP table and > aggregate throughput of between 200mbps and 800mbps, I get > these buffer overruns at an average rate of 28 per second > on the busiest interface. > > [firewall1.jnb1] ~ # sysctl dev.bce |grep com_no_buffers > dev.bce.0.com_no_buffers: 101 > dev.bce.1.com_no_buffers: 0 > dev.bce.2.com_no_buffers: 32547 > dev.bce.3.com_no_buffers: 444 > > I've tried increasing the TX_PAGES and RX_PAGES in > sys/dev/bce/if_bcereg.h as I've done in the past (to 64) > which is what resolved this problem on 8.2-STABLE to no avail. > It appears that there is a hard limit of 8 according to > bce_set_tunables() in if_bce.c. But no values to hw.bce.tx_pages > and hw.bce.rx_pages makes the slightest difference. > > 2. carp(4) on my backup router randomly takes over MASTER on the > standby host, but when ifconfig claims the carp interface > is master tcpdump shows that it's not broadcasting its > advertisement. The actual master still broadcasts and no > setting of advskew or advbase changes the 9-BETA host's > idea of who is actually master. I have to reboot the host > to reset the carp interfaces. destroying and re-creating > them just brings them up as backup for about a second and > then they regress to master. Is ipv6 involved in this? Do you have a couple of sample config files that I can drop onto two machines and recreate the issue, by any chance? > 3. PF doesn't expire state. The state table on my older host (pre > OpenBSD-4.5) has the following stats: > > Status: Enabled for 0 days 00:37:17 Debug: Urgent > State Table Total Rate > current entries 169546 > searches 94387451 42193.8/s > inserts 4012389 1793.6/s > removals 3842843 1717.9/s > > The 9-BETA3 host's current entries exactly match the number > of inserts until it hits the hard limit of 1.5M entries and > can add no more. It takes about 10 minutes to fill up and > then no new flows are routed. I've seen a few reports of this, and it's quite concerning. Please, can you submit this as a PR? Thanks, Gavin