From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:00:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56FB6106566C for ; Sun, 6 Mar 2011 01:00:23 +0000 (UTC) (envelope-from vanopen@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA588FC16 for ; Sun, 6 Mar 2011 01:00:22 +0000 (UTC) Received: by yxl31 with SMTP id 31so1384130yxl.13 for ; Sat, 05 Mar 2011 17:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :organization:x-operating-system:user-agent; bh=jNf/gPQiH/eHsGuXdJtVAxVJGQ53kBYePqG03iWTAY0=; b=biJmJhK/sejqW75AXW5IUakXm0/I8sguaK70UPk6Si4oiNwyKO1lHw6QD+wiS04Sv9 zhwFHWLmx+FCEhVzEZ37eof0ctNkA68ddfOREgfblLuv+3eH8ZxdPRNuu0AsIGIWAW/C 2ZEgi0FwY84zSItfZMsPFXs0kKI2sBZvb4J/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:organization :x-operating-system:user-agent; b=prGsBKvAABWu3N1qCQc8T2ehvTzRIf431z7TEukifhJmgRJXKyqyGrhONPlMv66MvC +a2tv3GTBmwpsoJ3t3cBGOyT0WAok1go/TUQxv2qWZaHJBA6IqyCBW9SxzUXrnls+hUU oRaMIIVEEO1Ep0RXI4/IWn6tPPWy89172FGIk= Received: by 10.146.219.42 with SMTP id r42mr3350367yag.37.1299373222163; Sat, 05 Mar 2011 17:00:22 -0800 (PST) Received: from fbsd.t60.cpu ([221.6.39.130]) by mx.google.com with ESMTPS id f10sm1490896anh.25.2011.03.05.17.00.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2011 17:00:21 -0800 (PST) Date: Sun, 6 Mar 2011 09:00:15 +0800 From: Yue Wu To: ml-freebsd-stable Message-ID: <20110306010015.GC4160@fbsd.t60.cpu> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D72A069.90104@FreeBSD.org> Organization: China Pharmaceutical University, Nanjing, China X-Operating-System: FreeBSD 8.2-PRERELEASE i386 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 01:00:23 -0000 Hello, sorry for poor English, I will try to explan clearer with my best. On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > > > I'm trying to use package instead of ports these day, but a few > > questions have: > > > > 1. How to reserve packages that fetched via `pkg_add -r`? > > > > 2. How to know if there are updates for packages, and how to update? > > For (1), do you mean 'preserve', as in save a copy? If so, then > 'portmaster -b [...]' will save a backup copy of installed packages. Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a installed package, so it will preserve it by packing up the files from a installed package, why not preserve it just when fetching with `pkg_add -r`? I think it's the best way, I don't like the portmaster way to do it after. > > There may be a better way, but one way to deal with (2) is to have an > up-to-date ports tree. Then 'pkg_version -vL=' will show you which of > your ports are out of date. Then 'portmaster -PP [...]' will force > package use for updates. > > If you have an up-to-date ports tree, then I think that > > portmaster -abPP > > will update all of your ports, using packages, and save a backup copy > of the installed versions. I'm trying to avoid to touch the port tree, it has 700+ MB... On Sat, Mar 05, 2011 at 12:43:21PM -0800, Doug Barton wrote: > On 03/05/2011 07:48, Greg Byshenk wrote: > > On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > > > >> I'm trying to use package instead of ports these day, but a few > >> questions have: > >> > >> 1. How to reserve packages that fetched via `pkg_add -r`? > > Not sure what you're asking here, can you clarify? Sorry, Greg has guessed it right ;p > >> 2. How to know if there are updates for packages, and how to update? > > > > There may be a better way, but one way to deal with (2) is to have an > > up-to-date ports tree. Then 'pkg_version -vL=' will show you which of > > your ports are out of date. Then 'portmaster -PP [...]' will force > > package use for updates. > > > > If you have an up-to-date ports tree, then I think that > > > > portmaster -abPP > > The -PP option has to be by itself on the command line, or you can use > --packages-only. > > However portmaster doesn't need a ports tree to operate on packages > only. You can use the --index-only --packages-only options and it'll > work just fine. You'll want to read the man page before getting started. > Is it the only way? As I said above, I don't like portmaster's way, I thought there might be a cmd package-update just like freebsd-update, but seems it doesn't, even doesn't have a KISS way to know if there are updates for packages. -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:01:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72BA7106566B for ; Sun, 6 Mar 2011 01:01:43 +0000 (UTC) (envelope-from cliftonr@oz.volcano.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mx1.freebsd.org (Postfix) with ESMTP id 301828FC12 for ; Sun, 6 Mar 2011 01:01:42 +0000 (UTC) X-Authority-Analysis: v=1.1 cv=dquaJDitHqzHCdqWSoZ6IgapSuTzW/4TaRYx9N9k4W8= c=1 sm=0 a=tNKROUZvqFQA:10 a=kj9zAlcOel0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:17 a=jb__rZ8GAAAA:8 a=H9iEQFZ8AAAA:8 a=xNG4kajUJUeXKUXnrWsA:9 a=9MAIaSS7JbBgC1nUG1YA:7 a=b7obUt-O5E1v2NwycfKai_En27oA:4 a=CjuIK1q_8ugA:10 a=sHp_62vNEjwA:10 a=fZFZujrNNEQA:10 a=G5OLwwqwWgs+1dCEPNHTSw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.80.196.236 Received: from [75.80.196.236] ([75.80.196.236:9677] helo=oz.volcano.org) by hrndva-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 0F/22-14011-5FCD27D4; Sun, 06 Mar 2011 01:01:42 +0000 Received: by oz.volcano.org (Postfix, from userid 1001) id B886B50824; Sat, 5 Mar 2011 15:01:40 -1000 (HST) Date: Sat, 5 Mar 2011 15:01:40 -1000 From: Clifton Royston To: Jeremy Chadwick Message-ID: <20110306010140.GA90699@lava.net> Mail-Followup-To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <20110305234514.GA34594@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110305234514.GA34594@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 01:01:43 -0000 On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > This is a strange one, and the more I started debugging it (starting > with truss, comparing fast vs. slow results, where all that appears > different is read() operations are taking a lot longer -- I haven't had > time to check with ktrace yet), the more strange it got: that's when I > found out the behaviour changes depending on if you're a user or root. > > Easy to reproduce: > > - grep -r string /usr/src, as non-root, is fast > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i From your results below, I think you mean *80* x slower! > - grep -r string /usr/src, as root, is fast > - grep -r -i string /usr/src, as root, is fast I can not reproduce this on 7.3-RELEASE-p4; I get consistent results between root and non-root, with -i being only marginally slower (about 15%) for each; results below. Just to satisfy my peace of mind, can you do 'which grep' and 'sudo sh -c "which grep"' as jdc to make sure it's not path-related weirdness? -- Clifton [cliftonr@oz ~]$ id uid=1001(cliftonr) gid=1001(cliftonr) groups=1001(cliftonr),0(wheel),1002(svn-user),1000(users) [cliftonr@oz ~]$ for i in {0..9}; do /usr/bin/time -h /usr/bin/grep -r \ PAE /usr/src/sys/dev > /dev/null; done 12.10s real 0.16s user 0.21s sys 0.20s real 0.12s user 0.08s sys ... [cliftonr@oz ~]$ for i in {0..9}; do /usr/bin/time -h /usr/bin/grep -r \ PAE /usr/src/sys/dev > /dev/null; done 0.20s real 0.11s user 0.09s sys 0.20s real 0.13s user 0.06s sys 0.20s real 0.12s user 0.08s sys 0.20s real 0.12s user 0.07s sys 0.20s real 0.14s user 0.06s sys 0.20s real 0.15s user 0.05s sys 0.20s real 0.12s user 0.08s sys 0.20s real 0.09s user 0.11s sys 0.20s real 0.14s user 0.06s sys 0.20s real 0.12s user 0.07s sys [cliftonr@oz ~]$ for i in {0..9}; do /usr/bin/time -h /usr/bin/grep -r \ -i PAE /usr/src/sys/dev > /dev/null; done 0.23s real 0.14s user 0.08s sys 0.23s real 0.15s user 0.07s sys 0.23s real 0.18s user 0.05s sys 0.23s real 0.14s user 0.08s sys 0.23s real 0.19s user 0.03s sys 0.23s real 0.18s user 0.04s sys 0.23s real 0.14s user 0.08s sys 0.23s real 0.13s user 0.09s sys 0.23s real 0.16s user 0.06s sys 0.22s real 0.17s user 0.05s sys [cliftonr@oz ~]$ sudo -v [cliftonr@oz ~]$ for i in {0..9}; do sudo /usr/bin/time -h \ /usr/bin/grep -r PAE /usr/src/sys/dev > /dev/null; done 0.20s real 0.18s user 0.02s sys 0.20s real 0.10s user 0.10s sys 0.20s real 0.14s user 0.06s sys 0.20s real 0.13s user 0.06s sys 0.20s real 0.12s user 0.08s sys 0.20s real 0.12s user 0.07s sys 0.20s real 0.12s user 0.08s sys 0.20s real 0.12s user 0.08s sys 0.20s real 0.16s user 0.03s sys 0.20s real 0.15s user 0.05s sys [cliftonr@oz ~]$ for i in {0..9}; do sudo /usr/bin/time -h \ /usr/bin/grep -r -i PAE /usr/src/sys/dev > /dev/null; done 0.23s real 0.17s user 0.05s sys 0.23s real 0.16s user 0.06s sys 0.23s real 0.17s user 0.05s sys 0.23s real 0.17s user 0.06s sys 0.23s real 0.17s user 0.06s sys 0.23s real 0.18s user 0.05s sys 0.23s real 0.17s user 0.05s sys 0.23s real 0.14s user 0.08s sys 0.23s real 0.15s user 0.08s sys 0.22s real 0.13s user 0.09s sys [cliftonr@oz ~]$ which grep /usr/bin/grep [cliftonr@oz ~]$ sudo sh -c "which grep" /usr/bin/grep -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:02:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9B51065679 for ; Sun, 6 Mar 2011 01:02:48 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 511658FC0A for ; Sun, 6 Mar 2011 01:02:47 +0000 (UTC) Received: by fxm19 with SMTP id 19so3622591fxm.13 for ; Sat, 05 Mar 2011 17:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TsYhN08A5YAlz/D3voFKzLEDkw4lgpmmm+8JaWX853w=; b=Oqlpf86GuIcpEH13XMlmavnBEGaR4vXW2OhA33vc9azSnDIDh9RmK1YyokXeKclXc/ KUdnsTkEX1AfKBeBMvCua2eUI6NhM3G43sybZ1+ew6JlPJ31i4HQ7EhSd27Yk0calw8i Q0zJEdVdeK9BWQ5SmM/X5FGwFzkT/8DCI1Dtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ndQu3fb3uXh621q4f5AeQXdfQJPdPGAj4/cm/QZpMpaHlnD0A/JwZLKYhU3twB5H6e 2XEzWyQOZj4pIGjHQ9kmiyWT7btbDMfxpysmi8f0hRyRgVzs4lek0jO3KqO2pKYAQ4ri 1Rli9YTrGKw2Ymd94KesZK+7uIkZN3kDA/6pU= MIME-Version: 1.0 Received: by 10.223.14.137 with SMTP id g9mr536142faa.2.1299373367217; Sat, 05 Mar 2011 17:02:47 -0800 (PST) Received: by 10.223.96.203 with HTTP; Sat, 5 Mar 2011 17:02:47 -0800 (PST) In-Reply-To: <20110306010015.GC4160@fbsd.t60.cpu> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> Date: Sat, 5 Mar 2011 20:02:47 -0500 Message-ID: From: "illoai@gmail.com" To: Yue Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ml-freebsd-stable Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 01:02:48 -0000 On 5 March 2011 20:00, Yue Wu wrote: > Hello, sorry for poor English, I will try to explan clearer with my > best. > > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: >> >> > I'm trying to use package instead of ports these day, but a few >> > questions have: >> > >> > 1. How to reserve packages that fetched via `pkg_add -r`? >> > >> > 2. How to know if there are updates for packages, and how to update? >> >> For (1), do you mean 'preserve', as in save a copy? =A0If so, then >> 'portmaster -b [...]' will save a backup copy of installed packages. > > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > installed package, so it will preserve it by packing up the files from a > installed package, why not preserve it just when fetching with `pkg_add > -r`? I think it's the best way, I don't like the portmaster way to do it > after. from man 1 pkg_add: -K, --keep Keep any downloaded package in PKGDIR if it is defined or in c= ur- rent directory by default. --=20 -- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:14:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46A5C106579A for ; Sun, 6 Mar 2011 01:14:41 +0000 (UTC) (envelope-from vanopen@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDBA38FC16 for ; Sun, 6 Mar 2011 01:14:40 +0000 (UTC) Received: by ywf9 with SMTP id 9so1381774ywf.13 for ; Sat, 05 Mar 2011 17:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:organization :x-operating-system:user-agent; bh=KVg9BbwPYAvHbdLidCsiZ+FU9aSGmgWt3aGJG/tIdto=; b=hylfPlKgq/NL5CpookD+5XS+hIZ/+TGxvVTQRDuZyfgeqXer/1993NcY6kDDn53r8L kg4Cn0j/UoviNH/u+FsEowl9sFuF9Hgr8wbG7USR+EgqfPun2nRp14Tpm8qMrrA/MdgY Cg39Y7b51gAfcffXmGvR6ItZeIBVPzxedJugA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:organization:x-operating-system:user-agent; b=rKJbq1VyFw4as7Js6tJACJQMmb4A4StyEQF8p5OdwtmGi4atYZlsuwt7N+1MIvYxrc H709RiQQSpzaj1Sp1PwTgAVhqML/n0F/a7Le9hcCwMIB2GCLxusbpRla7+SMpJF64taE xqyvYw0Xn0TG06cCcwo9CILrr5AowjrccR52w= Received: by 10.236.30.233 with SMTP id k69mr3815286yha.0.1299374080069; Sat, 05 Mar 2011 17:14:40 -0800 (PST) Received: from fbsd.t60.cpu ([221.6.39.130]) by mx.google.com with ESMTPS id g31sm707469yhd.26.2011.03.05.17.14.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2011 17:14:39 -0800 (PST) Date: Sun, 6 Mar 2011 09:14:33 +0800 From: Yue Wu To: ml-freebsd-stable Message-ID: <20110306011433.GA21857@fbsd.t60.cpu> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: China Pharmaceutical University, Nanjing, China X-Operating-System: FreeBSD 8.2-PRERELEASE i386 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 01:14:41 -0000 On Sat, Mar 05, 2011 at 08:02:47PM -0500, illoai@gmail.com wrote: > On 5 March 2011 20:00, Yue Wu wrote: > > Hello, sorry for poor English, I will try to explan clearer with my > > best. > > > > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > >> > >> > I'm trying to use package instead of ports these day, but a few > >> > questions have: > >> > > >> > 1. How to reserve packages that fetched via `pkg_add -r`? > >> > > >> > 2. How to know if there are updates for packages, and how to update? > >> > >> For (1), do you mean 'preserve', as in save a copy?  If so, then > >> 'portmaster -b [...]' will save a backup copy of installed packages. > > > > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > > installed package, so it will preserve it by packing up the files from a > > installed package, why not preserve it just when fetching with `pkg_add > > -r`? I think it's the best way, I don't like the portmaster way to do it > > after. > > from man 1 pkg_add: > > -K, --keep > Keep any downloaded package in PKGDIR if it is defined or in cur- > rent directory by default. > Thanks, sorry for no attentively reading ;p Another question arises after checking the pkg 'pkg_add' saves, why the pkg doesn't have a version appended to its name, it's hard to know the version the pkg downloaded... -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:43:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66540106564A for ; Sun, 6 Mar 2011 01:43:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1150A8FC0C for ; Sun, 6 Mar 2011 01:43:58 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id FddY1g0021ei1Bg5Edjz2U; Sun, 06 Mar 2011 01:43:59 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta24.westchester.pa.mail.comcast.net with comcast id Fdjx1g0080PUQVN3kdjyDq; Sun, 06 Mar 2011 01:43:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DCC4E9B422; Sat, 5 Mar 2011 17:43:55 -0800 (PST) Date: Sat, 5 Mar 2011 17:43:55 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20110306014355.GA36763@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306010140.GA90699@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306010140.GA90699@lava.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 01:43:59 -0000 On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: > On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > > This is a strange one, and the more I started debugging it (starting > > with truss, comparing fast vs. slow results, where all that appears > > different is read() operations are taking a lot longer -- I haven't had > > time to check with ktrace yet), the more strange it got: that's when I > > found out the behaviour changes depending on if you're a user or root. > > > > Easy to reproduce: > > > > - grep -r string /usr/src, as non-root, is fast > > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > > From your results below, I think you mean *80* x slower! Oops; yes, typo on my part. I was never any good at math either! ;-) > > - grep -r string /usr/src, as root, is fast > > - grep -r -i string /usr/src, as root, is fast > > I can not reproduce this on 7.3-RELEASE-p4; I get consistent results > between root and non-root, with -i being only marginally slower (about > 15%) for each; results below. Your results look more or less like what I see on the 4th system (the 7.0-STABLE one). I believe the speed difference there (and on your system) is justified, as I would imagine strcasecmp() a tiny bit slower than strcmp(). But an 80x slowdown is completely unacceptable, especially given the conditions. My first thought was "compiler optimisation bug?", which I suppose could still be the case, but I don't know how root vs. non-root would change that behaviour, not to mention only when -i was specified. Using 'truss -d' it looks like the slowdown is happening on read(2), which makes me very concerned, as it could indicate something odd going on with CAM? Sadly I cannot (for many reasons) get rid of ahci.ko on any of those 3 systems, so I can't compare stock ata(4) to ahci.ko easily on the same system. ktrace is next, but I have other things to do during the next few hours, then I can spend some cycles on this. > Just to satisfy my peace of mind, can you do 'which grep' and 'sudo sh > -c "which grep"' as jdc to make sure it's not path-related weirdness? It's definitely not path weirdness, which is why I pointed out that the greps on all the systems are identical. Here's a more detailed version: * System #1 $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x 9 root wheel 86936 1 Mar 00:22 /usr/bin/grep * System #2 $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x 9 root wheel 86936 25 Feb 00:13 /usr/bin/grep * System #3 $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x 9 root wheel 86936 20 Oct 02:14 /usr/bin/grep * System #4 (the one without the issue) $ which grep ; grep --version | head -1 ; sudo sh -c 'which grep ; grep --version | head -1' ; ls -l `which grep` /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD /usr/bin/grep grep (GNU grep) 2.5.1-FreeBSD -r-xr-xr-x 9 root wheel 76728 19 Apr 2008 /usr/bin/grep The file size difference should be expected given that it's a significantly older system, and i386 as well. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:49:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0A71065670 for ; Sun, 6 Mar 2011 01:49:48 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2E6A8FC08 for ; Sun, 6 Mar 2011 01:49:47 +0000 (UTC) Received: by fxm19 with SMTP id 19so3636494fxm.13 for ; Sat, 05 Mar 2011 17:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rzs2oaZk7fDFpL6dc+gXrxvqna3a6OtLK8i8m/VIkZs=; b=FVoZ3wZpep3PpCv3LnXSm0iQird73F4rLLtU5oKfTB6c1IHNxAPWFWQ7cnTrHgamlk Ma4EYEzF8rztLNa0yuM2VVAcwDST494VRt8qXuBwuJEoehe3OAX2EmHNe5jxDPMJQEwV OsLPIh2NjJihNluTx4KiEDZKlk6E0GZ3aXj44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m4axZGyUQzgWHpHyj29le9GmiP/lNYRfVh2jptUfoAS7UGhRw3N4QGDe+FA7j0Kgvq /Q+qhhWC8x7d1YDvipY5Gtyw8c29ARTQxDjhMLfanJs23FGDm0kxdqFaz7XdAt4VPIYD qJw8Wn1JixzFP3ZRcWZWHbHGzqBwDnBMtOYTg= MIME-Version: 1.0 Received: by 10.223.151.9 with SMTP id a9mr756739faw.40.1299376186765; Sat, 05 Mar 2011 17:49:46 -0800 (PST) Received: by 10.223.96.203 with HTTP; Sat, 5 Mar 2011 17:49:46 -0800 (PST) In-Reply-To: <20110306014355.GA36763@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306010140.GA90699@lava.net> <20110306014355.GA36763@icarus.home.lan> Date: Sat, 5 Mar 2011 20:49:46 -0500 Message-ID: From: "illoai@gmail.com" To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 01:49:48 -0000 On 5 March 2011 20:43, Jeremy Chadwick wrote: > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: >> > This is a strange one, and the more I started debugging it (starting >> > with truss, comparing fast vs. slow results, where all that appears >> > different is read() operations are taking a lot longer -- I haven't ha= d >> > time to check with ktrace yet), the more strange it got: that's when I >> > found out the behaviour changes depending on if you're a user or root. >> > >> > Easy to reproduce: >> > >> > - grep -r string /usr/src, as non-root, is fast >> > - grep -r -i string /usr/src, as non-root, is 8x slower than without -= i >> >> =A0 From your results below, I think you mean *80* x slower! > > Oops; yes, typo on my part. =A0I was never any good at math either! =A0;-= ) > >> > - grep -r string /usr/src, as root, is fast >> > - grep -r -i string /usr/src, as root, is fast >> >> =A0 I can not reproduce this on 7.3-RELEASE-p4; I get consistent results >> between root and non-root, with -i being only marginally slower (about >> 15%) for each; results below. > > Your results look more or less like what I see on the 4th system (the > 7.0-STABLE one). =A0I believe the speed difference there (and on your > system) is justified, as I would imagine strcasecmp() a tiny bit slower > than strcmp(). =A0But an 80x slowdown is completely unacceptable, > especially given the conditions. > > My first thought was "compiler optimisation bug?", which I suppose could > still be the case, but I don't know how root vs. non-root would change > that behaviour, not to mention only when -i was specified. > > Using 'truss -d' it looks like the slowdown is happening on read(2), > which makes me very concerned, as it could indicate something odd going > on with CAM? =A0Sadly I cannot (for many reasons) get rid of ahci.ko on > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko > easily on the same system. > On my 8.2-RELEASE system using ahci (built into the custom kernel) I don't notice your observed slowdown, so unless ahci is radically different on -STABLE I doubt it's the cause. --=20 -- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 01:55:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8899106564A for ; Sun, 6 Mar 2011 01:55:21 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 777BE8FC14 for ; Sun, 6 Mar 2011 01:55:21 +0000 (UTC) Received: by fxm19 with SMTP id 19so3637994fxm.13 for ; Sat, 05 Mar 2011 17:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0ackfre7HsOV6bHD7rpHK76ihMYownxUtbyHnt08rJs=; b=fYBVudRbA7YYW+sSiR501SqW3k4Um0R9UFZdxb8/6Rf+vXuGipvT1M+j0awdyWWGFr Mi7R56NxZ1cSOF9yg2vBB5Lel3/5u9wO4dnpZ0SyCxEwo5SRizPWpnygS/kejcrwYQQJ Yiw1GI/XcBLWRqNHkZJ6h4g401KQqc5MEx3p4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l8dcJIAlBAp+MEc+sfCEu/4cPLGa9SxOsjrpw1wxUK4cYedl+8Q2rp70SNccqplrSg qCsf9yaB33XpJ2av2kRzjKUNjSaRCTcmHmu1ktkRu/jnhBEEWB9E50SYRVd9DwjvxEAn ctFUTMTq+WaPfuD9My3+RM8QVmG3K/1NHINMQ= MIME-Version: 1.0 Received: by 10.223.14.137 with SMTP id g9mr564462faa.2.1299376007574; Sat, 05 Mar 2011 17:46:47 -0800 (PST) Received: by 10.223.96.203 with HTTP; Sat, 5 Mar 2011 17:46:47 -0800 (PST) In-Reply-To: <20110306011433.GA21857@fbsd.t60.cpu> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> <20110306011433.GA21857@fbsd.t60.cpu> Date: Sat, 5 Mar 2011 20:46:47 -0500 Message-ID: From: "illoai@gmail.com" To: Yue Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ml-freebsd-stable Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 01:55:22 -0000 On 5 March 2011 20:14, Yue Wu wrote: > On Sat, Mar 05, 2011 at 08:02:47PM -0500, illoai@gmail.com wrote: >> On 5 March 2011 20:00, Yue Wu wrote: >> > Hello, sorry for poor English, I will try to explan clearer with my >> > best. >> > >> > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: >> >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: >> >> >> >> > I'm trying to use package instead of ports these day, but a few >> >> > questions have: >> >> > >> >> > 1. How to reserve packages that fetched via `pkg_add -r`? >> >> > >> >> > 2. How to know if there are updates for packages, and how to update= ? >> >> >> >> For (1), do you mean 'preserve', as in save a copy? =A0If so, then >> >> 'portmaster -b [...]' will save a backup copy of installed packages. >> > >> > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a >> > installed package, so it will preserve it by packing up the files from= a >> > installed package, why not preserve it just when fetching with `pkg_ad= d >> > -r`? I think it's the best way, I don't like the portmaster way to do = it >> > after. >> >> from man 1 pkg_add: >> >> =A0 =A0 =A0-K, --keep >> =A0 =A0 =A0 =A0 =A0 =A0 =A0Keep any downloaded package in PKGDIR if it i= s defined or in cur- >> =A0 =A0 =A0 =A0 =A0 =A0 =A0rent directory by default. >> > > Thanks, sorry for no attentively reading ;p > > Another question arises after checking the pkg 'pkg_add' saves, why the > pkg doesn't have a version appended to its name, it's hard to know the > version the pkg downloaded... Without digging in too deeply (I use ports, so I'm not the _most_ knowledgeable on packages) I believe it has to do with the fact that the packages are symlinked to non- versioned names on the distribution server(s), probably to simplify fetching. The packages themselves should have the version information in their metadata somewhere, which might be possible to rename via script. I apologise if that isn't helpful. --=20 -- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 02:05:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 213C9106566B for ; Sun, 6 Mar 2011 02:05:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id BD3A68FC13 for ; Sun, 6 Mar 2011 02:05:50 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta07.westchester.pa.mail.comcast.net with comcast id Fe1U1g0010EZKEL57e5qxg; Sun, 06 Mar 2011 02:05:50 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta01.westchester.pa.mail.comcast.net with comcast id Fe5o1g00U0PUQVN3Me5oE0; Sun, 06 Mar 2011 02:05:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D5B1B9B422; Sat, 5 Mar 2011 18:05:46 -0800 (PST) Date: Sat, 5 Mar 2011 18:05:46 -0800 From: Jeremy Chadwick To: "illoai@gmail.com" Message-ID: <20110306020546.GA37414@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306010140.GA90699@lava.net> <20110306014355.GA36763@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 02:05:51 -0000 On Sat, Mar 05, 2011 at 08:49:46PM -0500, illoai@gmail.com wrote: > On 5 March 2011 20:43, Jeremy Chadwick wrote: > > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: > >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > >> > This is a strange one, and the more I started debugging it (starting > >> > with truss, comparing fast vs. slow results, where all that appears > >> > different is read() operations are taking a lot longer -- I haven't had > >> > time to check with ktrace yet), the more strange it got: that's when I > >> > found out the behaviour changes depending on if you're a user or root. > >> > > >> > Easy to reproduce: > >> > > >> > - grep -r string /usr/src, as non-root, is fast > >> > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > >> > >>   From your results below, I think you mean *80* x slower! > > > > Oops; yes, typo on my part.  I was never any good at math either!  ;-) > > > >> > - grep -r string /usr/src, as root, is fast > >> > - grep -r -i string /usr/src, as root, is fast > >> > >>   I can not reproduce this on 7.3-RELEASE-p4; I get consistent results > >> between root and non-root, with -i being only marginally slower (about > >> 15%) for each; results below. > > > > Your results look more or less like what I see on the 4th system (the > > 7.0-STABLE one).  I believe the speed difference there (and on your > > system) is justified, as I would imagine strcasecmp() a tiny bit slower > > than strcmp().  But an 80x slowdown is completely unacceptable, > > especially given the conditions. > > > > My first thought was "compiler optimisation bug?", which I suppose could > > still be the case, but I don't know how root vs. non-root would change > > that behaviour, not to mention only when -i was specified. > > > > Using 'truss -d' it looks like the slowdown is happening on read(2), > > which makes me very concerned, as it could indicate something odd going > > on with CAM?  Sadly I cannot (for many reasons) get rid of ahci.ko on > > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko > > easily on the same system. > > > > On my 8.2-RELEASE system using ahci (built into the custom > kernel) I don't notice your observed slowdown, so unless ahci > is radically different on -STABLE I doubt it's the cause. There are two versions of AHCI available in FreeBSD: ahci.ko (which is AHCI<->CAM) and ataahci.ko (which is AHCI support under ata(4) natively and does not use CAM). Which of the two are you using? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 02:09:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC4791065670 for ; Sun, 6 Mar 2011 02:09:26 +0000 (UTC) (envelope-from vanopen@gmail.com) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8AB8FC12 for ; Sun, 6 Mar 2011 02:09:26 +0000 (UTC) Received: by gwaa18 with SMTP id a18so2979419gwa.17 for ; Sat, 05 Mar 2011 18:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:organization :x-operating-system:user-agent; bh=ngb7hSgW4IxU28RZp2h7XGiniRhDpidmIy7SL1GofyU=; b=jKvXuzwf3GMn9qaOITzJgyXglMaJWlEJAYSPEn9A4fu7Gw7682q0iRRZRNiv/a9V4Y d7UPpmjOZGplqnzRgw7TluU0NrYvTOdgd9VI6+Q2zBLHK1mG93ni0o3Ki66bgjIJRL09 szsPnMqQI7/1UpnoLxpGoIp5DCutYRrVSHhVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:organization:x-operating-system:user-agent; b=Yv8P2TN9Llq093iRQcw0C/JddZtczVrg5XATHrFy0rXAvHnAtMJ0Nr+kU2jrEN/M4F +8DrCm3sF9dz5AmT/uj00YYGQbqVBw7ssmOLkWMugoPKJH38iFU3jf7VTtZpoFzXmEdC aWo6tVLZ/vd7GYvn1nvWcSo1SCE8MebDB7iUk= Received: by 10.91.202.2 with SMTP id e2mr3067893agq.135.1299377365362; Sat, 05 Mar 2011 18:09:25 -0800 (PST) Received: from fbsd.t60.cpu ([221.6.39.130]) by mx.google.com with ESMTPS id d14sm1579150ana.0.2011.03.05.18.09.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2011 18:09:24 -0800 (PST) Date: Sun, 6 Mar 2011 10:09:17 +0800 From: Yue Wu To: ml-freebsd-stable Message-ID: <20110306020917.GA90894@fbsd.t60.cpu> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> <20110306011433.GA21857@fbsd.t60.cpu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: China Pharmaceutical University, Nanjing, China X-Operating-System: FreeBSD 8.2-PRERELEASE i386 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 02:09:26 -0000 On Sat, Mar 05, 2011 at 08:46:47PM -0500, illoai@gmail.com wrote: > On 5 March 2011 20:14, Yue Wu wrote: > > On Sat, Mar 05, 2011 at 08:02:47PM -0500, illoai@gmail.com wrote: > >> On 5 March 2011 20:00, Yue Wu wrote: > >> > Hello, sorry for poor English, I will try to explan clearer with my > >> > best. > >> > > >> > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > >> >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > >> >> > >> >> > I'm trying to use package instead of ports these day, but a few > >> >> > questions have: > >> >> > > >> >> > 1. How to reserve packages that fetched via `pkg_add -r`? > >> >> > > >> >> > 2. How to know if there are updates for packages, and how to update? > >> >> > >> >> For (1), do you mean 'preserve', as in save a copy?  If so, then > >> >> 'portmaster -b [...]' will save a backup copy of installed packages. > >> > > >> > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > >> > installed package, so it will preserve it by packing up the files from a > >> > installed package, why not preserve it just when fetching with `pkg_add > >> > -r`? I think it's the best way, I don't like the portmaster way to do it > >> > after. > >> > >> from man 1 pkg_add: > >> > >>      -K, --keep > >>              Keep any downloaded package in PKGDIR if it is defined or in cur- > >>              rent directory by default. > >> > > > > Thanks, sorry for no attentively reading ;p > > > > Another question arises after checking the pkg 'pkg_add' saves, why the > > pkg doesn't have a version appended to its name, it's hard to know the > > version the pkg downloaded... > > Without digging in too deeply (I use ports, so I'm not the > _most_ knowledgeable on packages) I believe it has to > do with the fact that the packages are symlinked to non- > versioned names on the distribution server(s), probably > to simplify fetching. The packages themselves should > have the version information in their metadata somewhere, > which might be possible to rename via script. > > I apologise if that isn't helpful. Thank you for info, I got the reason :) ports with portmaster makes pkg installation mangement be much more flexiable and more friendly than package by pkg_add -r on FreeBSD, except that ports take much more time and resource. After trying with packages, I think I have to stick to ports. -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 02:11:34 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D82106566C for ; Sun, 6 Mar 2011 02:11:34 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC9278FC13 for ; Sun, 6 Mar 2011 02:11:33 +0000 (UTC) Received: by fxm19 with SMTP id 19so3642840fxm.13 for ; Sat, 05 Mar 2011 18:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oHHR88nfPchC9YXQzG5bLLfcuIbsXDn4sxIKpsXD1RA=; b=vRceteSRoyDUa5+BC05AQ9G0Sm2ku1mDIgnTOGXRiBriGL45tpb2ACggeykbMy6mce x05kKiRnb5tkLZr532UyVS6A5f4rAgBjLGNN4FJ0qwwhlMoavVKmi5Ql2ImIrJkryoAa kSLMmyM1xor7Vi5bq1eQwUcXmzHBKHBZKsKfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DcHRETuOdQdGaEELMFKQlVt+6s7CYY3/Wt41rpEOT1ge1NjWPNezeXSDXozKz65rO3 bkmGXtPn7TjmPkea6JfaXLB8MbFvP80l+VCfN/NmrOjuL1Pwv0NjCCVqX9+3eMfczlEO PJuAM6EX/EPd+gKstovp/Y2ZbDjRJQ81Rg25Q= MIME-Version: 1.0 Received: by 10.223.143.86 with SMTP id t22mr2899893fau.78.1299377492803; Sat, 05 Mar 2011 18:11:32 -0800 (PST) Received: by 10.223.96.203 with HTTP; Sat, 5 Mar 2011 18:11:32 -0800 (PST) In-Reply-To: <20110306020546.GA37414@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306010140.GA90699@lava.net> <20110306014355.GA36763@icarus.home.lan> <20110306020546.GA37414@icarus.home.lan> Date: Sat, 5 Mar 2011 21:11:32 -0500 Message-ID: From: "illoai@gmail.com" To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 02:11:34 -0000 On 5 March 2011 21:05, Jeremy Chadwick wrote: > On Sat, Mar 05, 2011 at 08:49:46PM -0500, illoai@gmail.com wrote: >> On 5 March 2011 20:43, Jeremy Chadwick wrote: >> > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: >> >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: >> >> > This is a strange one, and the more I started debugging it (startin= g >> >> > with truss, comparing fast vs. slow results, where all that appears >> >> > different is read() operations are taking a lot longer -- I haven't= had >> >> > time to check with ktrace yet), the more strange it got: that's whe= n I >> >> > found out the behaviour changes depending on if you're a user or ro= ot. >> >> > >> >> > Easy to reproduce: >> >> > >> >> > - grep -r string /usr/src, as non-root, is fast >> >> > - grep -r -i string /usr/src, as non-root, is 8x slower than withou= t -i >> >> >> >> =A0 From your results below, I think you mean *80* x slower! >> > >> > Oops; yes, typo on my part. =A0I was never any good at math either! = =A0;-) >> > >> >> > - grep -r string /usr/src, as root, is fast >> >> > - grep -r -i string /usr/src, as root, is fast >> >> >> >> =A0 I can not reproduce this on 7.3-RELEASE-p4; I get consistent resu= lts >> >> between root and non-root, with -i being only marginally slower (abou= t >> >> 15%) for each; results below. >> > >> > Your results look more or less like what I see on the 4th system (the >> > 7.0-STABLE one). =A0I believe the speed difference there (and on your >> > system) is justified, as I would imagine strcasecmp() a tiny bit slowe= r >> > than strcmp(). =A0But an 80x slowdown is completely unacceptable, >> > especially given the conditions. >> > >> > My first thought was "compiler optimisation bug?", which I suppose cou= ld >> > still be the case, but I don't know how root vs. non-root would change >> > that behaviour, not to mention only when -i was specified. >> > >> > Using 'truss -d' it looks like the slowdown is happening on read(2), >> > which makes me very concerned, as it could indicate something odd goin= g >> > on with CAM? =A0Sadly I cannot (for many reasons) get rid of ahci.ko o= n >> > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko >> > easily on the same system. >> > >> >> On my 8.2-RELEASE system using ahci (built into the custom >> kernel) I don't notice your observed slowdown, so unless ahci >> is radically different on -STABLE I doubt it's the cause. > > There are two versions of AHCI available in FreeBSD: ahci.ko (which is > AHCI<->CAM) and ataahci.ko (which is AHCI support under ata(4) natively > and does not use CAM). =A0Which of the two are you using? I have device ahci in my kernel, ataahci, not. > sysctl -a | grep ahci dev.ahci.0.%desc: ATI IXP600 AHCI SATA controller dev.ahci.0.%driver: ahci dev.ahci.0.%location: slot=3D18 function=3D0 handle=3D\_SB_.PCI0.SATA dev.ahci.0.%pnpinfo: vendor=3D0x1002 device=3D0x4380 subvendor=3D0x1179 subdevice=3D0xff68 class=3D0x01018f dev.ahci.0.%parent: pci0 dev.ahcich.0.%desc: AHCI channel dev.ahcich.0.%driver: ahcich dev.ahcich.0.%location: channel=3D0 dev.ahcich.0.%parent: ahci0 dev.ahcich.1.%desc: AHCI channel dev.ahcich.1.%driver: ahcich dev.ahcich.1.%location: channel=3D1 dev.ahcich.1.%parent: ahci0 dev.ahcich.2.%desc: AHCI channel dev.ahcich.2.%driver: ahcich dev.ahcich.2.%location: channel=3D2 dev.ahcich.2.%parent: ahci0 dev.ahcich.3.%desc: AHCI channel dev.ahcich.3.%driver: ahcich dev.ahcich.3.%location: channel=3D3 dev.ahcich.3.%parent: ahci0 HTH --=20 -- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 02:46:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57869106564A for ; Sun, 6 Mar 2011 02:46:07 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 296258FC0A for ; Sun, 6 Mar 2011 02:46:07 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pw3yu-000FSF-Dm; Sat, 05 Mar 2011 21:46:04 -0500 Date: Sat, 5 Mar 2011 21:46:04 -0500 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20110306024604.GA7746@in-addr.com> References: <20110305234514.GA34594@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110305234514.GA34594@icarus.home.lan> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 02:46:07 -0000 On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > This is a strange one, and the more I started debugging it (starting > with truss, comparing fast vs. slow results, where all that appears > different is read() operations are taking a lot longer -- I haven't had > time to check with ktrace yet), the more strange it got: that's when I > found out the behaviour changes depending on if you're a user or root. > > Easy to reproduce: > > - grep -r string /usr/src, as non-root, is fast > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > - grep -r string /usr/src, as root, is fast > - grep -r -i string /usr/src, as root, is fast This is a stab in the dark, but are there any differences in your shell environment variables between root and non-root? Specifically LANG or LC_ style variables. I ran into issues in the past with grep being horrendously slow and traced it to LANG or LC_* in the environment causing a much longer code path than without the settings. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 03:07:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D25071065673 for ; Sun, 6 Mar 2011 03:07:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id B83778FC1E for ; Sun, 6 Mar 2011 03:07:28 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta05.emeryville.ca.mail.comcast.net with comcast id Ff591g0031afHeLA5f7UdY; Sun, 06 Mar 2011 03:07:28 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta17.emeryville.ca.mail.comcast.net with comcast id Ff7M1g0070PUQVN8df7Noq; Sun, 06 Mar 2011 03:07:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B9FAE9B422; Sat, 5 Mar 2011 19:07:20 -0800 (PST) Date: Sat, 5 Mar 2011 19:07:20 -0800 From: Jeremy Chadwick To: Gary Palmer Message-ID: <20110306030720.GA99973@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306024604.GA7746@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306024604.GA7746@in-addr.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 03:07:29 -0000 On Sat, Mar 05, 2011 at 09:46:04PM -0500, Gary Palmer wrote: > On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: > > This is a strange one, and the more I started debugging it (starting > > with truss, comparing fast vs. slow results, where all that appears > > different is read() operations are taking a lot longer -- I haven't had > > time to check with ktrace yet), the more strange it got: that's when I > > found out the behaviour changes depending on if you're a user or root. > > > > Easy to reproduce: > > > > - grep -r string /usr/src, as non-root, is fast > > - grep -r -i string /usr/src, as non-root, is 8x slower than without -i > > - grep -r string /usr/src, as root, is fast > > - grep -r -i string /usr/src, as root, is fast > > This is a stab in the dark, but are there any differences in your > shell environment variables between root and non-root? Specifically > LANG or LC_ style variables. I ran into issues in the past with grep > being horrendously slow and traced it to LANG or LC_* in the environment > causing a much longer code path than without the settings. Bingo -- you found it, Gary. Thank you very much. I hadn't thought of LANG/LC_* variables but I did think of dotfile or shell differences, but didn't test them thoroughly. My dotfiles do make use of LANG/LC_CTYPE/LC_COLLATE: export LANG="en_GB.UTF-8" export LC_CTYPE="en_GB.UTF-8" export LC_COLLATE="C" Testing on System #1: $ unset LANG LC_CTYPE LC_COLLATE $ for i in {0..9}; do /usr/bin/time -h grep -r PAE /usr/src/sys/dev > /dev/null ; done 0.18s real 0.11s user 0.06s sys 0.15s real 0.09s user 0.05s sys 0.12s real 0.06s user 0.05s sys 0.12s real 0.06s user 0.05s sys 0.12s real 0.07s user 0.04s sys 0.12s real 0.08s user 0.03s sys 0.12s real 0.08s user 0.03s sys 0.12s real 0.07s user 0.04s sys 0.12s real 0.08s user 0.03s sys 0.12s real 0.07s user 0.04s sys $ for i in {0..9}; do /usr/bin/time -h grep -r -i PAE /usr/src/sys/dev > /dev/null ; done 0.13s real 0.11s user 0.02s sys 0.13s real 0.10s user 0.03s sys 0.13s real 0.08s user 0.05s sys 0.13s real 0.09s user 0.04s sys 0.13s real 0.08s user 0.05s sys 0.13s real 0.11s user 0.02s sys 0.13s real 0.10s user 0.03s sys 0.13s real 0.11s user 0.02s sys 0.13s real 0.09s user 0.03s sys 0.13s real 0.08s user 0.05s sys I wanted to track it down to a specific variable or combo: $ unset LANG - Result: still 80x slower with -i $ unset LANG LC_COLLATE - Result: still 80x slower with -i $ unset LANG LC_CTYPE - Result: normal/fast. $ unset LC_CTYPE - Result: still 80x slower with -i $ unset LC_CTYPE LC_COLLATE - Result: still 80x slower with -i $ unset LC_COLLATE - Result: still 80x slower with -i So the LANG + LC_CTYPE combo when used together are what cause this. I'm not sure what's going on with locale, but given the nasty side-effects it should probably be documented somewhere; maybe in setlocale(3)? Unsure. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 07:04:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 264B3106566B for ; Sun, 6 Mar 2011 07:04:53 +0000 (UTC) (envelope-from cliftonr@oz.volcano.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id C2F848FC12 for ; Sun, 6 Mar 2011 07:04:52 +0000 (UTC) X-Authority-Analysis: v=1.1 cv=dquaJDitHqzHCdqWSoZ6IgapSuTzW/4TaRYx9N9k4W8= c=1 sm=0 a=tNKROUZvqFQA:10 a=kj9zAlcOel0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:17 a=jb__rZ8GAAAA:8 a=H9iEQFZ8AAAA:8 a=fRjtwXCkqojsUOXsa5kA:9 a=iO7SVLa9z9SnrmdaOg1i3Hqc3qAA:4 a=CjuIK1q_8ugA:10 a=sHp_62vNEjwA:10 a=fZFZujrNNEQA:10 a=G5OLwwqwWgs+1dCEPNHTSw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.80.196.236 Received: from [75.80.196.236] ([75.80.196.236:30225] helo=oz.volcano.org) by hrndva-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 67/5F-14011-312337D4; Sun, 06 Mar 2011 07:04:51 +0000 Received: by oz.volcano.org (Postfix, from userid 1001) id 7291E50824; Sat, 5 Mar 2011 21:04:50 -1000 (HST) Date: Sat, 5 Mar 2011 21:04:50 -1000 From: Clifton Royston To: Jeremy Chadwick Message-ID: <20110306070450.GA92752@lava.net> Mail-Followup-To: Jeremy Chadwick , Gary Palmer , freebsd-stable@freebsd.org References: <20110305234514.GA34594@icarus.home.lan> <20110306024604.GA7746@in-addr.com> <20110306030720.GA99973@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306030720.GA99973@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 07:04:53 -0000 On Sat, Mar 05, 2011 at 07:07:20PM -0800, Jeremy Chadwick wrote: ... > $ unset LANG > - Result: still 80x slower with -i > $ unset LANG LC_COLLATE > - Result: still 80x slower with -i > $ unset LANG LC_CTYPE > - Result: normal/fast. > $ unset LC_CTYPE > - Result: still 80x slower with -i > $ unset LC_CTYPE LC_COLLATE > - Result: still 80x slower with -i > $ unset LC_COLLATE > - Result: still 80x slower with -i > > So the LANG + LC_CTYPE combo when used together are what cause this. Doesn't the above say that having either one set does it? I would guess it's probably that either one requires the 8.x grep -i to make a conversion function call for each char (or perhaps line) of input to ensure the proper upper/lower case conversion rules are followed. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 07:56:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C681065672 for ; Sun, 6 Mar 2011 07:56:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id A74EA8FC15 for ; Sun, 6 Mar 2011 07:56:33 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Fjty1g0021u4NiLA8jwZa6; Sun, 06 Mar 2011 07:56:33 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta21.emeryville.ca.mail.comcast.net with comcast id FjwX1g00i0PUQVN8hjwYqv; Sun, 06 Mar 2011 07:56:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 71D4E9B422; Sat, 5 Mar 2011 23:56:31 -0800 (PST) Date: Sat, 5 Mar 2011 23:56:31 -0800 From: Jeremy Chadwick To: Gary Palmer , freebsd-stable@freebsd.org Message-ID: <20110306075631.GA75125@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306024604.GA7746@in-addr.com> <20110306030720.GA99973@icarus.home.lan> <20110306070450.GA92752@lava.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306070450.GA92752@lava.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Strange performance issue with grep -r -i as non-root user 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: Sun, 06 Mar 2011 07:56:33 -0000 On Sat, Mar 05, 2011 at 09:04:50PM -1000, Clifton Royston wrote: > On Sat, Mar 05, 2011 at 07:07:20PM -0800, Jeremy Chadwick wrote: > ... > > $ unset LANG > > - Result: still 80x slower with -i > > $ unset LANG LC_COLLATE > > - Result: still 80x slower with -i > > $ unset LANG LC_CTYPE > > - Result: normal/fast. > > $ unset LC_CTYPE > > - Result: still 80x slower with -i > > $ unset LC_CTYPE LC_COLLATE > > - Result: still 80x slower with -i > > $ unset LC_COLLATE > > - Result: still 80x slower with -i > > > > So the LANG + LC_CTYPE combo when used together are what cause this. > > Doesn't the above say that having either one set does it? You're correct -- I phrased this incorrectly, my apologies. > I would guess it's probably that either one requires the 8.x > grep -i to make a conversion function call for each char (or perhaps > line) of input to ensure the proper upper/lower case conversion rules > are followed. A colleague of mine (who I wish I would have asked first) knew of this quirk with grep (apparently some other utilities behave oddly as well with LANG/LC_CTYPE; he mentioned less as another example), stating that a locale can induce very long delays like this solely due to the amount of processing needed to scan through lists of certain characters which are not always linear in order (thus multiple scans are needed). With ASCII this appears to be significantly easier given that uppercase range from 0x41-0x5a and lowercase from 0x61-0x7a. There's significantly less "stuff" to do in this situation. His statement, despite vague/no technical reference details, does make sense to me. I should also state (I forget if I did already) that the delays seen weren't actually "in" read(2) -- truss -d shows the amount of time that passes between syscalls. The delays I was seeing were *between* read(2) calls, which acts as a further indicator that some code internal to grep (or libc) was spinning/churning much more heavily when a locale was used. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 08:30:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF04A1065670 for ; Sun, 6 Mar 2011 08:30:42 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id CC15E8FC0C for ; Sun, 6 Mar 2011 08:30:42 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p268Ufku008619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Mar 2011 00:30:41 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p268UfD6008618; Sun, 6 Mar 2011 00:30:41 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA12390; Sun, 6 Mar 11 00:27:08 PST Date: Sun, 06 Mar 2011 00:27:19 -0800 From: perryh@pluto.rain.com To: illoai@gmail.com Message-Id: <4d734567.15evysQIxrkK6d6O%perryh@pluto.rain.com> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, vanopen@gmail.com Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 08:30:43 -0000 "illoai@gmail.com" wrote: > On 5 March 2011 20:00, Yue Wu wrote: > > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > >> > 1. How to reserve packages that fetched via `pkg_add -r`? > >> > ... > >> For (1), do you mean 'preserve', as in save a copy? ?If so, then > >> 'portmaster -b [...]' will save a backup copy of installed packages. > > > > Yes, I mean 'preserve'... > > from man 1 pkg_add: > > -K, --keep > Keep any downloaded package in PKGDIR if it is defined or in cur- > rent directory by default. Last time I tried it, pkg_add -r -K did indeed save local copies of the packages fetched from the remote repository, but a problem arose when one later wanted to _use_ that local stash while falling back to -r behavior for anything not found locally. Last I knew there was no easy way to tell pkg_add to do that. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 12:37:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B9A2106566C; Sun, 6 Mar 2011 12:37:46 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3075A8FC0A; Sun, 6 Mar 2011 12:37:45 +0000 (UTC) Received: by qyk35 with SMTP id 35so1238093qyk.13 for ; Sun, 06 Mar 2011 04:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LTW/9l3U2+l5UhJb30dKudVnAARIpMsalOohzZa8rUQ=; b=t7Ks9iQaNFAAYPe0S+lU4iLbnpg08wH3nC8FwWx6NsUxSrtnvRweh+trMZ0Fl62zvk amiBW7vHPcvpQA/c37/0iWjPFg0cKbX2tlE4+lYGWnsQZPY9s5UNxm+cZbIGfCpK/Yso C4A/xohPvjQGrR7Q2l8EHPhPwvPOM48TCYZyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eGuQKCzxqZVIIhw0XlzYv+gEW8vxMG2yeXrVm8Ak9tYWnOCMvjkgfmOdPKoNfarFyV HkAL8kcQEjmM4FbK6tOaMwUE0pKaHZ++5k1YEN+Cx6CUTTwN3PPnAxFHimMRIK8Tsy7y sJhB8k6qYRn9FVs5ciaDnDt0luGM25rIpLxZ0= MIME-Version: 1.0 Received: by 10.229.141.71 with SMTP id l7mr2100512qcu.44.1299415065135; Sun, 06 Mar 2011 04:37:45 -0800 (PST) Received: by 10.229.97.209 with HTTP; Sun, 6 Mar 2011 04:37:45 -0800 (PST) In-Reply-To: <494278763.20110305130320@serebryakov.spb.ru> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Sun, 6 Mar 2011 14:37:45 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Brandon Gooch , freebsd-net@freebsd.org, Jan Koum , Steven Hartland , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Sun, 06 Mar 2011 12:37:46 -0000 Hello, I've been testing the em.7.2.2 driver as kld. The system is up about 2 days 6 hours. System has 4 em interfaces, Throughput is about 200Mbit/s. System didn't hang, but em2 has Input Errors. I saw that, dev.em.2.mac_stats.missed_packets is not zero? What could be the problem? # uname -r 8.2-RELEASE # sysctl dev.em.| grep miss dev.em.0.mac_stats.missed_packets: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.2.mac_stats.missed_packets: 5886 dev.em.3.mac_stats.missed_packets: 0 # netstat -nWI em2 | grep Link Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll em2 1500 00:23:8b:89:e4:9e 267256324 5886 0 273081628 0 0 # sysctl dev.em.2. dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 dev.em.2.%driver: em dev.em.2.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P4.BR1E dev.em.2.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x108e subdevice=0x125e class=0x020000 dev.em.2.%parent: pci12 dev.em.2.nvm: -1 dev.em.2.debug: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 dev.em.2.flow_control: 3 dev.em.2.eee_control: 0 dev.em.2.link_irq: 0 dev.em.2.mbuf_alloc_fail: 0 dev.em.2.cluster_alloc_fail: 0 dev.em.2.dropped: 0 dev.em.2.tx_dma_fail: 0 dev.em.2.rx_overruns: 7 dev.em.2.watchdog_timeouts: 0 dev.em.2.device_control: 1075577409 dev.em.2.rx_control: 67141634 dev.em.2.fc_high_water: 30720 dev.em.2.fc_low_water: 29220 dev.em.2.queue0.txd_head: 3025 dev.em.2.queue0.txd_tail: 3025 dev.em.2.queue0.tx_irq: 0 dev.em.2.queue0.no_desc_avail: 0 dev.em.2.queue0.rxd_head: 1826 dev.em.2.queue0.rxd_tail: 1825 dev.em.2.queue0.rx_irq: 0 dev.em.2.mac_stats.excess_coll: 0 dev.em.2.mac_stats.single_coll: 0 dev.em.2.mac_stats.multiple_coll: 0 dev.em.2.mac_stats.late_coll: 0 dev.em.2.mac_stats.collision_count: 0 dev.em.2.mac_stats.symbol_errors: 0 dev.em.2.mac_stats.sequence_errors: 0 dev.em.2.mac_stats.defer_count: 0 dev.em.2.mac_stats.missed_packets: 5886 dev.em.2.mac_stats.recv_no_buff: 3407 dev.em.2.mac_stats.recv_undersize: 0 dev.em.2.mac_stats.recv_fragmented: 0 dev.em.2.mac_stats.recv_oversize: 0 dev.em.2.mac_stats.recv_jabber: 0 dev.em.2.mac_stats.recv_errs: 0 dev.em.2.mac_stats.crc_errs: 0 dev.em.2.mac_stats.alignment_errs: 0 dev.em.2.mac_stats.coll_ext_errs: 0 dev.em.2.mac_stats.xon_recvd: 0 dev.em.2.mac_stats.xon_txd: 0 dev.em.2.mac_stats.xoff_recvd: 0 dev.em.2.mac_stats.xoff_txd: 0 dev.em.2.mac_stats.total_pkts_recvd: 265358324 dev.em.2.mac_stats.good_pkts_recvd: 265352438 dev.em.2.mac_stats.bcast_pkts_recvd: 701728 dev.em.2.mac_stats.mcast_pkts_recvd: 4076 dev.em.2.mac_stats.rx_frames_64: 0 dev.em.2.mac_stats.rx_frames_65_127: 140801982 dev.em.2.mac_stats.rx_frames_128_255: 3553397 dev.em.2.mac_stats.rx_frames_256_511: 3418754 dev.em.2.mac_stats.rx_frames_512_1023: 8096866 dev.em.2.mac_stats.rx_frames_1024_1522: 109481439 dev.em.2.mac_stats.good_octets_recvd: 177455051448 dev.em.2.mac_stats.good_octets_txd: 274861571704 dev.em.2.mac_stats.total_pkts_txd: 270439410 dev.em.2.mac_stats.good_pkts_txd: 270439410 dev.em.2.mac_stats.bcast_pkts_txd: 194927 dev.em.2.mac_stats.mcast_pkts_txd: 48 dev.em.2.mac_stats.tx_frames_64: 23050855 dev.em.2.mac_stats.tx_frames_65_127: 54156414 dev.em.2.mac_stats.tx_frames_128_255: 4299280 dev.em.2.mac_stats.tx_frames_256_511: 7837146 dev.em.2.mac_stats.tx_frames_512_1023: 8272014 dev.em.2.mac_stats.tx_frames_1024_1522: 172823701 dev.em.2.mac_stats.tso_txd: 0 dev.em.2.mac_stats.tso_ctx_fail: 0 dev.em.2.interrupts.asserts: 283674059 dev.em.2.interrupts.rx_pkt_timer: 33585 dev.em.2.interrupts.rx_abs_timer: 0 dev.em.2.interrupts.tx_pkt_timer: 11022 dev.em.2.interrupts.tx_abs_timer: 22449 dev.em.2.interrupts.tx_queue_empty: 0 dev.em.2.interrupts.tx_queue_min_thresh: 0 dev.em.2.interrupts.rx_desc_min_thresh: 0 dev.em.2.interrupts.rx_overrun: 0 Regards, Ozkan KIRIK From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 14:05:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E700D1065670 for ; Sun, 6 Mar 2011 14:05:08 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5EF8FC0A for ; Sun, 6 Mar 2011 14:05:08 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p26E6SUP090990; Sun, 6 Mar 2011 15:06:28 +0100 (CET) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p26E6SeB090989; Sun, 6 Mar 2011 15:06:28 +0100 (CET) (envelope-from byshenknet) Date: Sun, 6 Mar 2011 15:06:28 +0100 From: Greg Byshenk To: Yue Wu Message-ID: <20110306140628.GS30336@core.byshenk.net> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> <20110306011433.GA21857@fbsd.t60.cpu> <20110306020917.GA90894@fbsd.t60.cpu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306020917.GA90894@fbsd.t60.cpu> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: ml-freebsd-stable Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 14:05:09 -0000 On Sun, Mar 06, 2011 at 10:09:17AM +0800, Yue Wu wrote: > On Sat, Mar 05, 2011 at 08:46:47PM -0500, illoai@gmail.com wrote: > > On 5 March 2011 20:14, Yue Wu wrote: > > > On Sat, Mar 05, 2011 at 08:02:47PM -0500, illoai@gmail.com wrote: > > >> On 5 March 2011 20:00, Yue Wu wrote: > > >> > Hello, sorry for poor English, I will try to explan clearer with my > > >> > best. > > >> > > > >> > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: > > >> >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: > > >> >> > > >> >> > I'm trying to use package instead of ports these day, but a few > > >> >> > questions have: > > >> >> > > > >> >> > 1. How to reserve packages that fetched via `pkg_add -r`? > > >> >> > > > >> >> > 2. How to know if there are updates for packages, and how to update? > > >> >> > > >> >> For (1), do you mean 'preserve', as in save a copy? ?If so, then > > >> >> 'portmaster -b [...]' will save a backup copy of installed packages. > > >> > > > >> > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > > >> > installed package, so it will preserve it by packing up the files from a > > >> > installed package, why not preserve it just when fetching with `pkg_add > > >> > -r`? I think it's the best way, I don't like the portmaster way to do it > > >> > after. > > >> > > >> from man 1 pkg_add: > > >> > > >> ? ? ?-K, --keep > > >> ? ? ? ? ? ? ?Keep any downloaded package in PKGDIR if it is defined or in cur- > > >> ? ? ? ? ? ? ?rent directory by default. > > >> > > > > > > Thanks, sorry for no attentively reading ;p > > > > > > Another question arises after checking the pkg 'pkg_add' saves, why the > > > pkg doesn't have a version appended to its name, it's hard to know the > > > version the pkg downloaded... > > > > Without digging in too deeply (I use ports, so I'm not the > > _most_ knowledgeable on packages) I believe it has to > > do with the fact that the packages are symlinked to non- > > versioned names on the distribution server(s), probably > > to simplify fetching. The packages themselves should > > have the version information in their metadata somewhere, > > which might be possible to rename via script. > > > > I apologise if that isn't helpful. > > Thank you for info, I got the reason :) > > ports with portmaster makes pkg installation mangement be much more > flexiable and more friendly than package by pkg_add -r on FreeBSD, > except that ports take much more time and resource. After trying with > packages, I think I have to stick to ports. As suggested by some of the other comments, you can choose to use portmaster with packages, if you prefer not to do local builds. In my own case, I use ports and packages, via portmaster. That is, I use one machine to build locally-configured packages (in some cases with non-standard options), and then install them on the rest of the machines as packages. It works very well in my environment. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 14:55:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63AAF106566B; Sun, 6 Mar 2011 14:55:16 +0000 (UTC) (envelope-from ctfreebsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7268FC0A; Sun, 6 Mar 2011 14:55:15 +0000 (UTC) Received: by gyh4 with SMTP id 4so1559405gyh.13 for ; Sun, 06 Mar 2011 06:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=gZvJ1FFEtWs2Uaj9Ub2TISF1SdZJZcvujNDq/8G4o9k=; b=HeGOfU+os9ohHP86mcmB6FMBSJNnu4ox7i1at5zyNxnnbI1BgKrWGBedP+L7+SBteu UpHjRe8+45duefGqboNR4+3f0oJC6GujIuhLcxe668bY1pL1MQa7JBiqi+BB4pjgK0Fu msEqx4vD05lA33C/CXVSpM9GKULqCPmmc22iQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JObVC8iOUX5P7U4ugGjcb61Ia7xiD1mj0nwYISM7HgCUNeaEBMd1ToXlR6hFlFlvAI G/DF7N++zIfVpBTOjQf3cRO5AbPOYr15tZebk7KFla4gUXfNUFprZLNltmMTruBLLM2k Ntn/wq8ER9vfUFST9WMYHJ7rRpWzCFwxYVQGc= MIME-Version: 1.0 Received: by 10.151.122.3 with SMTP id z3mr3310894ybm.89.1299421432647; Sun, 06 Mar 2011 06:23:52 -0800 (PST) Received: by 10.147.171.19 with HTTP; Sun, 6 Mar 2011 06:23:52 -0800 (PST) Date: Sun, 6 Mar 2011 16:23:52 +0200 Message-ID: From: Dave Johnson To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Kernel Update / IPFW not working 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: Sun, 06 Mar 2011 14:55:16 -0000 Hi all An IPFW problem when going from release to stable on 8.2 An help gladly accepted LOG ON Flushed all rules. 00010 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 00030 divert 8668 ip from any to any via bge0 ipfw: getsockopt(IP_FW_ADD): Invalid argument 50000 allow ip from any to any Firewall rules loaded. Starting natd. rc.conf defaultrouter="192.168.0.1" gateway_enable="YES" hostname="xxx.xxx.xxx" ifconfig_bge0="inet 192.168.0.11 netmask 255.255.255.0" ifconfig_em0="inet 192.168.1.2 netmask 255.255.255.0" keymap="us.iso" moused_enable="YES" sshd_enable="YES" firewall_enable="YES" firewall_script="/etc/rc.firewall" natd_program="/sbin/natd" natd_enable="YES" natd_interface="bge0" natd_flags="-f /etc/natd.conf" dhcpd_enable="NO" dhcpd_flags="-q" dhcpd_conf="/usr/local/etc/dhcpd.conf" dhcpd_ifaces="em0" dhcpd_withumask="022" natd.conf interface bge0 use_sockets yes same_ports yes log #redirect_port tcp 192.168.1.189:3389 3389 #redirect_port tcp 192.168.1.53:5500 5500 #!/bin/sh /sbin/ipfw -f flush /sbin/ipfw -f pipe flush #Nat Rules /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 /sbin/ipfw add 30 divert natd all from any to any via bge0 #Forward to Transparent Proxy Server #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 /sbin/ipfw add 50000 allow ip from any to any KERNEL options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET Regards From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 15:29:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 457FD10656B0 for ; Sun, 6 Mar 2011 15:29:11 +0000 (UTC) (envelope-from michael.scheidell@secnap.com) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [204.89.241.253]) by mx1.freebsd.org (Postfix) with ESMTP id BE0448FC1C for ; Sun, 6 Mar 2011 15:29:10 +0000 (UTC) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [10.70.1.253]) by mx1.secnap.com.ionspam.net (Postfix) with ESMTP id AFC732B7C8C; Sun, 6 Mar 2011 10:12:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secnap.com; h= mime-version:content-transfer-encoding:content-id:content-type :content-type:content-language:accept-language:in-reply-to :references:message-id:date:date:subject:subject:from:from; s= dkim; t=1299424368; x=1301238768; bh=vz1Ttd+qSnDlu47Eg5ZYs4/j7Lz twJE/98A3Y5+JYTI=; b=bztoAoQbvCNpl18CzashKy1YYmdrQxsbJDNbbiKAQIV pTy/Kc8MNPk/A/AObipSxWQ3Ts5x/iK6LzGM1CZK8WD59Xd0HlnbfHEN79e6xG2Q QRugMeMINvhEn7bLVhZE/RfCpS0O9EtMZwXrR4jWJoFquxRGf4BHMZYJJZdJG9Dg = X-Amavis-Modified: Mail body modified (using disclaimer) - mx1.secnap.com.ionspam.net X-Virus-Scanned: SpammerTrap(r) VPS-1500 2.14 at mx1.secnap.com.ionspam.net Received: from USBCTDC001.secnap.com (usbctdc001.secnap.com [10.70.1.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.secnap.com.ionspam.net (Postfix) with ESMTPS id C97822B7C6D; Sun, 6 Mar 2011 10:12:48 -0500 (EST) Received: from USBCTDC001.secnap.com ([10.70.1.1]) by USBCTDC001 ([10.70.1.1]) with mapi; Sun, 6 Mar 2011 10:12:48 -0500 From: Michael Scheidell To: Dave Johnson , "freebsd-ipfw@freebsd.org" , "freebsd-stable@freebsd.org" Thread-Topic: Kernel Update / IPFW not working Thread-Index: AcvcEPQgWRyJqaJTeUWP2HLfQh1VTA== Date: Sun, 6 Mar 2011 15:13:02 +0000 Message-ID: <0466161e-77f8-48a5-a540-67d7683a23ef@blur> References: <473bf4dd-bac3-4678-8eac-0f8d438775b6@blur> In-Reply-To: <473bf4dd-bac3-4678-8eac-0f8d438775b6@blur> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: Re: Kernel Update / IPFW not working 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: Sun, 06 Mar 2011 15:29:11 -0000 TWlnaHQgYmUgYW4gaXB2NiBpc3N1ZS4gIFRyeSBkaXZlcnQgaXB2NCBub3QgaXAuDQoNCi0tDQpN aWNoYWVsIFNjaGVpZGVsbA0KQ1RPIFNFQ05BUCBOZXR3b3JrIFNlY3VyaXR5DQo1NjEtOTQ4LTIy NTk8dGVsOjU2MTk0ODIyNTk+DQoNCg0KLS0tLS1PcmlnaW5hbCBtZXNzYWdlLS0tLS0NCkZyb206 IERhdmUgSm9obnNvbiA8Y3RmcmVlYnNkQGdtYWlsLmNvbT4NClRvOiAiZnJlZWJzZC1pcGZ3QGZy ZWVic2Qub3JnIiA8ZnJlZWJzZC1pcGZ3QGZyZWVic2Qub3JnPiwgImZyZWVic2Qtc3RhYmxlQGZy ZWVic2Qub3JnIiA8ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc+DQpTZW50OiBTdW4sIE1hciA2 LCAyMDExIDE0OjU2OjEyIEdNVCswMDowMA0KU3ViamVjdDogS2VybmVsIFVwZGF0ZSAvIElQRlcg bm90IHdvcmtpbmcNCg0KSGkgYWxsDQoNCg0KQW4gSVBGVyBwcm9ibGVtIHdoZW4gZ29pbmcgZnJv bSByZWxlYXNlIHRvIHN0YWJsZSBvbiA4LjINCg0KQW4gaGVscCBnbGFkbHkgYWNjZXB0ZWQNCg0K TE9HIE9ODQoNCkZsdXNoZWQgYWxsIHJ1bGVzLg0KMDAwMTAgYWxsb3cgaXAgZnJvbSAxMjcuMC4w LjEgdG8gMTI3LjAuMC4xIHZpYSBsbzANCjAwMDMwIGRpdmVydCA4NjY4IGlwIGZyb20gYW55IHRv IGFueSB2aWEgYmdlMA0KaXBmdzogZ2V0c29ja29wdChJUF9GV19BREQpOiBJbnZhbGlkIGFyZ3Vt ZW50DQo1MDAwMCBhbGxvdyBpcCBmcm9tIGFueSB0byBhbnkNCkZpcmV3YWxsIHJ1bGVzIGxvYWRl ZC4NClN0YXJ0aW5nIG5hdGQuDQoNCnJjLmNvbmYNCmRlZmF1bHRyb3V0ZXI9IjE5Mi4xNjguMC4x Ig0KZ2F0ZXdheV9lbmFibGU9IllFUyINCmhvc3RuYW1lPSJ4eHgueHh4Lnh4eCINCmlmY29uZmln X2JnZTA9ImluZXQgMTkyLjE2OC4wLjExIG5ldG1hc2sgMjU1LjI1NS4yNTUuMCINCmlmY29uZmln X2VtMD0iaW5ldCAxOTIuMTY4LjEuMiBuZXRtYXNrIDI1NS4yNTUuMjU1LjAiDQprZXltYXA9InVz LmlzbyINCm1vdXNlZF9lbmFibGU9IllFUyINCnNzaGRfZW5hYmxlPSJZRVMiDQpmaXJld2FsbF9l bmFibGU9IllFUyINCmZpcmV3YWxsX3NjcmlwdD0iL2V0Yy9yYy5maXJld2FsbCINCm5hdGRfcHJv Z3JhbT0iL3NiaW4vbmF0ZCINCm5hdGRfZW5hYmxlPSJZRVMiDQpuYXRkX2ludGVyZmFjZT0iYmdl MCINCm5hdGRfZmxhZ3M9Ii1mIC9ldGMvbmF0ZC5jb25mIg0KZGhjcGRfZW5hYmxlPSJOTyINCmRo Y3BkX2ZsYWdzPSItcSINCmRoY3BkX2NvbmY9Ii91c3IvbG9jYWwvZXRjL2RoY3BkLmNvbmYiDQpk aGNwZF9pZmFjZXM9ImVtMCINCmRoY3BkX3dpdGh1bWFzaz0iMDIyIg0KDQpuYXRkLmNvbmYNCg0K aW50ZXJmYWNlIGJnZTANCnVzZV9zb2NrZXRzIHllcw0Kc2FtZV9wb3J0cyB5ZXMNCmxvZw0KI3Jl ZGlyZWN0X3BvcnQgdGNwIDE5Mi4xNjguMS4xODk6MzM4OSAzMzg5DQojcmVkaXJlY3RfcG9ydCB0 Y3AgMTkyLjE2OC4xLjUzOjU1MDAgNTUwMA0KDQojIS9iaW4vc2gNCg0KL3NiaW4vaXBmdyAtZiBm bHVzaA0KL3NiaW4vaXBmdyAtZiBwaXBlIGZsdXNoDQoNCg0KDQojTmF0IFJ1bGVzDQovc2Jpbi9p cGZ3IGFkZCAxMCBhbGxvdyBpcCBmcm9tIDEyNy4wLjAuMSB0byAxMjcuMC4wLjEgdmlhIGxvMA0K L3NiaW4vaXBmdyBhZGQgMzAgZGl2ZXJ0IG5hdGQgYWxsIGZyb20gYW55IHRvIGFueSB2aWEgYmdl MA0KDQoNCiNGb3J3YXJkIHRvIFRyYW5zcGFyZW50IFByb3h5IFNlcnZlcg0KIy9zYmluL2lwZncg YWRkIDEwMDAxIGZ3ZCAxMjcuMC4wLjEsMzEyOCB0Y3AgZnJvbSBhbnkgdG8gYW55IDgwDQojL3Ni aW4vaXBmdyBhZGQgMTAwMTAgZndkIDEyNy4wLjAuMSwzMTI4IHRjcCBmcm9tIDEwLjAuMjEuMiB0 byBhbnkgODANCg0KL3NiaW4vaXBmdyBhZGQgMTAwMDEgZndkIDEyNy4wLjAuMSwzMTI4IHRjcCBm cm9tIGFueSB0byBhbnkgODANCg0KDQovc2Jpbi9pcGZ3IGFkZCA1MDAwMCBhbGxvdyBpcCBmcm9t IGFueSB0byBhbnkNCg0KS0VSTkVMDQoNCm9wdGlvbnMgSVBGSVJFV0FMTA0Kb3B0aW9ucyBJUEZJ UkVXQUxMX1ZFUkJPU0UNCm9wdGlvbnMgSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUPTUNCm9wdGlv bnMgSVBGSVJFV0FMTF9ERUZBVUxUX1RPX0FDQ0VQVA0Kb3B0aW9ucyBJUERJVkVSVA0Kb3B0aW9u cyBEVU1NWU5FVA0KDQpSZWdhcmRzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KZnJlZWJzZC1pcGZ3QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0 cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1pcGZ3DQpUbyB1 bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1pcGZ3LXVuc3Vic2NyaWJlQGZy ZWVic2Qub3JnIg0K From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 18:09:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 545C61065674 for ; Sun, 6 Mar 2011 18:09:02 +0000 (UTC) (envelope-from cliftonr@oz.volcano.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDDF8FC1B for ; Sun, 6 Mar 2011 18:09:01 +0000 (UTC) X-Authority-Analysis: v=1.1 cv=+c36koQ5Dcj/1qolKHjtkYAGXvrVJRRiKMp+84F5sLg= c=1 sm=0 a=-dGJ4BceWFsA:10 a=kj9zAlcOel0A:10 a=G5OLwwqwWgs+1dCEPNHTSw==:17 a=jb__rZ8GAAAA:8 a=H9iEQFZ8AAAA:8 a=H0bb8E1zvDuctSx5v9MA:9 a=-YuvZ_SyO_YwUxO2Kp4A:7 a=xvjwrvJ942Zsd8X5qeihICpcFG4A:4 a=CjuIK1q_8ugA:10 a=sHp_62vNEjwA:10 a=fZFZujrNNEQA:10 a=G5OLwwqwWgs+1dCEPNHTSw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.80.196.236 Received: from [75.80.196.236] ([75.80.196.236:42078] helo=oz.volcano.org) by hrndva-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 6E/00-24070-CBDC37D4; Sun, 06 Mar 2011 18:09:01 +0000 Received: by oz.volcano.org (Postfix, from userid 1001) id D8C2650824; Sun, 6 Mar 2011 08:08:59 -1000 (HST) Date: Sun, 6 Mar 2011 08:08:59 -1000 From: Clifton Royston To: Greg Byshenk Message-ID: <20110306180859.GA18399@lava.net> Mail-Followup-To: Greg Byshenk , Yue Wu , ml-freebsd-stable References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> <20110306011433.GA21857@fbsd.t60.cpu> <20110306020917.GA90894@fbsd.t60.cpu> <20110306140628.GS30336@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306140628.GS30336@core.byshenk.net> User-Agent: Mutt/1.4.2.3i Cc: ml-freebsd-stable , Yue Wu Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 18:09:02 -0000 On Sun, Mar 06, 2011 at 03:06:28PM +0100, Greg Byshenk wrote: > On Sun, Mar 06, 2011 at 10:09:17AM +0800, Yue Wu wrote: > > ports with portmaster makes pkg installation mangement be much more > > flexiable and more friendly than package by pkg_add -r on FreeBSD, > > except that ports take much more time and resource. After trying with > > packages, I think I have to stick to ports. > > As suggested by some of the other comments, you can choose to use > portmaster with packages, if you prefer not to do local builds. > > In my own case, I use ports and packages, via portmaster. That is, > I use one machine to build locally-configured packages (in some > cases with non-standard options), and then install them on the rest > of the machines as packages. It works very well in my environment. I second this approach if you are managing more than one machine. Once I got this approach working, we used to do this when I was working on a spam filtering solution, and also at my ISP. It greatly simplifies and reduces the time spent managing a multi-machine environment; it works even better when you're handling steps like deploying from a test environment into a production environment. You can even go a step further to define and create your own packages containing sets of configuration files you want to deploy in conjunction with the binaries. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 19:48:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EAB5106566C; Sun, 6 Mar 2011 19:48:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0510E8FC17; Sun, 6 Mar 2011 19:48:51 +0000 (UTC) Received: by vxc34 with SMTP id 34so3808018vxc.13 for ; Sun, 06 Mar 2011 11:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L9JqwY4NtvgZpR7g2ko1kUjTM1WiiZvrG1LMQcdxmzA=; b=Mbv+ImG24VUUdddsCR1BiAfRkQSOEpyw2x7s06wz+tQ81hNYX6QBWen3eVQh3EioM8 m/FDJmSZ5EvgWk6nCdNxvVsjdNBC6V/0puesXjW4f3FwUvnidbdwxGXBCzASznOll8+q mfHFrG3japaLol9HnEiyzI7a7DAS35m/2QUmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cNhrv+3ntJfZhAoMzxRBhaTSDefBpS2N/JZCB2uofuG12juTpCmuEBwd5nzTNGz5Gm X+92Us5QHnuRrRIoHy8iPdTdF3tEnyFZk5oSCjhC4z2aO9TfxNnOmv1ni5LU/wRUDjvp JWGDg4YCJyxNOZmU27+dXHchYqxLLTO1UZTq8= MIME-Version: 1.0 Received: by 10.52.91.231 with SMTP id ch7mr587356vdb.14.1299440930640; Sun, 06 Mar 2011 11:48:50 -0800 (PST) Received: by 10.52.169.100 with HTTP; Sun, 6 Mar 2011 11:48:50 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Sun, 6 Mar 2011 11:48:50 -0800 Message-ID: From: Jack Vogel To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Brandon Gooch , freebsd-net@freebsd.org, Jan Koum , Steven Hartland , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Sun, 06 Mar 2011 19:48:52 -0000 Missed packets just mean that some temporary resource shortage or error caused the packet to be dropped. I don't believe this is indicative of a problem, just let it keep running, 2 days is good but 2 weeks is better :) Thanks for testing it! Jack On Sun, Mar 6, 2011 at 4:37 AM, =D6zkan KIRIK wrote= : > Hello, > > I've been testing the em.7.2.2 driver as kld. The system is up about 2 > days 6 hours. > System has 4 em interfaces, Throughput is about 200Mbit/s. System > didn't hang, but em2 has Input Errors. > > I saw that, dev.em.2.mac_stats.missed_packets is not zero? What could > be the problem? > > # uname -r > 8.2-RELEASE > > # sysctl dev.em.| grep miss > dev.em.0.mac_stats.missed_packets: 0 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.2.mac_stats.missed_packets: 5886 > dev.em.3.mac_stats.missed_packets: 0 > > # netstat -nWI em2 | grep Link > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll > em2 1500 00:23:8b:89:e4:9e 267256324 5886 0 > 273081628 0 0 > > # sysctl dev.em.2. > dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 > dev.em.2.%driver: em > dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1E > dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e > subdevice=3D0x125e class=3D0x020000 > dev.em.2.%parent: pci12 > dev.em.2.nvm: -1 > dev.em.2.debug: -1 > dev.em.2.rx_int_delay: 0 > dev.em.2.tx_int_delay: 66 > dev.em.2.rx_abs_int_delay: 66 > dev.em.2.tx_abs_int_delay: 66 > dev.em.2.rx_processing_limit: 100 > dev.em.2.flow_control: 3 > dev.em.2.eee_control: 0 > dev.em.2.link_irq: 0 > dev.em.2.mbuf_alloc_fail: 0 > dev.em.2.cluster_alloc_fail: 0 > dev.em.2.dropped: 0 > dev.em.2.tx_dma_fail: 0 > dev.em.2.rx_overruns: 7 > dev.em.2.watchdog_timeouts: 0 > dev.em.2.device_control: 1075577409 > dev.em.2.rx_control: 67141634 > dev.em.2.fc_high_water: 30720 > dev.em.2.fc_low_water: 29220 > dev.em.2.queue0.txd_head: 3025 > dev.em.2.queue0.txd_tail: 3025 > dev.em.2.queue0.tx_irq: 0 > dev.em.2.queue0.no_desc_avail: 0 > dev.em.2.queue0.rxd_head: 1826 > dev.em.2.queue0.rxd_tail: 1825 > dev.em.2.queue0.rx_irq: 0 > dev.em.2.mac_stats.excess_coll: 0 > dev.em.2.mac_stats.single_coll: 0 > dev.em.2.mac_stats.multiple_coll: 0 > dev.em.2.mac_stats.late_coll: 0 > dev.em.2.mac_stats.collision_count: 0 > dev.em.2.mac_stats.symbol_errors: 0 > dev.em.2.mac_stats.sequence_errors: 0 > dev.em.2.mac_stats.defer_count: 0 > dev.em.2.mac_stats.missed_packets: 5886 > dev.em.2.mac_stats.recv_no_buff: 3407 > dev.em.2.mac_stats.recv_undersize: 0 > dev.em.2.mac_stats.recv_fragmented: 0 > dev.em.2.mac_stats.recv_oversize: 0 > dev.em.2.mac_stats.recv_jabber: 0 > dev.em.2.mac_stats.recv_errs: 0 > dev.em.2.mac_stats.crc_errs: 0 > dev.em.2.mac_stats.alignment_errs: 0 > dev.em.2.mac_stats.coll_ext_errs: 0 > dev.em.2.mac_stats.xon_recvd: 0 > dev.em.2.mac_stats.xon_txd: 0 > dev.em.2.mac_stats.xoff_recvd: 0 > dev.em.2.mac_stats.xoff_txd: 0 > dev.em.2.mac_stats.total_pkts_recvd: 265358324 > dev.em.2.mac_stats.good_pkts_recvd: 265352438 > dev.em.2.mac_stats.bcast_pkts_recvd: 701728 > dev.em.2.mac_stats.mcast_pkts_recvd: 4076 > dev.em.2.mac_stats.rx_frames_64: 0 > dev.em.2.mac_stats.rx_frames_65_127: 140801982 > dev.em.2.mac_stats.rx_frames_128_255: 3553397 > dev.em.2.mac_stats.rx_frames_256_511: 3418754 > dev.em.2.mac_stats.rx_frames_512_1023: 8096866 > dev.em.2.mac_stats.rx_frames_1024_1522: 109481439 > dev.em.2.mac_stats.good_octets_recvd: 177455051448 > dev.em.2.mac_stats.good_octets_txd: 274861571704 > dev.em.2.mac_stats.total_pkts_txd: 270439410 > dev.em.2.mac_stats.good_pkts_txd: 270439410 > dev.em.2.mac_stats.bcast_pkts_txd: 194927 > dev.em.2.mac_stats.mcast_pkts_txd: 48 > dev.em.2.mac_stats.tx_frames_64: 23050855 > dev.em.2.mac_stats.tx_frames_65_127: 54156414 > dev.em.2.mac_stats.tx_frames_128_255: 4299280 > dev.em.2.mac_stats.tx_frames_256_511: 7837146 > dev.em.2.mac_stats.tx_frames_512_1023: 8272014 > dev.em.2.mac_stats.tx_frames_1024_1522: 172823701 > dev.em.2.mac_stats.tso_txd: 0 > dev.em.2.mac_stats.tso_ctx_fail: 0 > dev.em.2.interrupts.asserts: 283674059 > dev.em.2.interrupts.rx_pkt_timer: 33585 > dev.em.2.interrupts.rx_abs_timer: 0 > dev.em.2.interrupts.tx_pkt_timer: 11022 > dev.em.2.interrupts.tx_abs_timer: 22449 > dev.em.2.interrupts.tx_queue_empty: 0 > dev.em.2.interrupts.tx_queue_min_thresh: 0 > dev.em.2.interrupts.rx_desc_min_thresh: 0 > dev.em.2.interrupts.rx_overrun: 0 > > Regards, > Ozkan KIRIK > From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 20:36:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC7BB1065675 for ; Sun, 6 Mar 2011 20:36:31 +0000 (UTC) (envelope-from Hilko.Meyer@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 119538FC15 for ; Sun, 6 Mar 2011 20:36:30 +0000 (UTC) Received: (qmail invoked by alias); 06 Mar 2011 20:09:48 -0000 Received: from p579EF8C8.dip.t-dialin.net (EHLO schrein.Speedport_W_700V) [87.158.248.200] by mail.gmx.net (mp043) with SMTP; 06 Mar 2011 21:09:48 +0100 X-Authenticated: #749823 X-Provags-ID: V01U2FsdGVkX1+1KStPW3K10awmU8UwALKQMeSKSkSBsWCvDVx3wS ofh8E1hjlrj2EH From: Hilko Meyer To: Doug Barton Date: Sun, 06 Mar 2011 21:09:40 +0100 Message-ID: References: <6v82n6934o8p7u4vpbde35dbnc41mjd4a5@4ax.com> <4D716CEE.7040106@quip.cz> <4D72A3CD.2070904@FreeBSD.org> In-Reply-To: <4D72A3CD.2070904@FreeBSD.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: service(8) doesn't list dhcpd startscript 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: Sun, 06 Mar 2011 20:36:31 -0000 Doug Barton schrieb: >On 03/04/2011 14:51, Miroslav Lachman wrote: >> Hilko Meyer wrote: >>> >>> today I played a bit with service(8) and I noticed that it doesn't >>> properly >>> detects the isc-dhcpd-startscript. System is 7.3-RELEASE-p4. 'service >>> -l' lists >>> isc-dhcpd but 'service -e' doesn't lists it: >>> | hilti@kirk:~> service -l | grep dhcp >>> | isc-dhcpd >>> | hilti@kirk:~> service -e | grep dhcp >>> | hilti@kirk:~> /usr/local/etc/rc.d/isc-dhcpd rcvar >>> | # dhcpd >>> | dhcpd_enable=3DYES >> >> It works for me on newer version of the FreeBSD (7.4-RELEASE) and with >> newer dhcpd (isc-dhcp41-server-4.1.2_2,1) >> >> ~/# service -l | grep dhcp >> isc-dhcpd >> isc-dhcpd6 >> >> ~/# service -e | grep dhcp >> /usr/local/etc/rc.d/isc-dhcpd >> /usr/local/etc/rc.d/isc-dhcpd6 >> >> ~/# /usr/local/etc/rc.d/isc-dhcpd rcvar >> # dhcpd >> dhcpd_enable=3DYES >> >> So you can compare rc scripts for those two versions or compare = changes >> in service between these two FreeBSD releases. > >I'm glad to hear that Miroslav was able to make it work. I looked at the= =20 >code and it's pretty simple, so I'm not sure why it would fail. > >Hilko, if you can add -x to the end of the #!/bin/sh line in=20 >/usr/sbin/service it might give you more of an idea of what's going on. Thanks for the hint. I think I found something: hilti@kirk:~/dhcpd> script log sh -x /usr/sbin/service -e [snip] + grep -q ^rcvar /etc/rc.d/yppasswdd + grep ^name=3D /etc/rc.d/yppasswdd + eval name=3D"yppasswdd" + name=3Dyppasswdd + grep ^rcvar /etc/rc.d/yppasswdd + eval rcvar=3D"nis_yppasswdd_enable" + rcvar=3Dnis_yppasswdd_enable + checkyesno nis_yppasswdd_enable + grep -q ^rcvar /usr/local/etc/rc.d/isc-dhcpd + grep ^name=3D /usr/local/etc/rc.d/isc-dhcpd + eval name=3Ddhcpd + name=3Ddhcpd + grep ^rcvar /usr/local/etc/rc.d/isc-dhcpd + eval rcvar_chuser () rcvar_jail () rcvar_chroot () rcvar_pidnleases () rcvar_rooted () rcvar=3D${name}_enable + checkyesno nis_yppasswdd_enable Seems 'grep ^rcvar /usr/local/etc/rc.d/isc-dhcpd' finds more than expected. I added a '=3D' in /usr/sbin/service and changed the line to eval `grep ^rcvar=3D $file`. Now it works like expected. But there is stil one question. Why it works in 7.4-RELEASE with newer dhcpd?=20 | hilti@kirk:~/dhcpd> grep ^rcvar isc-dhcpd_* | isc-dhcpd_3.1.in:rcvar_chuser () | isc-dhcpd_3.1.in:rcvar_jail () | isc-dhcpd_3.1.in:rcvar_chroot () | isc-dhcpd_3.1.in:rcvar_pidnleases () | isc-dhcpd_3.1.in:rcvar_rooted () | isc-dhcpd_3.1.in:rcvar=3D${name}_enable | isc-dhcpd_4.1.in:rcvar_chuser () | isc-dhcpd_4.1.in:rcvar_chroot () | isc-dhcpd_4.1.in:rcvar_pidnleases () | isc-dhcpd_4.1.in:rcvar_rooted () | isc-dhcpd_4.1.in:rcvar=3D${name}_enable In both files more than one result. And there was no change in service(8) between 7.3 and 74. Strange... Hilko From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 21:18:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42635106566C for ; Sun, 6 Mar 2011 21:18:30 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 981758FC08 for ; Sun, 6 Mar 2011 21:18:29 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id p26LIIov058404 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 6 Mar 2011 21:18:25 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk p26LIIov058404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1299446305; bh=mNmjI5zqbjGbX4BTDYcj/keHF5+nMsDc/RFWm+0tTMA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4D73FA12.4000104@infracaninophile.co.uk>|Date:=20S un,=2006=20Mar=202011=2021:18:10=20+0000|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.15)=20Gecko/20110303=20Thunderbird/3.1.9|MIME-Version:=201 .0|To:=20freebsd-stable@freebsd.org|Subject:=20Re:=20Question=20ab out=20packages=20installed=20via=20`pkg_add=20-r`|References:=20<2 0110305150436.GA2175@fbsd.t60.cpu>=09<20110305154817.GQ30336@core. byshenk.net>=20<4D72A069.90104@FreeBSD.org>=09<20110306010015.GC41 60@fbsd.t60.cpu>=09=20<4d734567.15evysQIxrkK6d6O%perryh@pluto.rain .com>|In-Reply-To:=20<4d734567.15evysQIxrkK6d6O%perryh@pluto.rain. com>|X-Enigmail-Version:=201.1.1|OpenPGP:=20id=3D60AE908C|Content- Type:=20multipart/signed=3B=20micalg=3Dpgp-sha1=3B=0D=0A=20protoco l=3D"application/pgp-signature"=3B=0D=0A=20boundary=3D"----------- -enig2F8384B59E94BDFE83DBACCF"; b=A+SDt+ZS55kWbwQSZ2j+vhvYjJND5ORjKUBGQr+1rzLkKZRytWZNMNT1lK7ZDB26M YaQ+CEv1vLMZGWMut8tb91xTreGXBOvxBKDu/n6Ss+GxljyW5KQ8hjvRNOgUlwYrzX 5YLL9HcRdFwI7pPFbFZ8RyS4uPEREnLPSulJizVw= Message-ID: <4D73FA12.4000104@infracaninophile.co.uk> Date: Sun, 06 Mar 2011 21:18:10 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> <4d734567.15evysQIxrkK6d6O%perryh@pluto.rain.com> In-Reply-To: <4d734567.15evysQIxrkK6d6O%perryh@pluto.rain.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F8384B59E94BDFE83DBACCF" X-Virus-Scanned: clamav-milter 0.97 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 21:18:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F8384B59E94BDFE83DBACCF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/03/2011 08:27, perryh@pluto.rain.com wrote: > Last time I tried it, pkg_add -r -K did indeed save local copies of > the packages fetched from the remote repository, but a problem arose > when one later wanted to _use_ that local stash while falling back to > -r behavior for anything not found locally. Last I knew there was no > easy way to tell pkg_add to do that. Interestingly, portmaster(8) is good for doing that. These two lines in portmasterrc (or the equivalent command line options: --packages, --local-packagedir) make portmaster try to install a package from a local package repository first, then fall back to fetching packages from the net, and only then try building the port: PM_PACKAGES=3Dfirst LOCAL_PACKAGEDIR=3D/usr/ports/packages Which is what you want. Or perhaps 'PM_PACKAGES=3Donly' which only uses pkgs and doesn't build any ports. Personally I find these most useful combined with a third option: PM_PACKAGES_LOCAL=3Dpmp_local (Cmd line: --packages-local) which makes portmaster try to install pkgs from a local repository first, and failing that, build the port. Oh, and to save anyone needlessly re-downloading packages: if you've got the port / package already installed, then you can recreate the pkg tarball easily by: # pkg_create -b pkg-name Add a '-R' to that to create pkg tarballs for everything pkg-name depends on too. pkg-name will include the version number as shown in eg. 'pkg_info -Ia' output. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig2F8384B59E94BDFE83DBACCF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1z+hoACgkQ8Mjk52CukIw9DwCfay+7nnFvtUYcYQxF6xM7Rmlz JAsAnAnZZnI9vo8k5PE3MSPJ5oDlPFKi =pvJV -----END PGP SIGNATURE----- --------------enig2F8384B59E94BDFE83DBACCF-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 21:23:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4828E1065673; Sun, 6 Mar 2011 21:23:21 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E604A8FC12; Sun, 6 Mar 2011 21:23:20 +0000 (UTC) Received: by iwn33 with SMTP id 33so3995057iwn.13 for ; Sun, 06 Mar 2011 13:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kllqkOK+mvh2RYBRmbLpq0dbT8K8d7AI6GYbGHXsWmA=; b=sgWRuemRaghSl06palv4rcE42kN1t8lltZeYzi452hDS/GoRtkX6MtTbIDQF5n3Ex7 c/tG/LYgJeCcZPVRneRRZAAdsAjpSmQKn9/nSMBOh3N21bDLxDcAeRSh/f2DlJz5AT/u z5e0tFBWlXCEcA21kDsQth4T9aWsGn1O5BIrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mTiaW3A3mgQjp+TOJIr2/u0YdHcuMFvOUgzVEQGru0K3Y58gl2CM0MchahTjBwLr+A ios3krD/EnDjxJsTvVaJfus98kxT0t5jL/PVibsYLRNTzXvGpjuARD1vzlpNyZmhGV44 rGmpn+P5VmT7OdO/6oi+fI1N18EGXuhuo0t6E= MIME-Version: 1.0 Received: by 10.42.223.134 with SMTP id ik6mr3861486icb.267.1299446599957; Sun, 06 Mar 2011 13:23:19 -0800 (PST) Received: by 10.42.172.198 with HTTP; Sun, 6 Mar 2011 13:23:19 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Sun, 6 Mar 2011 16:23:19 -0500 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, =?ISO-8859-1?Q?=D6zkan_KIRIK?= , Brandon Gooch , freebsd-net@freebsd.org, Jan Koum , Steven Hartland Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Sun, 06 Mar 2011 21:23:21 -0000 Hi Jack, On Sun, Mar 6, 2011 at 2:48 PM, Jack Vogel wrote: > Missed packets just mean that some temporary resource shortage or error > caused > the packet to be dropped. I don't believe this is indicative of a problem= , > just let it > keep running, 2 days is good but 2 weeks is better :) > > Thanks for testing it! > I still did not get any feedback from you about the patch I sent the list about not ignoring the RX overrun interrupt triggered by the card. Thanks, - Arnaud > Jack > > > On Sun, Mar 6, 2011 at 4:37 AM, =D6zkan KIRIK wro= te: >> >> Hello, >> >> I've been testing the em.7.2.2 driver as kld. The system is up about 2 >> days 6 hours. >> System has 4 em interfaces, Throughput is about 200Mbit/s. System >> didn't hang, but em2 has Input Errors. >> >> I saw that, dev.em.2.mac_stats.missed_packets is not zero? What could >> be the problem? >> >> # uname -r >> 8.2-RELEASE >> >> # sysctl dev.em.| grep miss >> dev.em.0.mac_stats.missed_packets: 0 >> dev.em.1.mac_stats.missed_packets: 0 >> dev.em.2.mac_stats.missed_packets: 5886 >> dev.em.3.mac_stats.missed_packets: 0 >> >> # netstat -nWI em2 | grep Link >> Name =A0 =A0 =A0Mtu Network =A0 =A0 =A0 Address =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ipkts Ierrs Idrop >> Opkts Oerrs =A0Coll >> em2 =A0 =A0 =A01500 =A0 =A0 =A000:23:8b:89:e4:9e 267256324 =A05= 886 =A0 =A0 0 >> 273081628 =A0 =A0 0 =A0 =A0 0 >> >> # sysctl dev.em.2. >> dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 >> dev.em.2.%driver: em >> dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1E >> dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e >> subdevice=3D0x125e class=3D0x020000 >> dev.em.2.%parent: pci12 >> dev.em.2.nvm: -1 >> dev.em.2.debug: -1 >> dev.em.2.rx_int_delay: 0 >> dev.em.2.tx_int_delay: 66 >> dev.em.2.rx_abs_int_delay: 66 >> dev.em.2.tx_abs_int_delay: 66 >> dev.em.2.rx_processing_limit: 100 >> dev.em.2.flow_control: 3 >> dev.em.2.eee_control: 0 >> dev.em.2.link_irq: 0 >> dev.em.2.mbuf_alloc_fail: 0 >> dev.em.2.cluster_alloc_fail: 0 >> dev.em.2.dropped: 0 >> dev.em.2.tx_dma_fail: 0 >> dev.em.2.rx_overruns: 7 >> dev.em.2.watchdog_timeouts: 0 >> dev.em.2.device_control: 1075577409 >> dev.em.2.rx_control: 67141634 >> dev.em.2.fc_high_water: 30720 >> dev.em.2.fc_low_water: 29220 >> dev.em.2.queue0.txd_head: 3025 >> dev.em.2.queue0.txd_tail: 3025 >> dev.em.2.queue0.tx_irq: 0 >> dev.em.2.queue0.no_desc_avail: 0 >> dev.em.2.queue0.rxd_head: 1826 >> dev.em.2.queue0.rxd_tail: 1825 >> dev.em.2.queue0.rx_irq: 0 >> dev.em.2.mac_stats.excess_coll: 0 >> dev.em.2.mac_stats.single_coll: 0 >> dev.em.2.mac_stats.multiple_coll: 0 >> dev.em.2.mac_stats.late_coll: 0 >> dev.em.2.mac_stats.collision_count: 0 >> dev.em.2.mac_stats.symbol_errors: 0 >> dev.em.2.mac_stats.sequence_errors: 0 >> dev.em.2.mac_stats.defer_count: 0 >> dev.em.2.mac_stats.missed_packets: 5886 >> dev.em.2.mac_stats.recv_no_buff: 3407 >> dev.em.2.mac_stats.recv_undersize: 0 >> dev.em.2.mac_stats.recv_fragmented: 0 >> dev.em.2.mac_stats.recv_oversize: 0 >> dev.em.2.mac_stats.recv_jabber: 0 >> dev.em.2.mac_stats.recv_errs: 0 >> dev.em.2.mac_stats.crc_errs: 0 >> dev.em.2.mac_stats.alignment_errs: 0 >> dev.em.2.mac_stats.coll_ext_errs: 0 >> dev.em.2.mac_stats.xon_recvd: 0 >> dev.em.2.mac_stats.xon_txd: 0 >> dev.em.2.mac_stats.xoff_recvd: 0 >> dev.em.2.mac_stats.xoff_txd: 0 >> dev.em.2.mac_stats.total_pkts_recvd: 265358324 >> dev.em.2.mac_stats.good_pkts_recvd: 265352438 >> dev.em.2.mac_stats.bcast_pkts_recvd: 701728 >> dev.em.2.mac_stats.mcast_pkts_recvd: 4076 >> dev.em.2.mac_stats.rx_frames_64: 0 >> dev.em.2.mac_stats.rx_frames_65_127: 140801982 >> dev.em.2.mac_stats.rx_frames_128_255: 3553397 >> dev.em.2.mac_stats.rx_frames_256_511: 3418754 >> dev.em.2.mac_stats.rx_frames_512_1023: 8096866 >> dev.em.2.mac_stats.rx_frames_1024_1522: 109481439 >> dev.em.2.mac_stats.good_octets_recvd: 177455051448 >> dev.em.2.mac_stats.good_octets_txd: 274861571704 >> dev.em.2.mac_stats.total_pkts_txd: 270439410 >> dev.em.2.mac_stats.good_pkts_txd: 270439410 >> dev.em.2.mac_stats.bcast_pkts_txd: 194927 >> dev.em.2.mac_stats.mcast_pkts_txd: 48 >> dev.em.2.mac_stats.tx_frames_64: 23050855 >> dev.em.2.mac_stats.tx_frames_65_127: 54156414 >> dev.em.2.mac_stats.tx_frames_128_255: 4299280 >> dev.em.2.mac_stats.tx_frames_256_511: 7837146 >> dev.em.2.mac_stats.tx_frames_512_1023: 8272014 >> dev.em.2.mac_stats.tx_frames_1024_1522: 172823701 >> dev.em.2.mac_stats.tso_txd: 0 >> dev.em.2.mac_stats.tso_ctx_fail: 0 >> dev.em.2.interrupts.asserts: 283674059 >> dev.em.2.interrupts.rx_pkt_timer: 33585 >> dev.em.2.interrupts.rx_abs_timer: 0 >> dev.em.2.interrupts.tx_pkt_timer: 11022 >> dev.em.2.interrupts.tx_abs_timer: 22449 >> dev.em.2.interrupts.tx_queue_empty: 0 >> dev.em.2.interrupts.tx_queue_min_thresh: 0 >> dev.em.2.interrupts.rx_desc_min_thresh: 0 >> dev.em.2.interrupts.rx_overrun: 0 >> >> Regards, >> Ozkan KIRIK > > From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 21:39:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D39351065674; Sun, 6 Mar 2011 21:39:47 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4F48FC15; Sun, 6 Mar 2011 21:39:46 +0000 (UTC) Received: by wyb32 with SMTP id 32so4241805wyb.13 for ; Sun, 06 Mar 2011 13:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v1JzfWJLQV/KLMWu0Qe4XdGNWuh+HD38nqTcO2wg/5Q=; b=peBss4uPlZg/LPHM4B/umxXr9QXMzWyojY/ROqbsEpx6lYeknLQH8h4HQ/475tTn4X rXckwGw6LH1phQ4FF7R1IzTLNcxqOP3pylvAhn5CxeAebSd+7Ba861VUCu3VIwjetuKz UAPciKzAVKuQDgRu8Zr9Pw0ZxXxc6sYwf+3Q0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UyLZTS0KImMvjNX0bJlwvVyZ5gcLyO0Bo/3gXtz3g05l81/kNsFy26+p683l9eIFm9 nb+JfwvFkfLezi9+4vGaPesJLK56os74p/SktRoo2lD5u/hM0gUAHODYfqbMCECmgscl M7pa+sqkOmNcg7z9jOE3wfHqnY+CeC7gJj1dM= MIME-Version: 1.0 Received: by 10.216.143.135 with SMTP id l7mr1646898wej.86.1299447586112; Sun, 06 Mar 2011 13:39:46 -0800 (PST) Received: by 10.216.28.81 with HTTP; Sun, 6 Mar 2011 13:39:46 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Sun, 6 Mar 2011 15:39:46 -0600 Message-ID: From: Brandon Gooch To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, =?ISO-8859-1?Q?=D6zkan_KIRIK?= , freebsd-net@freebsd.org, Jan Koum , Steven Hartland , Arnaud Lacombe Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Sun, 06 Mar 2011 21:39:47 -0000 On Sun, Mar 6, 2011 at 1:48 PM, Jack Vogel wrote: > Missed packets just mean that some temporary resource shortage or error > caused > the packet to be dropped. I don't believe this is indicative of a problem, > just let it > keep running, 2 days is good but 2 weeks is better :) > > Thanks for testing it! > > Jack Jack, I found several production machines I can test 7.2.2 on, if you'd be so kind to provide me with a link or an attachment :) I don't know exactly what chips they are, but I figure that testing is still testing... -Brandon From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 21:40:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1167D1065680; Sun, 6 Mar 2011 21:40:15 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE0B48FC0A; Sun, 6 Mar 2011 21:40:14 +0000 (UTC) Received: by iyj12 with SMTP id 12so4004446iyj.13 for ; Sun, 06 Mar 2011 13:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DfJxmbkEuUKVcnNJCwrKCy5h7eC+4PWWDFOJAX0y0bg=; b=SvFxNkcdQi89rqasHlFcbd1lFp2ufMSneHfvL+/vHvTx4jS93tcw850ffTVx8dSPUZ EZLwunNgkzwEMrSqnZ9XhkDK7fPJXmssXYWGOHqN7VOTZThC9qeE1oxij4R6K/w/ajhy +aQ3PL/ZAvNNFGo4yGKQmQUS5fdOvTtSqWztQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jltzk0kBqmCprc8FHFgSJMqw3Pq3uEi0hhDNFnBzzDPAAcIBSo4ceCdus3UsxkI8L6 zRPc07KuvDAR5CWCRGfX+j4dqpLtiFOv1muhRO8SFVWI3kdW+gkhqXQgVmPKSy/hwGHH iOi2Y18L9LB1Eo7+D7IcVFM2C+p9ncLMTTnnk= MIME-Version: 1.0 Received: by 10.43.64.69 with SMTP id xh5mr2472456icb.66.1299447613807; Sun, 06 Mar 2011 13:40:13 -0800 (PST) Received: by 10.42.172.198 with HTTP; Sun, 6 Mar 2011 13:40:13 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Sun, 6 Mar 2011 16:40:13 -0500 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, =?ISO-8859-1?Q?=D6zkan_KIRIK?= , Brandon Gooch , freebsd-net@freebsd.org, Jan Koum , Steven Hartland Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Sun, 06 Mar 2011 21:40:15 -0000 Hi, On Sun, Mar 6, 2011 at 4:23 PM, Arnaud Lacombe wrote: > Hi Jack, > > On Sun, Mar 6, 2011 at 2:48 PM, Jack Vogel wrote: >> Missed packets just mean that some temporary resource shortage or error >> caused >> the packet to be dropped. I don't believe this is indicative of a proble= m, >> just let it >> keep running, 2 days is good but 2 weeks is better :) >> >> Thanks for testing it! >> > I still did not get any feedback from you about the patch I sent the > list about not ignoring the RX overrun interrupt triggered by the > card. > Just to precise. For what I understood of Beezar Lui "fix", all the work is done in the RX interrupt context, ie. you rely on the card to trigger RX interrupt to refresh mbufs. If the resource shortage is too long, the card stops triggering RX interrupt and "hang", but it _still_ trigger RX overrun to warn the OS about the situation. Currently this interrupt is just ignored. Your original fix works for igb(4) as a single handler is used per queue; igb_rxeof() get called in both RX and TX context. This is not the case with em(4) as RX and TX interrupt are independent from each other. So if the hardware empties the ring and you cannot replenish it while you still get RX interrupt, you have no other choice than using the RX overrun interrupt to hope to recover. - Arnaud > Thanks, > =A0- Arnaud > >> Jack >> >> >> On Sun, Mar 6, 2011 at 4:37 AM, =D6zkan KIRIK wr= ote: >>> >>> Hello, >>> >>> I've been testing the em.7.2.2 driver as kld. The system is up about 2 >>> days 6 hours. >>> System has 4 em interfaces, Throughput is about 200Mbit/s. System >>> didn't hang, but em2 has Input Errors. >>> >>> I saw that, dev.em.2.mac_stats.missed_packets is not zero? What could >>> be the problem? >>> >>> # uname -r >>> 8.2-RELEASE >>> >>> # sysctl dev.em.| grep miss >>> dev.em.0.mac_stats.missed_packets: 0 >>> dev.em.1.mac_stats.missed_packets: 0 >>> dev.em.2.mac_stats.missed_packets: 5886 >>> dev.em.3.mac_stats.missed_packets: 0 >>> >>> # netstat -nWI em2 | grep Link >>> Name =A0 =A0 =A0Mtu Network =A0 =A0 =A0 Address =A0 =A0 =A0 =A0 =A0 =A0= =A0Ipkts Ierrs Idrop >>> Opkts Oerrs =A0Coll >>> em2 =A0 =A0 =A01500 =A0 =A0 =A000:23:8b:89:e4:9e 267256324 =A0= 5886 =A0 =A0 0 >>> 273081628 =A0 =A0 0 =A0 =A0 0 >>> >>> # sysctl dev.em.2. >>> dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 >>> dev.em.2.%driver: em >>> dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1E >>> dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e >>> subdevice=3D0x125e class=3D0x020000 >>> dev.em.2.%parent: pci12 >>> dev.em.2.nvm: -1 >>> dev.em.2.debug: -1 >>> dev.em.2.rx_int_delay: 0 >>> dev.em.2.tx_int_delay: 66 >>> dev.em.2.rx_abs_int_delay: 66 >>> dev.em.2.tx_abs_int_delay: 66 >>> dev.em.2.rx_processing_limit: 100 >>> dev.em.2.flow_control: 3 >>> dev.em.2.eee_control: 0 >>> dev.em.2.link_irq: 0 >>> dev.em.2.mbuf_alloc_fail: 0 >>> dev.em.2.cluster_alloc_fail: 0 >>> dev.em.2.dropped: 0 >>> dev.em.2.tx_dma_fail: 0 >>> dev.em.2.rx_overruns: 7 >>> dev.em.2.watchdog_timeouts: 0 >>> dev.em.2.device_control: 1075577409 >>> dev.em.2.rx_control: 67141634 >>> dev.em.2.fc_high_water: 30720 >>> dev.em.2.fc_low_water: 29220 >>> dev.em.2.queue0.txd_head: 3025 >>> dev.em.2.queue0.txd_tail: 3025 >>> dev.em.2.queue0.tx_irq: 0 >>> dev.em.2.queue0.no_desc_avail: 0 >>> dev.em.2.queue0.rxd_head: 1826 >>> dev.em.2.queue0.rxd_tail: 1825 >>> dev.em.2.queue0.rx_irq: 0 >>> dev.em.2.mac_stats.excess_coll: 0 >>> dev.em.2.mac_stats.single_coll: 0 >>> dev.em.2.mac_stats.multiple_coll: 0 >>> dev.em.2.mac_stats.late_coll: 0 >>> dev.em.2.mac_stats.collision_count: 0 >>> dev.em.2.mac_stats.symbol_errors: 0 >>> dev.em.2.mac_stats.sequence_errors: 0 >>> dev.em.2.mac_stats.defer_count: 0 >>> dev.em.2.mac_stats.missed_packets: 5886 >>> dev.em.2.mac_stats.recv_no_buff: 3407 >>> dev.em.2.mac_stats.recv_undersize: 0 >>> dev.em.2.mac_stats.recv_fragmented: 0 >>> dev.em.2.mac_stats.recv_oversize: 0 >>> dev.em.2.mac_stats.recv_jabber: 0 >>> dev.em.2.mac_stats.recv_errs: 0 >>> dev.em.2.mac_stats.crc_errs: 0 >>> dev.em.2.mac_stats.alignment_errs: 0 >>> dev.em.2.mac_stats.coll_ext_errs: 0 >>> dev.em.2.mac_stats.xon_recvd: 0 >>> dev.em.2.mac_stats.xon_txd: 0 >>> dev.em.2.mac_stats.xoff_recvd: 0 >>> dev.em.2.mac_stats.xoff_txd: 0 >>> dev.em.2.mac_stats.total_pkts_recvd: 265358324 >>> dev.em.2.mac_stats.good_pkts_recvd: 265352438 >>> dev.em.2.mac_stats.bcast_pkts_recvd: 701728 >>> dev.em.2.mac_stats.mcast_pkts_recvd: 4076 >>> dev.em.2.mac_stats.rx_frames_64: 0 >>> dev.em.2.mac_stats.rx_frames_65_127: 140801982 >>> dev.em.2.mac_stats.rx_frames_128_255: 3553397 >>> dev.em.2.mac_stats.rx_frames_256_511: 3418754 >>> dev.em.2.mac_stats.rx_frames_512_1023: 8096866 >>> dev.em.2.mac_stats.rx_frames_1024_1522: 109481439 >>> dev.em.2.mac_stats.good_octets_recvd: 177455051448 >>> dev.em.2.mac_stats.good_octets_txd: 274861571704 >>> dev.em.2.mac_stats.total_pkts_txd: 270439410 >>> dev.em.2.mac_stats.good_pkts_txd: 270439410 >>> dev.em.2.mac_stats.bcast_pkts_txd: 194927 >>> dev.em.2.mac_stats.mcast_pkts_txd: 48 >>> dev.em.2.mac_stats.tx_frames_64: 23050855 >>> dev.em.2.mac_stats.tx_frames_65_127: 54156414 >>> dev.em.2.mac_stats.tx_frames_128_255: 4299280 >>> dev.em.2.mac_stats.tx_frames_256_511: 7837146 >>> dev.em.2.mac_stats.tx_frames_512_1023: 8272014 >>> dev.em.2.mac_stats.tx_frames_1024_1522: 172823701 >>> dev.em.2.mac_stats.tso_txd: 0 >>> dev.em.2.mac_stats.tso_ctx_fail: 0 >>> dev.em.2.interrupts.asserts: 283674059 >>> dev.em.2.interrupts.rx_pkt_timer: 33585 >>> dev.em.2.interrupts.rx_abs_timer: 0 >>> dev.em.2.interrupts.tx_pkt_timer: 11022 >>> dev.em.2.interrupts.tx_abs_timer: 22449 >>> dev.em.2.interrupts.tx_queue_empty: 0 >>> dev.em.2.interrupts.tx_queue_min_thresh: 0 >>> dev.em.2.interrupts.rx_desc_min_thresh: 0 >>> dev.em.2.interrupts.rx_overrun: 0 >>> >>> Regards, >>> Ozkan KIRIK >> >> > From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 22:15:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 23D76106566C for ; Sun, 6 Mar 2011 22:15:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2353E150637; Sun, 6 Mar 2011 22:15:57 +0000 (UTC) Message-ID: <4D74079C.9050209@FreeBSD.org> Date: Sun, 06 Mar 2011 14:15:56 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yue Wu References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> In-Reply-To: <20110306010015.GC4160@fbsd.t60.cpu> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ml-freebsd-stable Subject: Re: Question about packages installed via `pkg_add -r` 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: Sun, 06 Mar 2011 22:15:59 -0000 On 03/05/2011 17:00, Yue Wu wrote: > Hello, sorry for poor English, I will try to explan clearer with my > best. > > On Sat, Mar 05, 2011 at 04:48:17PM +0100, Greg Byshenk wrote: >> On Sat, Mar 05, 2011 at 11:04:36PM +0800, Yue Wu wrote: >> >>> I'm trying to use package instead of ports these day, but a few >>> questions have: >>> >>> 1. How to reserve packages that fetched via `pkg_add -r`? >>> >>> 2. How to know if there are updates for packages, and how to update? >> >> For (1), do you mean 'preserve', as in save a copy? If so, then >> 'portmaster -b [...]' will save a backup copy of installed packages. > > Yes, I mean 'preserve'. I've maned portmaster, seems -b is for a > installed package, so it will preserve it by packing up the files from a > installed package, why not preserve it just when fetching with `pkg_add > -r`? I think it's the best way, I don't like the portmaster way to do it > after. This is why I wanted to confirm what you intended to do. The -b option does indeed preserve the existing version of the package, but the behavior that you're looking for (saving a copy of the new package) is actually the default behavior. The downloaded packages are saved in /usr/ports/packages/portmaster-download. It sounds like your best best would be to have an up to date ports tree, and use the -P option to install packages whenever they are available. hope this helps, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 03:30:25 2011 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 BB577106566B; Mon, 7 Mar 2011 03:30:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0A51E8FC08; Mon, 7 Mar 2011 03:30:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p272uogx035954; Mon, 7 Mar 2011 13:56:50 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 7 Mar 2011 13:56:49 +1100 (EST) From: Ian Smith To: Dave Johnson Message-ID: <20110307135057.C84485@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@freebsd.org, ipfw@freebsd.org Subject: Re: An IPFW problem when going from release to stable on 8.2/ Maybe bge0 network card? (fwd) 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: Mon, 07 Mar 2011 03:30:25 -0000 Oh, I see this one was to net@, whereas your earlier message was to ipfw@ and stable@ with different subject, a bit confusing .. Ian ---------- Forwarded message ---------- Date: Mon, 7 Mar 2011 13:49:20 +1100 (EST) From: Ian Smith To: Dave Johnson Cc: freebsd-net@freebsd.org Subject: Re: An IPFW problem when going from release to stable on 8.2/ Maybe bge0 network card? On Sun, 6 Mar 2011, Dave Johnson wrote: > Hi all > > > An IPFW problem when going from release to stable on 8.2 > > An help gladly accepted > > LOG ON > > Flushed all rules. > 00010 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > 00030 divert 8668 ip from any to any via bge0 > ipfw: getsockopt(IP_FW_ADD): Invalid argument > 50000 allow ip from any to any > Firewall rules loaded. > Starting natd. That error occured when attempting to install the fwd rule below. Checking with 'ipfw list' should show that rule as missing. > rc.conf > defaultrouter="192.168.0.1" > gateway_enable="YES" > hostname="xxx.xxx.xxx" > ifconfig_bge0="inet 192.168.0.11 netmask 255.255.255.0" > ifconfig_em0="inet 192.168.1.2 netmask 255.255.255.0" > keymap="us.iso" > moused_enable="YES" > sshd_enable="YES" > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > natd_program="/sbin/natd" > natd_enable="YES" > natd_interface="bge0" > natd_flags="-f /etc/natd.conf" > dhcpd_enable="NO" > dhcpd_flags="-q" > dhcpd_conf="/usr/local/etc/dhcpd.conf" > dhcpd_ifaces="em0" > dhcpd_withumask="022" > > natd.conf > > interface bge0 > use_sockets yes > same_ports yes > log > #redirect_port tcp 192.168.1.189:3389 3389 > #redirect_port tcp 192.168.1.53:5500 5500 > > #!/bin/sh > > /sbin/ipfw -f flush > /sbin/ipfw -f pipe flush > > > > #Nat Rules > /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > /sbin/ipfw add 30 divert natd all from any to any via bge0 Don't use 'all' or 'ip' with divert, specify ip4 instead; divert can't handle ip6 packets yet, panics have been reported. See /etc/rc.firewall > #Forward to Transparent Proxy Server > #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 > > /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > > > /sbin/ipfw add 50000 allow ip from any to any > > KERNEL > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=5 > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPDIVERT > options DUMMYNET But ipfw(8) sayeth: To enable fwd a custom kernel needs to be compiled with the option options IPFIREWALL_FORWARD. cheers, Ian [ aside: man.cgi is currently broken for 8.2-RELEASE, at least for ipfw. http://www.freebsd.org/cgi/man.cgi?query=ipfw&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&format=html reports "Sorry, no data found for `ipfw'. Please try a keyword search." Selecting 8.1-stable instead works correctly ] From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 12:12:19 2011 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 3971E106566C for ; Mon, 7 Mar 2011 12:12:19 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ticketswitch.com (constantine.ingresso.co.uk [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id D2D968FC16 for ; Mon, 7 Mar 2011 12:12:18 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PwZIQ-0000MM-2h for stable@freebsd.org; Mon, 07 Mar 2011 12:12:18 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PwZIQ-000BKd-1m for stable@freebsd.org; Mon, 07 Mar 2011 12:12:18 +0000 Date: Mon, 07 Mar 2011 12:12:18 +0000 Message-Id: To: stable@freebsd.org From: Pete French Cc: Subject: em - difference between 82566DM and 82546EB 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: Mon, 07 Mar 2011 12:12:19 -0000 I found a solution to my em0 problem - I dropped in a PCI card with two Intel controllers on it (em1 and em2 obviously) and those work fine. So, the question is, what is the difference between the plug in card, which is 82546EB, and the onboard 82566DM controller which makes the latter stop working under circumstances where the former does not ? Relevent bits of pciconv -lv: em0@pci0:0:25:0: class=0x020000 card=0x281e103c chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet em1@pci0:7:4:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet em2@pci0:7:4:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet The only thing I noticed was that em0 uses MSI, whereas the pliug in card does not. The sitiuation under which it stopped was very heavy receive traffic into the interface. Unfortunately I didnt get much time to debug it, as it's a pretty critical server. But I did observer that a quick ifconfig down/up doesn't fix it - the machine needed to reboot. By 'stop' I mean that the interface looks fine, but doesnt actially appear to receive packets anymore. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 12:12:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936671065708; Mon, 7 Mar 2011 12:12:27 +0000 (UTC) (envelope-from freebsduser@paradisegreen.co.uk) Received: from mail.paradisegreen.co.uk (almaz.paradisegreen.co.uk [81.187.228.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8A68FC19; Mon, 7 Mar 2011 12:12:26 +0000 (UTC) Received: from [10.0.0.17] (vaio2.paradise [10.0.0.17]) by mail.paradisegreen.co.uk (8.13.3/8.13.3) with ESMTP id p27BXpIK017071; Mon, 7 Mar 2011 11:33:52 GMT (envelope-from freebsduser@paradisegreen.co.uk) DomainKey-Signature: a=rsa-sha1; s=default; d=paradisegreen.co.uk; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Xm1bix8OFDPSEXtPtTFMluMdu1ETBSKcvRY7DvmkX7Fms3ha4shKQg7Vmr9jbNeAH uHR6xQiYXaW4k8jSftQiw== Message-ID: <4D74C296.70204@paradisegreen.co.uk> Date: Mon, 07 Mar 2011 11:33:42 +0000 From: Thomas Sandford User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dave Johnson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VERIFIED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on almaz.paradisegreen.co.uk Cc: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Kernel Update / IPFW not working 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: Mon, 07 Mar 2011 12:12:27 -0000 On 06/03/2011 14:23, Dave Johnson wrote: > An IPFW problem when going from release to stable on 8.2 > > An help gladly accepted > > LOG ON > > Flushed all rules. > 00010 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > 00030 divert 8668 ip from any to any via bge0 > ipfw: getsockopt(IP_FW_ADD): Invalid argument > 50000 allow ip from any to any > Firewall rules loaded. > Starting natd. > > rc.conf > defaultrouter="192.168.0.1" > gateway_enable="YES" > hostname="xxx.xxx.xxx" > ifconfig_bge0="inet 192.168.0.11 netmask 255.255.255.0" > ifconfig_em0="inet 192.168.1.2 netmask 255.255.255.0" > keymap="us.iso" > moused_enable="YES" > sshd_enable="YES" > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > natd_program="/sbin/natd" > natd_enable="YES" > natd_interface="bge0" > natd_flags="-f /etc/natd.conf" > dhcpd_enable="NO" > dhcpd_flags="-q" > dhcpd_conf="/usr/local/etc/dhcpd.conf" > dhcpd_ifaces="em0" > dhcpd_withumask="022" > > ... [additional config which doesn't further isolate the problem snipped] ... It's a bug with the ipfw / natd startup scripts. See: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/148137 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/148928 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/153155 The latter has a patch to fix the problem. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 12:26:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB4F106566B for ; Mon, 7 Mar 2011 12:26:08 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 53A6D8FC17 for ; Mon, 7 Mar 2011 12:26:07 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id p27CQ6uE062520 for ; Mon, 7 Mar 2011 13:26:06 +0100 (CET) Received: from [217.29.45.147] ([217.29.45.147]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p27CQ6wj079879 for ; Mon, 7 Mar 2011 13:26:06 +0100 (CET) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 13:26:01 +0100 Message-Id: To: freebsd-stable Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Disable probing of bge1? 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: Mon, 07 Mar 2011 12:26:08 -0000 Hi, all, I just discovered a minor problem when updating some rather dated systems from FreeBSD 6.x to 7.x or 8.x. The servers are Fujitsu Technology Solutions (former Fujitsu-Siemens) RX100 S4. The current generation of the same system is RX100 S6, so this is two generations old. Some of them still run fine in our datacenter, = though. While the S5 and S6 series features two gigabit ports and an additional network interface for out of band management (called iRMC, similar to = HP's iLO), the S4 has only two gigabit ports and the iRMC interface is piggybacked = to one of them. In our standard setup we disable the first interface in the BIOS. If you = do this, the physical port is available as a dedicated management interface to = the iRMC and only the second IF is probed by FreeBSD 6.x as bge0. Now I try to PXE boot an identically configured system via the remote = serial console with FreeBSD 7. Everything runs fine, until the kernel probes = the network interfaces. The last thing I see are messages about successful probing of both bge0 and bge1 and then my remote management connection and my console are gone. I have to reset the BMC by literally pulling the power to get the iRMC = back. Is it possible to use some device.hints entry to prohibit the probing of = bge1? I think that would be the easiest solution to the problem? Other = suggestions are of course welcome. I can provide more config details and dmesg = output if needed. Thanks, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 12:37:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18D9106566B for ; Mon, 7 Mar 2011 12:37:52 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5B48FC1C for ; Mon, 7 Mar 2011 12:37:52 +0000 (UTC) Received: by qyk35 with SMTP id 35so1772083qyk.13 for ; Mon, 07 Mar 2011 04:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fxd+w6F68BAKqBM+WqM8EgoCUqFTA2qse44BKvbylTM=; b=G/ai2c59A53281YINVaCGpnkNNYygZnyisMvBtmza6K4HaTZoBD3S9BeSXb6k+qTzS 8plmMowWuasR3mn5X1hc5nzb9NzOuU7VH+fnoWcZVMnL85TyIk2LSJ7PttrhNOldPFAs Upz55Prh+EF6YQGA9Cu4Sv9cllTqwT1yw2+hU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DVJshKhcHuqAvsuzGzmplv0pHB2S784rnH85kgWkWG2sgBG9Tk+RjSaoVxXWxOVSiu q42n02p7jbok1OYnNjDdp75jSrGpYV71wR1LtWLHSvHtjWTPyzCmsYwfYohQBQKFbT91 ilndzeVIks0t8R0hCEr5P33c4bgF5L/qVwebQ= MIME-Version: 1.0 Received: by 10.229.96.200 with SMTP id i8mr2734159qcn.226.1299501471629; Mon, 07 Mar 2011 04:37:51 -0800 (PST) Received: by 10.229.79.139 with HTTP; Mon, 7 Mar 2011 04:37:51 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Mar 2011 12:37:51 +0000 Message-ID: From: Tom Evans To: "Patrick M. Hausen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Disable probing of bge1? 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: Mon, 07 Mar 2011 12:37:53 -0000 On Mon, Mar 7, 2011 at 12:26 PM, Patrick M. Hausen wrote: > Hi, all, > > I just discovered a minor problem when updating some rather dated > systems from FreeBSD 6.x to 7.x or 8.x. > > The servers are Fujitsu Technology Solutions (former Fujitsu-Siemens) > RX100 S4. The current generation of the same system is RX100 S6, so this > is two generations old. Some of them still run fine in our datacenter, th= ough. > > While the S5 and S6 series features two gigabit ports and an additional > network interface for out of band management (called iRMC, similar to HP'= s iLO), > the S4 has only two gigabit ports and the iRMC interface is piggybacked t= o > one of them. > > In our standard setup we disable the first interface in the BIOS. If you = do this, > the physical port is available as a dedicated management interface to the= iRMC > and only the second IF is probed by FreeBSD 6.x as bge0. > > Now I try to PXE boot an identically configured system via the remote ser= ial > console with FreeBSD 7. Everything runs fine, until the kernel probes the > network interfaces. The last thing I see are messages about successful > probing of both bge0 and bge1 and then my remote management connection > and my console are gone. > > I have to reset the BMC by literally pulling the power to get the iRMC ba= ck. > > Is it possible to use some device.hints entry to prohibit the probing of = bge1? > I think that would be the easiest solution to the problem? Other suggesti= ons > are of course welcome. I can provide more config details and dmesg output > if needed. > > Thanks, > Patrick Maybe this loader tunable will help: hw.bge.allow_asf Allow the ASF feature for cooperating with IPMI. Can cause sys=E2= =80=90 tem lockup problems on a small number of systems. Disabled by default. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 13:33:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FA79106564A for ; Mon, 7 Mar 2011 13:33:22 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4928FC0A for ; Mon, 7 Mar 2011 13:33:22 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PwaYl-000Ot5-7x for freebsd-stable@freebsd.org; Mon, 07 Mar 2011 13:33:15 +0000 Date: Mon, 07 Mar 2011 22:33:14 +0900 Message-ID: From: Randy Bush To: FreeBSD Stable User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: 7.2 to RELENG_8 boot lockup 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: Mon, 07 Mar 2011 13:33:22 -0000 18 month old 7.2 FreeBSD dfw1.psg.com 7.2-STABLE FreeBSD 7.2-STABLE #1: Sat Aug 22 08:37:36 UTC 2009 root@dfw1.psg.com:/usr/obj/usr/src/sys/DFW1 amd64 csup and o make buildworld o make kernel o boot single user o locks up right after beastie, one twirly and locked boot verbose is reticent reset, boot to old kernel, all normal how to debug? randy From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 13:36:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FFA3106566B for ; Mon, 7 Mar 2011 13:36:45 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B2D648FC0A for ; Mon, 7 Mar 2011 13:36:44 +0000 (UTC) Received: by wyb32 with SMTP id 32so4776459wyb.13 for ; Mon, 07 Mar 2011 05:36:43 -0800 (PST) Received: by 10.227.169.140 with SMTP id z12mr3488918wby.89.1299505002115; Mon, 07 Mar 2011 05:36:42 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id u9sm2146574wbg.12.2011.03.07.05.36.40 (version=SSLv3 cipher=OTHER); Mon, 07 Mar 2011 05:36:41 -0800 (PST) Message-ID: <4D74DF67.4080209@my.gd> Date: Mon, 07 Mar 2011 14:36:39 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: 7.2 to RELENG_8 boot lockup 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: Mon, 07 Mar 2011 13:36:45 -0000 On 3/7/11 2:33 PM, Randy Bush wrote: > 18 month old 7.2 > > FreeBSD dfw1.psg.com 7.2-STABLE FreeBSD 7.2-STABLE #1: Sat Aug 22 08:37:36 UTC 2009 root@dfw1.psg.com:/usr/obj/usr/src/sys/DFW1 amd64 > > csup and > o make buildworld > o make kernel > o boot single user > o locks up right after beastie, one twirly and locked > > boot verbose is reticent > > reset, boot to old kernel, all normal > > how to debug? > > randy I would advise you build a *generic* 8.x kernel, as opposed to the custom one you seem to be using, first thing. I would also recommend you see and try if you can sell domain name psg.com to the french Paris Saint Germain football club for a couple million euros. -- dam From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 13:42:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EAE5106564A for ; Mon, 7 Mar 2011 13:42:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC818FC18 for ; Mon, 7 Mar 2011 13:42:53 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b465:c134:204f:fc84] ([IPv6:2607:f3e0:0:4:b465:c134:204f:fc84]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p27DgoFc049023 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 Mar 2011 08:42:51 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D74E0D4.8050103@sentex.net> Date: Mon, 07 Mar 2011 08:42:44 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: FreeBSD Stable Subject: Re: 7.2 to RELENG_8 boot lockup 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: Mon, 07 Mar 2011 13:42:53 -0000 On 3/7/2011 8:33 AM, Randy Bush wrote: > o locks up right after beastie, one twirly and locked On my hardware when that happens its due to USB legacy being enabled in the BIOS. Try disabling that ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 13:49:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95875106566C for ; Mon, 7 Mar 2011 13:49:17 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by mx1.freebsd.org (Postfix) with ESMTP id 78F0B8FC16 for ; Mon, 7 Mar 2011 13:49:17 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PwaoE-000OwM-Rr; Mon, 07 Mar 2011 13:49:15 +0000 Date: Mon, 07 Mar 2011 22:49:13 +0900 Message-ID: From: Randy Bush To: Damien Fleuriot In-Reply-To: <4D74DF67.4080209@my.gd> References: <4D74DF67.4080209@my.gd> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 to RELENG_8 boot lockup 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: Mon, 07 Mar 2011 13:49:17 -0000 > I would advise you build a *generic* 8.x kernel, as opposed to the > custom one you seem to be using, first thing. true. lemme try one thing mt recommended first. > I would also recommend you see and try if you can sell domain name > psg.com to the french Paris Saint Germain football club for a couple > million euros. occasionally i get phony attempts to buy from folk who think i do not know european football. the club has never contacted me, but for a couple of million euros, i would talk. randy From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 14:30:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FB71106564A; Mon, 7 Mar 2011 14:30:28 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id E0D978FC12; Mon, 7 Mar 2011 14:30:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p27E06DL071408; Tue, 8 Mar 2011 01:00:06 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 8 Mar 2011 01:00:05 +1100 (EST) From: Ian Smith To: Thomas Sandford In-Reply-To: <4D74C296.70204@paradisegreen.co.uk> Message-ID: <20110308001102.W68517@sola.nimnet.asn.au> References: <4D74C296.70204@paradisegreen.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org, Dave Johnson Subject: Re: Kernel Update / IPFW not working 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: Mon, 07 Mar 2011 14:30:28 -0000 On Mon, 7 Mar 2011, Thomas Sandford wrote: > On 06/03/2011 14:23, Dave Johnson wrote: > > An IPFW problem when going from release to stable on 8.2 > > > > An help gladly accepted > > > > LOG ON > > > > Flushed all rules. > > 00010 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > > 00030 divert 8668 ip from any to any via bge0 > > ipfw: getsockopt(IP_FW_ADD): Invalid argument > > 50000 allow ip from any to any > > Firewall rules loaded. > > Starting natd. > > > > rc.conf > > defaultrouter="192.168.0.1" > > gateway_enable="YES" > > hostname="xxx.xxx.xxx" > > ifconfig_bge0="inet 192.168.0.11 netmask 255.255.255.0" > > ifconfig_em0="inet 192.168.1.2 netmask 255.255.255.0" > > keymap="us.iso" > > moused_enable="YES" > > sshd_enable="YES" > > firewall_enable="YES" > > firewall_script="/etc/rc.firewall" > > natd_program="/sbin/natd" > > natd_enable="YES" > > natd_interface="bge0" > > natd_flags="-f /etc/natd.conf" > > dhcpd_enable="NO" > > dhcpd_flags="-q" > > dhcpd_conf="/usr/local/etc/dhcpd.conf" > > dhcpd_ifaces="em0" > > dhcpd_withumask="022" > > > > ... [additional config which doesn't further isolate the problem snipped] > > ... Beg to differ. 'ipfw fwd' still requires building a custom kernel with options IPFIREWALL_FORWARD last I heard. Julian's explained a few times that it's not compiled in by default for performance reasons, and can't be isolated to modules as it adds code in multiple parts of the stack. > It's a bug with the ipfw / natd startup scripts. > > See: > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/148137 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/148928 > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/153155 > > The latter has a patch to fix the problem. It's a similar but not quite the same issue, albeit the same message. Quoting your conf/153155: : /etc/rc.d/ipfw fails to load the ipdivert module when natd is enabled. : : This causes the divert rules that /etc/rc.firewall adds in this case to : fail on system boot, with the following error message displayed during : ipfw rule load: : ipfw: getsockopt(IP_FW_ADD): Invalid argument : : Restarting ipfw works around the problem as /etc/rc.d/natd (which is run : _after_ ipfw is intialised) DOES load ipdivert. And requoting Dave's: : > KERNEL : > : > options IPFIREWALL : > options IPFIREWALL_VERBOSE : > options IPFIREWALL_VERBOSE_LIMIT=5 : > options IPFIREWALL_DEFAULT_TO_ACCEPT : > options IPDIVERT : > options DUMMYNET In this case ipfw was built into kernel, including IPDIVERT, so it's not a failure to load that module but lack of IPFIREWALL_FORWARD, I believe. Hopefully hrs@ is still looking into patches including yours and mine re /etc/rc.d script module loading order and natd vs kernel nat issues .. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 16:40:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 157FD106564A for ; Mon, 7 Mar 2011 16:40:57 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 990678FC08 for ; Mon, 7 Mar 2011 16:40:56 +0000 (UTC) Received: by wyb32 with SMTP id 32so5004301wyb.13 for ; Mon, 07 Mar 2011 08:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XFuABydHmqgzaoJtsMo8shq2HvTczKpXgfnc8qLZ/2w=; b=QPW9P6cU45As/c5RdkvELMQEvq17F8nnSJdF5MciOycACG1XPOEqhCRtKpsIvkIjYP fL97ZTbh2vCo8rRpz8TBLsDvW5LBq+gRpjf3A325t1C48iJMT1ZQz/RtTTfNiaYO5Zkz fEwk4tZnpxmQkuQu38Nf7H3pRt9X+KzZRK8t8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rb7msRV+KPvhXGRpXA8UakBYHtw+RHx+YcZIApti4igijmPre8exm2ph7fM86k2RzO yMc25usUxf3EncuOiKsxhybX5F8i0+tmOTpxTw4xBClHVDcbk5AazUZxNi+B/O7FVF9T dKD5q5jarSeSskSEbGQ7DOvVN05R5EM3MPZF4= MIME-Version: 1.0 Received: by 10.227.198.206 with SMTP id ep14mr2312519wbb.174.1299516055351; Mon, 07 Mar 2011 08:40:55 -0800 (PST) Received: by 10.227.143.21 with HTTP; Mon, 7 Mar 2011 08:40:54 -0800 (PST) In-Reply-To: <20110306180859.GA18399@lava.net> References: <20110305150436.GA2175@fbsd.t60.cpu> <20110305154817.GQ30336@core.byshenk.net> <4D72A069.90104@FreeBSD.org> <20110306010015.GC4160@fbsd.t60.cpu> <20110306011433.GA21857@fbsd.t60.cpu> <20110306020917.GA90894@fbsd.t60.cpu> <20110306140628.GS30336@core.byshenk.net> <20110306180859.GA18399@lava.net> Date: Mon, 7 Mar 2011 18:40:54 +0200 Message-ID: From: Marin Atanasov Nikolov To: Greg Byshenk , Yue Wu , ml-freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Clifton Royston Subject: Re: Question about packages installed via `pkg_add -r` 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: Mon, 07 Mar 2011 16:40:57 -0000 On Sun, Mar 6, 2011 at 8:08 PM, Clifton Royston wrote: > On Sun, Mar 06, 2011 at 03:06:28PM +0100, Greg Byshenk wrote: >> On Sun, Mar 06, 2011 at 10:09:17AM +0800, Yue Wu wrote: >> > ports with portmaster makes pkg installation mangement be much more >> > flexiable and more friendly than package by pkg_add -r on FreeBSD, >> > except that ports take much more time and resource. After trying with >> > packages, I think I have to stick to ports. >> >> As suggested by some of the other comments, you can choose to use >> portmaster with packages, if you prefer not to do local builds. >> >> In my own case, I use ports and packages, via portmaster. That is, >> I use one machine to build locally-configured packages (in some >> cases with non-standard options), and then install them on the rest >> of the machines as packages. It works very well in my environment. > > =A0I second this approach if you are managing more than one machine. > Once I got this approach working, we used to do this when I was working > on a spam filtering solution, and also at my ISP. =A0It greatly > simplifies and reduces the time spent managing a multi-machine > environment; it works even better when you're handling steps like > deploying from a test environment into a production environment. =A0You > can even go a step further to define and create your own packages > containing sets of configuration files you want to deploy in > conjunction with the binaries. > I would go even further improving that setup and make a fully automated environment using something like this: [ VCS ] ---> [ Cfengine 2/3 Server ] / | \ / | \ / | \ [ System 1 ] [ System 2 ] [ System N ] Somewhere in the above picture we have as well Tinderbox'es building our packages and uploading them to a local FTP server. When you need to upgrade a package on multiple (or even all) systems/jails, you just update the Cfengine 2/3 configuration and that's all. This would greatly reduce the time and effort to keep your systems updated. Regards, Marin > =A0-- Clifton > > -- > =A0 =A0Clifton Royston =A0-- =A0cliftonr@iandicomputing.com / cliftonr@la= va.net > =A0 =A0 =A0 President =A0- I and I Computing * http://www.iandicomputing.= com/ > =A0Custom programming, network design, systems and network consulting ser= vices > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 08:29:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 115F11065670 for ; Tue, 8 Mar 2011 08:29:58 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C66068FC0C for ; Tue, 8 Mar 2011 08:29:57 +0000 (UTC) Received: by iyj12 with SMTP id 12so5450890iyj.13 for ; Tue, 08 Mar 2011 00:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=4fmWiPf0k/xj3mNzFL1D3014Y9Ch0oN3kMHcqdiSYqE=; b=ilneVwQdzH2N9pHe++r1aV7hEBVoUBFrU2YWv0dsjTp2gVamZ/ynALCtQrz3QsizFz 0f46LYTjruIirI2cuGKbcv75qHCK0f+nJ3mZbpsFztTlnBF1cfNfOxKq4fYJgkvJe0Oh S5RwNOQ8BX+DWg1dQXy01LZUgVbh+d5QXAem0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; b=YfoiDTjdQ768jLfSBbDXypDQ1DLD2WeUUw3OCY59ui/X/52O68vWm3pD+duiZ45VaU P3xiXjSDi54m3M3sfmYIFbYUmIVnJe0zbh3ZjUOnLg/Ao52MXOLdWzBVahJSSZxNbfeV ExXu+Vc4wc9JRMvnm7UtD0HVJAvrEl9LVXcAQ= Received: by 10.43.55.81 with SMTP id vx17mr4108115icb.52.1299572996933; Tue, 08 Mar 2011 00:29:56 -0800 (PST) Received: from disbatch.dataix.local (adsl-99-181-148-141.dsl.klmzmi.sbcglobal.net [99.181.148.141]) by mx.google.com with ESMTPS id d21sm433737ibg.9.2011.03.08.00.29.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 00:29:55 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 8 Mar 2011 03:29:46 -0500 From: "J. Hellenthal" To: FreeBSD Stable Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' 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: Tue, 08 Mar 2011 08:29:58 -0000 Hello Stable@, Compiling a kernel on stable/8 with DTrace support is failing with the above subject line upon linking kernel.debug. The text leading up to this is: ... ctfconvert -L VERSION -g vers.o linking kernel.debug clock.o(.text+0x84c): In function `clkintr': /usr/src/sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' And upon inspection of clock.c: #ifdef KDTRACE_HOOKS #include #endif And in clkintr(): #ifdef KDTRACE_HOOKS /* * If the DTrace hooks are configured and a callback function * has been registered, then call it to process the high speed * timers. */ int cpu = PCPU_GET(cpuid); if (cyclic_clock_func[cpu] != NULL) (*cyclic_clock_func[cpu])(frame); #endif It seems for some odd reason that is being forgotten when it comes time for linking ? What is going on here ? Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build to finish but in the case that I want to build another kernel without dtrace I would have to add them back. Anyone have a better fitting solution to this ? Would it be just as good to re-ifdef this to ?WITH_CTF? instead. Anyway... this is latest code from stable/8 on i386. And yes options KDTRACE_HOOKS is in the kernel config. And the command that caused all this: ( make kernel WITH_CTF=1 ) -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 09:19:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E91E31065673 for ; Tue, 8 Mar 2011 09:19:35 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A16D88FC1B for ; Tue, 8 Mar 2011 09:19:35 +0000 (UTC) Received: by iyj12 with SMTP id 12so5483473iyj.13 for ; Tue, 08 Mar 2011 01:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=Vo0VxuDXepakY4zkzJcXNk3GpwCy6RYAugBOERqwfBc=; b=fRmytyLL9x5+us8pyLIPWsID//XG06FC07uXFAq5GpHg9XfZDhDeVVGFjBSHGTD1Kn F9B1EBpn5cvA7cJHAlKfuag7BZrePS7uNnNOxS3keIFHoKsXc7M6tqB4iBa3eeAJnRpV cGDj6fFbjvkxF5jrah7+9sTXC4zGdVSxKMeRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=w1n++Gfmd4TqsdgWHWldgU2A+ptz5etWiwnOFIzKtONGku1bMOjHmrllphN5lTu3Gz zTNxWd6FDTOOAFRr2PMfZes7YWnkmUY95aXO0YLNaCLmBJ9dPis8KuWdl79d3T9UQfpx 0m8C5fol6YgoGbLzH6RANEYKJxTUz9Y9dZspY= Received: by 10.43.65.134 with SMTP id xm6mr6093002icb.313.1299575974970; Tue, 08 Mar 2011 01:19:34 -0800 (PST) Received: from disbatch.dataix.local (adsl-99-181-148-141.dsl.klmzmi.sbcglobal.net [99.181.148.141]) by mx.google.com with ESMTPS id d10sm476242ibb.0.2011.03.08.01.19.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 01:19:33 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 8 Mar 2011 04:18:41 -0500 From: "J. Hellenthal" To: FreeBSD Stable In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="80310268-219105719-1299575973=:58425" Subject: Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' 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: Tue, 08 Mar 2011 09:19:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --80310268-219105719-1299575973=:58425 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 8 Mar 2011 03:29, jhell@ wrote: > > Hello Stable@, > > Compiling a kernel on stable/8 with DTrace support is failing with the above > subject line upon linking kernel.debug. > > The text leading up to this is: > ... > ctfconvert -L VERSION -g vers.o > linking kernel.debug > clock.o(.text+0x84c): In function `clkintr': > /usr/src/sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' > > And upon inspection of clock.c: > #ifdef KDTRACE_HOOKS > #include > #endif > > And in clkintr(): > #ifdef KDTRACE_HOOKS > /* > * If the DTrace hooks are configured and a callback function > * has been registered, then call it to process the high speed > * timers. > */ > int cpu = PCPU_GET(cpuid); > if (cyclic_clock_func[cpu] != NULL) > (*cyclic_clock_func[cpu])(frame); > #endif > > > It seems for some odd reason that is being forgotten when > it comes time for linking ? What is going on here ? > > Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build to > finish but in the case that I want to build another kernel without dtrace I > would have to add them back. Anyone have a better fitting solution to this ? > > Would it be just as good to re-ifdef this to ?WITH_CTF? instead. > > Anyway... this is latest code from stable/8 on i386. And yes options > KDTRACE_HOOKS is in the kernel config. > > And the command that caused all this: > ( make kernel WITH_CTF=1 ) > In light of this I decided to just remove the effected section of clock.c and move forward as this part of the kernel with DTrace is not what I am looking into. Attached is a small patch that removes it in case someone else comes across the same thing and needs a quick workaround. - -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN -----BEGIN PGP SIGNATURE----- Comment: THIS SOFTWARE AND/OR CONTENTS IS PROVIDED BY THE AUTHOR ``AS IS'' AND Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR Comment: PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY Comment: DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, Comment: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING Comment: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE Comment: POSSIBILITY OF SUCH DAMAGE. iQEcBAEBAgAGBQJNdfSCAAoJEJBXh4mJ2FR+K18H/A1KD0Ki1GR696dCvn2iJByH ym2nrsREjdVzFS2P7tW5PO0fmIc8eiFvqimeKHjexDS9JUH+3ybJ2ccF8JqHrR50 G/lNluptzLibPsqQY3+l/EsOUe//8NZUrUYV0ymOGfMsO5v49fBIfSKAT3JBFmY7 nq8wXMP5ncP8cjGdT6abSryIHmXVxY+E2R2DUOyfmbwZ+J/8fjfNEqxZta+Vc2Bv N2BJlEW1eJQBHrq2YuEM3iMBGqRkYywaG7hAWnJXXGUf+/8A/B3SgE1zLBlyCbfB osUjJE/AA7TtBawG6b5V10GCBSMxLaFdhaEzzyd4MtrRPnhuFWsjnPi4ACqnrhc= =3a8e -----END PGP SIGNATURE----- --80310268-219105719-1299575973=:58425 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=clock-dtrace-removal.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=clock-dtrace-removal.patch Y2hhbmdlc2V0OiAgIDk0Nzo2ZGM4ZGU3Yjk3MzUNCmJyYW5jaDogICAgICBE YXRhSVgNCnRhZzogICAgICAgICB0aXANCnVzZXI6ICAgICAgICBKLiBIZWxs ZW50aGFsIDxqaGVsbEBEYXRhSVgubmV0Pg0KZGF0ZTogICAgICAgIFR1ZSBN YXIgMDggMDM6NTY6MzQgMjAxMSAtMDUwMA0Kc3VtbWFyeTogICAgIGNsa2lu dHIgcmVtb3ZhbCBvZiBjeWNsaWNfY2xvY2tfZnVuYyBLRFRSQUNFX0hPT0tT DQoNCmRpZmYgLXIgYjhmNzM5MmRlYWY2IC1yIDZkYzhkZTdiOTczNSBzeXMv eDg2L2lzYS9jbG9jay5jDQotLS0gYS9zeXMveDg2L2lzYS9jbG9jay5jCU1v biBNYXIgMDcgMTM6MDY6NTAgMjAxMSAtMDUwMA0KKysrIGIvc3lzL3g4Ni9p c2EvY2xvY2suYwlUdWUgTWFyIDA4IDAzOjU2OjM0IDIwMTEgLTA1MDANCkBA IC0xNzksMTcgKzE3OSw2IEBADQogCUtBU1NFUlQodXNpbmdfbGFwaWNfdGlt ZXIgPT0gTEFQSUNfQ0xPQ0tfTk9ORSwNCiAJICAgICgiY2xrIGludGVycnVw dCBlbmFibGVkIHdpdGggbGFwaWMgdGltZXIiKSk7DQogDQotI2lmZGVmIEtE VFJBQ0VfSE9PS1MNCi0JLyoNCi0JICogSWYgdGhlIERUcmFjZSBob29rcyBh cmUgY29uZmlndXJlZCBhbmQgYSBjYWxsYmFjayBmdW5jdGlvbg0KLQkgKiBo YXMgYmVlbiByZWdpc3RlcmVkLCB0aGVuIGNhbGwgaXQgdG8gcHJvY2VzcyB0 aGUgaGlnaCBzcGVlZA0KLQkgKiB0aW1lcnMuDQotCSAqLw0KLQlpbnQgY3B1 ID0gUENQVV9HRVQoY3B1aWQpOw0KLQlpZiAoY3ljbGljX2Nsb2NrX2Z1bmNb Y3B1XSAhPSBOVUxMKQ0KLQkJKCpjeWNsaWNfY2xvY2tfZnVuY1tjcHVdKShm cmFtZSk7DQotI2VuZGlmDQotDQogCWlmICh1c2luZ19hdHJ0Y190aW1lcikg ew0KICNpZmRlZiBTTVANCiAJCWlmIChzbXBfc3RhcnRlZCkNCg0K --80310268-219105719-1299575973=:58425-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 10:54:33 2011 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 30B5E106564A for ; Tue, 8 Mar 2011 10:54:33 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id BC0EC8FC16 for ; Tue, 8 Mar 2011 10:54:32 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 2972F153434 for ; Tue, 8 Mar 2011 11:54:31 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E5nrIT8yT0J for ; Tue, 8 Mar 2011 11:54:29 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:1c1d:9f4:7c9:d3b7] (unknown [IPv6:2001:4cb8:3:1:1c1d:9f4:7c9:d3b7]) by mail.digiware.nl (Postfix) with ESMTP id 12DBB153433 for ; Tue, 8 Mar 2011 11:54:29 +0100 (CET) Message-ID: <4D760AEC.7050604@digiware.nl> Date: Tue, 08 Mar 2011 11:54:36 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic on vm_page_cache_transfer: object 0xfffffff0035508000's type is not compatible with cache pages 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: Tue, 08 Mar 2011 10:54:33 -0000 System: FreeBSD zfs.digiware.nl 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Feb 26 06:28:43 CET 2011 root@zfs.digiware.nl:/usr/obj/usr/src/src8/src/sys/ZFS amd64 Don't have a serial console, so I wrote down the traceback. But my guess is that that is not enough, however I needed the system so I rebooted. tb: vm_object_split at .... +0x125 vm_space_fork at .... +0x3f7 fork1 at .... +0x6a9 fork at .... +0xee syscall_entr at .... +1c syscall at .... +4c rip = 0x8006bc39c rsp = 0x7fffffffe9d8 rbp = 0x800a04470 It looks a lot like what I find on http://people.freebsd.org/~pho/stress/log/kostik079.html But my system is amd64, with 8Gb RAM and is fully ZFS based with swap on 2 gpt freebsd-swap partitions. System crashed last night around 1:30, which is when a few large rsync backups are coming in. Would I be able to call doadump to obtain something usefull afterward (provided I have savecore set?) --WjW From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 11:26:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46544106564A for ; Tue, 8 Mar 2011 11:26:57 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7878FC0C for ; Tue, 8 Mar 2011 11:26:56 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id p28BQtiQ077414 for ; Tue, 8 Mar 2011 12:26:55 +0100 (CET) Received: from [217.29.45.147] ([217.29.45.147]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p28BQtr2022645 for ; Tue, 8 Mar 2011 12:26:55 +0100 (CET) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 12:26:49 +0100 Message-Id: To: freebsd-stable Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: ZFS performance as the FS fills up? 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: Tue, 08 Mar 2011 11:26:57 -0000 Hi, all, we use a big JBOD and ZFS with raidz2 as the target for our nightly Amanda backups. I already suspected that the fact that the FS was > 90% full might be the cause of our backup performance continously decreasing. I just added another vdev - 6 disks of 750 GB each, raidz2 and the FS usage is back to 71% currently. This was while backups were running and write performance instantly skyrocketed compared to the values before. So, is it possible to name a reasonable amount of free space to keep on a raidz2 volume? On last year's EuroBSDCon I got the impression that with recent (RELENG_8) ZFS merges I could get away with using around 90%. Thanks, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 11:48:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFF341065672 for ; Tue, 8 Mar 2011 11:48:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id D79FE8FC1D for ; Tue, 8 Mar 2011 11:48:12 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta06.emeryville.ca.mail.comcast.net with comcast id Gbno1g0030lTkoCA6boCHj; Tue, 08 Mar 2011 11:48:12 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta04.emeryville.ca.mail.comcast.net with comcast id GboB1g0060PUQVN8QboBGJ; Tue, 08 Mar 2011 11:48:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 61A849B422; Tue, 8 Mar 2011 03:48:10 -0800 (PST) Date: Tue, 8 Mar 2011 03:48:10 -0800 From: Jeremy Chadwick To: "Patrick M. Hausen" Message-ID: <20110308114810.GA37554@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable Subject: Re: ZFS performance as the FS fills up? 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: Tue, 08 Mar 2011 11:48:13 -0000 On Tue, Mar 08, 2011 at 12:26:49PM +0100, Patrick M. Hausen wrote: > we use a big JBOD and ZFS with raidz2 as the target > for our nightly Amanda backups. > > I already suspected that the fact that the FS was > 90% full might > be the cause of our backup performance continously decreasing. > > I just added another vdev - 6 disks of 750 GB each, raidz2 and the > FS usage is back to 71% currently. This was while backups were > running and write performance instantly skyrocketed compared to > the values before. > > So, is it possible to name a reasonable amount of free space to > keep on a raidz2 volume? On last year's EuroBSDCon I got > the impression that with recent (RELENG_8) ZFS merges > I could get away with using around 90%. I'm in no way attempting to dissuade you from your efforts to figure out a good number for utilisation, but when I hear of disks -- no matter how many -- being 90% full, I immediately conclude performance is going to suck simply because the outer "tracks" on a disk contains more sectors than the inner "tracks". This is the reason for performance degradation as the seek offset increases, resulting in graphs like this: http://img171.imageshack.us/img171/4776/1tb2.png Given this info, it shouldn't come as too much of a surprise that adding another vdev (effectively adding more disks to the pool) greatly helps in relieving this issue. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 14:29:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DACFA1065679 for ; Tue, 8 Mar 2011 14:29:53 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id B41A48FC16 for ; Tue, 8 Mar 2011 14:29:53 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1Pwxv6-0004Xh-TU for freebsd-stable@freebsd.org; Tue, 08 Mar 2011 06:29:52 -0800 Message-ID: <31097583.post@talk.nabble.com> Date: Tue, 8 Mar 2011 06:29:52 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4D150C56.4080801@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> <4CE0010D.7080505@FreeBSD.org> <4D150C56.4080801@FreeBSD.org> Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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: Tue, 08 Mar 2011 14:29:53 -0000 Hello. Just ensuring that this issue would not be forgotten, If I recall correctly, without added patches one cannot burn CD with cdrtools, quite a problem for media burning suite ;) best regards, - Jakub Lach -- View this message in context: http://old.nabble.com/Sense-fetching--Was%3A-cdrtools--devel-...--tp30144095p31097583.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 15:15:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1BE1065675; Tue, 8 Mar 2011 15:15:38 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1602E8FC0A; Tue, 8 Mar 2011 15:15:37 +0000 (UTC) Received: by wwc33 with SMTP id 33so1230943wwc.31 for ; Tue, 08 Mar 2011 07:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sCLCvtb86WF/1o6lbdDHV1mRbivl36uLIHmrt4BA4yY=; b=nq362rtbn3pgNk7OcrOX+SzVuCaEo29lF+MtMrZzvqlsr7C9vYqQ11obnxW6K9XlrR nTX/AYGoewhaQcfIaNgZaOmSwB7apYGCdxzl1tX0XnBRpmMVna8gMe1AXBY5kti7lnVN PalfejWe/u5RoA1ORbwDG7mATe6gcDQ7WBD9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fqodjfNMDAJ8/FiMB/W2N9VbV/HgM0StKt68arlz3C+n3tgcVlR/4LmzwaHhrd9Yzx 2rwOkPw+pflfGnkzrHw573HxX+2YjtkGGtR6g4NW81MyV1Osfyrm8bJoPk3LEaQtQnxj RIDonCVX6YleYkwyUbULMzAQfOLgO+Sn3JHYc= MIME-Version: 1.0 Received: by 10.216.213.29 with SMTP id z29mr4553546weo.19.1299597336865; Tue, 08 Mar 2011 07:15:36 -0800 (PST) Received: by 10.216.73.78 with HTTP; Tue, 8 Mar 2011 07:15:36 -0800 (PST) In-Reply-To: <31097583.post@talk.nabble.com> References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> <4CE0010D.7080505@FreeBSD.org> <4D150C56.4080801@FreeBSD.org> <31097583.post@talk.nabble.com> Date: Tue, 8 Mar 2011 09:15:36 -0600 Message-ID: From: Brandon Gooch To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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: Tue, 08 Mar 2011 15:15:38 -0000 On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach wrote: > > Hello. > > Just ensuring that this issue would not be forgotten, > If I recall correctly, without added patches one > cannot burn CD with cdrtools, quite a problem > for media burning suite ;) > > best regards, > - Jakub Lach mav@ is working on graid(4), a replacement for ataraid(4) using the GEOM framework. This effort has taken precedence over a few outstanding patches he was working on, but he will eventually come back to it :) Perhaps another developer will step up and continue the work on the patches: http://people.freebsd.org/~mav/sense/ -Brandon From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 15:19:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B501065670 for ; Tue, 8 Mar 2011 15:19:53 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 173138FC17 for ; Tue, 8 Mar 2011 15:19:52 +0000 (UTC) Received: by iwn33 with SMTP id 33so5772012iwn.13 for ; Tue, 08 Mar 2011 07:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=3sk4oGxXF0MFgHC8YtXR3NRNS8BL18eQQV5o8jXyqqQ=; b=bVSxy89zC+GvULRBxvet9NvY20JyfmGT/P0q96HXR0VN/iFijKuIKBQQ6ieb12Qw0w 8GQ+KLC0G3uZp2iJi9xV8jKcavNMVu2fCYbDzsXGcQtOqTmBM9bg/XXmyyhLlia4jlbl ZGF5r7mneUl/jGdHuRTvqLfnSBd51Vz4Mnuwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=wPNwFpkojvboceNV9tcR8tMWr+qa+Vu7MGMANHUc7hlMsziN8EB/t3BK5ZWpZNKebC vYjFtKQitXF1iZwP2by26qmFL2qaw6T+cKf4Fy8vMIk7oTy4Z2RzyqkpNVDtMWlA3ChA y25Iv5HEh16bceAbKrSYLxXTqCn9+QtIWePuA= Received: by 10.42.151.195 with SMTP id f3mr6384383icw.472.1299597592495; Tue, 08 Mar 2011 07:19:52 -0800 (PST) Received: from disbatch.dataix.local (adsl-99-181-148-141.dsl.klmzmi.sbcglobal.net [99.181.148.141]) by mx.google.com with ESMTPS id wt14sm640575icb.16.2011.03.08.07.19.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 07:19:50 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 8 Mar 2011 10:19:30 -0500 From: "J. Hellenthal" To: FreeBSD Stable In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="80310268-209080405-1299597590=:40738" Subject: Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' 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: Tue, 08 Mar 2011 15:19:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --80310268-209080405-1299597590=:40738 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 8 Mar 2011 04:18, jhell@ wrote: > On Tue, 8 Mar 2011 03:29, jhell@ wrote: >> >> Hello Stable@, >> >> Compiling a kernel on stable/8 with DTrace support is failing with the >> above >> subject line upon linking kernel.debug. >> >> The text leading up to this is: >> ... >> ctfconvert -L VERSION -g vers.o >> linking kernel.debug >> clock.o(.text+0x84c): In function `clkintr': >> /usr/src/sys/x86/isa/clock.c:189: undefined reference to >> `cyclic_clock_func' >> >> And upon inspection of clock.c: >> #ifdef KDTRACE_HOOKS >> #include >> #endif >> >> And in clkintr(): >> #ifdef KDTRACE_HOOKS >> /* >> * If the DTrace hooks are configured and a callback function >> * has been registered, then call it to process the high speed >> * timers. >> */ >> int cpu = PCPU_GET(cpuid); >> if (cyclic_clock_func[cpu] != NULL) >> (*cyclic_clock_func[cpu])(frame); >> #endif >> >> >> It seems for some odd reason that is being forgotten >> when >> it comes time for linking ? What is going on here ? >> >> Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build >> to >> finish but in the case that I want to build another kernel without dtrace I >> would have to add them back. Anyone have a better fitting solution to this >> ? >> >> Would it be just as good to re-ifdef this to ?WITH_CTF? instead. >> >> Anyway... this is latest code from stable/8 on i386. And yes options >> KDTRACE_HOOKS is in the kernel config. >> >> And the command that caused all this: >> ( make kernel WITH_CTF=1 ) >> > > In light of this I decided to just remove the effected section of clock.c > and move forward as this part of the kernel with DTrace is not what I am > looking into. > > Attached is a small patch that removes it in case someone else comes > across the same thing and needs a quick workaround. > To my best belief the cause is this i386 build is being done without "device apic" that includes I/O APIC (local_apic.c) which defines in a ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ). Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own definition of the same cyclic_clock_func, so I have added this in the same way that its implemented in local_apic.c to clock.c and the build succeeds and is usable. Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h instead ? and remove the definition in local_apic.c ? Additional references: ( Thanks to rwatson@ ) http://fxr.watson.org/fxr/ident?v=FREEBSD8&i=cyclic_clock_func Attached is the patch that solved this here but its just adding another definition that could probably be avoided by adding it somewhere else. - -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN -----BEGIN PGP SIGNATURE----- Comment: THIS SOFTWARE AND/OR CONTENTS IS PROVIDED BY THE AUTHOR ``AS IS'' AND Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR Comment: PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY Comment: DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, Comment: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING Comment: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE Comment: POSSIBILITY OF SUCH DAMAGE. iQEcBAEBAgAGBQJNdkkMAAoJEJBXh4mJ2FR+8j4H/3qcymOBXvbMj2fqILJA/2xx Xj+Og+INWT+3NAM95Ljeq375lLeV0h3FzXUKrHB+z/bQlY8NYdBdZHOtEUWl1ZvV 5W5RGAncSJq1cBU+EMOoGprvmwWaNIYIHJUUHSpSrJbhwdW53unP285ts4bqvk0I eirtOitgmaiyOzBpJAIfDBBWU7RgQWCc/IFsm6GAU90JmjATy65kEeBtba6fNVcV SlHqu5OmtuVN6eHEq/rf3Ai8jGktwvuS9Flgf4rM+u/tZTA1nC9cfo97Rbtek9TH lQ/yZe9U7Wz4OFSdidMoY1nJN3CYisp3Kq+gqabsd3XDkJQQiXcBIIh61hnnjog= =tC6l -----END PGP SIGNATURE----- --80310268-209080405-1299597590=:40738 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=cyclic_clock_func_t.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=cyclic_clock_func_t.patch Y2hhbmdlc2V0OiAgIDk1Mjo1ZWI3ZGU4ZGNkYzANCmJyYW5jaDogICAgICBE YXRhSVgNCnRhZzogICAgICAgICB0aXANCnVzZXI6ICAgICAgICBKLiBIZWxs ZW50aGFsIDxqaGVsbEBEYXRhSVgubmV0Pg0KZGF0ZTogICAgICAgIFR1ZSBN YXIgMDggMDg6MjA6MjggMjAxMSAtMDUwMA0Kc3VtbWFyeTogICAgIGN5Y2xp Y19jbG9ja19mdW5jX3QgY3ljbGljX2Nsb2NrX2Z1bmNbTUFYQ1BVXTsgZGVm aW5pdGlvbi4NCg0KZGlmZiAtciBlMWM4YTIwZWI0YjIgLXIgNWViN2RlOGRj ZGMwIHN5cy94ODYvaXNhL2Nsb2NrLmMNCi0tLSBhL3N5cy94ODYvaXNhL2Ns b2NrLmMJVHVlIE1hciAwOCAwODoxNjo1OSAyMDExIC0wNTAwDQorKysgYi9z eXMveDg2L2lzYS9jbG9jay5jCVR1ZSBNYXIgMDggMDg6MjA6MjggMjAxMSAt MDUwMA0KQEAgLTgyLDYgKzgyLDcgQEANCiANCiAjaWZkZWYgS0RUUkFDRV9I T09LUw0KICNpbmNsdWRlIDxzeXMvZHRyYWNlX2JzZC5oPg0KK2N5Y2xpY19j bG9ja19mdW5jX3QJY3ljbGljX2Nsb2NrX2Z1bmNbTUFYQ1BVXTsNCiAjZW5k aWYNCiANCiAjZGVmaW5lCVRJTUVSX0RJVih4KSAoKGk4MjU0X2ZyZXEgKyAo eCkgLyAyKSAvICh4KSkNCg0K --80310268-209080405-1299597590=:40738-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 15:51:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FB90106566B for ; Tue, 8 Mar 2011 15:51:41 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 23D0C8FC1A for ; Tue, 8 Mar 2011 15:51:40 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id p28Fpdx3018441; Tue, 8 Mar 2011 16:51:39 +0100 (CET) Received: from [217.29.46.5] ([217.29.46.5]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p28FpcuP031123; Tue, 8 Mar 2011 16:51:39 +0100 (CET) (envelope-from hausen@punkt.de) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Patrick M. Hausen" In-Reply-To: Date: Tue, 8 Mar 2011 16:51:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Evans X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable Subject: Re: Disable probing of bge1? 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: Tue, 08 Mar 2011 15:51:41 -0000 Hello, Am 07.03.2011 um 13:37 schrieb Tom Evans: > Maybe this loader tunable will help: > hw.bge.allow_asf > Allow the ASF feature for cooperating with IPMI. Can cause = sys=E2=80=90 > tem lockup problems on a small number of systems. Disabled by > default. No - same result: bge0: mem 0xfd210000-0xfd21ffff,0xfd200000-0xfd20ffff irq 16 at = device 4.0 on pci8 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto bge0: Ethernet address: 00:0a:e4:82:c1:0f bge0: [ITHREAD] bge1: irq 1 Here the iRMC console is disconnected. Thanks anyway, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 19:50:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 643E41065673 for ; Tue, 8 Mar 2011 19:50:30 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE8EA8FC15 for ; Tue, 8 Mar 2011 19:50:29 +0000 (UTC) Received: by fxm19 with SMTP id 19so6250120fxm.13 for ; Tue, 08 Mar 2011 11:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uWKe02EiUmpXrnNkvIRgc28yBQaTUAdCV4KtDmDfqtE=; b=pmmq4k6NYiy3TIargsIl5lhHyMgVpdB3+PEbXidelNRbG1ZHrOob2v4eK0L7ohqr+w /Z6DOV9OQwJnEuGdk4Brb3yVs12mVXIBoBbRpb2p1CWWVoSWkMUT11HBAcguit5b2WFm CILiWkmRpCdngp3yRVE1jWcGjgj8svxaVKg/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=amnECS4tEMtDAEqvyf0dSnYeOdOvMXGnjpFIBdP6quM6OSWKeydpHvZklXPM4V27xD URKLcuk0kN93VR/KnEWqLcjbE9LHKgMXhrhkcG3DdqeM/8N64+fUfhulU4xgqwJCHcFt YdG8oEp0rOEERi2af+uC/3THry5ffsKQQYsYY= Received: by 10.223.2.205 with SMTP id 13mr6919746fak.138.1299611650775; Tue, 08 Mar 2011 11:14:10 -0800 (PST) Received: from Groseille.malikania.fr (65.21.102-84.rev.gaoland.net [84.102.21.65]) by mx.google.com with ESMTPS id r24sm512098fax.27.2011.03.08.11.14.08 (version=SSLv3 cipher=OTHER); Tue, 08 Mar 2011 11:14:09 -0800 (PST) Message-ID: <4D768002.405@gmail.com> Date: Tue, 08 Mar 2011 20:14:10 +0100 From: David Demelier User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110306 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> <4CE0010D.7080505@FreeBSD.org> <4D150C56.4080801@FreeBSD.org> <31097583.post@talk.nabble.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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: Tue, 08 Mar 2011 19:50:30 -0000 On 08/03/2011 16:15, Brandon Gooch wrote: > On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach wrote: >> >> Hello. >> >> Just ensuring that this issue would not be forgotten, >> If I recall correctly, without added patches one >> cannot burn CD with cdrtools, quite a problem >> for media burning suite ;) >> >> best regards, >> - Jakub Lach > > mav@ is working on graid(4), a replacement for ataraid(4) using the > GEOM framework. This effort has taken precedence over a few > outstanding patches he was working on, but he will eventually come > back to it :) > > Perhaps another developer will step up and continue the work on the patches: > > http://people.freebsd.org/~mav/sense/ > > -Brandon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I hope because I want to use ahci on my machines! :-) -- David Demelier From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 19:59:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E59106564A; Tue, 8 Mar 2011 19:59:31 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 589028FC08; Tue, 8 Mar 2011 19:59:31 +0000 (UTC) Received: by gyh4 with SMTP id 4so2477657gyh.13 for ; Tue, 08 Mar 2011 11:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=020ZrKEKaEZNM6sOzp+86gAb6JXSodtawtTWvWT6MzI=; b=spB/nLzM4AvsX7ZVrT2ZNw2wIqp+GHrkF9IRKy0ZvxDjZVJdQQR81kciNE+uy8ujnW KF4OTJJWChJYUMkiFvCOvT/uD8K1NQKqGTZ0Z0KF5xUGzgMTqZT5J5do4DX37/w7lbRb aE1+pOjyy/ZPi6afFSbQknW0o59+ddiPnbXQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=C20cKeOL4Hgx+dT61pa1M5DLRZE3uCXWqSrJuw1TJDEklaZmDYhrI55tmvZwe2FAxw XX90po9+4yxceRrPlKAztswWBno+FXqmc7cPbY1cItLILl/jzPspI1FCI3pvAzdTwtYo q0ueTXzvRnFqehivKCEc7Zpk0WXND4Vn08fc8= MIME-Version: 1.0 Received: by 10.101.186.1 with SMTP id n1mr2260124anp.244.1299614370525; Tue, 08 Mar 2011 11:59:30 -0800 (PST) Received: by 10.100.125.14 with HTTP; Tue, 8 Mar 2011 11:59:30 -0800 (PST) In-Reply-To: <20110220154651.GA17661@icarus.home.lan> References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> <4D6133AC.6070507@sentex.net> <20110220154651.GA17661@icarus.home.lan> Date: Tue, 8 Mar 2011 11:59:30 -0800 Message-ID: From: Freddie Cash To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Andrey Smagin , Eugene Grosbein , Andrew Boyer , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: About "panic: bufwrite: buffer is not busy???" 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: Tue, 08 Mar 2011 19:59:31 -0000 Not sure if the CC: line needs to be trimmed, leaving it as is for now. On Sun, Feb 20, 2011 at 7:46 AM, Jeremy Chadwick wrote: > On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: >> On 2/20/2011 9:33 AM, Andrey Smagin wrote: >> > On week -current I have same problem, my box paniced every 2-15 min. I= resolve problem by next steps - unplug network connectors from 2 intel em = (82574L) cards. I think last time that mpd5 related panic, but mpd5 work wi= th another re interface interated on MB. I think it may be em related panic= , or em+mpd5. >> >> The latest panic I saw didnt have anything to do with em. =C2=A0Are you = sure >> your crashes are because of the nic drive ? > > Not to mention, the error string the OP provided (see Subject) is only > contained in one file: sys/ufs/ffs/ffs_vfsops.c, function > ffs_bufwrite(). =C2=A0So, that would be some kind of weird filesystem-rel= ated > issue, not NIC-specific. =C2=A0I have no idea how to debug said problem. I can semi-reliably reproduce this panic message on a 9-CURRENT box, with sources from March 7. On this box, it happens every other time I start hastd. hastd creates the 12 GEOM providers used to create a ZFS pool. A simple "service hastd onestart" will generate the panic. Is there any extra info that needed to help track this down? --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 21:24:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4EA1065703; Tue, 8 Mar 2011 21:24:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 621758FC1B; Tue, 8 Mar 2011 21:24:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 168D346B91; Tue, 8 Mar 2011 16:24:16 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0BD58A01B; Tue, 8 Mar 2011 16:24:15 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 8 Mar 2011 09:15:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D760AEC.7050604@digiware.nl> In-Reply-To: <4D760AEC.7050604@digiware.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103080915.29284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 08 Mar 2011 16:24:15 -0500 (EST) Cc: Alan Cox , Willem Jan Withagen Subject: Re: panic on vm_page_cache_transfer: object 0xfffffff0035508000's type is not compatible with cache pages 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: Tue, 08 Mar 2011 21:24:16 -0000 On Tuesday, March 08, 2011 5:54:36 am Willem Jan Withagen wrote: > System: > > FreeBSD zfs.digiware.nl 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Feb 26 > 06:28:43 CET 2011 > root@zfs.digiware.nl:/usr/obj/usr/src/src8/src/sys/ZFS amd64 > > Don't have a serial console, so I wrote down the traceback. > But my guess is that that is not enough, however I needed the system so > I rebooted. > > tb: > vm_object_split at .... +0x125 > vm_space_fork at .... +0x3f7 > fork1 at .... +0x6a9 > fork at .... +0xee > syscall_entr at .... +1c > syscall at .... +4c > > rip = 0x8006bc39c > rsp = 0x7fffffffe9d8 > rbp = 0x800a04470 > > It looks a lot like what I find on > http://people.freebsd.org/~pho/stress/log/kostik079.html > > But my system is amd64, with 8Gb RAM and is fully ZFS based > with swap on 2 gpt freebsd-swap partitions. > > System crashed last night around 1:30, which is when a few large rsync > backups are coming in. > > Would I be able to call doadump to obtain something usefull afterward > (provided I have savecore set?) Hmm, judging from the info at the URL above, I'm not sure what to make of this assertion. In vm_object_split(), the 'new_object' is always OBJT_DEFAULT, so it will always fail that half of the assertion. In fact, this is the only place that vm_page_cache_transfer() is called, so 'new_object->type == OBJT_SWAP' is pretty much guaranteed to almost never be true. I guess it is assuming that swap_pager_copy() would have always converted 'new_object' to OBJT_SWAP if it had any cache pages? Perhaps that is a bogus assumption if 'orig_object' only has cache pages and no currently-swapped out pages (or if the swapped out pages are not in the range of the new object)? I've cc'd Alan to see if he has any ideas. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 21:32:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53A21065670 for ; Tue, 8 Mar 2011 21:32:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 850088FC08 for ; Tue, 8 Mar 2011 21:32:06 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 41BCD46B49; Tue, 8 Mar 2011 16:32:06 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DC3FD8A027; Tue, 8 Mar 2011 16:32:05 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 8 Mar 2011 16:31:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103081631.54304.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 08 Mar 2011 16:32:06 -0500 (EST) Cc: Subject: Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' 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: Tue, 08 Mar 2011 21:32:06 -0000 On Tuesday, March 08, 2011 10:19:30 am J. Hellenthal wrote: > > On Tue, 8 Mar 2011 04:18, jhell@ wrote: > > On Tue, 8 Mar 2011 03:29, jhell@ wrote: > >> > >> Hello Stable@, > >> > >> Compiling a kernel on stable/8 with DTrace support is failing with the > >> above > >> subject line upon linking kernel.debug. > >> > >> The text leading up to this is: > >> ... > >> ctfconvert -L VERSION -g vers.o > >> linking kernel.debug > >> clock.o(.text+0x84c): In function `clkintr': > >> /usr/src/sys/x86/isa/clock.c:189: undefined reference to > >> `cyclic_clock_func' > >> > >> And upon inspection of clock.c: > >> #ifdef KDTRACE_HOOKS > >> #include > >> #endif > >> > >> And in clkintr(): > >> #ifdef KDTRACE_HOOKS > >> /* > >> * If the DTrace hooks are configured and a callback function > >> * has been registered, then call it to process the high speed > >> * timers. > >> */ > >> int cpu = PCPU_GET(cpuid); > >> if (cyclic_clock_func[cpu] != NULL) > >> (*cyclic_clock_func[cpu])(frame); > >> #endif > >> > >> > >> It seems for some odd reason that is being forgotten > >> when > >> it comes time for linking ? What is going on here ? > >> > >> Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build > >> to > >> finish but in the case that I want to build another kernel without dtrace I > >> would have to add them back. Anyone have a better fitting solution to this > >> ? > >> > >> Would it be just as good to re-ifdef this to ?WITH_CTF? instead. > >> > >> Anyway... this is latest code from stable/8 on i386. And yes options > >> KDTRACE_HOOKS is in the kernel config. > >> > >> And the command that caused all this: > >> ( make kernel WITH_CTF=1 ) > >> > > > > In light of this I decided to just remove the effected section of clock.c > > and move forward as this part of the kernel with DTrace is not what I am > > looking into. > > > > Attached is a small patch that removes it in case someone else comes > > across the same thing and needs a quick workaround. > > > > To my best belief the cause is this i386 build is being done without > "device apic" that includes I/O APIC (local_apic.c) which defines in a > ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ). > Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own > definition of the same cyclic_clock_func, so I have added this in the same > way that its implemented in local_apic.c to clock.c and the build succeeds > and is usable. > > Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h > instead ? and remove the definition in local_apic.c ? I think DTrace requires the local APIC to work as it hooks directly into the local APIC timer interrupt IIRC. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Mar 8 22:52:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1783106566C; Tue, 8 Mar 2011 22:52:53 +0000 (UTC) (envelope-from ctfreebsd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 479B48FC12; Tue, 8 Mar 2011 22:52:52 +0000 (UTC) Received: by yie12 with SMTP id 12so2487892yie.13 for ; Tue, 08 Mar 2011 14:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=gedAWUzA6rZkfYzSfRFSxJ5WvM/k/d3qmx8PaDPNouI=; b=eGF8oSGQVvxClf++VlM5L/prl0dCKX41MHVsy7k2nL/sfroKDYFp8mwOeccAylUhI0 TQWcUaG73s7i0+2VsArx5G64zM4Goa6FJsp7vPMdsSpx2dMZMyBPxnjhzmcjAS7fCxnS 3Kl7pyTy5nCOTwVqhvsN0ZcXD4bZbKWJgDvl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=q9JeVSLbE8C4jIYWAGorKoLvw3hK8ZJV+CmrjPF4C42zYK68coDpFIH3tgIafoDpu2 C8dZoUXt6hNIC5vQqoKsDsI9Sjmt4KRmjkVyIhR5Ic6r81R5SMSB3JRYc8qzTYvS+w1K Uyy2tgp6oRAJWlBhhZaJxGWAKerT8ptE3XgUA= MIME-Version: 1.0 Received: by 10.151.122.3 with SMTP id z3mr6884957ybm.89.1299624772288; Tue, 08 Mar 2011 14:52:52 -0800 (PST) Received: by 10.147.171.19 with HTTP; Tue, 8 Mar 2011 14:52:52 -0800 (PST) Date: Wed, 9 Mar 2011 00:52:52 +0200 Message-ID: From: Dave Johnson To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Port 80 closed? 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: Tue, 08 Mar 2011 22:52:53 -0000 Hi all An IPFW problem? An help gladly accepted It would appear Port 80 closed Ports 21 25 443 587 998 work well rc.conf defaultrouter="192.168.0.1" gateway_enable="YES" hostname="xxx.xxx.xxx" ifconfig_re0="inet 192.168.0.11 netmask 255.255.255.0" ifconfig_re1="inet 192.168.1.2 netmask 255.255.255.0" keymap="us.iso" moused_enable="YES" sshd_enable="YES" firewall_enable="YES" firewall_script="/etc/rc.firewall" natd_program="/sbin/natd" natd_enable="YES" natd_interface="re0" natd_flags="-f /etc/natd.conf" dhcpd_enable="NO" dhcpd_flags="-q" dhcpd_conf="/usr/local/etc/dhcpd.conf" dhcpd_ifaces="re1" dhcpd_withumask="022" natd.conf interface re0 use_sockets yes same_ports yes log #redirect_port tcp 192.168.1.189:3389 3389 #redirect_port tcp 192.168.1.53:5500 5500 #!/bin/sh /sbin/ipfw -f flush /sbin/ipfw -f pipe flush #Nat Rules /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 /sbin/ipfw add 30 divert natd all from any to any via re0 #Forward to Transparent Proxy Server #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 /sbin/ipfw add 50000 allow ip from any to any Regards From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 01:26:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D46106566B for ; Wed, 9 Mar 2011 01:26:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 784098FC13 for ; Wed, 9 Mar 2011 01:26:13 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p291Q9v7035958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Mar 2011 11:56:10 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Wed, 9 Mar 2011 11:56:09 +1030 Content-Transfer-Encoding: 7bit Message-Id: References: To: Dave Johnson X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD-STABLE Mailing List Subject: Re: Port 80 closed? 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, 09 Mar 2011 01:26:14 -0000 On 09/03/2011, at 9:22, Dave Johnson wrote: > An IPFW problem? > > An help gladly accepted > > It would appear Port 80 closed > > Ports 21 25 443 587 998 work well It's quite possible your ISP blocks port 80 inbound. And/or there is a problem with your router. PS don't cross post. > > > rc.conf > defaultrouter="192.168.0.1" > gateway_enable="YES" > hostname="xxx.xxx.xxx" > ifconfig_re0="inet 192.168.0.11 netmask 255.255.255.0" > ifconfig_re1="inet 192.168.1.2 netmask 255.255.255.0" > keymap="us.iso" > moused_enable="YES" > sshd_enable="YES" > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > natd_program="/sbin/natd" > natd_enable="YES" > natd_interface="re0" > natd_flags="-f /etc/natd.conf" > dhcpd_enable="NO" > dhcpd_flags="-q" > dhcpd_conf="/usr/local/etc/dhcpd.conf" > dhcpd_ifaces="re1" > dhcpd_withumask="022" > > natd.conf > > interface re0 > use_sockets yes > same_ports yes > log > #redirect_port tcp 192.168.1.189:3389 3389 > #redirect_port tcp 192.168.1.53:5500 5500 > > #!/bin/sh > > /sbin/ipfw -f flush > /sbin/ipfw -f pipe flush > > > > #Nat Rules > /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > /sbin/ipfw add 30 divert natd all from any to any via re0 > > > #Forward to Transparent Proxy Server > #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 > > /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > > > /sbin/ipfw add 50000 allow ip from any to any > > > Regards > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 05:08:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC36C1065670; Wed, 9 Mar 2011 05:08:13 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8DB8FC0C; Wed, 9 Mar 2011 05:08:13 +0000 (UTC) Received: by iyj12 with SMTP id 12so207170iyj.13 for ; Tue, 08 Mar 2011 21:08:12 -0800 (PST) Received: by 10.43.54.142 with SMTP id vu14mr7430009icb.384.1299647292706; Tue, 08 Mar 2011 21:08:12 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id wo11sm495779icb.20.2011.03.08.21.08.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 21:08:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Juergen Lock" References: <201102211924.p1LJOPuw039863@triton8.kn-bremen.de> <20110221223949.GA53037@triton8.kn-bremen.de> Date: Tue, 08 Mar 2011 23:08:09 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20110221223949.GA53037@triton8.kn-bremen.de> User-Agent: Opera Mail/11.01 (FreeBSD) Cc: freebsd-emulation@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Panic from linux emulation (flashplugin) 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, 09 Mar 2011 05:08:13 -0000 Well it started happening again. Basically what I did was rebuild all of ports which downgraded my nvidia driver. I was getting consistent crashes in youtube after this happened. I upgraded my nvidia driver to 260.19.44 by modifying the port and now I can't get it to crash anymore. *HOWEVER* This may or may not be unrelated -- I'm running opera and have a youtube video hidden in another tab. I have upgraded my nvidia driver but didn't reboot, just removed the kernel module and started X again. For some reason the Youtube video in the hidden tab is able to be seen when I put my terminal over the area where it would be if it was in the active tab. http://feld.me/stuff/flash_bug.png is an example of it. I haven't yet rebooted to see what happens on a clean boot, but this is certainly interesting... perhaps bad flash/linuxulator behavior that doesn't trip a panic in the newer nvidia drivers? Weird stuff either way... Now that I have seemingly figured out the combination to a crash I'll see if I can catch one on the console and have something worthwhile to report. Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 05:54:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33EC2106564A for ; Wed, 9 Mar 2011 05:54:54 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2BA08FC0A for ; Wed, 9 Mar 2011 05:54:53 +0000 (UTC) Received: by iwn33 with SMTP id 33so233386iwn.13 for ; Tue, 08 Mar 2011 21:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type :content-transfer-encoding; bh=eo0HqzZRWQHzQ/c/Jq/3PV2xA2RO27aXbnCed1HjYFs=; b=NjhGob9G3Zm/9Xg8zIELU1DONQ6ENt6k7o3LyZP/WkGVMPSlOrbdK9xN9zGeW/LGH7 cmoTDV3HHCCZbAjMEpQ6JiZYgH72UIiBtVrzMUSxgN19elQdgr16eAVba8UsPXdg1qHx KomKXGgxvpegsLfZmPIlh+9G8Zsg5Tp608nEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; b=AwigU2eU5mTaZVl7LTroYe0kUt3QRtQbwE5ag7qMLdcd0kbNhL9yYEv5DuxMI1w5+4 F3I3C7o47ShMR/gGGdgPNt8Y6UmTNZOCyLFsJ53ZzO6krF7Zuo2itOWNxVSakFJ0gaGg VvNOCyEi3nmgr8xBT5aaKFzZxfuImPWblFrQI= Received: by 10.231.185.76 with SMTP id cn12mr4739035ibb.33.1299650093123; Tue, 08 Mar 2011 21:54:53 -0800 (PST) Received: from disbatch.dataix.local (adsl-99-19-43-28.dsl.klmzmi.sbcglobal.net [99.19.43.28]) by mx.google.com with ESMTPS id u9sm1243276ibe.8.2011.03.08.21.54.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 21:54:51 -0800 (PST) Sender: "J. Hellenthal" Date: Wed, 9 Mar 2011 00:54:35 -0500 From: "J. Hellenthal" To: John Baldwin In-Reply-To: <201103081631.54304.jhb@freebsd.org> Message-ID: References: <201103081631.54304.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Cc: freebsd-stable@freebsd.org Subject: Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' 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, 09 Mar 2011 05:54:54 -0000 On Tue, 8 Mar 2011 16:31, jhb@ wrote: > On Tuesday, March 08, 2011 10:19:30 am J. Hellenthal wrote: >> >> On Tue, 8 Mar 2011 04:18, jhell@ wrote: >>> On Tue, 8 Mar 2011 03:29, jhell@ wrote: >>>> >>>> Hello Stable@, >>>> >>>> Compiling a kernel on stable/8 with DTrace support is failing with the >>>> above >>>> subject line upon linking kernel.debug. >>>> >>>> The text leading up to this is: >>>> ... >>>> ctfconvert -L VERSION -g vers.o >>>> linking kernel.debug >>>> clock.o(.text+0x84c): In function `clkintr': >>>> /usr/src/sys/x86/isa/clock.c:189: undefined reference to >>>> `cyclic_clock_func' >>>> >>>> And upon inspection of clock.c: >>>> #ifdef KDTRACE_HOOKS >>>> #include >>>> #endif >>>> >>>> And in clkintr(): >>>> #ifdef KDTRACE_HOOKS >>>> /* >>>> * If the DTrace hooks are configured and a callback function >>>> * has been registered, then call it to process the high speed >>>> * timers. >>>> */ >>>> int cpu = PCPU_GET(cpuid); >>>> if (cyclic_clock_func[cpu] != NULL) >>>> (*cyclic_clock_func[cpu])(frame); >>>> #endif >>>> >>>> >>>> It seems for some odd reason that is being forgotten >>>> when >>>> it comes time for linking ? What is going on here ? >>>> >>>> Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the > build >>>> to >>>> finish but in the case that I want to build another kernel without dtrace > I >>>> would have to add them back. Anyone have a better fitting solution to > this >>>> ? >>>> >>>> Would it be just as good to re-ifdef this to ?WITH_CTF? instead. >>>> >>>> Anyway... this is latest code from stable/8 on i386. And yes options >>>> KDTRACE_HOOKS is in the kernel config. >>>> >>>> And the command that caused all this: >>>> ( make kernel WITH_CTF=1 ) >>>> >>> >>> In light of this I decided to just remove the effected section of clock.c >>> and move forward as this part of the kernel with DTrace is not what I am >>> looking into. >>> >>> Attached is a small patch that removes it in case someone else comes >>> across the same thing and needs a quick workaround. >>> >> >> To my best belief the cause is this i386 build is being done without >> "device apic" that includes I/O APIC (local_apic.c) which defines in a >> ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ). >> Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own >> definition of the same cyclic_clock_func, so I have added this in the same >> way that its implemented in local_apic.c to clock.c and the build succeeds >> and is usable. >> >> Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h >> instead ? and remove the definition in local_apic.c ? > > I think DTrace requires the local APIC to work as it hooks directly into the > local APIC timer interrupt IIRC. > I was starting to think that myself but after adding the above to clock.c it fixed the issue I was seeing. It appears that clock.c is providing enough of a interrupt to at least hotkernel and dtruss + procsystime. hotkernel ... kernel`bzero 28 0.1% kernel`copyout 31 0.1% kernel`syscallret 31 0.1% kernel`uma_zfree_arg 33 0.1% kernel`fget_unlocked 35 0.1% kernel`cpu_fetch_syscall_args 37 0.1% kernel`sopoll_generic 39 0.1% kernel`uma_zalloc_arg 41 0.1% kernel`poll 44 0.1% kernel`copyin 48 0.1% kernel`soreceive_generic 60 0.1% kernel`kern_select 66 0.2% kernel`syscallenter 93 0.2% kernel`sched_idletd 135 0.3% kernel`spinlock_exit 337 0.8% kernel`acpi_cpu_c1 40525 95.1% I would say at least for the tests I ran with this so far it fixes it¿ procsystime ... Elapsed Times for all processes, SYSCALL TIME (ns) getppid 13579 sigreturn 18646 fcntl 27752 getpid 36201 fstat 45574 close 47142 socket 55193 sigpending 86178 mmap 111586 connect 171967 swapcontext 224511 write 360017 sigprocmask 369920 setitimer 409114 sigaction 650495 writev 667841 gettimeofday 1480759 ioctl 3403788 stat 4044830 clock_gettime 4704770 __sysctl 7789725 read 9526207068 kevent 10024305765 _umtx_op 10142262643 poll 15037340342 select 34427328326 And a simple run of a d.d from example: vfs:namecache:enter:done { @distribution = quantize(strlen((string)arg1)); } value ------------- Distribution ------------- count 1 | 0 2 |@@@@@@@@@@@@@@ 20 4 |@@@@@@@@@@@@@@@@@@ 25 8 |@@@@@@@@ 12 16 | 0 -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 08:09:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE7C0106564A for ; Wed, 9 Mar 2011 08:09:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 71F028FC12 for ; Wed, 9 Mar 2011 08:09:26 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PxESS-000PIG-5p; Wed, 09 Mar 2011 10:09:24 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: george+freebsd@m5p.com In-reply-to: <201102091420.p19EKJ5u001268@m5p.com> References: <201102091420.p19EKJ5u001268@m5p.com> Comments: In-reply-to george+freebsd@m5p.com message dated "Wed, 09 Feb 2011 09:20:19 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Mar 2011 10:09:24 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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, 09 Mar 2011 08:09:26 -0000 > Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up > (with rpc.statd and rpc.lockd enabled in rc.conf), I get: > > Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use > Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd > > and slightly later: > > Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 > > I can start rpc.statd and rpc.lockd manually at this point (and I have to > start them to run firefox and mail with my NFS-mounted home directory and > mail spool). But what might cause the above errors? -- George Mitchell We have been seeing this too, with the addition of mountd. So I decided to try and track it down. rpc.lockd, rpc.statd or mountd, all share the same code for allocating address/port. I added some more info to be displayed in case of error, mainly the ai_family and port, so after many successfull reboots, I got: Mar 9 09:18:19 chamsa mountd[1070]: bindresvport_sa: (2/617) Address already in use but: chamsa> rpcinfo | grep mountd 100005 1 udp 0.0.0.0.2.105 mountd superuser 100005 3 udp 0.0.0.0.2.105 mountd superuser 100005 1 tcp 0.0.0.0.2.105 mountd superuser 100005 3 tcp 0.0.0.0.2.105 mountd superuser BTW, 0.0.0.2.105 is 617, and 2 is AF_INET the above is wierd, since the rpc stuff happens after the bindresvport_sa(...) danny From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 10:14:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8754106566B for ; Wed, 9 Mar 2011 10:14:36 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 48D238FC13 for ; Wed, 9 Mar 2011 10:14:35 +0000 (UTC) Received: by wwc33 with SMTP id 33so387200wwc.31 for ; Wed, 09 Mar 2011 02:14:35 -0800 (PST) Received: by 10.227.108.105 with SMTP id e41mr5550119wbp.48.1299665675091; Wed, 09 Mar 2011 02:14:35 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id o6sm1340897wbo.9.2011.03.09.02.14.33 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 02:14:34 -0800 (PST) Message-ID: <4D775309.20401@my.gd> Date: Wed, 09 Mar 2011 11:14:33 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Port 80 closed? 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, 09 Mar 2011 10:14:36 -0000 On 3/8/11 11:52 PM, Dave Johnson wrote: > Hi all > > > An IPFW problem? > > An help gladly accepted > > It would appear Port 80 closed > > Ports 21 25 443 587 998 work well > > > rc.conf > defaultrouter="192.168.0.1" > gateway_enable="YES" > hostname="xxx.xxx.xxx" > ifconfig_re0="inet 192.168.0.11 netmask 255.255.255.0" > ifconfig_re1="inet 192.168.1.2 netmask 255.255.255.0" > keymap="us.iso" > moused_enable="YES" > sshd_enable="YES" > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > natd_program="/sbin/natd" > natd_enable="YES" > natd_interface="re0" > natd_flags="-f /etc/natd.conf" > dhcpd_enable="NO" > dhcpd_flags="-q" > dhcpd_conf="/usr/local/etc/dhcpd.conf" > dhcpd_ifaces="re1" > dhcpd_withumask="022" > > natd.conf > > interface re0 > use_sockets yes > same_ports yes > log > #redirect_port tcp 192.168.1.189:3389 3389 > #redirect_port tcp 192.168.1.53:5500 5500 > > #!/bin/sh > > /sbin/ipfw -f flush > /sbin/ipfw -f pipe flush > > > > #Nat Rules > /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > /sbin/ipfw add 30 divert natd all from any to any via re0 > > > #Forward to Transparent Proxy Server > #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 > > /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > > > /sbin/ipfw add 50000 allow ip from any to any > > > Regards > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hi Dave, First of all, I'd suggest you explain what you're trying to do. >From your IPFW conf I can only guess you're trying to set up a transparent proxy. How do you test to see if the port is open or not ? Is your squid instance running and configured for transparent forwarding with IPFW ? From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 10:28:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83894106564A for ; Wed, 9 Mar 2011 10:28:53 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0006B8FC12 for ; Wed, 9 Mar 2011 10:28:52 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p29AHZVM042249; Wed, 9 Mar 2011 11:17:35 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p29AHZ1l042248; Wed, 9 Mar 2011 11:17:35 +0100 (CET) (envelope-from marius) Date: Wed, 9 Mar 2011 11:17:35 +0100 From: Marius Strobl To: "Patrick M. Hausen" Message-ID: <20110309101734.GA42208@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable Subject: Re: Disable probing of bge1? 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, 09 Mar 2011 10:28:53 -0000 On Mon, Mar 07, 2011 at 01:26:01PM +0100, Patrick M. Hausen wrote: > Hi, all, > > I just discovered a minor problem when updating some rather dated > systems from FreeBSD 6.x to 7.x or 8.x. > > The servers are Fujitsu Technology Solutions (former Fujitsu-Siemens) > RX100 S4. The current generation of the same system is RX100 S6, so this > is two generations old. Some of them still run fine in our datacenter, though. > > While the S5 and S6 series features two gigabit ports and an additional > network interface for out of band management (called iRMC, similar to HP's iLO), > the S4 has only two gigabit ports and the iRMC interface is piggybacked to > one of them. > > In our standard setup we disable the first interface in the BIOS. If you do this, > the physical port is available as a dedicated management interface to the iRMC > and only the second IF is probed by FreeBSD 6.x as bge0. > > Now I try to PXE boot an identically configured system via the remote serial > console with FreeBSD 7. Everything runs fine, until the kernel probes the > network interfaces. The last thing I see are messages about successful > probing of both bge0 and bge1 and then my remote management connection > and my console are gone. > > I have to reset the BMC by literally pulling the power to get the iRMC back. > > Is it possible to use some device.hints entry to prohibit the probing of bge1? > I think that would be the easiest solution to the problem? Other suggestions > are of course welcome. I can provide more config details and dmesg output > if needed. > Unfortunately, there's currently no generic way to disable probing/ attaching of specific PCI devices. You'd need to hack the driver like in the following example to achieve that: Index: /usr/src/sys/dev/bge/if_bge.c =================================================================== --- /usr/src/sys/dev/bge/if_bge.c (revision 213448) +++ /usr/src/sys/dev/bge/if_bge.c (working copy) @@ -2472,6 +2472,9 @@ bge_attach(device_t dev) u_char eaddr[ETHER_ADDR_LEN]; int error, msicount, reg, rid, trys; + if (device_get_unit(dev) == 1) + return (ENXIO); + sc = device_get_softc(dev); sc->bge_dev = dev; Marius From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 10:56:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A44106564A for ; Wed, 9 Mar 2011 10:56:19 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 04BEB8FC08 for ; Wed, 9 Mar 2011 10:56:18 +0000 (UTC) Received: from [10.0.2.78] (ppp203-122-198-153.lns6.adl6.internode.on.net [203.122.198.153]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p29Au7ep078639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Mar 2011 21:26:08 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20110309101734.GA42208@alchemy.franken.de> Date: Wed, 9 Mar 2011 21:26:07 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <7B8A7FC8-2547-4A63-8BCC-3CCDF39211D2@gsoft.com.au> References: <20110309101734.GA42208@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable Subject: Re: Disable probing of bge1? 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, 09 Mar 2011 10:56:19 -0000 On 09/03/2011, at 20:47, Marius Strobl wrote: >> Is it possible to use some device.hints entry to prohibit the probing = of bge1? >> I think that would be the easiest solution to the problem? Other = suggestions >> are of course welcome. I can provide more config details and dmesg = output >> if needed. >>=20 >=20 > Unfortunately, there's currently no generic way to disable probing/ > attaching of specific PCI devices. You'd need to hack the driver > like in the following example to achieve that: > Index: /usr/src/sys/dev/bge/if_bge.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/dev/bge/if_bge.c (revision 213448) > +++ /usr/src/sys/dev/bge/if_bge.c (working copy) > @@ -2472,6 +2472,9 @@ bge_attach(device_t dev) > u_char eaddr[ETHER_ADDR_LEN]; > int error, msicount, reg, rid, trys; >=20 > + if (device_get_unit(dev) =3D=3D 1) > + return (ENXIO); > + > sc =3D device_get_softc(dev); > sc->bge_dev =3D dev; Does.. hint.bge.0.disabled=3D"1" in the loader work? (I suspect not but am ever hopeful..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 11:23:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79A59106566B for ; Wed, 9 Mar 2011 11:23:33 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 686398FC0C for ; Wed, 9 Mar 2011 11:23:32 +0000 (UTC) Received: (qmail invoked by alias); 09 Mar 2011 10:56:50 -0000 Received: from g230081165.adsl.alicedsl.de (EHLO [192.168.0.4]) [92.230.81.165] by mail.gmx.net (mp001) with SMTP; 09 Mar 2011 11:56:50 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1/UegN1+ZbUdkyPUu1lJ1ijHKo39p1x+q6IVRhEvq CXSeinJgaPfxfx Message-ID: <4D775CF1.1010501@gmx.de> Date: Wed, 09 Mar 2011 11:56:49 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Mnenhy/0.8.3 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110308114810.GA37554@icarus.home.lan> In-Reply-To: <20110308114810.GA37554@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: ZFS performance as the FS fills up? 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, 09 Mar 2011 11:23:33 -0000 Am 08.03.2011 12:48, schrieb Jeremy Chadwick: > On Tue, Mar 08, 2011 at 12:26:49PM +0100, Patrick M. Hausen wrote: >> we use a big JBOD and ZFS with raidz2 as the target >> for our nightly Amanda backups. >> >> I already suspected that the fact that the FS was > 90% full might >> be the cause of our backup performance continously decreasing. >> >> I just added another vdev - 6 disks of 750 GB each, raidz2 and the >> FS usage is back to 71% currently. This was while backups were >> running and write performance instantly skyrocketed compared to >> the values before. >> >> So, is it possible to name a reasonable amount of free space to >> keep on a raidz2 volume? On last year's EuroBSDCon I got >> the impression that with recent (RELENG_8) ZFS merges >> I could get away with using around 90%. > > I'm in no way attempting to dissuade you from your efforts to figure out > a good number for utilisation, but when I hear of disks -- no matter how > many -- being 90% full, I immediately conclude performance is going to > suck simply because the outer "tracks" on a disk contains more sectors > than the inner "tracks". This is the reason for performance degradation > as the seek offset increases, resulting in graphs like this: Whatever. I've experienced similar massive performance decrease even on a non-redundant single-disk ZFS setup after the ZFS (8-STABLE between 8.0 and before 8.2) had filled up once. Even clearing the disk down to 70% didn't get my /usr (which was a ZFS mount) snappy again. The speed decrease was one to two orders of magnitude in excess of what you'd attribute to the CLV or sectors-per-track change across the disk. What I heard from my 7200/min WD RE3 drive (which seeks rather fast for a 7200/min drive - I think it was the fastest seeking 7200/min drive when I bought it) it was seeking and thrashing heads like hell even on single-threaded bulk reads of large files, and I suppose there was fragmentation and/or non-caching of metadata afoot, and it was far worse than any decrease in constant linear velocity or sectors-per-track of the disk tracks could explain, and the relevant ZFS ARC related options didn't rectify that either, so I reverted to GJOURNAL-enabled UFS which gave me a much better performance on a 5400/min disk than I've ever had with a halfway filled ZFS on the 7200/min RAID-class disk. And bulk transfer rates of both drives are beyond any doubt. In other words, the file system didn't recover speed (I'm not sure if that's a zfs or zpool feature), and I attribute that (and the failure to rm files from a 100% full file system) to the write-ahead-logging behaviour of ZFS. Any comments? -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 12:07:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669C61065676 for ; Wed, 9 Mar 2011 12:07:58 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (unknown [IPv6:2001:418:3fd::3]) by mx1.freebsd.org (Postfix) with ESMTP id 36CC58FC14 for ; Wed, 9 Mar 2011 12:07:58 +0000 (UTC) Received: from wonderland.m5p.com (wonderland.m5p.com [IPv6:2001:418:3fd::19]) by mailhost.m5p.com (8.14.3/8.14.3) with ESMTP id p29C7QeJ094643; Wed, 9 Mar 2011 07:07:31 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <4D776D7E.2080908@m5p.com> Date: Wed, 09 Mar 2011 07:07:26 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110217 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Braniss References: <201102091420.p19EKJ5u001268@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.9 () BAYES_00,J_CHICKENPOX_35 X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:418:3fd::f7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Wed, 09 Mar 2011 07:07:31 -0500 (EST) Cc: freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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, 09 Mar 2011 12:07:58 -0000 On 03/09/11 03:09, Daniel Braniss wrote: >> Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up >> (with rpc.statd and rpc.lockd enabled in rc.conf), I get: >> >> Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use >> Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd >> >> and slightly later: >> >> Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 >> >> I can start rpc.statd and rpc.lockd manually at this point (and I have to >> start them to run firefox and mail with my NFS-mounted home directory and >> mail spool). But what might cause the above errors? -- George Mitchell > > We have been seeing this too, with the addition of mountd. > So I decided to try and track it down. > rpc.lockd, rpc.statd or mountd, all share the same code for allocating > address/port. I added some more info to be displayed in case of error, > mainly the ai_family and port, so after many successfull reboots, I got: > > Mar 9 09:18:19 chamsa mountd[1070]: bindresvport_sa: (2/617) Address already > in use > > but: > > chamsa> rpcinfo | grep mountd > 100005 1 udp 0.0.0.0.2.105 mountd superuser > 100005 3 udp 0.0.0.0.2.105 mountd superuser > 100005 1 tcp 0.0.0.0.2.105 mountd superuser > 100005 3 tcp 0.0.0.0.2.105 mountd superuser > > BTW, 0.0.0.2.105 is 617, and 2 is AF_INET > > the above is wierd, since the rpc stuff happens after the bindresvport_sa(...) > > danny > > Thanks for the analysis. The reason I originally posted is to see why this might have popped up in 8.x, as it never happened in 7.x. -- George Mitchell From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 12:30:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A546F1065672 for ; Wed, 9 Mar 2011 12:30:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8C20C8FC1B for ; Wed, 9 Mar 2011 12:30:29 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta04.emeryville.ca.mail.comcast.net with comcast id H0Vx1g00216AWCUA40WUJ8; Wed, 09 Mar 2011 12:30:28 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta06.emeryville.ca.mail.comcast.net with comcast id H0WR1g00N0PUQVN8S0WT2F; Wed, 09 Mar 2011 12:30:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 202C39B422; Wed, 9 Mar 2011 04:30:25 -0800 (PST) Date: Wed, 9 Mar 2011 04:30:25 -0800 From: Jeremy Chadwick To: George Mitchell Message-ID: <20110309123025.GA62338@icarus.home.lan> References: <201102091420.p19EKJ5u001268@m5p.com> <4D776D7E.2080908@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D776D7E.2080908@m5p.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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, 09 Mar 2011 12:30:29 -0000 On Wed, Mar 09, 2011 at 07:07:26AM -0500, George Mitchell wrote: > On 03/09/11 03:09, Daniel Braniss wrote: > >>Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up > >>(with rpc.statd and rpc.lockd enabled in rc.conf), I get: > >> > >>Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use > >>Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd > >> > >>and slightly later: > >> > >>Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 > >> > >>I can start rpc.statd and rpc.lockd manually at this point (and I have to > >>start them to run firefox and mail with my NFS-mounted home directory and > >>mail spool). But what might cause the above errors? -- George Mitchell > > > >We have been seeing this too, with the addition of mountd. > >So I decided to try and track it down. > >rpc.lockd, rpc.statd or mountd, all share the same code for allocating > >address/port. I added some more info to be displayed in case of error, > >mainly the ai_family and port, so after many successfull reboots, I got: > > > >Mar 9 09:18:19 chamsa mountd[1070]: bindresvport_sa: (2/617) Address already > >in use > > > >but: > > > >chamsa> rpcinfo | grep mountd > > 100005 1 udp 0.0.0.0.2.105 mountd superuser > > 100005 3 udp 0.0.0.0.2.105 mountd superuser > > 100005 1 tcp 0.0.0.0.2.105 mountd superuser > > 100005 3 tcp 0.0.0.0.2.105 mountd superuser > > > >BTW, 0.0.0.2.105 is 617, and 2 is AF_INET > > > >the above is wierd, since the rpc stuff happens after the bindresvport_sa(...) > > > >danny > > > > > > Thanks for the analysis. The reason I originally posted is to see why > this might have popped up in 8.x, as it never happened in 7.x. This problem has happened on our RELENG_7 systems in the past, though the port binding failed because something else had bound to a port number that (if I remember right) mountd randomly chose/tried to bind to and failed. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 12:51:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC6ED1065673 for ; Wed, 9 Mar 2011 12:51:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 975058FC13 for ; Wed, 9 Mar 2011 12:51:41 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id H0if1g0061swQuc570renZ; Wed, 09 Mar 2011 12:51:38 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta15.westchester.pa.mail.comcast.net with comcast id H0ra1g00h0PUQVN3b0rasK; Wed, 09 Mar 2011 12:51:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 958949B422; Wed, 9 Mar 2011 04:51:32 -0800 (PST) Date: Wed, 9 Mar 2011 04:51:32 -0800 From: Jeremy Chadwick To: Matthias Andree Message-ID: <20110309125132.GB62338@icarus.home.lan> References: <20110308114810.GA37554@icarus.home.lan> <4D775CF1.1010501@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D775CF1.1010501@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS performance as the FS fills up? 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, 09 Mar 2011 12:51:42 -0000 On Wed, Mar 09, 2011 at 11:56:49AM +0100, Matthias Andree wrote: > Am 08.03.2011 12:48, schrieb Jeremy Chadwick: > > On Tue, Mar 08, 2011 at 12:26:49PM +0100, Patrick M. Hausen wrote: > >> we use a big JBOD and ZFS with raidz2 as the target > >> for our nightly Amanda backups. > >> > >> I already suspected that the fact that the FS was > 90% full might > >> be the cause of our backup performance continously decreasing. > >> > >> I just added another vdev - 6 disks of 750 GB each, raidz2 and the > >> FS usage is back to 71% currently. This was while backups were > >> running and write performance instantly skyrocketed compared to > >> the values before. > >> > >> So, is it possible to name a reasonable amount of free space to > >> keep on a raidz2 volume? On last year's EuroBSDCon I got > >> the impression that with recent (RELENG_8) ZFS merges > >> I could get away with using around 90%. > > > > I'm in no way attempting to dissuade you from your efforts to figure out > > a good number for utilisation, but when I hear of disks -- no matter how > > many -- being 90% full, I immediately conclude performance is going to > > suck simply because the outer "tracks" on a disk contains more sectors > > than the inner "tracks". This is the reason for performance degradation > > as the seek offset increases, resulting in graphs like this: > > Whatever. I've experienced similar massive performance decrease even on > a non-redundant single-disk ZFS setup after the ZFS (8-STABLE between > 8.0 and before 8.2) had filled up once. > > Even clearing the disk down to 70% didn't get my /usr (which was a ZFS > mount) snappy again. The speed decrease was one to two orders of > magnitude in excess of what you'd attribute to the CLV or > sectors-per-track change across the disk. > > What I heard from my 7200/min WD RE3 drive (which seeks rather fast for > a 7200/min drive - I think it was the fastest seeking 7200/min drive > when I bought it) it was seeking and thrashing heads like hell even on > single-threaded bulk reads of large files, and I suppose there was > fragmentation and/or non-caching of metadata afoot, and it was far worse > than any decrease in constant linear velocity or sectors-per-track of > the disk tracks could explain, and the relevant ZFS ARC related options > didn't rectify that either, so I reverted to GJOURNAL-enabled UFS which > gave me a much better performance on a 5400/min disk than I've ever had > with a halfway filled ZFS on the 7200/min RAID-class disk. And bulk > transfer rates of both drives are beyond any doubt. > > In other words, the file system didn't recover speed (I'm not sure if > that's a zfs or zpool feature), and I attribute that (and the failure to > rm files from a 100% full file system) to the write-ahead-logging > behaviour of ZFS. > > Any comments? FWIW: we have ZFS filesystems at my workplace, using Solaris 10, which fill to 95-99% quite often (workhorse database servers). Userland apps bail out when 100% is reached, of course. Once some space is freed up, things are back to normal (our disk I/O graphs indicate there's nothing different before or after the fs fills/free space is restored). The filesystems are single-disk pools, and in some other cases 3-disk raidz1 pools. FreeBSD is not Solaris, true. But possibly the issue has been addressed with the ZFS v15 commit that happened between 8.1 and 8.2? Here's the said commit (I just picked one of the files during the MFC; the commit message was the same across them all). One would need to review each of the individual OpenSolaris bugfix numbers to find out if any of them are relevant: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c#rev1.8.2.6 Otherwise, I can imagine that prefetching could cause what you describe, which is enabled by default in 8.0 and 8.1 and auto-disables in 8.2 if the amount of available memory is less than 4GB. If that's not it, then I would think this would be pretty easy to reproduce given its nature. Can you or the OP reproduce it reliably and provide some hard data here for developers to review? Right now there's just some generic statements. It's important that folks who experience issues with ZFS on FreeBSD provide: - dmesg output (this will include relevant FreeBSD build dates, versions, architecture type, amount of RAM, and highly relevant disk/storage subsystem details) - Date of when your source was csup'd (if different from build date) - /boot/loader.conf contents - /etc/sysctl.conf contents - "zpool status" output - "zfs get all" output - "top" output (mainly the header portions, re: memory usage) - "sysctl -a | grep zfs" output - If I/O is slow, "zpool iostat -v 1" output while the problem happens - Anything else they can think of that seems relevant (disk I/O graphs, or whatever you think might play a role) Otherwise I can't see the devs being able to track down anything without concrete data. I imagine opening a PR would be helpful too, but discussions often come first, which is fine. Hope this helps. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 13:28:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A8721065673 for ; Wed, 9 Mar 2011 13:28:52 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30B718FC26 for ; Wed, 9 Mar 2011 13:28:52 +0000 (UTC) Received: by qyk27 with SMTP id 27so389738qyk.13 for ; Wed, 09 Mar 2011 05:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MglkwsWyCBVXtLIX8HERvKH7cMSXV7L6zXeZq6SITlg=; b=PhAIiufpCy8oy96wn3pfMuhlnoy2qffnd/5VEe7NcQHsWD6AyfUL8irQGobIMPQthK eDl+uytlxNxSbD6S6/+XhczgtEWJmSHdRVFH7kpmrGIytm6XWrhFqUQlCFLi256qy6L4 zaiwutYtUBFZdzgeV4p7xAIV+UC7B/rpPgegg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q3rBcnnSKfSWxsCyVK6s2FY2PG+YkY2vRLSpMKJu7OYfZoDU4mmPK2jYcgqSR/qLZh fttdC/nF4iQW89Z0ojWvDzXPKWOW8YLqAvd9g3fgZ8gnjiPpwcKXCJmykujPbjwTjxHv 12PQHcsqTvuyaDZWOZn6iuJi+sFvdMBDTUtgk= MIME-Version: 1.0 Received: by 10.224.135.95 with SMTP id m31mr1388550qat.90.1299677330512; Wed, 09 Mar 2011 05:28:50 -0800 (PST) Received: by 10.229.79.139 with HTTP; Wed, 9 Mar 2011 05:28:50 -0800 (PST) In-Reply-To: <20110309125132.GB62338@icarus.home.lan> References: <20110308114810.GA37554@icarus.home.lan> <4D775CF1.1010501@gmx.de> <20110309125132.GB62338@icarus.home.lan> Date: Wed, 9 Mar 2011 13:28:50 +0000 Message-ID: From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: Matthias Andree , freebsd-stable@freebsd.org Subject: Re: ZFS performance as the FS fills up? 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, 09 Mar 2011 13:28:52 -0000 On Wed, Mar 9, 2011 at 12:51 PM, Jeremy Chadwick wrote: > > Otherwise, I can imagine that prefetching could cause what you describe, > which is enabled by default in 8.0 and 8.1 and auto-disables in 8.2 if > the amount of available memory is less than 4GB. > I don't think this is accurate. Prefetch was certainly disabled by default on 8.0 if you had 4GB of RAM or less, requiring the sysctl vfs.zfs.prefetch_disable=0 to be set if you wanted prefetch and had 4GB of RAM or less. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 14:01:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44353106564A for ; Wed, 9 Mar 2011 14:01:47 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id A3F1D8FC1B for ; Wed, 9 Mar 2011 14:01:46 +0000 (UTC) Received: (qmail invoked by alias); 09 Mar 2011 14:01:44 -0000 Received: from g230081165.adsl.alicedsl.de (EHLO [192.168.0.4]) [92.230.81.165] by mail.gmx.net (mp006) with SMTP; 09 Mar 2011 15:01:44 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1/Eu71xx2LEvyZkFSSreYdtnXCNw6SeCz4lgXiPMc 5f8VGPxPDS6raS Message-ID: <4D778846.3080008@gmx.de> Date: Wed, 09 Mar 2011 15:01:42 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Mnenhy/0.8.3 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110308114810.GA37554@icarus.home.lan> <4D775CF1.1010501@gmx.de> <20110309125132.GB62338@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Jeremy Chadwick Subject: Re: ZFS performance as the FS fills up? 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, 09 Mar 2011 14:01:47 -0000 Am 09.03.2011 14:28, schrieb Tom Evans: > On Wed, Mar 9, 2011 at 12:51 PM, Jeremy Chadwick > wrote: >> >> Otherwise, I can imagine that prefetching could cause what you describe, >> which is enabled by default in 8.0 and 8.1 and auto-disables in 8.2 if >> the amount of available memory is less than 4GB. >> > > I don't think this is accurate. Prefetch was certainly disabled by > default on 8.0 if you had 4GB of RAM or less, requiring the sysctl > vfs.zfs.prefetch_disable=0 to be set if you wanted prefetch and had > 4GB of RAM or less. Personally I've got a 4 GB amd64 setup, had been on RELENG_8 aka 8-STABLE before 8.2-RELEASE (and use RELENG_8_2 aka 8.2-RELEASE now), and I had tried vfs.zfs.prefetch_disable either way without seeing a big difference in sluggish performance (and actually even moved out /usr/home to a UFS file system to get somewhat back up to speed). I suppose that fragmentation was a big issue but cannot confirm that now. However, I cannot produce the data Jeremy has asked for any more, as the incriminated file system no longer exists. I recall ZFS (even the earlier versions before the bigger version leap) was very responsive when it was less than 50% full. I have, however, collected and reformatted (for Wiki) Jeremy's list at - we'd need to review this and once deemed suitable, link it from the ZFS and possibly ZFSTuningGuide pages, and possibly also from the FreeBSD ZFS manual pages. HTH Matthias -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 15:40:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D44F106564A for ; Wed, 9 Mar 2011 15:40:59 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id C32E38FC21 for ; Wed, 9 Mar 2011 15:40:58 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id p29Fevw6034522; Wed, 9 Mar 2011 16:40:57 +0100 (CET) Received: from [217.29.45.147] ([217.29.45.147]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id p29FeuBT072537; Wed, 9 Mar 2011 16:40:56 +0100 (CET) (envelope-from hausen@punkt.de) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Patrick M. Hausen" In-Reply-To: Date: Wed, 9 Mar 2011 16:40:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110308114810.GA37554@icarus.home.lan> <4D775CF1.1010501@gmx.de> <20110309125132.GB62338@icarus.home.lan> To: Tom Evans X-Mailer: Apple Mail (2.1082) Cc: Matthias Andree , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ZFS performance as the FS fills up? 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, 09 Mar 2011 15:40:59 -0000 Hello, Am 09.03.2011 um 14:28 schrieb Tom Evans: > I don't think this is accurate. Prefetch was certainly disabled by > default on 8.0 if you had 4GB of RAM or less, requiring the sysctl > vfs.zfs.prefetch_disable=3D0 to be set if you wanted prefetch and had > 4GB of RAM or less. My configuration is this: JBOD with 24 disks before the performance increase, now 30. 5 vdevs of 6 disks each, raidz2. 16 GB RAM, 8.2 amd64. vm.kmem_size=3D"12288M" vfs.zfs.arc_max=3D"8192M" vfs.zfs.prefetch_disable=3D"1" vfs.zfs.txg.timeout=3D"5" ------- net.inet.tcp.sendbuf_max=3D16777216 net.inet.tcp.recvbuf_max=3D16777216 net.inet.tcp.sendspace=3D65536 net.inet.tcp.recvspace=3D131072 kern.maxvnodes=3D250000 vfs.zfs.txg.write_limit_override=3D1073741824 After I added the last 6 disks net write performance (that means how quick Amanda fills the current vtape) at least doubled. Without any further Amanda tuning. I am aware that there are many components involved that affect performance, so what would be the best way to measure the ZFS part? Working crystal balls have become rare these days ;-) Kind regards, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 18:08:03 2011 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 6E9A8106566B for ; Wed, 9 Mar 2011 18:08:03 +0000 (UTC) (envelope-from whatsnew10@gallopade1.com) Received: from gallopade2.nmsrv.com (gallopade2.nmsrv.com [208.70.247.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4AE8FC15 for ; Wed, 9 Mar 2011 18:08:03 +0000 (UTC) Received: (qmail 5387 invoked from network); 10 Mar 2011 01:42:05 -0000 Received: from 70-46-213-34.fdn.fdn.com (HELO http://70.46.213.35) (70.46.213.34) by gallopade2.nmsrv.com with SMTP; 10 Mar 2011 01:42:05 -0000 Date: Wed, 9 Mar 2011 12:41:23 -0500 To: Homeschool From: WhatsNew10 Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Weather-Related Teaching Tools For Spring X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: emailreply@gallopade1.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:08:03 -0000 [1]If this email does not display correctly click = here [2]3D"" = =EF=BB=BFEVERYBODY loves spring! Flowers bloom. The = weather turns warmer. And summer is one season closer. It's the perfect time to engage kids in the = interesting science of weather! It's also a good time to discuss = weather-related safety tips. Award-winning children's = author Carole Marsh offers great kid-friendly tools that teach about all = things weather--from the different types of clouds (including how to = create a cloud in an empty soda bottle) to the F-Scale that measures = tornados to how to make a home safety kit. Kids can learn individually, as = a class or in a smaller group. Start with fun weather-related = activities and experiments from Willie Gets Wild About = Weather, one of the 16 Science Alliance books. Next, read = The Treacherous Tornado Mystery to excite your = kids about the adventures of Currie and Nick Masters as they travel with = their scientist dad across Tornado Alley, get involved in solving a mystery and learn all about = stormy weather too. Then, test what's been learned by playing = Don't Know Beans = About...Weather--perfect for any day, even a rainy = one. Lastly, use the All-In-One Weather Bulletin Board = Set for great visuals PLUS a downloadable activity that = turns students' classroom work into part of the board. = Whether (no pun intended!) you take advantage of these tools as a set = or separately, they can provide hands-on activities (and unique fun!) for = teaching about the weather! [3]CLICK = HERE to see the products and sets detailed below. [4]3D"" = =EF=BB=BFStudy weather using the = 4-product Weather Teaching Set for $35.96, which = includes: One 32-page reproducible Willie Gets = Wild About Weather book filled with weather-related = activities, experiments and a science project One = The Treacherous Tornado Mystery paperback = book One Don't Know Beans = About...Weather game One = All-In-One Weather Bulletin Board 15 FREE = Masters of Disasters bookmarks Or buy these products = individually: Willie Gets Wild About = Weather $6.99 The Treacherous = Tornado Mystery paperback book $5.99; or hardcover book = $14.95; or library bound book $18.99 = Don't Know Beans About...Weather game = $9.99 All-In-One Weather Bulletin = Board $12.99 Try reading The = Treacherous Tornado Mystery as a class or group: = Classroom Set of 30 mysteries for $179.70 includes 30 = FREE Masters of Disasters series bookmarks = Reading Group Set of 5 mysteries for $29.95 includes 5 = FREE bookmarks [5]3D"" = 3D"" [6]3D"Facebook" [7]3D"Twitter" [8]3D"Blog" You are receiving this = email because of your interest in education, or you participated in a = Gallopade promotion on the web or via some other method. If you would rather not receive any more email from us, [9]click here. 4102127 Gallopade International, P.O. = Box 2779, Peachtree City, GA 30269 = [index.php?ent=] = References 1. 3D"http://70.46.213.=/ 2. 3D"http://www.gallopade.com/showproducts.cfm?WPCID=3D1865" 3. 3D"http://70.46.213.35/index.php?entry= 4. 3D"http://www.gallopade.com/showproducts.cfm?WPCID=3D1865" 5. 3D"http://www.gallopade.com/showproducts.cfm?WPCID=3D1865" 6. 3D"http://70.46.213.35/index.php?entryPoint=3Dcampaign_trackerv2&trac= 7. 3D"http://70.46.213.35/index.php?entryPoint=3Dcampaign_trackerv2&trac= 8. 3D"http://70.46.213.35/index.php?entryPoint=3Dcampaign_track= 9. 3D"http://70.46.2=/ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 20:49:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F221106564A for ; Wed, 9 Mar 2011 20:49:01 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (adsl-074-168-200-170.sip.rmo.bellsouth.net [74.168.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id E578B8FC20 for ; Wed, 9 Mar 2011 20:49:00 +0000 (UTC) Received: from dave.dignus.com (dave.dignus.com [10.1.0.4]) by dignus.com (8.14.4/8.14.4) with ESMTP id p29KJaiB011540 for ; Wed, 9 Mar 2011 15:19:36 -0500 (EST) (envelope-from rivers@dignus.com) Received: from dave.dignus.com (localhost [127.0.0.1]) by dave.dignus.com (8.13.8/8.11.3) with ESMTP id p29KFd89077850 for ; Wed, 9 Mar 2011 15:15:39 -0500 (EST) (envelope-from rivers@dave.dignus.com) Received: (from rivers@localhost) by dave.dignus.com (8.13.8/8.13.8/Submit) id p29KFd0U077849 for freebsd-stable@freebsd.org; Wed, 9 Mar 2011 15:15:39 -0500 (EST) (envelope-from rivers) From: Thomas David Rivers Message-Id: <201103092015.p29KFd0U077849@dave.dignus.com> Date: Wed, 09 Mar 2011 15:15:39 -0500 To: freebsd-stable@freebsd.org User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on office.dignus.com Subject: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)? 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, 09 Mar 2011 20:49:01 -0000 Just installed a fresh 8.2-stable on a brand-spanking-new 64-bit machine... But, when I try to build 32-bit programs I get problems linking, and I stumbled onto PR bin/139146. The PR mentions this quick test: uname -sr && echo "int main () { }" > t.c && gcc -v --help 2>&1 | grep m32 && gcc -m32 t.c which I try to get this output: FreeBSD 8.2-RELEASE -m32 Generate 32bit i386 code /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc So - I'm wondering what the proper approach is on amd64 to build 32-bit applications? - Thanks! - - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 20:52:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75EFA1065673 for ; Wed, 9 Mar 2011 20:52:54 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4688FC13 for ; Wed, 9 Mar 2011 20:52:53 +0000 (UTC) Received: by iyj12 with SMTP id 12so1042258iyj.13 for ; Wed, 09 Mar 2011 12:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BlpBnUbIgIlURv+PRYfo+2O6/OPkxPy9j6/oquCPj+A=; b=Yc/aTvQAivvTJW4IIAREiJDC5eRKW91lZnoSVWTJgiD6+D6MoLIsc3ZUEuI0g25KBd guvpD69WrWiQjHWkGD50NYdkejLklCMFzieHnyM4CWsLiv28xMs2S8E1TEEpcT9a8MNC rDRVyzVWpEoZQ1ZKXb6r1gJlIX56ZnAnWKRkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=ThXqBeWUhNqBIrSRxhjWtAFXH0rNUF8b0POHMQdPtV8DIvKYRZFghHDvd8O7Mjxrqi vKImJiD4wWe/oijRBkGCkrvKcgDBZFPMgtW00EiM5cUfhl3mGHHdZuBzS8q51D4vQgEW rYKjor8BtcPfRmcOHTu34mFHNvdGts9oMbbjs= MIME-Version: 1.0 Received: by 10.42.140.129 with SMTP id k1mr674165icu.146.1299703973262; Wed, 09 Mar 2011 12:52:53 -0800 (PST) Received: by 10.231.183.13 with HTTP; Wed, 9 Mar 2011 12:52:53 -0800 (PST) In-Reply-To: <201103092015.p29KFd0U077849@dave.dignus.com> References: <201103092015.p29KFd0U077849@dave.dignus.com> Date: Wed, 9 Mar 2011 12:52:53 -0800 Message-ID: From: Josh Carroll To: Thomas David Rivers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:52:54 -0000 On Wed, Mar 9, 2011 at 12:15 PM, Thomas David Rivers wr= ote: > > Just installed a fresh 8.2-stable on a brand-spanking-new 64-bit > machine... > > But, when I try to build 32-bit programs I get problems linking, > and I stumbled onto PR bin/139146. > > The PR mentions this quick test: > > =A0uname -sr && echo "int main () { }" > t.c && gcc -v --help 2>&1 | grep= m32 && gcc -m32 t.c Add -B/usr/lib32 to the gcc command line, e.g.: echo "int main () { }" > t.c && gcc -v --help 2>&1 | grep m32 && gcc -m32 -B/usr/lib32 t.c Then it should work. Josh From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 21:08:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A58F106564A for ; Wed, 9 Mar 2011 21:08:56 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (adsl-074-168-200-170.sip.rmo.bellsouth.net [74.168.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0A58FC0A for ; Wed, 9 Mar 2011 21:08:55 +0000 (UTC) Received: from dave.dignus.com (dave.dignus.com [10.1.0.4]) by dignus.com (8.14.4/8.14.4) with ESMTP id p29LC8K7013123; Wed, 9 Mar 2011 16:12:08 -0500 (EST) (envelope-from rivers@dignus.com) Received: from dave.dignus.com (localhost [127.0.0.1]) by dave.dignus.com (8.13.8/8.11.3) with ESMTP id p29L8AQ4078229; Wed, 9 Mar 2011 16:08:10 -0500 (EST) (envelope-from rivers@dave.dignus.com) Received: (from rivers@localhost) by dave.dignus.com (8.13.8/8.13.8/Submit) id p29L8AmI078228; Wed, 9 Mar 2011 16:08:10 -0500 (EST) (envelope-from rivers) From: Thomas David Rivers Message-Id: <201103092108.p29L8AmI078228@dave.dignus.com> Date: Wed, 09 Mar 2011 16:08:10 -0500 To: rivers@dignus.com, linimon@lonesome.com References: <201103092015.p29KFd0U077849@dave.dignus.com> <20110309205501.GD18229@lonesome.com> In-Reply-To: <20110309205501.GD18229@lonesome.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on office.dignus.com Cc: freebsd-stable@freebsd.org Subject: Re: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)? 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, 09 Mar 2011 21:08:56 -0000 Thanks everyone! -B/usr/lib32 worked around the issue... - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 21:13:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DCAE106564A for ; Wed, 9 Mar 2011 21:13:43 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3FDEF8FC15 for ; Wed, 9 Mar 2011 21:13:43 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 3BE6656160; Wed, 9 Mar 2011 14:55:01 -0600 (CST) Date: Wed, 9 Mar 2011 14:55:01 -0600 From: Mark Linimon To: Thomas David Rivers Message-ID: <20110309205501.GD18229@lonesome.com> References: <201103092015.p29KFd0U077849@dave.dignus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103092015.p29KFd0U077849@dave.dignus.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)? 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, 09 Mar 2011 21:13:43 -0000 On Wed, Mar 09, 2011 at 03:15:39PM -0500, Thomas David Rivers wrote: > But, when I try to build 32-bit programs I get problems linking, > and I stumbled onto PR bin/139146. That one was closed as a duplicate of gnu/112215. I've forwarded your email to GNATS with the followup redirected there. mcl From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 21:44:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA2601065670 for ; Wed, 9 Mar 2011 21:44:43 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 06CA28FC0A for ; Wed, 9 Mar 2011 21:44:42 +0000 (UTC) Received: (qmail invoked by alias); 09 Mar 2011 21:44:41 -0000 Received: from g230081165.adsl.alicedsl.de (EHLO mandree.no-ip.org) [92.230.81.165] by mail.gmx.net (mp017) with SMTP; 09 Mar 2011 22:44:41 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+8CuJR/NW8imbvYqPMZhA1+f89gSmiaCNG6NdU8H puCqWGdemNP4p/ Received: from apollo.emma.line.org (apollo.emma.line.org [192.168.0.4]) by merlin.emma.line.org (Postfix) with ESMTP id 1075F94815 for ; Wed, 9 Mar 2011 22:44:40 +0100 (CET) Received: from [IPv6:::1] (unknown [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 8E11725AD88 for ; Wed, 9 Mar 2011 22:44:39 +0100 (CET) Message-ID: <4D77F4C7.5020304@gmx.de> Date: Wed, 09 Mar 2011 22:44:39 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Mnenhy/0.8.3 Thunderbird/3.1.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201103092015.p29KFd0U077849@dave.dignus.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)? 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, 09 Mar 2011 21:44:43 -0000 Am 09.03.2011 21:52, schrieb Josh Carroll: > On Wed, Mar 9, 2011 at 12:15 PM, Thomas David Rivers wrote: >> >> Just installed a fresh 8.2-stable on a brand-spanking-new 64-bit >> machine... >> >> But, when I try to build 32-bit programs I get problems linking, >> and I stumbled onto PR bin/139146. >> >> The PR mentions this quick test: >> >> uname -sr && echo "int main () { }" > t.c && gcc -v --help 2>&1 | grep m32 && gcc -m32 t.c > > Add -B/usr/lib32 to the gcc command line, e.g.: > > echo "int main () { }" > t.c && gcc -v --help 2>&1 | grep m32 && gcc > -m32 -B/usr/lib32 t.c > > Then it should work. I experienced the same some time ago - but: Shouldn't this (-B/usr/lib32) be subsumed under the -m32 switch in the future? Best regards -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Wed Mar 9 23:03:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C10106566B for ; Wed, 9 Mar 2011 23:03:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 47F5D8FC0A for ; Wed, 9 Mar 2011 23:03:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPOVd02DaFvO/2dsb2JhbACELaM5sgmRJoEng0h2BIUihxg X-IronPort-AV: E=Sophos;i="4.62,292,1297054800"; d="scan'208";a="112669646" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 09 Mar 2011 18:03:36 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 64ECEB3F23; Wed, 9 Mar 2011 18:03:36 -0500 (EST) Date: Wed, 9 Mar 2011 18:03:36 -0500 (EST) From: Rick Macklem To: George Mitchell Message-ID: <1139116164.1119047.1299711816326.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4D776D7E.2080908@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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, 09 Mar 2011 23:03:37 -0000 > > Thanks for the analysis. The reason I originally posted is to see why > this might have popped up in 8.x, as it never happened in 7.x. > -- George Mitchell > I suspect two things make this occur more frequently with 8.x. One is that it does IPv6 first (I suspect IPv6 wasn't enabled by default on 7.x?). The other is the port randomization code, which probably results in more frequent collisions with port #s used by other things. (Basically, the code selects an unused port# for either UDP or TCP over IPv6 (I can't remember which comes first:-) and then expects that port to be available for the other 3 combinations of UDP/TCP x IPv6/IPv4. rick From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 06:49:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3611106566B for ; Thu, 10 Mar 2011 06:49:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 954438FC1A for ; Thu, 10 Mar 2011 06:49:06 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PxZgG-0007EI-5r; Thu, 10 Mar 2011 08:49:04 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Rick Macklem In-reply-to: <1139116164.1119047.1299711816326.JavaMail.root@erie.cs.uoguelph.ca> References: <1139116164.1119047.1299711816326.JavaMail.root@erie.cs.uoguelph.ca> Comments: In-reply-to Rick Macklem message dated "Wed, 09 Mar 2011 18:03:36 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Mar 2011 08:49:04 +0200 From: Daniel Braniss Message-ID: Cc: George Mitchell , freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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: Thu, 10 Mar 2011 06:49:07 -0000 > > > > Thanks for the analysis. The reason I originally posted is to see why > > this might have popped up in 8.x, as it never happened in 7.x. > > -- George Mitchell > > > I suspect two things make this occur more frequently with 8.x. One is > that it does IPv6 first (I suspect IPv6 wasn't enabled by default on 7.x?). > > The other is the port randomization code, which probably results in > more frequent collisions with port #s used by other things. (Basically, > the code selects an unused port# for either UDP or TCP over IPv6 (I can't > remember which comes first:-) and then expects that port to be available > for the other 3 combinations of UDP/TCP x IPv6/IPv4. anothere reason for it is probably the multy-cores, most of these daemons fork very early, and very quickly are compiting for resources in parallel. danny PS: rick, can you send me your patch? From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 09:51:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F841065672 for ; Thu, 10 Mar 2011 09:51:10 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA6C8FC0A for ; Thu, 10 Mar 2011 09:51:08 +0000 (UTC) Received: by ewy1 with SMTP id 1so459516ewy.13 for ; Thu, 10 Mar 2011 01:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bn/X+rGGWQ9VHVoJfDHtU6aKaMlIda0y2Yuin9xWhnw=; b=ucHVftpDWQPMUHVDtEo+kbHBUasqlU0vXuEvhxbD/fcm49chCoLdIpWnYZzUekYKom u0OB/7MNDVO9maqthk8gm8zFwy/wTVj+R6qmQ2odcJSbVwQ2tfrHD+nQSVKhGkHCjfbv DvhBQiBvLXM7v/L2KJJu6edoXjnG8mwSVJ6Lg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=W1ZI5u1aFaKBl0tImEi6zNDR6HsuZh3XKBUTql4C+4VLA8rYSvPL0ftmbtLaI+YpOE ACP3ejAy0B10hagkAoJ6c71lKHkoiAYTWyXxbS0Xg74P9ihYqDIQPLP3ZRRnEvKnCIXD aq0mdBT3fxjfN5V3Ryr+tA3Os434A29YSmqyY= Received: by 10.14.125.7 with SMTP id y7mr4421336eeh.28.1299750668099; Thu, 10 Mar 2011 01:51:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.31.161 with HTTP; Thu, 10 Mar 2011 01:50:48 -0800 (PST) In-Reply-To: References: <4D6DA259.4050307@sentex.net> <201103030955.23620.jhb@freebsd.org> From: "Jack L." Date: Thu, 10 Mar 2011 01:50:48 -0800 Message-ID: To: Yanhui Shen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 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: Thu, 10 Mar 2011 09:51:10 -0000 I just got the error just now. I'm keeping the machine booted for a little longer in case someone wants to ask any questions. If I simple reboot the machine, it will just hang forever and eventually need to power cycle it. Mar 9 04:58:51 jpr1 kernel: jack@jpr1.prdhost.com:/usr/obj/usr/src/sys/JPR1 amd64 Mar 9 04:58:51 jpr1 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 9 04:58:51 jpr1 kernel: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6400+ (3214.84-MHz K8-class CPU) Mar 9 04:58:51 jpr1 kernel: Origin = "AuthenticAMD" Id = 0x40f33 Family = f Model = 43 Stepping = 3 Mar 9 04:58:51 jpr1 kernel: Features=0x178bfbff Mar 9 04:58:51 jpr1 kernel: Features2=0x2001 Mar 9 04:58:51 jpr1 kernel: AMD Features=0xea500800 Mar 9 04:58:51 jpr1 kernel: AMD Features2=0x1f Mar 9 04:58:51 jpr1 kernel: real memory = 8589934592 (8192 MB) Mar 9 04:58:51 jpr1 kernel: avail memory = 8228098048 (7846 MB) Mar 9 04:58:51 jpr1 kernel: ACPI APIC Table: Mar 9 04:58:51 jpr1 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Mar 9 04:58:51 jpr1 kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Mar 9 04:58:51 jpr1 kernel: cpu0 (BSP): APIC ID: 0 Mar 9 04:58:51 jpr1 kernel: cpu1 (AP): APIC ID: 1 Mar 9 04:58:51 jpr1 kernel: ioapic0: Changing APIC ID to 4 Mar 9 04:58:51 jpr1 kernel: ioapic0 irqs 0-23 on motherboard Mar 9 04:58:51 jpr1 kernel: kbd1 at kbdmux0 Mar 9 04:58:51 jpr1 kernel: acpi0: on motherboard Mar 9 04:58:51 jpr1 kernel: acpi0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: acpi0: Power Button (fixed) Mar 9 04:58:51 jpr1 kernel: acpi0: reservation of 0, a0000 (3) failed Mar 9 04:58:51 jpr1 kernel: acpi0: reservation of 100000, cedf0000 (3) failed Mar 9 04:58:51 jpr1 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 9 04:58:51 jpr1 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Mar 9 04:58:51 jpr1 kernel: cpu0: on acpi0 Mar 9 04:58:51 jpr1 kernel: cpu1: on acpi0 Mar 9 04:58:51 jpr1 kernel: acpi_button0: on acpi0 Mar 9 04:58:51 jpr1 kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 9 04:58:51 jpr1 kernel: pci0: on pcib0 Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.0 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.1 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.2 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.3 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.4 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.5 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.6 (no driver attached) Mar 9 04:58:51 jpr1 kernel: pci0: at device 0.7 (no driver attached) Mar 9 04:58:51 jpr1 kernel: vgapci0: mem 0xfc000000-0xfcffffff,0xd0000000-0xdfffffff,0xfb000000-0xfbffffff irq 16 at device 5.0 on pci0 Mar 9 04:58:51 jpr1 kernel: pci0: at device 9.0 (no driver attached) Mar 9 04:58:51 jpr1 kernel: isab0: at device 10.0 on pci0 Mar 9 04:58:51 jpr1 kernel: isa0: on isab0 Mar 9 04:58:51 jpr1 kernel: nfsmb0: port 0x4c00-0x4c3f,0x4c40-0x4c7f at device 10.1 on pci0 Mar 9 04:58:51 jpr1 kernel: smbus0: on nfsmb0 Mar 9 04:58:51 jpr1 kernel: smb0: on smbus0 Mar 9 04:58:51 jpr1 kernel: nfsmb1: on nfsmb0 Mar 9 04:58:51 jpr1 kernel: smbus1: on nfsmb1 Mar 9 04:58:51 jpr1 kernel: smb1: on smbus1 Mar 9 04:58:51 jpr1 kernel: pci0: at device 10.2 (no driver attached) Mar 9 04:58:51 jpr1 kernel: ohci0: mem 0xfe02f000-0xfe02ffff at device 11.0 on pci0 Mar 9 04:58:51 jpr1 kernel: ohci0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: usbus0: on ohci0 Mar 9 04:58:51 jpr1 kernel: ehci0: mem 0xfe02e000-0xfe02e0ff at device 11.1 on pci0 Mar 9 04:58:51 jpr1 kernel: ehci0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: usbus1: EHCI version 1.0 Mar 9 04:58:51 jpr1 kernel: usbus1: on ehci0 Mar 9 04:58:51 jpr1 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfd00-0xfd0f at device 13.0 on pci0 Mar 9 04:58:51 jpr1 kernel: ata0: on atapci0 Mar 9 04:58:51 jpr1 kernel: ata0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: ata1: on atapci0 Mar 9 04:58:51 jpr1 kernel: ata1: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf800-0xf80f mem 0xfe02d000-0xfe02dfff irq 20 at device 14.0 on pci0 Mar 9 04:58:51 jpr1 kernel: atapci1: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: ata2: on atapci1 Mar 9 04:58:51 jpr1 kernel: ata2: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: ata3: on atapci1 Mar 9 04:58:51 jpr1 kernel: ata3: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf300-0xf30f mem 0xfe02c000-0xfe02cfff irq 21 at device 15.0 on pci0 Mar 9 04:58:51 jpr1 kernel: atapci2: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: ata4: on atapci2 Mar 9 04:58:51 jpr1 kernel: ata4: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: ata5: on atapci2 Mar 9 04:58:51 jpr1 kernel: ata5: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: pcib1: at device 16.0 on pci0 Mar 9 04:58:51 jpr1 kernel: pci1: on pcib1 Mar 9 04:58:51 jpr1 kernel: fwohci0: mem 0xfddff000-0xfddff7ff,0xfddf8000-0xfddfbfff irq 19 at device 5.0 on pci1 Mar 9 04:58:51 jpr1 kernel: fwohci0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: fwohci0: OHCI version 1.10 (ROM=1) Mar 9 04:58:51 jpr1 kernel: fwohci0: No. of Isochronous channels is 4. Mar 9 04:58:51 jpr1 kernel: fwohci0: EUI64 00:11:d8:00:01:46:4c:23 Mar 9 04:58:51 jpr1 kernel: fwohci0: Phy 1394a available S400, 2 ports. Mar 9 04:58:51 jpr1 kernel: fwohci0: Link S400, max_rec 2048 bytes. Mar 9 04:58:51 jpr1 kernel: firewire0: on fwohci0 Mar 9 04:58:51 jpr1 kernel: fwohci0: Initiate bus reset Mar 9 04:58:51 jpr1 kernel: fwohci0: fwohci_intr_core: BUS reset Mar 9 04:58:51 jpr1 kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Mar 9 04:58:51 jpr1 kernel: rl0: port 0xec00-0xecff mem 0xfddfe000-0xfddfe0ff irq 16 at device 8.0 on pci1 Mar 9 04:58:51 jpr1 kernel: miibus0: on rl0 Mar 9 04:58:51 jpr1 kernel: rlphy0: PHY 0 on miibus0 Mar 9 04:58:51 jpr1 kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Mar 9 04:58:51 jpr1 kernel: rl0: Ethernet address: 00:14:c1:0e:e6:8c Mar 9 04:58:51 jpr1 kernel: rl0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: pci0: at device 16.1 (no driver attached) Mar 9 04:58:51 jpr1 kernel: nfe0: port 0xf200-0xf207 mem 0xfe02b000-0xfe02bfff irq 23 at device 20.0 on pci0 Mar 9 04:58:51 jpr1 kernel: miibus1: on nfe0 Mar 9 04:58:51 jpr1 kernel: e1000phy0: PHY 1 on miibus1 Mar 9 04:58:51 jpr1 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Mar 9 04:58:51 jpr1 kernel: nfe0: Ethernet address: 00:1b:fc:25:43:42 Mar 9 04:58:51 jpr1 kernel: nfe0: [FILTER] Mar 9 04:58:51 jpr1 kernel: amdtemp0: on hostb3 Mar 9 04:58:51 jpr1 kernel: acpi_tz0: on acpi0 Mar 9 04:58:51 jpr1 kernel: ACPI Warning: For \_TZ_.THRM._PSL: Return Package type mismatch at index 0 - found [NULL Object Descriptor], expected Reference (20101013/nspredef-1197) Mar 9 04:58:51 jpr1 kernel: acpi_hpet0: iomem 0xfefff000-0xfefff3ff irq 0,8 on acpi0 Mar 9 04:58:51 jpr1 kernel: Timecounter "HPET" frequency 25000000 Hz quality 900 Mar 9 04:58:51 jpr1 kernel: atrtc0: port 0x70-0x73 on acpi0 Mar 9 04:58:51 jpr1 kernel: orm0: at iomem 0xd0000-0xd3fff on isa0 Mar 9 04:58:51 jpr1 kernel: sc0: at flags 0x100 on isa0 Mar 9 04:58:51 jpr1 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 9 04:58:51 jpr1 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 9 04:58:51 jpr1 kernel: atkbdc0: at port 0x60,0x64 on isa0 Mar 9 04:58:51 jpr1 kernel: atkbd0: irq 1 on atkbdc0 Mar 9 04:58:51 jpr1 kernel: kbd0 at atkbd0 Mar 9 04:58:51 jpr1 kernel: atkbd0: [GIANT-LOCKED] Mar 9 04:58:51 jpr1 kernel: atkbd0: [ITHREAD] Mar 9 04:58:51 jpr1 kernel: powernow0: on cpu0 Mar 9 04:58:51 jpr1 kernel: device_attach: powernow0 attach returned 6 Mar 9 04:58:51 jpr1 kernel: powernow1: on cpu1 Mar 9 04:58:51 jpr1 kernel: device_attach: powernow1 attach returned 6 Mar 9 04:58:51 jpr1 kernel: Timecounters tick every 1.000 msec Mar 9 04:58:51 jpr1 kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Mar 9 04:58:51 jpr1 kernel: firewire0: bus manager 0 Mar 9 04:58:51 jpr1 kernel: IP Filter: v4.1.28 initialized. Default = pass all, Logging = disabled Mar 9 04:58:51 jpr1 kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging disabled Mar 9 04:58:51 jpr1 kernel: load_dn_sched dn_sched RR loaded Mar 9 04:58:51 jpr1 kernel: load_dn_sched dn_sched WF2Q+ loaded Mar 9 04:58:51 jpr1 kernel: load_dn_sched dn_sched FIFO loaded Mar 9 04:58:51 jpr1 kernel: load_dn_sched dn_sched PRIO loaded Mar 9 04:58:51 jpr1 kernel: load_dn_sched dn_sched QFQ loaded Mar 9 04:58:51 jpr1 kernel: usbus0: 12Mbps Full Speed USB v1.0 Mar 9 04:58:51 jpr1 kernel: usbus1: 480Mbps High Speed USB v2.0 Mar 9 04:58:51 jpr1 kernel: ugen0.1: at usbus0 Mar 9 04:58:51 jpr1 kernel: uhub0: on usbus0 Mar 9 04:58:51 jpr1 kernel: ugen1.1: at usbus1 Mar 9 04:58:51 jpr1 kernel: uhub1: on usbus1 Mar 9 04:58:58 jpr1 named[1048]: starting BIND 9.6.3 -t /var/named -u bind Mar 9 04:58:58 jpr1 named[1048]: built with '--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' '--without-libxml2' Mar 9 04:59:00 jpr1 named[1048]: command channel listening on 127.0.0.1#953 63S/T 1Mar 9 04:59:00 jpr1 named[1048]: command channel listening on ::1#953 Mar 9 04:59:00 jpr1 named[1048]: the working directory is not writable Mar 9 04:59:01 jpr1 named[1048]: running0630AS 3.AAE> ATA-7 SATA 2.x device Mar 9 05:00:20 jpr1 root: /etc/rc: WARNING: failed to start apache22DMA5, PIO 8192bMar 9 05:00:31 jpr1 kernel: nfe0: promiscuous mode enabled Mar 9 05:00:44 jpr1 bandwidthd: Failed to parse part of log file. Giving up on the fileC) Mar 9 05:02:32 jpr1 su: jack to root on /dev/pts/0d! Mar 9 05:02:56 jpr1 kernel: WARNING: R/W mount of /sites denied. Filesystem is not clean - run fsckpr1 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ada0. Mar 9 05:03:00 jpr1 kernel: WARNING: /sites was not properly dismounted Mar 9 05:17:03 jpr1 kernel: ugen0.2: at usbus0 (disconnected)wered Mar 9 05:17:03 jpr1 kernel: ukbd0: at uhub0, port 2, addr 2 (disconnected)1a Mar 9 06:32:46 jpr1 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ada0 finished. 9 04:58:51 jpr1 kernel: ukbd0: Mar 9 18:51:02 jpr1 kernel: CPU1: local APIC error 0x80 jpr1# pciconf -lv none0@pci0:0:0:0: class=0x050000 card=0x81c01043 chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Host Bridge' class = memory subclass = RAM none1@pci0:0:0:1: class=0x050000 card=0x81c01043 chip=0x02fa10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Memory Controller 0' class = memory subclass = RAM none2@pci0:0:0:2: class=0x050000 card=0x81c01043 chip=0x02fe10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Memory Controller 1' class = memory subclass = RAM none3@pci0:0:0:3: class=0x050000 card=0x81c01043 chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Memory Controller 5' class = memory subclass = RAM none4@pci0:0:0:4: class=0x050000 card=0x81c01043 chip=0x02f910de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Memory Controller 4' class = memory subclass = RAM none5@pci0:0:0:5: class=0x050000 card=0x81c01043 chip=0x02ff10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Host Bridge' class = memory subclass = RAM none6@pci0:0:0:6: class=0x050000 card=0x81c01043 chip=0x027f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Memory Controller 3' class = memory subclass = RAM none7@pci0:0:0:7: class=0x050000 card=0x81c01043 chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C51 Memory Controller 2' class = memory subclass = RAM vgapci0@pci0:0:5:0: class=0x030000 card=0x81cd1043 chip=0x024010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA GeForce 6150 (C51)' class = display subclass = VGA none8@pci0:0:9:0: class=0x050000 card=0x81c01043 chip=0x027010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Host Bridge' class = memory subclass = RAM isab0@pci0:0:10:0: class=0x060100 card=0x81c01043 chip=0x026010de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 LPC Bridge' class = bridge subclass = PCI-ISA nfsmb0@pci0:0:10:1: class=0x0c0500 card=0x81c01043 chip=0x026410de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA nForce PCI System Management (NVIDIA SMB Bus Controller)' class = serial bus subclass = SMBus none9@pci0:0:10:2: class=0x050000 card=0x81c01043 chip=0x027210de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Memory Controller 0' class = memory subclass = RAM ohci0@pci0:0:11:0: class=0x0c0310 card=0x81c01043 chip=0x026d10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:11:1: class=0x0c0320 card=0x81c01043 chip=0x026e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:13:0: class=0x01018a card=0x81c01043 chip=0x026510de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:14:0: class=0x010185 card=0x81c01043 chip=0x026610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA nForce 430/410 Serial ATA Controller (MCP51S)' class = mass storage subclass = ATA atapci2@pci0:0:15:0: class=0x010185 card=0x81c01043 chip=0x026710de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA nForce 430/410 Serial ATA Controller (MCP51S)' class = mass storage subclass = ATA pcib1@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'MCP51 PCI Bridge' class = bridge subclass = PCI-PCI none10@pci0:0:16:1: class=0x040300 card=0x81cb1043 chip=0x026c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'High Definition Audio Controller (MCP51)' class = multimedia subclass = HDA nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Network Bus Enumerator' class = bridge hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class = bridge subclass = HOST-PCI fwohci0@pci0:1:5:0: class=0x0c0010 card=0x808b1043 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr (TSB43AB21/A)' class = serial bus subclass = FireWire rl0@pci0:1:8:0: class=0x020000 card=0x00ff16ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC (RTL-8139/8139C/8139D)' class = network subclass = ethernet On Thu, Mar 3, 2011 at 6:23 PM, Yanhui Shen wrote: > It works fine. > When I grep the dmesg, I can find this message. > > > -- > Best regards, > Yanhui > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 11:19:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9FFE106566B for ; Thu, 10 Mar 2011 11:19:33 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1EAC08FC19 for ; Thu, 10 Mar 2011 11:19:32 +0000 (UTC) Received: by ewy1 with SMTP id 1so492726ewy.13 for ; Thu, 10 Mar 2011 03:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=LNI51aG4+y5NjIxZrtM/oAatGcX3XLFNlraWPK0u3JE=; b=Ib5cbpm39kjZDkKpxzeB8GpXS6TCoqbW7XVPp08WPx9neb58mWY/lq4jcuK7qnJxrv cM34BkeESP/lAyLjmyxd4t9aUmS/WHUI3qGgzo9nwACSj+GIOr3NA4M2tvkXcCXhFac9 vd+YUtT+fyfQV7lLbhPoJhS+HptkySIit3Aug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=oo9cFnq2mQaEDsnnHEUVWpDGR7/fKJRgXbJT34jkN3PJeJEcwxWRu3T7ObUFOfTxfb v5tBIcNQYX974zxrcbhXKMGzDJydydi3bQXKsKa8JlSO8Ea+llVO3lpSGCH86xh6JMgx xalxOMk5zx8dfD/MUATL+a5GFVesRBce91rpM= Received: by 10.14.121.138 with SMTP id r10mr4460677eeh.25.1299755971911; Thu, 10 Mar 2011 03:19:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.31.161 with HTTP; Thu, 10 Mar 2011 03:19:09 -0800 (PST) In-Reply-To: References: <4D6DA259.4050307@sentex.net> <201103030955.23620.jhb@freebsd.org> From: "Jack L." Date: Thu, 10 Mar 2011 03:19:09 -0800 Message-ID: To: Yanhui Shen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 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: Thu, 10 Mar 2011 11:19:33 -0000 Here's what happened when i did a ctrl+alt+del on the console. Mar 10 03:10:23 jpr1 rc.shutdown: 30 second watchdog timeout expired. Shutdown terminated. Mar 10 03:10:23 jpr1 init: /bin/sh on /etc/rc.shutdown terminated abnormally, going to single user mode Mar 10 03:10:23 jpr1 syslogd: exiting on signal 15 Mar 10 03:13:26 jpr1 syslogd: kernel boot file is /boot/kernel/kernel Mar 10 03:13:26 jpr1 kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Mar 10 03:13:26 jpr1 kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...timed out Mar 10 03:13:26 jpr1 kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Mar 10 03:13:26 jpr1 kernel: Syncing disks, vnodes remaining...0 timed out Mar 10 03:13:26 jpr1 kernel: All buffers synced. On Thu, Mar 10, 2011 at 1:50 AM, Jack L. wrote: > I just got the error just now. I'm keeping the machine booted for a > little longer in case someone wants to ask any questions. If I simple > reboot the machine, it will just hang forever and eventually need to > power cycle it. > > Mar =C2=A09 04:58:51 jpr1 kernel: > jack@jpr1.prdhost.com:/usr/obj/usr/src/sys/JPR1 amd64 > Mar =C2=A09 04:58:51 jpr1 kernel: Timecounter "i8254" frequency 1193182 H= z quality 0 > Mar =C2=A09 04:58:51 jpr1 kernel: CPU: AMD Athlon(tm) 64 X2 Dual Core > Processor 6400+ (3214.84-MHz K8-class CPU) > Mar =C2=A09 04:58:51 jpr1 kernel: Origin =3D "AuthenticAMD" =C2=A0Id =3D = 0x40f33 > Family =3D f =C2=A0Model =3D 43 =C2=A0Stepping =3D 3 > Mar =C2=A09 04:58:51 jpr1 kernel: > Features=3D0x178bfbff > Mar =C2=A09 04:58:51 jpr1 kernel: Features2=3D0x2001 > Mar =C2=A09 04:58:51 jpr1 kernel: AMD > Features=3D0xea500800 > Mar =C2=A09 04:58:51 jpr1 kernel: AMD Features2=3D0x1f > Mar =C2=A09 04:58:51 jpr1 kernel: real memory =C2=A0=3D 8589934592 (8192 = MB) > Mar =C2=A09 04:58:51 jpr1 kernel: avail memory =3D 8228098048 (7846 MB) > Mar =C2=A09 04:58:51 jpr1 kernel: ACPI APIC Table: > Mar =C2=A09 04:58:51 jpr1 kernel: FreeBSD/SMP: Multiprocessor System Dete= cted: 2 CPUs > Mar =C2=A09 04:58:51 jpr1 kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) > Mar =C2=A09 04:58:51 jpr1 kernel: cpu0 (BSP): APIC ID: =C2=A00 > Mar =C2=A09 04:58:51 jpr1 kernel: cpu1 (AP): APIC ID: =C2=A01 > Mar =C2=A09 04:58:51 jpr1 kernel: ioapic0: Changing APIC ID to 4 > Mar =C2=A09 04:58:51 jpr1 kernel: ioapic0 irqs 0-23 on moth= erboard > Mar =C2=A09 04:58:51 jpr1 kernel: kbd1 at kbdmux0 > Mar =C2=A09 04:58:51 jpr1 kernel: acpi0: on motherboard > Mar =C2=A09 04:58:51 jpr1 kernel: acpi0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: acpi0: Power Button (fixed) > Mar =C2=A09 04:58:51 jpr1 kernel: acpi0: reservation of 0, a0000 (3) fail= ed > Mar =C2=A09 04:58:51 jpr1 kernel: acpi0: reservation of 100000, cedf0000 = (3) failed > Mar =C2=A09 04:58:51 jpr1 kernel: Timecounter "ACPI-fast" frequency 35795= 45 > Hz quality 1000 > Mar =C2=A09 04:58:51 jpr1 kernel: acpi_timer0: <24-bit timer at > 3.579545MHz> port 0x4008-0x400b on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: cpu0: on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: cpu1: on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: acpi_button0: on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: pcib0: port > 0xcf8-0xcff on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: on pcib0 > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.0 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.1 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.2 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.3 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.4 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.5 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.6 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 0.7 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: vgapci0: mem > 0xfc000000-0xfcffffff,0xd0000000-0xdfffffff,0xfb000000-0xfbffffff irq > 16 at device 5.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 9.0 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: isab0: at device 10.0 = on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: isa0: on isab0 > Mar =C2=A09 04:58:51 jpr1 kernel: nfsmb0: Controller> port 0x4c00-0x4c3f,0x4c40-0x4c7f at device 10.1 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: smbus0: on nfsm= b0 > Mar =C2=A09 04:58:51 jpr1 kernel: smb0: on smbus0 > Mar =C2=A09 04:58:51 jpr1 kernel: nfsmb1: Controller> on nfsmb0 > Mar =C2=A09 04:58:51 jpr1 kernel: smbus1: on nfsm= b1 > Mar =C2=A09 04:58:51 jpr1 kernel: smb1: on smbus1 > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 10.2 (no > driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: ohci0: > mem 0xfe02f000-0xfe02ffff at device 11.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: ohci0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: usbus0: = on ohci0 > Mar =C2=A09 04:58:51 jpr1 kernel: ehci0: controller> mem 0xfe02e000-0xfe02e0ff at device 11.1 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: ehci0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: usbus1: EHCI version 1.0 > Mar =C2=A09 04:58:51 jpr1 kernel: usbus1: controller> on ehci0 > Mar =C2=A09 04:58:51 jpr1 kernel: atapci0: controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfd00-0xfd0f at > device 13.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: ata0: on atapci0 > Mar =C2=A09 04:58:51 jpr1 kernel: ata0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: ata1: on atapci0 > Mar =C2=A09 04:58:51 jpr1 kernel: ata1: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: atapci1: controller> port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf800-0xf80f mem > 0xfe02d000-0xfe02dfff irq 20 at device 14.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: atapci1: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: ata2: on atapci1 > Mar =C2=A09 04:58:51 jpr1 kernel: ata2: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: ata3: on atapci1 > Mar =C2=A09 04:58:51 jpr1 kernel: ata3: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: atapci2: controller> port > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf300-0xf30f mem > 0xfe02c000-0xfe02cfff irq 21 at device 15.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: atapci2: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: ata4: on atapci2 > Mar =C2=A09 04:58:51 jpr1 kernel: ata4: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: ata5: on atapci2 > Mar =C2=A09 04:58:51 jpr1 kernel: ata5: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: pcib1: at device = 16.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: pci1: on pcib1 > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: > mem 0xfddff000-0xfddff7ff,0xfddf8000-0xfddfbfff irq 19 at device 5.0 > on pci1 > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: OHCI version 1.10 (ROM=3D1) > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: No. of Isochronous channels is= 4. > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: EUI64 00:11:d8:00:01:46:4c:23 > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: Phy 1394a available S400, 2 po= rts. > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: Link S400, max_rec 2048 bytes. > Mar =C2=A09 04:58:51 jpr1 kernel: firewire0: on = fwohci0 > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: Initiate bus reset > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: fwohci_intr_core: BUS reset > Mar =C2=A09 04:58:51 jpr1 kernel: fwohci0: fwohci_intr_core: > node_id=3D0x00000000, SelfID Count=3D1, CYCLEMASTER mode > Mar =C2=A09 04:58:51 jpr1 kernel: rl0: port > 0xec00-0xecff mem 0xfddfe000-0xfddfe0ff irq 16 at device 8.0 on pci1 > Mar =C2=A09 04:58:51 jpr1 kernel: miibus0: on rl0 > Mar =C2=A09 04:58:51 jpr1 kernel: rlphy0: interface> PHY 0 on miibus0 > Mar =C2=A09 04:58:51 jpr1 kernel: rlphy0: =C2=A010baseT, 10baseT-FDX, 100= baseTX, > 100baseTX-FDX, auto > Mar =C2=A09 04:58:51 jpr1 kernel: rl0: Ethernet address: 00:14:c1:0e:e6:8= c > Mar =C2=A09 04:58:51 jpr1 kernel: rl0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: pci0: at device 16.1 > (no driver attached) > Mar =C2=A09 04:58:51 jpr1 kernel: nfe0: Adapter> port 0xf200-0xf207 mem 0xfe02b000-0xfe02bfff irq 23 at device > 20.0 on pci0 > Mar =C2=A09 04:58:51 jpr1 kernel: miibus1: on nfe0 > Mar =C2=A09 04:58:51 jpr1 kernel: e1000phy0: > PHY 1 on miibus1 > Mar =C2=A09 04:58:51 jpr1 kernel: e1000phy0: =C2=A010baseT, 10baseT-FDX, > 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, > 1000baseT-FDX-master, auto, auto-flow > Mar =C2=A09 04:58:51 jpr1 kernel: nfe0: Ethernet address: 00:1b:fc:25:43:= 42 > Mar =C2=A09 04:58:51 jpr1 kernel: nfe0: [FILTER] > Mar =C2=A09 04:58:51 jpr1 kernel: amdtemp0: on h= ostb3 > Mar =C2=A09 04:58:51 jpr1 kernel: acpi_tz0: on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: ACPI Warning: For \_TZ_.THRM._PSL: Retu= rn > Package type mismatch at index 0 - found [NULL Object Descriptor], > expected Reference (20101013/nspredef-1197) > Mar =C2=A09 04:58:51 jpr1 kernel: acpi_hpet0: > iomem 0xfefff000-0xfefff3ff irq 0,8 on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: Timecounter "HPET" frequency 25000000 H= z > quality 900 > Mar =C2=A09 04:58:51 jpr1 kernel: atrtc0: port 0x70-0= x73 on acpi0 > Mar =C2=A09 04:58:51 jpr1 kernel: orm0: at iomem > 0xd0000-0xd3fff on isa0 > Mar =C2=A09 04:58:51 jpr1 kernel: sc0: at flags 0x100 on= isa0 > Mar =C2=A09 04:58:51 jpr1 kernel: sc0: VGA <16 virtual consoles, flags=3D= 0x300> > Mar =C2=A09 04:58:51 jpr1 kernel: vga0: at port > 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Mar =C2=A09 04:58:51 jpr1 kernel: atkbdc0: = at > port 0x60,0x64 on isa0 > Mar =C2=A09 04:58:51 jpr1 kernel: atkbd0: irq 1 on atkbdc0 > Mar =C2=A09 04:58:51 jpr1 kernel: kbd0 at atkbd0 > Mar =C2=A09 04:58:51 jpr1 kernel: atkbd0: [GIANT-LOCKED] > Mar =C2=A09 04:58:51 jpr1 kernel: atkbd0: [ITHREAD] > Mar =C2=A09 04:58:51 jpr1 kernel: powernow0: on cpu0 > Mar =C2=A09 04:58:51 jpr1 kernel: device_attach: powernow0 attach returne= d 6 > Mar =C2=A09 04:58:51 jpr1 kernel: powernow1: on cpu1 > Mar =C2=A09 04:58:51 jpr1 kernel: device_attach: powernow1 attach returne= d 6 > Mar =C2=A09 04:58:51 jpr1 kernel: Timecounters tick every 1.000 msec > Mar =C2=A09 04:58:51 jpr1 kernel: firewire0: 1 nodes, maxhop <=3D 0 cable= IRM > irm(0) =C2=A0(me) > Mar =C2=A09 04:58:51 jpr1 kernel: firewire0: bus manager 0 > Mar =C2=A09 04:58:51 jpr1 kernel: IP Filter: v4.1.28 initialized. =C2=A0D= efault > =3D pass all, Logging =3D disabled > Mar =C2=A09 04:58:51 jpr1 kernel: ipfw2 (+ipv6) initialized, divert > loadable, nat loadable, rule-based forwarding enabled, default to > accept, logging disabled > Mar =C2=A09 04:58:51 jpr1 kernel: load_dn_sched dn_sched RR loaded > Mar =C2=A09 04:58:51 jpr1 kernel: load_dn_sched dn_sched WF2Q+ loaded > Mar =C2=A09 04:58:51 jpr1 kernel: load_dn_sched dn_sched FIFO loaded > Mar =C2=A09 04:58:51 jpr1 kernel: load_dn_sched dn_sched PRIO loaded > Mar =C2=A09 04:58:51 jpr1 kernel: load_dn_sched dn_sched QFQ loaded > Mar =C2=A09 04:58:51 jpr1 kernel: usbus0: 12Mbps Full Speed USB v1.0 > Mar =C2=A09 04:58:51 jpr1 kernel: usbus1: 480Mbps High Speed USB v2.0 > Mar =C2=A09 04:58:51 jpr1 kernel: ugen0.1: at usbus0 > Mar =C2=A09 04:58:51 jpr1 kernel: uhub0: rev 1.00/1.00, addr 1> on usbus0 > Mar =C2=A09 04:58:51 jpr1 kernel: ugen1.1: at usbus1 > Mar =C2=A09 04:58:51 jpr1 kernel: uhub1: rev 2.00/1.00, addr 1> on usbus1 > Mar =C2=A09 04:58:58 jpr1 named[1048]: starting BIND 9.6.3 -t /var/named = -u bind > Mar =C2=A09 04:58:58 jpr1 named[1048]: built with '--prefix=3D/usr' > '--infodir=3D/usr/share/info' '--mandir=3D/usr/share/man' > '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' > '--with-openssl=3D/usr' '--with-randomdev=3D/dev/random' '--without-idn' > '--without-libxml2' > Mar =C2=A09 04:59:00 jpr1 named[1048]: command channel listening on > 127.0.0.1#953 63S/T 1Mar =C2=A09 04:59:00 jpr1 named[1048]: command chann= el > listening on ::1#953 > Mar =C2=A09 04:59:00 jpr1 named[1048]: the working directory is not writa= ble > Mar =C2=A09 04:59:01 jpr1 named[1048]: running0630AS 3.AAE> ATA-7 SATA 2.= x device > Mar =C2=A09 05:00:20 jpr1 root: /etc/rc: WARNING: failed to start > apache22DMA5, PIO 8192bMar =C2=A09 05:00:31 jpr1 kernel: nfe0: promiscuou= s > mode enabled > Mar =C2=A09 05:00:44 jpr1 bandwidthd: Failed to parse part of log file. > Giving up on the fileC) > Mar =C2=A09 05:02:32 jpr1 su: jack to root on /dev/pts/0d! > Mar =C2=A09 05:02:56 jpr1 kernel: WARNING: R/W mount of /sites denied. > Filesystem is not clean - run fsckpr1 kernel: GEOM_MIRROR: Device gm0: > rebuilding provider ada0. > Mar =C2=A09 05:03:00 jpr1 kernel: WARNING: /sites was not properly dismou= nted > Mar =C2=A09 05:17:03 jpr1 kernel: ugen0.2: at usbus0 (disconnected= )wered > Mar =C2=A09 05:17:03 jpr1 kernel: ukbd0: at uhub0, port 2, addr 2 (discon= nected)1a > Mar =C2=A09 06:32:46 jpr1 kernel: GEOM_MIRROR: Device gm0: rebuilding > provider ada0 finished. 9 04:58:51 jpr1 kernel: ukbd0: Keyboard, class 0/0, rev 1.10/3.0Mar =C2=A09 12:07:03 jpr1 sm-mta[4761]: > p29K73lP004759: SYSERR(root): portalnations.com. config error: mail > loops back to me (MX problem?) > Mar =C2=A09 12:59:40 jpr1 kernel: pid 3022 (httpd), uid 80: exited on > signal 6stem is notMar =C2=A09 12:59:48 jpr1 kernel: pid 3257 (httpd), ui= d > 80: exited on signal 6 > Mar =C2=A09 13:00:10 jpr1 kernel: pid 2987 (httpd), uid 80: exited on sig= nal 6 > Mar =C2=A09 13:00:34 jpr1 kernel: pid 2816 (httpd), uid 80: exited on > signal 6stem is notMar =C2=A09 14:53:21 jpr1 sm-mta[5354]: p29MpT1o005354= : > SYSERR(root): collect: I/O error on connection from [190.43.98.182], > from=3D > Mar =C2=A09 18:51:02 jpr1 kernel: CPU1: local APIC error 0x80 > > jpr1# pciconf -lv > none0@pci0:0:0:0: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x02f010de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Host Bridge' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none1@pci0:0:0:1: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x02fa10de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Memory Controller 0' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none2@pci0:0:0:2: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x02fe10de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Memory Controller 1' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none3@pci0:0:0:3: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x02f810de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Memory Controller 5' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none4@pci0:0:0:4: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x02f910de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Memory Controller 4' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none5@pci0:0:0:5: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x02ff10de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Host Bridge' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none6@pci0:0:0:6: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x027f10de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Memory Controller 3' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > none7@pci0:0:0:7: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x027e10de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'C51 Memory Controller 2' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > vgapci0@pci0:0:5:0: =C2=A0 =C2=A0 class=3D0x030000 card=3D0x81cd1043 chip= =3D0x024010de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'NVIDIA GeForce 6150 (C51)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D display > =C2=A0 =C2=A0subclass =C2=A0 =3D VGA > none8@pci0:0:9:0: =C2=A0 =C2=A0 =C2=A0 class=3D0x050000 card=3D0x81c01043= chip=3D0x027010de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 Host Bridge' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > isab0@pci0:0:10:0: =C2=A0 =C2=A0 =C2=A0class=3D0x060100 card=3D0x81c01043= chip=3D0x026010de > rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 LPC Bridge' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D PCI-ISA > nfsmb0@pci0:0:10:1: =C2=A0 =C2=A0 class=3D0x0c0500 card=3D0x81c01043 chip= =3D0x026410de > rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'NVIDIA nForce PCI System Managemen= t (NVIDIA SMB Bus > Controller)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D serial bus > =C2=A0 =C2=A0subclass =C2=A0 =3D SMBus > none9@pci0:0:10:2: =C2=A0 =C2=A0 =C2=A0class=3D0x050000 card=3D0x81c01043= chip=3D0x027210de > rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 Memory Controller 0' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D memory > =C2=A0 =C2=A0subclass =C2=A0 =3D RAM > ohci0@pci0:0:11:0: =C2=A0 =C2=A0 =C2=A0class=3D0x0c0310 card=3D0x81c01043= chip=3D0x026d10de > rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 USB Controller' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D serial bus > =C2=A0 =C2=A0subclass =C2=A0 =3D USB > ehci0@pci0:0:11:1: =C2=A0 =C2=A0 =C2=A0class=3D0x0c0320 card=3D0x81c01043= chip=3D0x026e10de > rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 USB Controller' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D serial bus > =C2=A0 =C2=A0subclass =C2=A0 =3D USB > atapci0@pci0:0:13:0: =C2=A0 =C2=A0class=3D0x01018a card=3D0x81c01043 chip= =3D0x026510de > rev=3D0xa1 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 Parallel ATA Controller' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D mass storage > =C2=A0 =C2=A0subclass =C2=A0 =3D ATA > atapci1@pci0:0:14:0: =C2=A0 =C2=A0class=3D0x010185 card=3D0x81c01043 chip= =3D0x026610de > rev=3D0xa1 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'NVIDIA nForce 430/410 Serial ATA C= ontroller (MCP51S)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D mass storage > =C2=A0 =C2=A0subclass =C2=A0 =3D ATA > atapci2@pci0:0:15:0: =C2=A0 =C2=A0class=3D0x010185 card=3D0x81c01043 chip= =3D0x026710de > rev=3D0xa1 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'NVIDIA nForce 430/410 Serial ATA C= ontroller (MCP51S)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D mass storage > =C2=A0 =C2=A0subclass =C2=A0 =3D ATA > pcib1@pci0:0:16:0: =C2=A0 =C2=A0 =C2=A0class=3D0x060401 card=3D0xcb8410de= chip=3D0x026f10de > rev=3D0xa2 hdr=3D0x01 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 PCI Bridge' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D PCI-PCI > none10@pci0:0:16:1: =C2=A0 =C2=A0 class=3D0x040300 card=3D0x81cb1043 chip= =3D0x026c10de > rev=3D0xa2 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'High Definition Audio Controller (= MCP51)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D multimedia > =C2=A0 =C2=A0subclass =C2=A0 =3D HDA > nfe0@pci0:0:20:0: =C2=A0 =C2=A0 =C2=A0 class=3D0x068000 card=3D0x816a1043= chip=3D0x026910de > rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'NVIDIA Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'MCP51 Network Bus Enumerator' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > hostb0@pci0:0:24:0: =C2=A0 =C2=A0 class=3D0x060000 card=3D0x00000000 chip= =3D0x11001022 > rev=3D0x00 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Advanced Micro Devices (AMD)' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Athlon64/Opteron/Sempron (K8 Famil= y) HyperTransport > Technology Configuration' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D HOST-PCI > hostb1@pci0:0:24:1: =C2=A0 =C2=A0 class=3D0x060000 card=3D0x00000000 chip= =3D0x11011022 > rev=3D0x00 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Advanced Micro Devices (AMD)' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Athlon64/Opteron/Sempron (K8 Famil= y) Address Map' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D HOST-PCI > hostb2@pci0:0:24:2: =C2=A0 =C2=A0 class=3D0x060000 card=3D0x00000000 chip= =3D0x11021022 > rev=3D0x00 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Advanced Micro Devices (AMD)' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Athlon64/Opteron/Sempron (K8 Famil= y) DRAM Controller' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D HOST-PCI > hostb3@pci0:0:24:3: =C2=A0 =C2=A0 class=3D0x060000 card=3D0x00000000 chip= =3D0x11031022 > rev=3D0x00 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Advanced Micro Devices (AMD)' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Athlon64/Opteron/Sempron (K8 Famil= y) Miscellaneous Control' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D HOST-PCI > fwohci0@pci0:1:5:0: =C2=A0 =C2=A0 class=3D0x0c0010 card=3D0x808b1043 chip= =3D0x8023104c > rev=3D0x00 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Texas Instruments (TI)' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'IEEE1394a-2000 OHCI PHY/Link-Layer= Ctrlr (TSB43AB21/A)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D serial bus > =C2=A0 =C2=A0subclass =C2=A0 =3D FireWire > rl0@pci0:1:8:0: class=3D0x020000 card=3D0x00ff16ec chip=3D0x813910ec rev= =3D0x10 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Realtek Semiconductor' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Realtek RTL8139 Family PCI Fast Et= hernet NIC > (RTL-8139/8139C/8139D)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D network > =C2=A0 =C2=A0subclass =C2=A0 =3D ethernet > > > On Thu, Mar 3, 2011 at 6:23 PM, Yanhui Shen wrote: >> It works fine. >> When I grep the dmesg, I can find this message. >> >> >> -- >> Best regards, >> Yanhui >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " >> > From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 16:35:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C25106564A for ; Thu, 10 Mar 2011 16:35:33 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp1.sbb.rs (smtp1.sbb.rs [89.216.2.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4268FC15 for ; Thu, 10 Mar 2011 16:35:32 +0000 (UTC) Received: from localhost (cable-94-189-176-79.dynamic.sbb.rs [94.189.176.79]) by smtp1.sbb.rs (8.14.0/8.14.0) with ESMTP id p2AGFRDk029188 for ; Thu, 10 Mar 2011 17:15:27 +0100 Date: Thu, 10 Mar 2011 17:15:27 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20110310161527.GA1252@pilgrim.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 Subject: Re: happy hacker lite 2 keyboard 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: Thu, 10 Mar 2011 16:35:33 -0000 Quite late return to the subject. I finally ordered one for myself and have a question regarding it's usage with 64 bit system. All newer HH keuboards are usb ones. Manufacturer doesn't confirm connection to ps/2 port with usb to ps/2 adapter. Is there any reason not to do that on amd64? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 17:31:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36D611065672 for ; Thu, 10 Mar 2011 17:31:42 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 096D68FC16 for ; Thu, 10 Mar 2011 17:31:41 +0000 (UTC) Received: by iyj12 with SMTP id 12so2092995iyj.13 for ; Thu, 10 Mar 2011 09:31:41 -0800 (PST) Received: by 10.43.71.82 with SMTP id yj18mr7852657icb.39.1299778301366; Thu, 10 Mar 2011 09:31:41 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id uf10sm2400276icb.17.2011.03.10.09.31.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 09:31:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <20110310161527.GA1252@pilgrim.sbb.rs> Date: Thu, 10 Mar 2011 11:31:38 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20110310161527.GA1252@pilgrim.sbb.rs> User-Agent: Opera Mail/11.01 (FreeBSD) Subject: Re: happy hacker lite 2 keyboard 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: Thu, 10 Mar 2011 17:31:42 -0000 On Thu, 10 Mar 2011 10:15:27 -0600, Zoran Kolic wrote: > Quite late return to the subject. I finally ordered one for > myself and have a question regarding it's usage with 64 bit > system. > All newer HH keuboards are usb ones. Manufacturer doesn't > confirm connection to ps/2 port with usb to ps/2 adapter. > Is there any reason not to do that on amd64? Hrm, strange that a nice keyboard like that comes as USB only. My Adesso comes natively as PS/2 but has a PS/2 to USB converter that works flawlessly. The idea is that PS/2 is better for keyboards because it allows you to simultaneously press more keys at once than USB can handle. Anyway, I've had really bad luck with off the shelf adapters. You are probably OK with just running it as USB. Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 18:11:26 2011 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 E66181065709; Thu, 10 Mar 2011 18:11:26 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 75E678FC13; Thu, 10 Mar 2011 18:11:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id p2AIBLTx060746; Thu, 10 Mar 2011 21:11:21 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 10 Mar 2011 21:11:21 +0300 (MSK) From: Dmitry Morozovsky To: Pawel Jakub Dawidek Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (woozle.rinet.ru [0.0.0.0]); Thu, 10 Mar 2011 21:11:21 +0300 (MSK) Cc: stable@FreeBSD.org Subject: gmirror start bug? 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: Thu, 10 Mar 2011 18:11:27 -0000 Dear Pawel, it seems thet gmirror is entering the endless loop if one inserted disk with previously configured mirror part in syncronyzing state: root@moose:/media/sata# gmirror list m0g Geom name: m0g State: STARTING Components: 2 Balance: split Slice: 4096 Flags: NONE GenID: 0 SyncID: 0 ID: 2992987948 Consumers: 1. Name: ad22g Mediasize: 272441875968 (254G) Sectorsize: 512 Mode: r1w1e1 State: NEW Priority: 0 Flags: SYNCHRONIZING GenID: 0 SyncID: 2 ID: 3619189671 root@moose:/media/sata# gmirror stop m0g ; gmirror clear ad22g Can't clear metadata on ad22g: Operation not permitted. gmirror: Not fully done. from kernel log: Mar 10 21:04:31 moose kernel: GEOM_MIRROR: Force device m0g start due to timeout. Mar 10 21:04:31 moose kernel: GEOM_MIRROR: Device m0g destroyed. Mar 10 21:04:35 moose kernel: GEOM_MIRROR: Force device m0g start due to timeout. Mar 10 21:04:35 moose kernel: GEOM_MIRROR: Device m0g destroyed. Mar 10 21:04:39 moose kernel: GEOM_MIRROR: Force device m0g start due to timeout. Mar 10 21:04:39 moose kernel: GEOM_MIRROR: Device m0g destroyed. ... In my case, a workaround was: detach broken disk, configure mirror with the same name (I did it over md), then gmirror clear ad22g -- but I suppose this situation should be somehow detected and loop broken. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 18:35:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711EE106564A for ; Thu, 10 Mar 2011 18:35:12 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADB98FC0C for ; Thu, 10 Mar 2011 18:35:11 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p2AIOeKp042851; Thu, 10 Mar 2011 10:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1299781481; bh=SxwUgBlaVv+95chkQo3lghwaYsfcQv+v4A/Y0UA7XqE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=i24BT1rO1s+MDBw9/CLO6ZqYYpvQ9sxNtYalC/xhZU90S9hZXLw1OQgB0eLknsJQP jlBdU/GqIS1+u0+dRCTM2Z5KiK9yvr7ZnXIzrjC531VNChQ3fqeYJDv+miF027DOaJ oPlNFt8vtwub3N05kaNs0Y5ly/JRlgyw6rPOUp4g= From: Sean Bruno To: Pete French In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Mar 2011 10:24:40 -0800 Message-ID: <1299781480.2617.5.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: em0 hangs without any messages like "Watchdog timeout" only down/up reset it. 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: Thu, 10 Mar 2011 18:35:12 -0000 On Thu, 2011-02-24 at 03:03 -0800, Pete French wrote: > I havent investigated far enough yet to see if this is the same problem, but > I am also seeing hangs on em0 when under heavy load. This is 8-STABLE from > the 17 at around 3pm. > > em0@pci0:0:25:0: class=0x020000 card=0x281e103c chip=0x10bd8086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' > class = network > subclass = ethernet > > What I am doing here is using ggated/ggatec to provide drives to another > machine which is adding them into a ZFS pool. This locks up the ethernet > in about 20 minutes. Going to concole on the machine all looks fine, > but it is not possible to ping anything through the em0 interface. > > I have no special tunings for em0, though I do have expanded buffer > space to improve the ggated performance > > kern.ipc.maxsockbuf=1048576 > net.inet.tcp.sendspace=131072 > net.inet.tcp.recvspace=131072 > > Machine is amd64 with 6 gig of RAM. > > -pete. > _____________________________________ If you ifconfig down/up the interface does it come back to life? Sean From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 19:26:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 6019D1065672 for ; Thu, 10 Mar 2011 19:26:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8C7E314F542; Thu, 10 Mar 2011 19:26:17 +0000 (UTC) Message-ID: <4D7925D9.5040901@FreeBSD.org> Date: Thu, 10 Mar 2011 11:26:17 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mark Felder References: <20110310161527.GA1252@pilgrim.sbb.rs> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: happy hacker lite 2 keyboard 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: Thu, 10 Mar 2011 19:26:18 -0000 On 03/10/2011 09:31, Mark Felder wrote: > Hrm, strange that a nice keyboard like that comes as USB only. It's not _that_ strange. PS/2 doesn't allow for safe hot-plugging, USB does. And very few typists are going to exceed the keyrate of USB. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 20:41:26 2011 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 E4F2A106564A for ; Thu, 10 Mar 2011 20:41:26 +0000 (UTC) (envelope-from m.tsatsenko@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F02F8FC17 for ; Thu, 10 Mar 2011 20:41:26 +0000 (UTC) Received: by wyf23 with SMTP id 23so2223340wyf.13 for ; Thu, 10 Mar 2011 12:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=HOJzIXzmgyr/rkSNZxFVSuQn858MsVEvPmhxArur5wk=; b=wYubXFL+eNQ47TjK3igOMD6wbbdgzq//EIfFHUyurz8c+X8bTn+OM6iqMHvYqBWpe1 R1ESmr9JMtXSSTDiJ0EXHhSb6k02BEzbPwytQKsYyYVziHtQj4PekCU8NQr0/nwRM1t0 WATBsJ1qbumit58S5FaDIGiyLPAvuxnVSJzFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZPk/RLjq2Tlzgw2Ar7WgdneFNfOexxV5jsAuH8VjidHZN/DKipH3yCKLNgvqon3gtt P37GM1hq2Jo9xVmhb01opC4i+VGiiSu6/UcwBTPNKqGLCH27CJh2d8MuJW8FA6IRZZZJ ZoVmcAIio2AvpUXOre1am6g+5c1Ux2sd79RBw= MIME-Version: 1.0 Received: by 10.216.141.72 with SMTP id f50mr450576wej.26.1299788302502; Thu, 10 Mar 2011 12:18:22 -0800 (PST) Received: by 10.216.15.9 with HTTP; Thu, 10 Mar 2011 12:18:22 -0800 (PST) Date: Thu, 10 Mar 2011 23:18:22 +0300 Message-ID: From: Mikhail Tsatsenko To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: kldload if_carp fails on 8.2 when kernel built without SCTP option -- link_elf_obj: symbol sha1_loop undefined 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: Thu, 10 Mar 2011 20:41:27 -0000 Hello! I have amd64 FreeBSD-8.2 box and found that kldload'ing if_carp fails with "link_elf_obj: symbol sha1_loop undefined" message. When using a kernel with SCTP option the problem goes away. Is it intentional? Is carp really needs SCTP? Also if I run ld manually the module loads fine: cd /usr/src/sys/modules/if_carp && make && ld -d -warn-common -r -d -o if_carp.ko ip_carp.o /usr/obj/usr/src/sys/XGATE/modules/usr/src/sys/modules/crypto/sha1.o && make load. Unfortunately I am not familiar with with kernel build process and need advice how to make happy if_carp module and my kernel. -- Mikhail From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 20:48:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80072106564A for ; Thu, 10 Mar 2011 20:48:04 +0000 (UTC) (envelope-from eric@egsner.cirr.com) Received: from egsner.cirr.com (egsner.cirr.com [IPv6:2620:0:de0::1]) by mx1.freebsd.org (Postfix) with ESMTP id 23B638FC0C for ; Thu, 10 Mar 2011 20:48:03 +0000 (UTC) Received: from egsner.cirr.com (IDENT:eric@localhost [127.0.0.1]) by egsner.cirr.com (8.14.4/8.14.2/$Revision: 1.32 $) with ESMTP id p2AKm3Fq015932 for ; Thu, 10 Mar 2011 14:48:03 -0600 (CST) Message-Id: <201103102048.p2AKm3Fq015932@egsner.cirr.com> From: eric@cirr.com (Eric Schnoebelen) To: freebsd-stable@freebsd.org In-reply-to: Your message of "Thu, 10 Mar 2011 11:31:38 CST." Date: Thu, 10 Mar 2011 14:48:03 -0600 Sender: eric@cirr.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.6 (egsner.cirr.com [127.0.0.1]); Thu, 10 Mar 2011 14:48:03 -0600 (CST) Subject: Re: happy hacker lite 2 keyboard 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: Thu, 10 Mar 2011 20:48:04 -0000 "Mark Felder" writes: - On Thu, 10 Mar 2011 10:15:27 -0600, Zoran Kolic wrote: - > All newer HH keuboards are usb ones. Manufacturer doesn't - > confirm connection to ps/2 port with usb to ps/2 adapter. - > Is there any reason not to do that on amd64? - - - Hrm, strange that a nice keyboard like that comes as USB only. The orginal Happy Hacker was PS2. I have two of those, as well as two of the USB HH2's.. I don't know if the original Happy Hacker keyboard is still available, it hasn't been an issue for me. :D -- Eric Schnoebelen eric@cirr.com http://www.cirr.com "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 21:19:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A514106564A for ; Thu, 10 Mar 2011 21:19:41 +0000 (UTC) (envelope-from dustinwenz@xtechllc.com) Received: from internet02.xtechllc.com (internet02.xtechllc.com [65.127.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id 332358FC19 for ; Thu, 10 Mar 2011 21:19:40 +0000 (UTC) Received: from service02.office.ebureau.com (service02.office.ebureau.com [192.168.20.15]) by internet02.xtechllc.com (Postfix) with ESMTP id 907A17202C0 for ; Thu, 10 Mar 2011 15:00:20 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by service02.office.ebureau.com (Postfix) with ESMTP id 8C810672F140 for ; Thu, 10 Mar 2011 15:00:20 -0600 (CST) X-Virus-Scanned: amavisd-new at ebureau.com Received: from service02.office.ebureau.com ([127.0.0.1]) by localhost (service02.office.iscompanies.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md2LlXFQkyFB for ; Thu, 10 Mar 2011 15:00:19 -0600 (CST) Received: from square.office.iscompanies.com (square.office.iscompanies.com [10.10.20.22]) by service02.office.ebureau.com (Postfix) with ESMTPSA id EBC0A672F132 for ; Thu, 10 Mar 2011 15:00:19 -0600 (CST) From: Dustin Wenz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 15:00:19 -0600 Message-Id: <2D5317E3-D96F-4123-88D5-5AF1BEAD5B9F@xtechllc.com> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: LSI SAS2008 performance with mps(4) driver 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: Thu, 10 Mar 2011 21:19:41 -0000 I'm running a build of the mps(4) driver on FreeBSD 8.2 with an LSI = SAS2008 bus adapter. The code I'm using was current as of the last = commit on 2011-02-25, and is built for amd64. I can't seem to get any better performance than about 250MB/s writes = through the controller. I'm testing with a zpool of six 250MB magnetic = SATA disks, doing a couple of concurrent sequential writes with dd: dd bs=3D128k if=3D/dev/zero of=3D/datadisk/zero1 & dd bs=3D128k if=3D/dev/zero of=3D/datadisk/zero2 & This is in comparison to an older LSI C1068E controller using the mpt = driver with an identical 6-disk zpool. Such a configuration can easily = sustain 500MB/s writes. A devlist from camcontrol reports: scbus0 on mps0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3,da3) at scbus0 target 4 lun 0 (pass4,da4) at scbus0 target 5 lun 0 (pass5,da5) at scbus0 target 6 lun 0 (pass6,da6) at scbus0 target 7 lun 0 (pass7,da7) scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) I realize that this driver is fairly new; if there is any information = that would be helpful in finding the bottleneck, I would be happy to = provide it. Thanks! - .Dustin= From owner-freebsd-stable@FreeBSD.ORG Thu Mar 10 22:29:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05AC81065670 for ; Thu, 10 Mar 2011 22:29:57 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ticketswitch.com (constantine.ingresso.co.uk [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id BF97C8FC14 for ; Thu, 10 Mar 2011 22:29:56 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PxoMi-0000Iq-So; Thu, 10 Mar 2011 22:29:53 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PxoMi-000PBQ-Rt; Thu, 10 Mar 2011 22:29:52 +0000 Date: Thu, 10 Mar 2011 22:29:52 +0000 Message-Id: To: petefrench@ingresso.co.uk, seanbru@yahoo-inc.com In-Reply-To: <1299781480.2617.5.camel@hitfishpass-lx.corp.yahoo.com> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: em0 hangs without any messages like "Watchdog timeout" only down/up reset it. 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: Thu, 10 Mar 2011 22:29:57 -0000 > If you ifconfig down/up the interface does it come back to life? Nope - has no effect. See another separate post of mine about how I added another em card, and that works fine. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 00:32:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4E31106566B for ; Fri, 11 Mar 2011 00:32:39 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:266:e1ff:fe0c:8f16]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDBA8FC0A for ; Fri, 11 Mar 2011 00:32:38 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p2B0WZAT079922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Mar 2011 11:02:35 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Mar 2011 11:02:35 +1030 To: freebsd-stable List Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Subject: if_bridge and IPv6 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: Fri, 11 Mar 2011 00:32:39 -0000 Hi, I have a bridge interface with em0 and tap0/tap1 on it to run a layer 2 = VPN. I find that em0 gets an IPv6 link local address but bridge0 does not = (via net.inet6.ip6.auto_linklocal). I did some googling and it seems = that this is a deliberate policy decision, and unfortunately you can't = change it on a per interface basis :) It would be nice if I could suppress automatic link local for em0 and = enable it on bridge0 rather than having to delete & add them manually. Also, does anyone have a code snippet handy for generating link local = addresses? My google-fu was unable to find a description.. Thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 04:09:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9371065670 for ; Fri, 11 Mar 2011 04:09:31 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07AD68FC15 for ; Fri, 11 Mar 2011 04:09:30 +0000 (UTC) Received: by qwj8 with SMTP id 8so2013025qwj.13 for ; Thu, 10 Mar 2011 20:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=71eObGE/0bqwp99CUpWAYtOXDnZ0/kpvTCf1O/qVMcY=; b=qgiiU8mhtfsYBwZQmNPYTd0bUCLjdz1qOi7/F5sXFsx9GEimt9jipLbNJqYFEz2I5X 56diABIERx0CEvaMF44IJTmuylcDyIdIsOVgDaOAlA5sgs+65Xy2V0rrI+LzouItqnkM QqHFACBlZ2oFf6nbyQp94dhTbWg3+LjB5Sfxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iqOhfJdFjn0XTQvrhI3Urrhi4/tiGFVBEeL4UeyHP1r6+mcbHYeSsHepWojYZM+8qm f+RIjq6j4WFAyS58DDmijPOaUAlCfQDLTQPeoHTB9k8VCS5+xWBrYnHD2AszBV2xRZFP jYtiq9GQIH+MSVQWWrOggAPGdlRzk9MJ+aEvg= MIME-Version: 1.0 Received: by 10.229.234.12 with SMTP id ka12mr7170428qcb.66.1299816570210; Thu, 10 Mar 2011 20:09:30 -0800 (PST) Received: by 10.229.226.10 with HTTP; Thu, 10 Mar 2011 20:09:30 -0800 (PST) In-Reply-To: <2D5317E3-D96F-4123-88D5-5AF1BEAD5B9F@xtechllc.com> References: <2D5317E3-D96F-4123-88D5-5AF1BEAD5B9F@xtechllc.com> Date: Thu, 10 Mar 2011 20:09:30 -0800 Message-ID: From: Rumen Telbizov To: Dustin Wenz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: LSI SAS2008 performance with mps(4) driver 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: Fri, 11 Mar 2011 04:09:31 -0000 Hello Dustin, I've been testing this SAS2008 LSI chip (on a LSI 9211-8i) for the last month or so and I can say that it makes a pretty good HBA but there are indeed a few caveats you might need to be aware of. In support of that - tonight I finished a FreeBSD 8.2-STABLE machine with 2 x 24 disk chassis (each with a 3Gbit expander) = 48 x 2TB SATA RE4-GP disks in 6 x 8disk raidz2 and I am able to squeeze out 900MB/s write and 1200 MB/s read in a sequential (single dd) manner. The limit here is the backplane speed. So back to your problem: 1) What kind of backplane are you using: please specify the exact model. Is it a SAS expander or direct attached? 3Gbit/s or 6Gbit/s? 2) What kind of disk controller exactly are you using? More importantly what kind of firmware does it have? Those two are very important. In my case it turned out that if I was connecting SAS2008 chips to pretty much every kind of SuperMicro SAS expander backplanes (tried against 826EL26, 836E1, 846E1) I was getting around 200-300MB/s read/write speeds (FreeBSD and Linux). Direct attached backplanes (826A) worked fine. At the end it turned out that it was some sort of a problem with the LSI firmware (version 8.00 in my case) and I was given to try version 9.00 (soon to be released) which completely solved the problem. Contact LSI support (very high quality) if you want to try this firmware. I can't seem to get any better performance than about 250MB/s writes through > the controller. I'm testing with a zpool of six 250MB magnetic SATA disks, > doing a couple of concurrent sequential writes with dd: > > dd bs=128k if=/dev/zero of=/datadisk/zero1 & > dd bs=128k if=/dev/zero of=/datadisk/zero2 & > > 3) What kind of zpool raid level do you have those disks organized in? 4) Running two parallel dd's on the same pool will actually turn the game into no-so-sequential type and more of a random access. Please try the following and paste results here: 4.1) dd if=/dev/zero of=/datadisk/zero1 bs=1M count=50000 (only one dd and use a file size larger than your memory) 4.2) Destroy the zpool (if you have no useful data on it of course) and try dd against each and every disk individually. So something like: dd if=/dev/zero of=/dev/da0 bs=1M count=50000 dd if=/dev/da0 of=/dev/null bs=1M count=50000 monitor throughput with gstat -f da0 or I can send you a simple C program that I wrote which resembles dd but prints stats every second. On a related note I also experienced very slow read speeds (200MB/s) with the above mentioned configuration and after enabling prefetch (I used to set it to disabled as per Jeremy Chadwick's advise) everything went back to normal - so keep it in mind. Cheers, Rumen Telbizov -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 05:19:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDF301065670 for ; Fri, 11 Mar 2011 05:19:08 +0000 (UTC) (envelope-from carlj@peak.org) Received: from oak.localnet (unknown [IPv6:2001:1938:266:0:6ef0:49ff:fe05:658b]) by mx1.freebsd.org (Postfix) with ESMTP id 68B298FC0C for ; Fri, 11 Mar 2011 05:19:08 +0000 (UTC) Received: from oak.localnet (localhost [127.0.0.1]) by oak.localnet (Postfix) with ESMTP id A276DC321 for ; Thu, 10 Mar 2011 21:19:00 -0800 (PST) Received: (from carlj@localhost) by oak.localnet (8.14.4/8.14.4/Submit) id p2B5J0FA090515; Thu, 10 Mar 2011 21:19:00 -0800 (PST) (envelope-from carlj@peak.org) X-Authentication-Warning: oak.localnet: carlj set sender to carlj@peak.org using -f From: Carl Johnson To: freebsd-stable@freebsd.org References: Mail-Followup-To: freebsd-stable@freebsd.org Date: Thu, 10 Mar 2011 21:19:00 -0800 In-Reply-To: (Daniel O'Connor's message of "Fri, 11 Mar 2011 11:02:35 +1030") Message-ID: <87oc5i5j5n.fsf@oak.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: if_bridge and IPv6 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: Fri, 11 Mar 2011 05:19:09 -0000 "Daniel O'Connor" writes: > Hi, I have a bridge interface with em0 and tap0/tap1 on it to run a > layer 2 VPN. > > I find that em0 gets an IPv6 link local address but bridge0 does not > (via net.inet6.ip6.auto_linklocal). I did some googling and it seems > that this is a deliberate policy decision, and unfortunately you can't > change it on a per interface basis :) > > It would be nice if I could suppress automatic link local for em0 and > enable it on bridge0 rather than having to delete & add them manually. > > Also, does anyone have a code snippet handy for generating link local > addresses? My google-fu was unable to find a description.. You should be able to do something like the following: ifconfig bridge0 inet6 fe80:: eui64 add That assumes that it has a MAC address already assigned. I can't help if it doesn't have one yet. -- Carl Johnson carlj@peak.org From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 05:38:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 325E4106564A for ; Fri, 11 Mar 2011 05:38:40 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id B0CCF8FC08 for ; Fri, 11 Mar 2011 05:38:38 +0000 (UTC) Received: from ameno.mahoroba.org (IDENT:hIBoUY14ra6fG17fMTMriYz9pnmrKFaKzsZgfXZn/hEpjZGD1LvUe2zsueoOdBrL@ameno.mahoroba.org [IPv6:2001:2f0:104:8010:20a:79ff:fe69:ee6b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p2B5cVPQ068033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 14:38:31 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 11 Mar 2011 14:38:31 +0900 Message-ID: From: Hajimu UMEMOTO To: Carl Johnson In-Reply-To: <87oc5i5j5n.fsf@oak.localnet> References: <87oc5i5j5n.fsf@oak.localnet> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Fri_Mar_11_14:38:28_2011-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 11 Mar 2011 14:38:31 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: freebsd-stable@freebsd.org Subject: Re: if_bridge and IPv6 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: Fri, 11 Mar 2011 05:38:40 -0000 --Multipart_Fri_Mar_11_14:38:28_2011-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Thu, 10 Mar 2011 21:19:00 -0800 >>>>> Carl Johnson said: carlj> You should be able to do something like the following: carlj> ifconfig bridge0 inet6 fe80:: eui64 add carlj> That assumes that it has a MAC address already assigned. I can't help carlj> if it doesn't have one yet. Unfortunately, eui64 option doesn't support link-local address. You need to specify link-local address, explicitly. Here is a patch to support it. Sincerely, --Multipart_Fri_Mar_11_14:38:28_2011-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ifconfig-af_inet6.c-linklocal.diff" Content-Transfer-Encoding: 7bit Index: sbin/ifconfig/af_inet6.c diff -u -p sbin/ifconfig/af_inet6.c.orig sbin/ifconfig/af_inet6.c --- sbin/ifconfig/af_inet6.c.orig 2009-11-21 20:28:57.783110487 +0900 +++ sbin/ifconfig/af_inet6.c 2009-11-23 21:00:02.212252557 +0900 @@ -36,6 +36,9 @@ static const char rcsid[] = #include #include #include +#include +#include +#include #include #include @@ -130,6 +133,56 @@ setip6vltime(const char *seconds, int du setip6lifetime("vltime", seconds, s, afp); } +static struct sockaddr_dl * +getsdl(struct ifaddrs *ifap, char *ifname) +{ + struct ifaddrs *ifa; + struct sockaddr_dl *sdl = NULL; + + for (ifa = ifap; ifa; ifa = ifa->ifa_next) { + if (ifname != NULL && strcmp(ifa->ifa_name, ifname) != 0) + continue; + if (ifa->ifa_addr == NULL) + continue; + if (ifa->ifa_addr->sa_family != AF_LINK) + continue; + sdl = (struct sockaddr_dl *)ifa->ifa_addr; + if (sdl == NULL) + continue; + if (sdl->sdl_type != IFT_ETHER || + sdl->sdl_alen != ETHER_ADDR_LEN) { + sdl = NULL; + continue; + } + break; + } + return (sdl); +} + +static void +link2eui64(struct ifaddrs *ifap, struct in6_addr *in6) +{ + struct sockaddr_dl *sdl; + char *cp; + + sdl = getsdl(ifap, name); + if (sdl == NULL) { + sdl = getsdl(ifap, NULL); + if (sdl == NULL) + errx(EXIT_FAILURE, "cannot find interface information"); + } + cp = (char *)(sdl->sdl_data + sdl->sdl_nlen); + in6->s6_addr[8] = cp[0]; + in6->s6_addr[8] ^= 0x02; /* reverse the u/l bit*/ + in6->s6_addr[9] = cp[1]; + in6->s6_addr[10] = cp[2]; + in6->s6_addr[11] = 0xff; + in6->s6_addr[12] = 0xfe; + in6->s6_addr[13] = cp[3]; + in6->s6_addr[14] = cp[4]; + in6->s6_addr[15] = cp[5]; +} + static void setip6eui64(const char *cmd, int dummy __unused, int s, const struct afswtch *afp) @@ -156,10 +209,13 @@ setip6eui64(const char *cmd, int dummy _ } } } - if (!lladdr) - errx(EXIT_FAILURE, "could not determine link local address"); - - memcpy(&in6->s6_addr[8], &lladdr->s6_addr[8], 8); + if (!lladdr) { + if (!IN6_IS_ADDR_LINKLOCAL(in6)) + errx(EXIT_FAILURE, + "could not determine link local address"); + link2eui64(ifap, in6); + } else + memcpy(&in6->s6_addr[8], &lladdr->s6_addr[8], 8); freeifaddrs(ifap); } --Multipart_Fri_Mar_11_14:38:28_2011-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Fri_Mar_11_14:38:28_2011-1-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 07:28:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EFC9106566C for ; Fri, 11 Mar 2011 07:28:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2340D8FC1B for ; Fri, 11 Mar 2011 07:28:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Pxwm0-000HgA-0Y; Fri, 11 Mar 2011 09:28:32 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Rick Macklem In-reply-to: Your message of Thu, 10 Mar 2011 17:58:30 -0500 (EST) . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Mar 2011 09:28:31 +0200 From: Daniel Braniss Message-ID: Cc: George Mitchell , freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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: Fri, 11 Mar 2011 07:28:35 -0000 >> On 02/18/2011 10:08, Rick Macklem wrote: >> > The attached patches changes the behaviour so that it tries to >> > get an unused port for each of the 4 cases. >> >> can you send me the patches? >> thanks, >> danny > They're attached. If you get to test them, please let me know > how it goes. > > rick Hi Rick, the good side of living on different time zones :-) I got impatient, so I came up with a different fix. The rational is that IMHO, there is no need for all listeners to be on the same port: rnd> rpcinfo protonew |grep mountd 100005 1 udp6 ::.3.141 mountd superuser 100005 3 udp6 ::.3.141 mountd superuser 100005 1 tcp6 ::.3.141 mountd superuser 100005 3 tcp6 ::.3.141 mountd superuser 100005 1 udp 0.0.0.0.3.141 mountd superuser 100005 3 udp 0.0.0.0.3.141 mountd superuser 100005 1 tcp 0.0.0.0.3.92 mountd superuser <--- 100005 3 tcp 0.0.0.0.3.92 mountd superuser <--- rnd> rpcinfo -t protonew mountd program 100005 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 3 program 100005 version 2 is not available program 100005 version 3 ready and waiting the patches are in: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/patches/address_already_in_use/ cheers, danny From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 14:57:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E875C106564A; Fri, 11 Mar 2011 14:57:27 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 698158FC0A; Fri, 11 Mar 2011 14:57:27 +0000 (UTC) Received: by qyk35 with SMTP id 35so5604073qyk.13 for ; Fri, 11 Mar 2011 06:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4wkhjkHqDW9Oe+bzLeYISa+/rmjTH2HMlCeDBDpru5Y=; b=QrjAcXOpTEvOrkynCnprfCEddOo77yb9hisWnSUm6Weeu1D6/8bxSnZ1EKepYFGDp7 9nH0v2htDTOIBGBt60bzBNKb0xDkDoduSrRQtHAZRYWrbjCGdW9cSbF4WNPnDh/HOfDP QxMsPF0voFGNz1JqMHoV96K4ZaPa1DuEthpTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ACzDw3j1wpfE6hamMeMjnEHItOvkfjbUctSuM7LWDRv3pyoT8j+XV6DkBfpMXh5hEZ SlZ7Pep7tej+AehFobQ7FlkC3Q0xwuQT/S2ejdOtTvoGXlBsB6mDNlsfJEfVK/L2fxBX 4/Q+XVvfpOT9hii6yLs/lBS7AceOS/irO4F78= MIME-Version: 1.0 Received: by 10.229.102.165 with SMTP id g37mr7696900qco.120.1299855445805; Fri, 11 Mar 2011 06:57:25 -0800 (PST) Received: by 10.229.97.209 with HTTP; Fri, 11 Mar 2011 06:57:25 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Fri, 11 Mar 2011 16:57:25 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Fri, 11 Mar 2011 14:57:28 -0000 Hi again, I wanna share state of test machine. em-7.2.2 driver runs as kld. No hangs. Altough em0 has about 200Mbps traffic, cpu usage of em0 is too high. Should I try -DEM_MULTIQUEUE option ? Regards, Ozkan KIRIK # uptime 4:36PM up 7 days, 8:30, 1 user, load averages: 4.19, 3.73, 3.71 # uname -srp FreeBSD 8.2-RELEASE amd64 # bwm-ng input: getifaddrs type: rate | iface Rx Tx = Total =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D em0: 149356.24 Kb/s 30202.86 Kb/s 179559.10= Kb/s em1: 1896.86 Kb/s 225.53 Kb/s 2122.39= Kb/s bce0: 8201.30 Kb/s 42895.40 Kb/s 51096.70= Kb/s em2: 22524.07 Kb/s 42751.14 Kb/s 65275.21= Kb/s em3: 3767.80 Kb/s 51521.05 Kb/s 55288.85= Kb/s # top -SHn last pid: 38924; load averages: 2.97, 3.32, 3.51 up 7+08:35:29 16:4= 1:59 693 processes: 13 running, 656 sleeping, 24 waiting Mem: 4393M Active, 8060M Inact, 2761M Wired, 255M Cache, 1647M Buf, 402M Fr= ee Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -68 0 0K 176K CPU2 2 45.9H 83.30% {em0 taskq} 11 root 171 ki31 0K 128K RUN 3 154.7H 82.28% {idle: cpu3= } 11 root 171 ki31 0K 128K CPU7 7 152.4H 74.85% {idle: cpu7= } 11 root 171 ki31 0K 128K CPU1 1 143.4H 71.53% {idle: cpu1= } 11 root 171 ki31 0K 128K RUN 6 150.2H 70.90% {idle: cpu6= } 11 root 171 ki31 0K 128K CPU0 0 135.0H 67.53% {idle: cpu0= } 11 root 171 ki31 0K 128K RUN 5 142.3H 56.49% {idle: cpu5= } 11 root 171 ki31 0K 128K CPU4 4 133.7H 56.45% {idle: cpu4= } 12 root -68 - 0K 384K WAIT 4 992:45 35.25% {irq258: bc= e0} 0 root -68 0 0K 176K - 5 18.8H 33.84% {em2 taskq} 11 root 171 ki31 0K 128K RUN 2 124.5H 19.24% {idle: cpu2= } 0 root -68 0 0K 176K CPU6 6 898:40 17.68% {em3 taskq} # sysctl dev.em. | grep miss dev.em.0.mac_stats.missed_packets: 910 dev.em.1.mac_stats.missed_packets: 0 dev.em.2.mac_stats.missed_packets: 5886 dev.em.3.mac_stats.missed_packets: 5518 # sysctl dev.em. dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.NPE2.SPE4.P8P= C.LAN0 dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x108e subdevice=3D0x4843 class=3D0x020000 dev.em.0.%parent: pci4 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.eee_control: 0 dev.em.0.link_irq: 0 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 1 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1075593793 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 30720 dev.em.0.fc_low_water: 29220 dev.em.0.queue0.txd_head: 311 dev.em.0.queue0.txd_tail: 311 dev.em.0.queue0.tx_irq: 0 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 1144 dev.em.0.queue0.rxd_tail: 1120 dev.em.0.queue0.rx_irq: 0 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 910 dev.em.0.mac_stats.recv_no_buff: 7050 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 3324123116 dev.em.0.mac_stats.good_pkts_recvd: 3324122206 dev.em.0.mac_stats.bcast_pkts_recvd: 159692 dev.em.0.mac_stats.mcast_pkts_recvd: 0 dev.em.0.mac_stats.rx_frames_64: 314397503 dev.em.0.mac_stats.rx_frames_65_127: 511431761 dev.em.0.mac_stats.rx_frames_128_255: 62445780 dev.em.0.mac_stats.rx_frames_256_511: 76542752 dev.em.0.mac_stats.rx_frames_512_1023: 111888998 dev.em.0.mac_stats.rx_frames_1024_1522: 2247415412 dev.em.0.mac_stats.good_octets_recvd: 3546201196566 dev.em.0.mac_stats.good_octets_txd: 1361437676103 dev.em.0.mac_stats.total_pkts_txd: 2931605576 dev.em.0.mac_stats.good_pkts_txd: 2931605576 dev.em.0.mac_stats.bcast_pkts_txd: 27621 dev.em.0.mac_stats.mcast_pkts_txd: 8 dev.em.0.mac_stats.tx_frames_64: 532709844 dev.em.0.mac_stats.tx_frames_65_127: 1405874859 dev.em.0.mac_stats.tx_frames_128_255: 54604175 dev.em.0.mac_stats.tx_frames_256_511: 51889529 dev.em.0.mac_stats.tx_frames_512_1023: 113268603 dev.em.0.mac_stats.tx_frames_1024_1522: 773258566 dev.em.0.mac_stats.tso_txd: 11638542 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 1386007928 dev.em.0.interrupts.rx_pkt_timer: 183978 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 93292 dev.em.0.interrupts.tx_abs_timer: 143694 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 dev.em.1.%driver: em dev.em.1.%location: slot=3D0 function=3D1 handle=3D\_SB_.PCI0.NPE2.SPE4.P8P= C.LAN1 dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x108e subdevice=3D0x4843 class=3D0x020000 dev.em.1.%parent: pci4 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.eee_control: 0 dev.em.1.link_irq: 0 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1075593793 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 30720 dev.em.1.fc_low_water: 29220 dev.em.1.queue0.txd_head: 2182 dev.em.1.queue0.txd_tail: 2182 dev.em.1.queue0.tx_irq: 0 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 3788 dev.em.1.queue0.rxd_tail: 3787 dev.em.1.queue0.rx_irq: 0 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.1.mac_stats.recv_no_buff: 0 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 612589160 dev.em.1.mac_stats.good_pkts_recvd: 612589160 dev.em.1.mac_stats.bcast_pkts_recvd: 47088 dev.em.1.mac_stats.mcast_pkts_recvd: 0 dev.em.1.mac_stats.rx_frames_64: 6785503 dev.em.1.mac_stats.rx_frames_65_127: 35934851 dev.em.1.mac_stats.rx_frames_128_255: 17109287 dev.em.1.mac_stats.rx_frames_256_511: 12238891 dev.em.1.mac_stats.rx_frames_512_1023: 11759994 dev.em.1.mac_stats.rx_frames_1024_1522: 528760634 dev.em.1.mac_stats.good_octets_recvd: 802710429802 dev.em.1.mac_stats.good_octets_txd: 33871996870 dev.em.1.mac_stats.total_pkts_txd: 236188292 dev.em.1.mac_stats.good_pkts_txd: 236188292 dev.em.1.mac_stats.bcast_pkts_txd: 21565 dev.em.1.mac_stats.mcast_pkts_txd: 5 dev.em.1.mac_stats.tx_frames_64: 41242650 dev.em.1.mac_stats.tx_frames_65_127: 168115252 dev.em.1.mac_stats.tx_frames_128_255: 9453471 dev.em.1.mac_stats.tx_frames_256_511: 4589683 dev.em.1.mac_stats.tx_frames_512_1023: 4863510 dev.em.1.mac_stats.tx_frames_1024_1522: 7923726 dev.em.1.mac_stats.tso_txd: 655 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 334830743 dev.em.1.interrupts.rx_pkt_timer: 59237 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 21979 dev.em.1.interrupts.tx_abs_timer: 23600 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 dev.em.2.%driver: em dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1E dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e subdevice=3D0x125e class=3D0x020000 dev.em.2.%parent: pci12 dev.em.2.nvm: -1 dev.em.2.debug: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 dev.em.2.flow_control: 3 dev.em.2.eee_control: 0 dev.em.2.link_irq: 0 dev.em.2.mbuf_alloc_fail: 0 dev.em.2.cluster_alloc_fail: 0 dev.em.2.dropped: 0 dev.em.2.tx_dma_fail: 0 dev.em.2.rx_overruns: 7 dev.em.2.watchdog_timeouts: 0 dev.em.2.device_control: 1075577409 dev.em.2.rx_control: 67141634 dev.em.2.fc_high_water: 30720 dev.em.2.fc_low_water: 29220 dev.em.2.queue0.txd_head: 1848 dev.em.2.queue0.txd_tail: 1848 dev.em.2.queue0.tx_irq: 0 dev.em.2.queue0.no_desc_avail: 0 dev.em.2.queue0.rxd_head: 3669 dev.em.2.queue0.rxd_tail: 3666 dev.em.2.queue0.rx_irq: 0 dev.em.2.mac_stats.excess_coll: 0 dev.em.2.mac_stats.single_coll: 0 dev.em.2.mac_stats.multiple_coll: 0 dev.em.2.mac_stats.late_coll: 0 dev.em.2.mac_stats.collision_count: 0 dev.em.2.mac_stats.symbol_errors: 0 dev.em.2.mac_stats.sequence_errors: 0 dev.em.2.mac_stats.defer_count: 0 dev.em.2.mac_stats.missed_packets: 5886 dev.em.2.mac_stats.recv_no_buff: 3407 dev.em.2.mac_stats.recv_undersize: 0 dev.em.2.mac_stats.recv_fragmented: 0 dev.em.2.mac_stats.recv_oversize: 0 dev.em.2.mac_stats.recv_jabber: 0 dev.em.2.mac_stats.recv_errs: 0 dev.em.2.mac_stats.crc_errs: 0 dev.em.2.mac_stats.alignment_errs: 0 dev.em.2.mac_stats.coll_ext_errs: 0 dev.em.2.mac_stats.xon_recvd: 0 dev.em.2.mac_stats.xon_txd: 0 dev.em.2.mac_stats.xoff_recvd: 0 dev.em.2.mac_stats.xoff_txd: 0 dev.em.2.mac_stats.total_pkts_recvd: 1278663367 dev.em.2.mac_stats.good_pkts_recvd: 1278657479 dev.em.2.mac_stats.bcast_pkts_recvd: 4797331 dev.em.2.mac_stats.mcast_pkts_recvd: 12303 dev.em.2.mac_stats.rx_frames_64: 1 dev.em.2.mac_stats.rx_frames_65_127: 790457496 dev.em.2.mac_stats.rx_frames_128_255: 25476141 dev.em.2.mac_stats.rx_frames_256_511: 28419874 dev.em.2.mac_stats.rx_frames_512_1023: 52544603 dev.em.2.mac_stats.rx_frames_1024_1522: 381759364 dev.em.2.mac_stats.good_octets_recvd: 671412801559 dev.em.2.mac_stats.good_octets_txd: 1407902706334 dev.em.2.mac_stats.total_pkts_txd: 1378397063 dev.em.2.mac_stats.good_pkts_txd: 1378397063 dev.em.2.mac_stats.bcast_pkts_txd: 530670 dev.em.2.mac_stats.mcast_pkts_txd: 310 dev.em.2.mac_stats.tx_frames_64: 166321947 dev.em.2.mac_stats.tx_frames_65_127: 214815586 dev.em.2.mac_stats.tx_frames_128_255: 26196882 dev.em.2.mac_stats.tx_frames_256_511: 45186662 dev.em.2.mac_stats.tx_frames_512_1023: 42820430 dev.em.2.mac_stats.tx_frames_1024_1522: 883055556 dev.em.2.mac_stats.tso_txd: 0 dev.em.2.mac_stats.tso_ctx_fail: 0 dev.em.2.interrupts.asserts: 1261244440 dev.em.2.interrupts.rx_pkt_timer: 145439 dev.em.2.interrupts.rx_abs_timer: 0 dev.em.2.interrupts.tx_pkt_timer: 54195 dev.em.2.interrupts.tx_abs_timer: 94511 dev.em.2.interrupts.tx_queue_empty: 0 dev.em.2.interrupts.tx_queue_min_thresh: 0 dev.em.2.interrupts.rx_desc_min_thresh: 0 dev.em.2.interrupts.rx_overrun: 0 dev.em.2.wake: 0 dev.em.3.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 dev.em.3.%driver: em dev.em.3.%location: slot=3D0 function=3D1 dev.em.3.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e subdevice=3D0x125e class=3D0x020000 dev.em.3.%parent: pci12 dev.em.3.nvm: -1 dev.em.3.debug: -1 dev.em.3.rx_int_delay: 0 dev.em.3.tx_int_delay: 66 dev.em.3.rx_abs_int_delay: 66 dev.em.3.tx_abs_int_delay: 66 dev.em.3.rx_processing_limit: 100 dev.em.3.flow_control: 3 dev.em.3.eee_control: 0 dev.em.3.link_irq: 0 dev.em.3.mbuf_alloc_fail: 0 dev.em.3.cluster_alloc_fail: 0 dev.em.3.dropped: 0 dev.em.3.tx_dma_fail: 0 dev.em.3.rx_overruns: 1 dev.em.3.watchdog_timeouts: 0 dev.em.3.device_control: 1075577409 dev.em.3.rx_control: 67141634 dev.em.3.fc_high_water: 30720 dev.em.3.fc_low_water: 29220 dev.em.3.queue0.txd_head: 4066 dev.em.3.queue0.txd_tail: 4066 dev.em.3.queue0.tx_irq: 0 dev.em.3.queue0.no_desc_avail: 0 dev.em.3.queue0.rxd_head: 1489 dev.em.3.queue0.rxd_tail: 1488 dev.em.3.queue0.rx_irq: 0 dev.em.3.mac_stats.excess_coll: 0 dev.em.3.mac_stats.single_coll: 0 dev.em.3.mac_stats.multiple_coll: 0 dev.em.3.mac_stats.late_coll: 0 dev.em.3.mac_stats.collision_count: 0 dev.em.3.mac_stats.symbol_errors: 0 dev.em.3.mac_stats.sequence_errors: 0 dev.em.3.mac_stats.defer_count: 0 dev.em.3.mac_stats.missed_packets: 5518 dev.em.3.mac_stats.recv_no_buff: 31 dev.em.3.mac_stats.recv_undersize: 0 dev.em.3.mac_stats.recv_fragmented: 0 dev.em.3.mac_stats.recv_oversize: 0 dev.em.3.mac_stats.recv_jabber: 0 dev.em.3.mac_stats.recv_errs: 0 dev.em.3.mac_stats.crc_errs: 0 dev.em.3.mac_stats.alignment_errs: 0 dev.em.3.mac_stats.coll_ext_errs: 0 dev.em.3.mac_stats.xon_recvd: 0 dev.em.3.mac_stats.xon_txd: 0 dev.em.3.mac_stats.xoff_recvd: 0 dev.em.3.mac_stats.xoff_txd: 0 dev.em.3.mac_stats.total_pkts_recvd: 1004852864 dev.em.3.mac_stats.good_pkts_recvd: 1004847345 dev.em.3.mac_stats.bcast_pkts_recvd: 19377766 dev.em.3.mac_stats.mcast_pkts_recvd: 1713418 dev.em.3.mac_stats.rx_frames_64: 1031384 dev.em.3.mac_stats.rx_frames_65_127: 612329188 dev.em.3.mac_stats.rx_frames_128_255: 21097424 dev.em.3.mac_stats.rx_frames_256_511: 16515533 dev.em.3.mac_stats.rx_frames_512_1023: 36547146 dev.em.3.mac_stats.rx_frames_1024_1522: 317326670 dev.em.3.mac_stats.good_octets_recvd: 529331348489 dev.em.3.mac_stats.good_octets_txd: 1389567129164 dev.em.3.mac_stats.total_pkts_txd: 1302125119 dev.em.3.mac_stats.good_pkts_txd: 1302125119 dev.em.3.mac_stats.bcast_pkts_txd: 412749 dev.em.3.mac_stats.mcast_pkts_txd: 301 dev.em.3.mac_stats.tx_frames_64: 156524010 dev.em.3.mac_stats.tx_frames_65_127: 134491341 dev.em.3.mac_stats.tx_frames_128_255: 25754249 dev.em.3.mac_stats.tx_frames_256_511: 46463156 dev.em.3.mac_stats.tx_frames_512_1023: 57886605 dev.em.3.mac_stats.tx_frames_1024_1522: 881005758 dev.em.3.mac_stats.tso_txd: 0 dev.em.3.mac_stats.tso_ctx_fail: 0 dev.em.3.interrupts.asserts: 1017261076 dev.em.3.interrupts.rx_pkt_timer: 110374 dev.em.3.interrupts.rx_abs_timer: 0 dev.em.3.interrupts.tx_pkt_timer: 62746 dev.em.3.interrupts.tx_abs_timer: 100063 dev.em.3.interrupts.tx_queue_empty: 0 dev.em.3.interrupts.tx_queue_min_thresh: 0 dev.em.3.interrupts.rx_desc_min_thresh: 0 dev.em.3.interrupts.rx_overrun: 0 On Sun, Mar 6, 2011 at 9:48 PM, Jack Vogel wrote: > Missed packets just mean that some temporary resource shortage or error > caused > the packet to be dropped. I don't believe this is indicative of a problem= , > just let it > keep running, 2 days is good but 2 weeks is better :) > > Thanks for testing it! > > Jack > > > On Sun, Mar 6, 2011 at 4:37 AM, =D6zkan KIRIK wro= te: >> >> Hello, >> >> I've been testing the em.7.2.2 driver as kld. The system is up about 2 >> days 6 hours. >> System has 4 em interfaces, Throughput is about 200Mbit/s. System >> didn't hang, but em2 has Input Errors. >> >> I saw that, dev.em.2.mac_stats.missed_packets is not zero? What could >> be the problem? >> >> # uname -r >> 8.2-RELEASE >> >> # sysctl dev.em.| grep miss >> dev.em.0.mac_stats.missed_packets: 0 >> dev.em.1.mac_stats.missed_packets: 0 >> dev.em.2.mac_stats.missed_packets: 5886 >> dev.em.3.mac_stats.missed_packets: 0 >> >> # netstat -nWI em2 | grep Link >> Name =A0 =A0 =A0Mtu Network =A0 =A0 =A0 Address =A0 =A0 =A0 =A0 =A0 =A0 = =A0Ipkts Ierrs Idrop >> Opkts Oerrs =A0Coll >> em2 =A0 =A0 =A01500 =A0 =A0 =A000:23:8b:89:e4:9e 267256324 =A05= 886 =A0 =A0 0 >> 273081628 =A0 =A0 0 =A0 =A0 0 >> >> # sysctl dev.em.2. >> dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 >> dev.em.2.%driver: em >> dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1E >> dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e >> subdevice=3D0x125e class=3D0x020000 >> dev.em.2.%parent: pci12 >> dev.em.2.nvm: -1 >> dev.em.2.debug: -1 >> dev.em.2.rx_int_delay: 0 >> dev.em.2.tx_int_delay: 66 >> dev.em.2.rx_abs_int_delay: 66 >> dev.em.2.tx_abs_int_delay: 66 >> dev.em.2.rx_processing_limit: 100 >> dev.em.2.flow_control: 3 >> dev.em.2.eee_control: 0 >> dev.em.2.link_irq: 0 >> dev.em.2.mbuf_alloc_fail: 0 >> dev.em.2.cluster_alloc_fail: 0 >> dev.em.2.dropped: 0 >> dev.em.2.tx_dma_fail: 0 >> dev.em.2.rx_overruns: 7 >> dev.em.2.watchdog_timeouts: 0 >> dev.em.2.device_control: 1075577409 >> dev.em.2.rx_control: 67141634 >> dev.em.2.fc_high_water: 30720 >> dev.em.2.fc_low_water: 29220 >> dev.em.2.queue0.txd_head: 3025 >> dev.em.2.queue0.txd_tail: 3025 >> dev.em.2.queue0.tx_irq: 0 >> dev.em.2.queue0.no_desc_avail: 0 >> dev.em.2.queue0.rxd_head: 1826 >> dev.em.2.queue0.rxd_tail: 1825 >> dev.em.2.queue0.rx_irq: 0 >> dev.em.2.mac_stats.excess_coll: 0 >> dev.em.2.mac_stats.single_coll: 0 >> dev.em.2.mac_stats.multiple_coll: 0 >> dev.em.2.mac_stats.late_coll: 0 >> dev.em.2.mac_stats.collision_count: 0 >> dev.em.2.mac_stats.symbol_errors: 0 >> dev.em.2.mac_stats.sequence_errors: 0 >> dev.em.2.mac_stats.defer_count: 0 >> dev.em.2.mac_stats.missed_packets: 5886 >> dev.em.2.mac_stats.recv_no_buff: 3407 >> dev.em.2.mac_stats.recv_undersize: 0 >> dev.em.2.mac_stats.recv_fragmented: 0 >> dev.em.2.mac_stats.recv_oversize: 0 >> dev.em.2.mac_stats.recv_jabber: 0 >> dev.em.2.mac_stats.recv_errs: 0 >> dev.em.2.mac_stats.crc_errs: 0 >> dev.em.2.mac_stats.alignment_errs: 0 >> dev.em.2.mac_stats.coll_ext_errs: 0 >> dev.em.2.mac_stats.xon_recvd: 0 >> dev.em.2.mac_stats.xon_txd: 0 >> dev.em.2.mac_stats.xoff_recvd: 0 >> dev.em.2.mac_stats.xoff_txd: 0 >> dev.em.2.mac_stats.total_pkts_recvd: 265358324 >> dev.em.2.mac_stats.good_pkts_recvd: 265352438 >> dev.em.2.mac_stats.bcast_pkts_recvd: 701728 >> dev.em.2.mac_stats.mcast_pkts_recvd: 4076 >> dev.em.2.mac_stats.rx_frames_64: 0 >> dev.em.2.mac_stats.rx_frames_65_127: 140801982 >> dev.em.2.mac_stats.rx_frames_128_255: 3553397 >> dev.em.2.mac_stats.rx_frames_256_511: 3418754 >> dev.em.2.mac_stats.rx_frames_512_1023: 8096866 >> dev.em.2.mac_stats.rx_frames_1024_1522: 109481439 >> dev.em.2.mac_stats.good_octets_recvd: 177455051448 >> dev.em.2.mac_stats.good_octets_txd: 274861571704 >> dev.em.2.mac_stats.total_pkts_txd: 270439410 >> dev.em.2.mac_stats.good_pkts_txd: 270439410 >> dev.em.2.mac_stats.bcast_pkts_txd: 194927 >> dev.em.2.mac_stats.mcast_pkts_txd: 48 >> dev.em.2.mac_stats.tx_frames_64: 23050855 >> dev.em.2.mac_stats.tx_frames_65_127: 54156414 >> dev.em.2.mac_stats.tx_frames_128_255: 4299280 >> dev.em.2.mac_stats.tx_frames_256_511: 7837146 >> dev.em.2.mac_stats.tx_frames_512_1023: 8272014 >> dev.em.2.mac_stats.tx_frames_1024_1522: 172823701 >> dev.em.2.mac_stats.tso_txd: 0 >> dev.em.2.mac_stats.tso_ctx_fail: 0 >> dev.em.2.interrupts.asserts: 283674059 >> dev.em.2.interrupts.rx_pkt_timer: 33585 >> dev.em.2.interrupts.rx_abs_timer: 0 >> dev.em.2.interrupts.tx_pkt_timer: 11022 >> dev.em.2.interrupts.tx_abs_timer: 22449 >> dev.em.2.interrupts.tx_queue_empty: 0 >> dev.em.2.interrupts.tx_queue_min_thresh: 0 >> dev.em.2.interrupts.rx_desc_min_thresh: 0 >> dev.em.2.interrupts.rx_overrun: 0 >> >> Regards, >> Ozkan KIRIK > > From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 16:15:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6CD1106566C for ; Fri, 11 Mar 2011 16:15:37 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp9.sbb.rs (smtp9.sbb.rs [89.216.2.41]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFE88FC0C for ; Fri, 11 Mar 2011 16:15:36 +0000 (UTC) Received: from faust (cable-94-189-180-102.dynamic.sbb.rs [94.189.180.102]) by smtp9.sbb.rs (8.14.0/8.14.0) with ESMTP id p2BGFYwo011977 for ; Fri, 11 Mar 2011 17:15:35 +0100 Received: by faust (Postfix, from userid 1001) id 364701701D; Fri, 11 Mar 2011 17:16:18 +0100 (CET) Date: Fri, 11 Mar 2011 17:16:18 +0100 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20110311161618.GA978@faust> References: <20110311120040.A3C7F10657EF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110311120040.A3C7F10657EF@hub.freebsd.org> X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -0.8 Subject: Re: happy hacker lite 2 keyboard 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: Fri, 11 Mar 2011 16:15:37 -0000 > Anyway, I've had really bad luck with off the shelf adapters. You are > probably OK with just running it as USB. Should do if running through adapter fails. I always remove usb stack from kernel. Have to check how the change interacts with x configura- tion. Console mode asks for few lines to recog- nize kb. Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 17:24:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 348FD106564A; Fri, 11 Mar 2011 17:24:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A59788FC14; Fri, 11 Mar 2011 17:24:00 +0000 (UTC) Received: by yxl31 with SMTP id 31so1426796yxl.13 for ; Fri, 11 Mar 2011 09:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=asxg94q7xzrS2nlqM5fITbAP/GoHI3y7Zk4X2bONiEs=; b=OtggIYRiMjUlIx1sU4vqzJziyUpeZ6Bt4yF49jtiLZQNoIeLStDq6B9MtLaO6VZfBe ovnXvzfYNilJ3p3S7qXTRkM1sLodzLOZeQrIBDDdum8j+qScpDgBcLHVTSso8SOfnfVO PlEEp5V7FNNdqu6C5DcH4vMWwWaduJVShtXH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dTDnGN1SjU08PI2fn1GvJtNjZ3KtLt89dqkgNpz9T46ntF+99YxJPUHVLqETWuK7KK tGBo1HsfUYNoQmaIJBU0hANmO1PjxdIOL14qw3jAHI+EfFRpJcX2ZHJGpqa7xupo2/Ph cmTJu8IIJgvIzm41qr+3HKR0dH7Jcv2kP9EOs= MIME-Version: 1.0 Received: by 10.43.70.20 with SMTP id ye20mr2712247icb.156.1299864239577; Fri, 11 Mar 2011 09:23:59 -0800 (PST) Received: by 10.42.213.200 with HTTP; Fri, 11 Mar 2011 09:23:59 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> Date: Fri, 11 Mar 2011 09:23:59 -0800 Message-ID: From: Jack Vogel To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Fri, 11 Mar 2011 17:24:01 -0000 MULTIQUEUE won't help on that hardware, only the 82574 has the ability to use multiple queues in the em driver. Its the advanced server adapters supported by the igb driver that are the best choice in that regard. So, now the driver does not hang but cpu is too high... Anyone else find this to be the case that is testing this driver? Jack On Fri, Mar 11, 2011 at 6:57 AM, =D6zkan KIRIK wrot= e: > Hi again, > > I wanna share state of test machine. em-7.2.2 driver runs as kld. No hang= s. > Altough em0 has about 200Mbps traffic, cpu usage of em0 is too high. > Should I try -DEM_MULTIQUEUE option ? > > Regards, > Ozkan KIRIK > > # uptime > 4:36PM up 7 days, 8:30, 1 user, load averages: 4.19, 3.73, 3.71 > > # uname -srp > FreeBSD 8.2-RELEASE amd64 > > # bwm-ng > > input: getifaddrs type: rate > | iface Rx Tx > Total > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > em0: 149356.24 Kb/s 30202.86 Kb/s 179559.1= 0 > Kb/s > em1: 1896.86 Kb/s 225.53 Kb/s 2122.3= 9 > Kb/s > bce0: 8201.30 Kb/s 42895.40 Kb/s 51096.7= 0 > Kb/s > em2: 22524.07 Kb/s 42751.14 Kb/s 65275.2= 1 > Kb/s > em3: 3767.80 Kb/s 51521.05 Kb/s 55288.8= 5 > Kb/s > > > # top -SHn > last pid: 38924; load averages: 2.97, 3.32, 3.51 up 7+08:35:29 > 16:41:59 > 693 processes: 13 running, 656 sleeping, 24 waiting > Mem: 4393M Active, 8060M Inact, 2761M Wired, 255M Cache, 1647M Buf, 402M > Free > Swap: 4096M Total, 4096M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 0 root -68 0 0K 176K CPU2 2 45.9H 83.30% {em0 taskq= } > 11 root 171 ki31 0K 128K RUN 3 154.7H 82.28% {idle: cpu= 3} > 11 root 171 ki31 0K 128K CPU7 7 152.4H 74.85% {idle: cpu= 7} > 11 root 171 ki31 0K 128K CPU1 1 143.4H 71.53% {idle: cpu= 1} > 11 root 171 ki31 0K 128K RUN 6 150.2H 70.90% {idle: cpu= 6} > 11 root 171 ki31 0K 128K CPU0 0 135.0H 67.53% {idle: cpu= 0} > 11 root 171 ki31 0K 128K RUN 5 142.3H 56.49% {idle: cpu= 5} > 11 root 171 ki31 0K 128K CPU4 4 133.7H 56.45% {idle: cpu= 4} > 12 root -68 - 0K 384K WAIT 4 992:45 35.25% {irq258: > bce0} > 0 root -68 0 0K 176K - 5 18.8H 33.84% {em2 taskq= } > 11 root 171 ki31 0K 128K RUN 2 124.5H 19.24% {idle: cpu= 2} > 0 root -68 0 0K 176K CPU6 6 898:40 17.68% {em3 taskq= } > > # sysctl dev.em. | grep miss > dev.em.0.mac_stats.missed_packets: 910 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.2.mac_stats.missed_packets: 5886 > dev.em.3.mac_stats.missed_packets: 5518 > > # sysctl dev.em. > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 > dev.em.0.%driver: em > dev.em.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.NPE2.SPE4.P= 8PC.LAN0 > dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x108e > subdevice=3D0x4843 class=3D0x020000 > dev.em.0.%parent: pci4 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.flow_control: 3 > dev.em.0.eee_control: 0 > dev.em.0.link_irq: 0 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.rx_overruns: 1 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1075593793 > dev.em.0.rx_control: 67141634 > dev.em.0.fc_high_water: 30720 > dev.em.0.fc_low_water: 29220 > dev.em.0.queue0.txd_head: 311 > dev.em.0.queue0.txd_tail: 311 > dev.em.0.queue0.tx_irq: 0 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 1144 > dev.em.0.queue0.rxd_tail: 1120 > dev.em.0.queue0.rx_irq: 0 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 910 > dev.em.0.mac_stats.recv_no_buff: 7050 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 3324123116 > dev.em.0.mac_stats.good_pkts_recvd: 3324122206 > dev.em.0.mac_stats.bcast_pkts_recvd: 159692 > dev.em.0.mac_stats.mcast_pkts_recvd: 0 > dev.em.0.mac_stats.rx_frames_64: 314397503 > dev.em.0.mac_stats.rx_frames_65_127: 511431761 > dev.em.0.mac_stats.rx_frames_128_255: 62445780 > dev.em.0.mac_stats.rx_frames_256_511: 76542752 > dev.em.0.mac_stats.rx_frames_512_1023: 111888998 > dev.em.0.mac_stats.rx_frames_1024_1522: 2247415412 > dev.em.0.mac_stats.good_octets_recvd: 3546201196566 > dev.em.0.mac_stats.good_octets_txd: 1361437676103 > dev.em.0.mac_stats.total_pkts_txd: 2931605576 > dev.em.0.mac_stats.good_pkts_txd: 2931605576 > dev.em.0.mac_stats.bcast_pkts_txd: 27621 > dev.em.0.mac_stats.mcast_pkts_txd: 8 > dev.em.0.mac_stats.tx_frames_64: 532709844 > dev.em.0.mac_stats.tx_frames_65_127: 1405874859 > dev.em.0.mac_stats.tx_frames_128_255: 54604175 > dev.em.0.mac_stats.tx_frames_256_511: 51889529 > dev.em.0.mac_stats.tx_frames_512_1023: 113268603 > dev.em.0.mac_stats.tx_frames_1024_1522: 773258566 > dev.em.0.mac_stats.tso_txd: 11638542 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 1386007928 > dev.em.0.interrupts.rx_pkt_timer: 183978 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 93292 > dev.em.0.interrupts.tx_abs_timer: 143694 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 > dev.em.1.%driver: em > dev.em.1.%location: slot=3D0 function=3D1 handle=3D\_SB_.PCI0.NPE2.SPE4.P= 8PC.LAN1 > dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x1096 subvendor=3D0x108e > subdevice=3D0x4843 class=3D0x020000 > dev.em.1.%parent: pci4 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > dev.em.1.flow_control: 3 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 0 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1075593793 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 30720 > dev.em.1.fc_low_water: 29220 > dev.em.1.queue0.txd_head: 2182 > dev.em.1.queue0.txd_tail: 2182 > dev.em.1.queue0.tx_irq: 0 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 3788 > dev.em.1.queue0.rxd_tail: 3787 > dev.em.1.queue0.rx_irq: 0 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.1.mac_stats.recv_no_buff: 0 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 0 > dev.em.1.mac_stats.xon_txd: 0 > dev.em.1.mac_stats.xoff_recvd: 0 > dev.em.1.mac_stats.xoff_txd: 0 > dev.em.1.mac_stats.total_pkts_recvd: 612589160 > dev.em.1.mac_stats.good_pkts_recvd: 612589160 > dev.em.1.mac_stats.bcast_pkts_recvd: 47088 > dev.em.1.mac_stats.mcast_pkts_recvd: 0 > dev.em.1.mac_stats.rx_frames_64: 6785503 > dev.em.1.mac_stats.rx_frames_65_127: 35934851 > dev.em.1.mac_stats.rx_frames_128_255: 17109287 > dev.em.1.mac_stats.rx_frames_256_511: 12238891 > dev.em.1.mac_stats.rx_frames_512_1023: 11759994 > dev.em.1.mac_stats.rx_frames_1024_1522: 528760634 > dev.em.1.mac_stats.good_octets_recvd: 802710429802 > dev.em.1.mac_stats.good_octets_txd: 33871996870 > dev.em.1.mac_stats.total_pkts_txd: 236188292 > dev.em.1.mac_stats.good_pkts_txd: 236188292 > dev.em.1.mac_stats.bcast_pkts_txd: 21565 > dev.em.1.mac_stats.mcast_pkts_txd: 5 > dev.em.1.mac_stats.tx_frames_64: 41242650 > dev.em.1.mac_stats.tx_frames_65_127: 168115252 > dev.em.1.mac_stats.tx_frames_128_255: 9453471 > dev.em.1.mac_stats.tx_frames_256_511: 4589683 > dev.em.1.mac_stats.tx_frames_512_1023: 4863510 > dev.em.1.mac_stats.tx_frames_1024_1522: 7923726 > dev.em.1.mac_stats.tso_txd: 655 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 334830743 > dev.em.1.interrupts.rx_pkt_timer: 59237 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 21979 > dev.em.1.interrupts.tx_abs_timer: 23600 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 0 > dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 > dev.em.2.%driver: em > dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1E > dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e > subdevice=3D0x125e class=3D0x020000 > dev.em.2.%parent: pci12 > dev.em.2.nvm: -1 > dev.em.2.debug: -1 > dev.em.2.rx_int_delay: 0 > dev.em.2.tx_int_delay: 66 > dev.em.2.rx_abs_int_delay: 66 > dev.em.2.tx_abs_int_delay: 66 > dev.em.2.rx_processing_limit: 100 > dev.em.2.flow_control: 3 > dev.em.2.eee_control: 0 > dev.em.2.link_irq: 0 > dev.em.2.mbuf_alloc_fail: 0 > dev.em.2.cluster_alloc_fail: 0 > dev.em.2.dropped: 0 > dev.em.2.tx_dma_fail: 0 > dev.em.2.rx_overruns: 7 > dev.em.2.watchdog_timeouts: 0 > dev.em.2.device_control: 1075577409 > dev.em.2.rx_control: 67141634 > dev.em.2.fc_high_water: 30720 > dev.em.2.fc_low_water: 29220 > dev.em.2.queue0.txd_head: 1848 > dev.em.2.queue0.txd_tail: 1848 > dev.em.2.queue0.tx_irq: 0 > dev.em.2.queue0.no_desc_avail: 0 > dev.em.2.queue0.rxd_head: 3669 > dev.em.2.queue0.rxd_tail: 3666 > dev.em.2.queue0.rx_irq: 0 > dev.em.2.mac_stats.excess_coll: 0 > dev.em.2.mac_stats.single_coll: 0 > dev.em.2.mac_stats.multiple_coll: 0 > dev.em.2.mac_stats.late_coll: 0 > dev.em.2.mac_stats.collision_count: 0 > dev.em.2.mac_stats.symbol_errors: 0 > dev.em.2.mac_stats.sequence_errors: 0 > dev.em.2.mac_stats.defer_count: 0 > dev.em.2.mac_stats.missed_packets: 5886 > dev.em.2.mac_stats.recv_no_buff: 3407 > dev.em.2.mac_stats.recv_undersize: 0 > dev.em.2.mac_stats.recv_fragmented: 0 > dev.em.2.mac_stats.recv_oversize: 0 > dev.em.2.mac_stats.recv_jabber: 0 > dev.em.2.mac_stats.recv_errs: 0 > dev.em.2.mac_stats.crc_errs: 0 > dev.em.2.mac_stats.alignment_errs: 0 > dev.em.2.mac_stats.coll_ext_errs: 0 > dev.em.2.mac_stats.xon_recvd: 0 > dev.em.2.mac_stats.xon_txd: 0 > dev.em.2.mac_stats.xoff_recvd: 0 > dev.em.2.mac_stats.xoff_txd: 0 > dev.em.2.mac_stats.total_pkts_recvd: 1278663367 > dev.em.2.mac_stats.good_pkts_recvd: 1278657479 > dev.em.2.mac_stats.bcast_pkts_recvd: 4797331 > dev.em.2.mac_stats.mcast_pkts_recvd: 12303 > dev.em.2.mac_stats.rx_frames_64: 1 > dev.em.2.mac_stats.rx_frames_65_127: 790457496 > dev.em.2.mac_stats.rx_frames_128_255: 25476141 > dev.em.2.mac_stats.rx_frames_256_511: 28419874 > dev.em.2.mac_stats.rx_frames_512_1023: 52544603 > dev.em.2.mac_stats.rx_frames_1024_1522: 381759364 > dev.em.2.mac_stats.good_octets_recvd: 671412801559 > dev.em.2.mac_stats.good_octets_txd: 1407902706334 > dev.em.2.mac_stats.total_pkts_txd: 1378397063 > dev.em.2.mac_stats.good_pkts_txd: 1378397063 > dev.em.2.mac_stats.bcast_pkts_txd: 530670 > dev.em.2.mac_stats.mcast_pkts_txd: 310 > dev.em.2.mac_stats.tx_frames_64: 166321947 > dev.em.2.mac_stats.tx_frames_65_127: 214815586 > dev.em.2.mac_stats.tx_frames_128_255: 26196882 > dev.em.2.mac_stats.tx_frames_256_511: 45186662 > dev.em.2.mac_stats.tx_frames_512_1023: 42820430 > dev.em.2.mac_stats.tx_frames_1024_1522: 883055556 > dev.em.2.mac_stats.tso_txd: 0 > dev.em.2.mac_stats.tso_ctx_fail: 0 > dev.em.2.interrupts.asserts: 1261244440 > dev.em.2.interrupts.rx_pkt_timer: 145439 > dev.em.2.interrupts.rx_abs_timer: 0 > dev.em.2.interrupts.tx_pkt_timer: 54195 > dev.em.2.interrupts.tx_abs_timer: 94511 > dev.em.2.interrupts.tx_queue_empty: 0 > dev.em.2.interrupts.tx_queue_min_thresh: 0 > dev.em.2.interrupts.rx_desc_min_thresh: 0 > dev.em.2.interrupts.rx_overrun: 0 > dev.em.2.wake: 0 > dev.em.3.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 > dev.em.3.%driver: em > dev.em.3.%location: slot=3D0 function=3D1 > dev.em.3.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e > subdevice=3D0x125e class=3D0x020000 > dev.em.3.%parent: pci12 > dev.em.3.nvm: -1 > dev.em.3.debug: -1 > dev.em.3.rx_int_delay: 0 > dev.em.3.tx_int_delay: 66 > dev.em.3.rx_abs_int_delay: 66 > dev.em.3.tx_abs_int_delay: 66 > dev.em.3.rx_processing_limit: 100 > dev.em.3.flow_control: 3 > dev.em.3.eee_control: 0 > dev.em.3.link_irq: 0 > dev.em.3.mbuf_alloc_fail: 0 > dev.em.3.cluster_alloc_fail: 0 > dev.em.3.dropped: 0 > dev.em.3.tx_dma_fail: 0 > dev.em.3.rx_overruns: 1 > dev.em.3.watchdog_timeouts: 0 > dev.em.3.device_control: 1075577409 > dev.em.3.rx_control: 67141634 > dev.em.3.fc_high_water: 30720 > dev.em.3.fc_low_water: 29220 > dev.em.3.queue0.txd_head: 4066 > dev.em.3.queue0.txd_tail: 4066 > dev.em.3.queue0.tx_irq: 0 > dev.em.3.queue0.no_desc_avail: 0 > dev.em.3.queue0.rxd_head: 1489 > dev.em.3.queue0.rxd_tail: 1488 > dev.em.3.queue0.rx_irq: 0 > dev.em.3.mac_stats.excess_coll: 0 > dev.em.3.mac_stats.single_coll: 0 > dev.em.3.mac_stats.multiple_coll: 0 > dev.em.3.mac_stats.late_coll: 0 > dev.em.3.mac_stats.collision_count: 0 > dev.em.3.mac_stats.symbol_errors: 0 > dev.em.3.mac_stats.sequence_errors: 0 > dev.em.3.mac_stats.defer_count: 0 > dev.em.3.mac_stats.missed_packets: 5518 > dev.em.3.mac_stats.recv_no_buff: 31 > dev.em.3.mac_stats.recv_undersize: 0 > dev.em.3.mac_stats.recv_fragmented: 0 > dev.em.3.mac_stats.recv_oversize: 0 > dev.em.3.mac_stats.recv_jabber: 0 > dev.em.3.mac_stats.recv_errs: 0 > dev.em.3.mac_stats.crc_errs: 0 > dev.em.3.mac_stats.alignment_errs: 0 > dev.em.3.mac_stats.coll_ext_errs: 0 > dev.em.3.mac_stats.xon_recvd: 0 > dev.em.3.mac_stats.xon_txd: 0 > dev.em.3.mac_stats.xoff_recvd: 0 > dev.em.3.mac_stats.xoff_txd: 0 > dev.em.3.mac_stats.total_pkts_recvd: 1004852864 > dev.em.3.mac_stats.good_pkts_recvd: 1004847345 > dev.em.3.mac_stats.bcast_pkts_recvd: 19377766 > dev.em.3.mac_stats.mcast_pkts_recvd: 1713418 > dev.em.3.mac_stats.rx_frames_64: 1031384 > dev.em.3.mac_stats.rx_frames_65_127: 612329188 > dev.em.3.mac_stats.rx_frames_128_255: 21097424 > dev.em.3.mac_stats.rx_frames_256_511: 16515533 > dev.em.3.mac_stats.rx_frames_512_1023: 36547146 > dev.em.3.mac_stats.rx_frames_1024_1522: 317326670 > dev.em.3.mac_stats.good_octets_recvd: 529331348489 > dev.em.3.mac_stats.good_octets_txd: 1389567129164 > dev.em.3.mac_stats.total_pkts_txd: 1302125119 > dev.em.3.mac_stats.good_pkts_txd: 1302125119 > dev.em.3.mac_stats.bcast_pkts_txd: 412749 > dev.em.3.mac_stats.mcast_pkts_txd: 301 > dev.em.3.mac_stats.tx_frames_64: 156524010 > dev.em.3.mac_stats.tx_frames_65_127: 134491341 > dev.em.3.mac_stats.tx_frames_128_255: 25754249 > dev.em.3.mac_stats.tx_frames_256_511: 46463156 > dev.em.3.mac_stats.tx_frames_512_1023: 57886605 > dev.em.3.mac_stats.tx_frames_1024_1522: 881005758 > dev.em.3.mac_stats.tso_txd: 0 > dev.em.3.mac_stats.tso_ctx_fail: 0 > dev.em.3.interrupts.asserts: 1017261076 > dev.em.3.interrupts.rx_pkt_timer: 110374 > dev.em.3.interrupts.rx_abs_timer: 0 > dev.em.3.interrupts.tx_pkt_timer: 62746 > dev.em.3.interrupts.tx_abs_timer: 100063 > dev.em.3.interrupts.tx_queue_empty: 0 > dev.em.3.interrupts.tx_queue_min_thresh: 0 > dev.em.3.interrupts.rx_desc_min_thresh: 0 > dev.em.3.interrupts.rx_overrun: 0 > > > On Sun, Mar 6, 2011 at 9:48 PM, Jack Vogel wrote: > > Missed packets just mean that some temporary resource shortage or error > > caused > > the packet to be dropped. I don't believe this is indicative of a > problem, > > just let it > > keep running, 2 days is good but 2 weeks is better :) > > > > Thanks for testing it! > > > > Jack > > > > > > On Sun, Mar 6, 2011 at 4:37 AM, =D6zkan KIRIK > wrote: > >> > >> Hello, > >> > >> I've been testing the em.7.2.2 driver as kld. The system is up about 2 > >> days 6 hours. > >> System has 4 em interfaces, Throughput is about 200Mbit/s. System > >> didn't hang, but em2 has Input Errors. > >> > >> I saw that, dev.em.2.mac_stats.missed_packets is not zero? What could > >> be the problem? > >> > >> # uname -r > >> 8.2-RELEASE > >> > >> # sysctl dev.em.| grep miss > >> dev.em.0.mac_stats.missed_packets: 0 > >> dev.em.1.mac_stats.missed_packets: 0 > >> dev.em.2.mac_stats.missed_packets: 5886 > >> dev.em.3.mac_stats.missed_packets: 0 > >> > >> # netstat -nWI em2 | grep Link > >> Name Mtu Network Address Ipkts Ierrs Idrop > >> Opkts Oerrs Coll > >> em2 1500 00:23:8b:89:e4:9e 267256324 5886 0 > >> 273081628 0 0 > >> > >> # sysctl dev.em.2. > >> dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.2 > >> dev.em.2.%driver: em > >> dev.em.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P0P4.BR1= E > >> dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x108e > >> subdevice=3D0x125e class=3D0x020000 > >> dev.em.2.%parent: pci12 > >> dev.em.2.nvm: -1 > >> dev.em.2.debug: -1 > >> dev.em.2.rx_int_delay: 0 > >> dev.em.2.tx_int_delay: 66 > >> dev.em.2.rx_abs_int_delay: 66 > >> dev.em.2.tx_abs_int_delay: 66 > >> dev.em.2.rx_processing_limit: 100 > >> dev.em.2.flow_control: 3 > >> dev.em.2.eee_control: 0 > >> dev.em.2.link_irq: 0 > >> dev.em.2.mbuf_alloc_fail: 0 > >> dev.em.2.cluster_alloc_fail: 0 > >> dev.em.2.dropped: 0 > >> dev.em.2.tx_dma_fail: 0 > >> dev.em.2.rx_overruns: 7 > >> dev.em.2.watchdog_timeouts: 0 > >> dev.em.2.device_control: 1075577409 > >> dev.em.2.rx_control: 67141634 > >> dev.em.2.fc_high_water: 30720 > >> dev.em.2.fc_low_water: 29220 > >> dev.em.2.queue0.txd_head: 3025 > >> dev.em.2.queue0.txd_tail: 3025 > >> dev.em.2.queue0.tx_irq: 0 > >> dev.em.2.queue0.no_desc_avail: 0 > >> dev.em.2.queue0.rxd_head: 1826 > >> dev.em.2.queue0.rxd_tail: 1825 > >> dev.em.2.queue0.rx_irq: 0 > >> dev.em.2.mac_stats.excess_coll: 0 > >> dev.em.2.mac_stats.single_coll: 0 > >> dev.em.2.mac_stats.multiple_coll: 0 > >> dev.em.2.mac_stats.late_coll: 0 > >> dev.em.2.mac_stats.collision_count: 0 > >> dev.em.2.mac_stats.symbol_errors: 0 > >> dev.em.2.mac_stats.sequence_errors: 0 > >> dev.em.2.mac_stats.defer_count: 0 > >> dev.em.2.mac_stats.missed_packets: 5886 > >> dev.em.2.mac_stats.recv_no_buff: 3407 > >> dev.em.2.mac_stats.recv_undersize: 0 > >> dev.em.2.mac_stats.recv_fragmented: 0 > >> dev.em.2.mac_stats.recv_oversize: 0 > >> dev.em.2.mac_stats.recv_jabber: 0 > >> dev.em.2.mac_stats.recv_errs: 0 > >> dev.em.2.mac_stats.crc_errs: 0 > >> dev.em.2.mac_stats.alignment_errs: 0 > >> dev.em.2.mac_stats.coll_ext_errs: 0 > >> dev.em.2.mac_stats.xon_recvd: 0 > >> dev.em.2.mac_stats.xon_txd: 0 > >> dev.em.2.mac_stats.xoff_recvd: 0 > >> dev.em.2.mac_stats.xoff_txd: 0 > >> dev.em.2.mac_stats.total_pkts_recvd: 265358324 > >> dev.em.2.mac_stats.good_pkts_recvd: 265352438 > >> dev.em.2.mac_stats.bcast_pkts_recvd: 701728 > >> dev.em.2.mac_stats.mcast_pkts_recvd: 4076 > >> dev.em.2.mac_stats.rx_frames_64: 0 > >> dev.em.2.mac_stats.rx_frames_65_127: 140801982 > >> dev.em.2.mac_stats.rx_frames_128_255: 3553397 > >> dev.em.2.mac_stats.rx_frames_256_511: 3418754 > >> dev.em.2.mac_stats.rx_frames_512_1023: 8096866 > >> dev.em.2.mac_stats.rx_frames_1024_1522: 109481439 > >> dev.em.2.mac_stats.good_octets_recvd: 177455051448 > >> dev.em.2.mac_stats.good_octets_txd: 274861571704 > >> dev.em.2.mac_stats.total_pkts_txd: 270439410 > >> dev.em.2.mac_stats.good_pkts_txd: 270439410 > >> dev.em.2.mac_stats.bcast_pkts_txd: 194927 > >> dev.em.2.mac_stats.mcast_pkts_txd: 48 > >> dev.em.2.mac_stats.tx_frames_64: 23050855 > >> dev.em.2.mac_stats.tx_frames_65_127: 54156414 > >> dev.em.2.mac_stats.tx_frames_128_255: 4299280 > >> dev.em.2.mac_stats.tx_frames_256_511: 7837146 > >> dev.em.2.mac_stats.tx_frames_512_1023: 8272014 > >> dev.em.2.mac_stats.tx_frames_1024_1522: 172823701 > >> dev.em.2.mac_stats.tso_txd: 0 > >> dev.em.2.mac_stats.tso_ctx_fail: 0 > >> dev.em.2.interrupts.asserts: 283674059 > >> dev.em.2.interrupts.rx_pkt_timer: 33585 > >> dev.em.2.interrupts.rx_abs_timer: 0 > >> dev.em.2.interrupts.tx_pkt_timer: 11022 > >> dev.em.2.interrupts.tx_abs_timer: 22449 > >> dev.em.2.interrupts.tx_queue_empty: 0 > >> dev.em.2.interrupts.tx_queue_min_thresh: 0 > >> dev.em.2.interrupts.rx_desc_min_thresh: 0 > >> dev.em.2.interrupts.rx_overrun: 0 > >> > >> Regards, > >> Ozkan KIRIK > > > > > From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 17:40:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D3B106564A; Fri, 11 Mar 2011 17:40:43 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 00FC48FC08; Fri, 11 Mar 2011 17:40:42 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:4433:c074:8d7b:b33d] ([IPv6:2607:f3e0:0:4:4433:c074:8d7b:b33d]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p2BHefPj012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 12:40:41 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D7A5E93.1030102@sentex.net> Date: Fri, 11 Mar 2011 12:40:35 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Vogel References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> <4D6D00C1.1040805@sentex.net> <1416421652.20110301225215@serebryakov.spb.ru> <1627628072.20110303111046@serebryakov.spb.ru> <1894628540.20110304012554@serebryakov.spb.ru> <31A99DAA7E5F4095B22B9DD57DD0E19E@multiplay.co.uk> <494278763.20110305130320@serebryakov.spb.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, =?ISO-8859-1?Q?=D6zkan_KIRIK?= Subject: Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!) 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: Fri, 11 Mar 2011 17:40:43 -0000 On 3/11/2011 12:23 PM, Jack Vogel wrote: > > So, now the driver does not hang but cpu is too high... Anyone else find > this to > be the case that is testing this driver? Just eyeballing the load avg graphs on the 2 boxes where I am testing, I dont see any glaring differences. But I have not set out to do any specific measurements / tests in that regard. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 23:03:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86AF7106564A for ; Fri, 11 Mar 2011 23:03:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 48AE08FC08 for ; Fri, 11 Mar 2011 23:03:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPM4ek2DaFvO/2dsb2JhbACEOaJ2sVCQe4Eng0V2BIUphyaMMQ X-IronPort-AV: E=Sophos;i="4.62,305,1297054800"; d="scan'208";a="114009618" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 11 Mar 2011 18:03:42 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7925EB3F32; Fri, 11 Mar 2011 18:03:42 -0500 (EST) Date: Fri, 11 Mar 2011 18:03:42 -0500 (EST) From: Rick Macklem To: Daniel Braniss Message-ID: <2122282816.1268010.1299884622480.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: George Mitchell , freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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: Fri, 11 Mar 2011 23:03:43 -0000 > >> On 02/18/2011 10:08, Rick Macklem wrote: > >> > The attached patches changes the behaviour so that it tries to > >> > get an unused port for each of the 4 cases. > >> > >> can you send me the patches? > >> thanks, > >> danny > > > They're attached. If you get to test them, please let me know > > how it goes. > > > > rick > > Hi Rick, > the good side of living on different time zones :-) > I got impatient, so I came up with a different fix. > The rational is that IMHO, there is no need for all listeners > to be on the same port: > rnd> rpcinfo protonew |grep mountd > 100005 1 udp6 ::.3.141 mountd superuser > 100005 3 udp6 ::.3.141 mountd superuser > 100005 1 tcp6 ::.3.141 mountd superuser > 100005 3 tcp6 ::.3.141 mountd superuser > 100005 1 udp 0.0.0.0.3.141 mountd superuser > 100005 3 udp 0.0.0.0.3.141 mountd superuser > 100005 1 tcp 0.0.0.0.3.92 mountd superuser <--- > 100005 3 tcp 0.0.0.0.3.92 mountd superuser <--- > rnd> rpcinfo -t protonew mountd > program 100005 version 1 ready and waiting > rpcinfo: RPC: Program/version mismatch; low version = 1, high version > = 3 > program 100005 version 2 is not available > program 100005 version 3 ready and waiting > > the patches are in: > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/patches/address_already_in_use/ > > cheers, > danny > Yep, a patch that doesn't make them all use the same port# is much simpler. However, others, such as Doug Barton feel that it is important that they use the same port#. (Something he called "tracking".) rick From owner-freebsd-stable@FreeBSD.ORG Fri Mar 11 23:54:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B93A106564A for ; Fri, 11 Mar 2011 23:54:41 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from internet02.xtechllc.com (internet02.xtechllc.com [65.127.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id 20DA58FC20 for ; Fri, 11 Mar 2011 23:54:40 +0000 (UTC) Received: from service02.office.ebureau.com (service02.office.ebureau.com [192.168.20.15]) by internet02.xtechllc.com (Postfix) with ESMTP id ACE397264E6; Fri, 11 Mar 2011 17:36:50 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by service02.office.ebureau.com (Postfix) with ESMTP id 8E77B675CAEB; Fri, 11 Mar 2011 17:36:50 -0600 (CST) X-Virus-Scanned: amavisd-new at ebureau.com Received: from service02.office.ebureau.com ([127.0.0.1]) by localhost (service02.office.iscompanies.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9KiW7yDswaf; Fri, 11 Mar 2011 17:36:49 -0600 (CST) Received: from square.office.iscompanies.com (square.office.iscompanies.com [10.10.20.22]) by service02.office.ebureau.com (Postfix) with ESMTPSA id 6CD80675CAD9; Fri, 11 Mar 2011 17:36:49 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dustin Wenz In-Reply-To: Date: Fri, 11 Mar 2011 17:36:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E4869D6-FE68-4746-BA79-2F709EDE9F67@ebureau.com> References: <2D5317E3-D96F-4123-88D5-5AF1BEAD5B9F@xtechllc.com> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1082) Cc: Rumen Telbizov Subject: Re: LSI SAS2008 performance with mps(4) driver 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: Fri, 11 Mar 2011 23:54:41 -0000 Thanks; It's good to know that it's at least possible to make this work = in some instances. Unfortunately, our SAS2008 controller is integrated with the logic board = (a SuperMicro X8DT6) connected to a SAS-113TQ backplane. It's not so = much of an expander; there are two breakout cables that go from the = SFF8087 connectors to individual SATA connectors for each drive on the = backplane. I've spoken with LSI, and (unsurprisingly) they are unable to = provide firmware for chips which are integrated in 3rd party devices. = SuperMicro also doesn't have any particularly recent updates - the = newest I could find was from last August. If this is indeed an issue with the onboard SAS2008 hardware/firmware, = I'm probably going to have to spring for a separate controller card in = the short term. :/ - .Dustin On Mar 10, 2011, at 10:09 PM, Rumen Telbizov wrote: > Hello Dustin, >=20 > I've been testing this SAS2008 LSI chip (on a LSI 9211-8i) for the = last month or so and I can say > that it makes a pretty good HBA but there are indeed a few caveats you = might need to be aware of. > In support of that - tonight I finished a FreeBSD 8.2-STABLE machine = with 2 x 24 disk chassis (each with > a 3Gbit expander) =3D 48 x 2TB SATA RE4-GP disks in 6 x 8disk raidz2 = and I am able to squeeze out 900MB/s > write and 1200 MB/s read in a sequential (single dd) manner. The limit = here is the backplane speed. >=20 > So back to your problem: >=20 > 1) What kind of backplane are you using: please specify the exact = model. Is it a SAS expander or direct attached? > 3Gbit/s or 6Gbit/s? > 2) What kind of disk controller exactly are you using? More = importantly what kind of firmware does it have? >=20 > Those two are very important. In my case it turned out that if I was = connecting SAS2008 chips > to pretty much every kind of SuperMicro SAS expander backplanes (tried = against 826EL26, 836E1, 846E1) I was > getting around 200-300MB/s read/write speeds (FreeBSD and Linux). = Direct attached backplanes (826A) worked fine. > At the end it turned out that it was some sort of a problem with the = LSI firmware (version 8.00 in my case) and I was given > to try version 9.00 (soon to be released) which completely solved the = problem. Contact LSI support (very high quality) if you want to try this = firmware. >=20 > I can't seem to get any better performance than about 250MB/s writes = through the controller. I'm testing with a zpool of six 250MB magnetic = SATA disks, doing a couple of concurrent sequential writes with dd: >=20 > dd bs=3D128k if=3D/dev/zero of=3D/datadisk/zero1 & > dd bs=3D128k if=3D/dev/zero of=3D/datadisk/zero2 & >=20 >=20 > 3) What kind of zpool raid level do you have those disks organized in? > 4) Running two parallel dd's on the same pool will actually turn the = game into no-so-sequential type and more of a random access. > Please try the following and paste results here: > 4.1) dd if=3D/dev/zero of=3D/datadisk/zero1 bs=3D1M count=3D50000 = (only one dd and use a file size larger than your memory) > 4.2) Destroy the zpool (if you have no useful data on it of course) = and try dd against each and every disk individually. > So something like: > dd if=3D/dev/zero of=3D/dev/da0 bs=3D1M count=3D50000 > dd if=3D/dev/da0 of=3D/dev/null bs=3D1M count=3D50000 > monitor throughput with gstat -f da0 or I can send you a simple C = program that I wrote which resembles dd but=20 > prints stats every second. > =20 > On a related note I also experienced very slow read speeds (200MB/s) = with the above mentioned configuration and after enabling > prefetch (I used to set it to disabled as per Jeremy Chadwick's = advise) everything went back to normal - so keep it in mind.=20 >=20 > Cheers, > Rumen Telbizov >=20 > --=20 > Rumen Telbizov > http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 02:04:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97A1A106564A for ; Sat, 12 Mar 2011 02:04:20 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 472DF8FC0C for ; Sat, 12 Mar 2011 02:04:20 +0000 (UTC) Received: by qyk35 with SMTP id 35so101990qyk.13 for ; Fri, 11 Mar 2011 18:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vZIZP/rAzfn0ScCj0VJsBn0+yzzA/WS4T9xE3wjt78M=; b=jhAUok/jJn+cokPUTsAzlS3DdwD7xSdgrXFHCokrEfD7JtdcNxg7sq5txxB0KOA4O4 9l9KmVAkszoCJjjGwqhba8oCCCOVyxBb+lkJruaL5T0eYLmIOtlPDhIkfs2JyFoDmA4x ID9q8fa1GAcJYWTe4buTZf44AMxfyt6dOO22s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r8v96rF7+u+1NqNgAFogzRB8TtdJwto4JayYo5uIm48NGxehf4B3xtigFGoNwzeWG1 KrcIDnp/18rp6D7PePvPx70ylk52ifRUGh/vnz2KQwVVfeSXa9SxHfJLNbU0vHHS0V5n rNlcXVRZdB+1ElkaM5iz7E8s0BSgZQ7xnsxcY= MIME-Version: 1.0 Received: by 10.229.234.12 with SMTP id ka12mr8277980qcb.66.1299895459400; Fri, 11 Mar 2011 18:04:19 -0800 (PST) Received: by 10.229.226.10 with HTTP; Fri, 11 Mar 2011 18:04:19 -0800 (PST) In-Reply-To: <7E4869D6-FE68-4746-BA79-2F709EDE9F67@ebureau.com> References: <2D5317E3-D96F-4123-88D5-5AF1BEAD5B9F@xtechllc.com> <7E4869D6-FE68-4746-BA79-2F709EDE9F67@ebureau.com> Date: Fri, 11 Mar 2011 18:04:19 -0800 Message-ID: From: Rumen Telbizov To: Dustin Wenz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: LSI SAS2008 performance with mps(4) driver 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: Sat, 12 Mar 2011 02:04:20 -0000 Dustin, Thanks; It's good to know that it's at least possible to make this work in > some instances. > It does. Unfortunately, our SAS2008 controller is integrated with the logic board (a > SuperMicro X8DT6) connected to a SAS-113TQ backplane. Well I forgot to mention that those 9211-8i's that I have were actually used on X8DT6-F motherboard that I purchased specifically so that I use the built-in controller and save one external. Well listen ... the chip on this mother board is SAS2008 and is exactly the same as far as I can tell. I did go ahead and flashed it too with the latest firmware - 9.00 and it did make a difference for me when playing with the SAS expanders. > It's not so much of an expander; there are two breakout cables that go from > the SFF8087 connectors to individual SATA connectors for each drive on the > backplane. Interesting. It is indeed a direct attached backplane then. Nevertheless I wouldn't be surprised if there's another form of incompatibility with some of the direct attached backplanes. > I've spoken with LSI, and (unsurprisingly) they are unable to provide > firmware for chips which are integrated in 3rd party devices. SuperMicro > also doesn't have any particularly recent updates - the newest I could find > was from last August. > I think version 9.00 will be released any moment now. > If this is indeed an issue with the onboard SAS2008 hardware/firmware, I'm > probably going to have to spring for a separate controller card in the short > term. :/ > > - .Dustin > > On Mar 10, 2011, at 10:09 PM, Rumen Telbizov wrote: > > > Hello Dustin, > > > > I've been testing this SAS2008 LSI chip (on a LSI 9211-8i) for the last > month or so and I can say > > that it makes a pretty good HBA but there are indeed a few caveats you > might need to be aware of. > > In support of that - tonight I finished a FreeBSD 8.2-STABLE machine with > 2 x 24 disk chassis (each with > > a 3Gbit expander) = 48 x 2TB SATA RE4-GP disks in 6 x 8disk raidz2 and I > am able to squeeze out 900MB/s > > write and 1200 MB/s read in a sequential (single dd) manner. The limit > here is the backplane speed. > > > > So back to your problem: > > > > 1) What kind of backplane are you using: please specify the exact model. > Is it a SAS expander or direct attached? > > 3Gbit/s or 6Gbit/s? > > 2) What kind of disk controller exactly are you using? More importantly > what kind of firmware does it have? > > > > Those two are very important. In my case it turned out that if I was > connecting SAS2008 chips > > to pretty much every kind of SuperMicro SAS expander backplanes (tried > against 826EL26, 836E1, 846E1) I was > > getting around 200-300MB/s read/write speeds (FreeBSD and Linux). Direct > attached backplanes (826A) worked fine. > > At the end it turned out that it was some sort of a problem with the LSI > firmware (version 8.00 in my case) and I was given > > to try version 9.00 (soon to be released) which completely solved the > problem. Contact LSI support (very high quality) if you want to try this > firmware. > > > > I can't seem to get any better performance than about 250MB/s writes > through the controller. I'm testing with a zpool of six 250MB magnetic SATA > disks, doing a couple of concurrent sequential writes with dd: > > > > dd bs=128k if=/dev/zero of=/datadisk/zero1 & > > dd bs=128k if=/dev/zero of=/datadisk/zero2 & > > > > > > 3) What kind of zpool raid level do you have those disks organized in? > > 4) Running two parallel dd's on the same pool will actually turn the game > into no-so-sequential type and more of a random access. > > Please try the following and paste results here: > > 4.1) dd if=/dev/zero of=/datadisk/zero1 bs=1M count=50000 (only one dd > and use a file size larger than your memory) > > 4.2) Destroy the zpool (if you have no useful data on it of course) and > try dd against each and every disk individually. > > So something like: > > dd if=/dev/zero of=/dev/da0 bs=1M count=50000 > > dd if=/dev/da0 of=/dev/null bs=1M count=50000 > > monitor throughput with gstat -f da0 or I can send you a simple C program > that I wrote which resembles dd but > > prints stats every second. > > > > On a related note I also experienced very slow read speeds (200MB/s) with > the above mentioned configuration and after enabling > > prefetch (I used to set it to disabled as per Jeremy Chadwick's advise) > everything went back to normal - so keep it in mind. > > > > Cheers, > > Rumen Telbizov > > > > -- > > Rumen Telbizov > > http://telbizov.com > > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 10:21:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3171C106566C for ; Sat, 12 Mar 2011 10:21:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id DD5AA8FC18 for ; Sat, 12 Mar 2011 10:21:17 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PyLwg-000PaY-Fu; Sat, 12 Mar 2011 12:21:14 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Rick Macklem In-reply-to: <2122282816.1268010.1299884622480.JavaMail.root@erie.cs.uoguelph.ca> References: <2122282816.1268010.1299884622480.JavaMail.root@erie.cs.uoguelph.ca> Comments: In-reply-to Rick Macklem message dated "Fri, 11 Mar 2011 18:03:42 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Mar 2011 12:21:14 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Doug Barton Subject: Re: statd/lockd startup failure 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: Sat, 12 Mar 2011 10:21:18 -0000 > > >> On 02/18/2011 10:08, Rick Macklem wrote: > > >> > The attached patches changes the behaviour so that it tries to > > >> > get an unused port for each of the 4 cases. > > >> > > >> can you send me the patches? > > >> thanks, > > >> danny > > > > > They're attached. If you get to test them, please let me know > > > how it goes. > > > > > > rick > > > > Hi Rick, > > the good side of living on different time zones :-) > > I got impatient, so I came up with a different fix. > > The rational is that IMHO, there is no need for all listeners > > to be on the same port: > > rnd> rpcinfo protonew |grep mountd > > 100005 1 udp6 ::.3.141 mountd superuser > > 100005 3 udp6 ::.3.141 mountd superuser > > 100005 1 tcp6 ::.3.141 mountd superuser > > 100005 3 tcp6 ::.3.141 mountd superuser > > 100005 1 udp 0.0.0.0.3.141 mountd superuser > > 100005 3 udp 0.0.0.0.3.141 mountd superuser > > 100005 1 tcp 0.0.0.0.3.92 mountd superuser <--- > > 100005 3 tcp 0.0.0.0.3.92 mountd superuser <--- > > rnd> rpcinfo -t protonew mountd > > program 100005 version 1 ready and waiting > > rpcinfo: RPC: Program/version mismatch; low version = 1, high version > > = 3 > > program 100005 version 2 is not available > > program 100005 version 3 ready and waiting > > > > the patches are in: > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/patches/address_already_in_use/ > > > > cheers, > > danny > > > Yep, a patch that doesn't make them all use the same port# is much > simpler. However, others, such as Doug Barton feel that it is important > that they use the same port#. (Something he called "tracking".) The problem with trying to get the same port for all tcp/udp/inet/inet6 though might succeed most of the time, will fail sometimes, then what? I saw Doug's commnent, and also the :), it's not as simple as tracking port 80 or 25, needs some efford, but it's deterministic/programable, and worst case you can still use the -p option (which again will fail sometimes :-). IMHO, having a system that might fail to reboot is not very pleasant. danny From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 17:32:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E707106564A for ; Sat, 12 Mar 2011 17:32:43 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mx1.freebsd.org (Postfix) with ESMTP id D46348FC0A for ; Sat, 12 Mar 2011 17:32:42 +0000 (UTC) Received: from mail-in-01-z2.arcor-online.net (mail-in-01-z2.arcor-online.net [151.189.8.13]) by mx.arcor.de (Postfix) with ESMTP id 9BCE42D64AC for ; Sat, 12 Mar 2011 17:59:14 +0100 (CET) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 95E6E15B72D for ; Sat, 12 Mar 2011 17:59:14 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-092-075-209-195.pools.arcor-ip.net [92.75.209.195]) by mail-in-16.arcor-online.net (Postfix) with ESMTPS id 54B4883FC for ; Sat, 12 Mar 2011 17:59:14 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-16.arcor-online.net 54B4883FC Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.4/8.14.3) with ESMTP id p2CGxDp7043710 for ; Sat, 12 Mar 2011 17:59:13 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.4/8.14.4/Submit) id p2CGxD9n043709 for freebsd-stable@freebsd.org; Sat, 12 Mar 2011 17:59:13 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Sat, 12 Mar 2011 16:59:13 +0000 (UTC) Message-ID: References: <201103102048.p2AKm3Fq015932@egsner.cirr.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-stable@freebsd.org Subject: Re: happy hacker lite 2 keyboard 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: Sat, 12 Mar 2011 17:32:43 -0000 Eric Schnoebelen wrote: > - > All newer HH keuboards are usb ones. Manufacturer doesn't > - > confirm connection to ps/2 port with usb to ps/2 adapter. > - > Is there any reason not to do that on amd64? > - > - Hrm, strange that a nice keyboard like that comes as USB only. > > The orginal Happy Hacker was PS2. The original Happy Hacking Keyboard offered a choice of PS/2, Sun, and ADB with different adapter cables. The original HHKB Lite was PS/2. > I don't know if the original Happy Hacker keyboard is still > available, it hasn't been an issue for me. :D The successor to the original HHKB were the HHKB Professional (I'm typing this on one) and now the HHKB Professional 2. Both are USB only; the Pro2 added a hub. Wikipedia has an overview of all models: https://secure.wikimedia.org/wikipedia/en/wiki/Happy_Hacking_Keyboard -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 17:47:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A8F106564A for ; Sat, 12 Mar 2011 17:47:05 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B19F8FC16 for ; Sat, 12 Mar 2011 17:47:04 +0000 (UTC) Received: by iwn33 with SMTP id 33so4344625iwn.13 for ; Sat, 12 Mar 2011 09:47:04 -0800 (PST) Received: by 10.42.138.68 with SMTP id b4mr2909567icu.499.1299952023759; Sat, 12 Mar 2011 09:47:03 -0800 (PST) Received: from skeletor.feld.me (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id wu1sm775293icb.22.2011.03.12.09.47.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 09:47:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Sat, 12 Mar 2011 11:47:01 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: User-Agent: Opera Mail/11.10 (FreeBSD) Subject: Dell 850 Panic on boot 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: Sat, 12 Mar 2011 17:47:05 -0000 Hi guys, Not sure if this is the right place to report this but we have a couple Dell 850s at work and the extra one we're trying to put FreeBSD on panics on boot. The servers are running 3.0ghz Pentium D processors (dual core) and they've got the EMT64 extension. So far it panics with the install cd for these versions: 8.1 i386 and amd64 8.2 i386 and amd64 7.4 amd64 I haven't tried any others. We needed to get this up to test something BSD specific so right now it's running OpenBSD. Here is a picture of the console from when it panics: http://feld.me/stuff/freebsd/dell_850_panic.png Some people in the ##freebsd channel on Freenode said it looked like it panics whenever it initializes the second CPU. There's no option in the BIOS (which is up to date) that offers you the ability to disable a core or hyperthreading or whatever this CPU does. Any insight would be greatly appreciated. Thanks, Mark From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 18:30:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE722106566C for ; Sat, 12 Mar 2011 18:30:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 031628FC13 for ; Sat, 12 Mar 2011 18:30:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA28818; Sat, 12 Mar 2011 20:30:15 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PyTZu-000NV2-Ka; Sat, 12 Mar 2011 20:30:14 +0200 Message-ID: <4D7BBBB6.4060004@freebsd.org> Date: Sat, 12 Mar 2011 20:30:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mark Felder References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Dell 850 Panic on boot 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: Sat, 12 Mar 2011 18:30:19 -0000 on 12/03/2011 19:47 Mark Felder said the following: > Hi guys, > > Not sure if this is the right place to report this but we have a couple Dell > 850s at work and the extra one we're trying to put FreeBSD on panics on boot. > The servers are running 3.0ghz Pentium D processors (dual core) and they've got > the EMT64 extension. So far it panics with the install cd for these versions: > > 8.1 i386 and amd64 > 8.2 i386 and amd64 > 7.4 amd64 > > I haven't tried any others. We needed to get this up to test something BSD > specific so right now it's running OpenBSD. > > Here is a picture of the console from when it panics: > > http://feld.me/stuff/freebsd/dell_850_panic.png > > Some people in the ##freebsd channel on Freenode said it looked like it panics > whenever it initializes the second CPU. There's no option in the BIOS (which is > up to date) that offers you the ability to disable a core or hyperthreading or > whatever this CPU does. > > Any insight would be greatly appreciated. Mark, do you get exactly the same panic message with 8.2 or a slightly more informative one? If the latter, then could please provide a screenshot of that? Thanks for the report! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 19:55:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F5EC106566C for ; Sat, 12 Mar 2011 19:55:53 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 197428FC13 for ; Sat, 12 Mar 2011 19:55:53 +0000 (UTC) Received: from supra.b1c1l1.com (supra.b1c1l1.com [IPv6:2001:470:83fb:0:225:ff:fe4d:54b6]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id D74385C2F for ; Sat, 12 Mar 2011 11:55:52 -0800 (PST) Message-ID: <4D7BCFC0.8030602@b1c1l1.com> Date: Sat, 12 Mar 2011 11:55:44 -0800 From: Benjamin Lee User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110122 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFA5EA8DE812F1FD1030DEC16" Subject: mfi(4) command timeout loop on boot on releng/8.2 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: Sat, 12 Mar 2011 19:55:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFA5EA8DE812F1FD1030DEC16 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I just filed PR kern/155499 regarding an mfi(4) command timeout loop when I try to boot an 8.2-RELEASE kernel. This system does not have any problems with 8.1-RELEASE. With MFI_DEBUG I get the following output: mfi0: COMMAND 0xffffff80002c6440 TIMEOUT AFTER 59 SECONDS mfi0: cm=3D0xffffff80002c6440 index=3D8 total_frame_size=3D52 extra_frame= s=3D0 mfi0: flags=3D83 mfi0: cmd=3DMFI_CMD_DCMD opcode=3DLD_GET_LIST data_len=3D1032 mfi0: flags=3D12 SG List: 0x1a3d000:001032 mfi0: mfi_timeout 2522 COMMAND 0xffffff80002c6440 S/G count bad 0 1032 10= 32 0x1a3d000 mfi0: cm=3D0xffffff80002c6440 index=3D8 total_frame_size=3D52 extra_frame= s=3D0 mfi0: flags=3D83 mfi0: cmd=3DMFI_CMD_DCMD opcode=3DLD_GET_LIST data_len=3D1032 mfi0: flags=3D12 SG List: 0x1a3d000:001032 This output repeats itself every 30 seconds (with the timeout counter increasing). The card is an LSI MegaRAID SAS 8408E: blee@genesis ~ $ pciconf -lv | grep -A4 mfi0 mfi0@pci0:6:14:0: class=3D0x010400 card=3D0x10011000 chip=3D0x04111000 rev=3D0x00 hdr=3D0x00 vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' device =3D 'MegaRAID Family RAID Controller' class =3D mass storage subclass =3D RAID blee@genesis ~ $ sudo mfiutil show adapter mfi0 Adapter: Product Name: MegaRAID SAS 8408E Serial Number: P186584707 Firmware: 7.0.1-0081 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M Upgrading to the latest firmware had no effect: blee@genesis ~ $ sudo mfiutil show firmware mfi0 Firmware Package Version: 7.0.1-0081 mfi0 Firmware Images: Name Version Date Time Status BTBL R.2.3.15 May 20 2008 16:09:27 active BIOS MT33 active MPT1 MPTFW-01.18.172.00-IT 01/31/11 16:49:08 active APP 1.12.310-1112 Dec 17 2010 14:54:35 active BCON 1.1-33j-e_11-Rel Aug 20 2009 21:16:24 active CTLR 1.04-019A Aug 13 2007 23:21:34 active MPT3 MPTFW-01.18.172.00-IT 01/31/11 16:49:29 active PCLI 01.00-011:#%00001 Oct 10 2007 16:30:36 active Any suggestions? --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enigFA5EA8DE812F1FD1030DEC16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNe8/IAAoJEDQaOGXZe8jkw44P/jChTExiGlfIkOFA/77AZDCX IgCMv7lvX/+kNe9XnuFsfe14Bnyk2WVXuMSDAhw//mfgzFBTPJOfbxPskPETylX3 R+Cb323wKqSToKVCh6zaiWspnJuaCNUyhu4oWAuGSWjsfYXauora+lINcHsLWJ9Y RN7u3XaMhV14NY+7IZBXj3nR+K8xjbKK0T2u5GBLXpiCTdeXSREPuZY5ZDKfEubd ujZkRcCAlkzn/IKu8l8Gd6bDqzjcb0rM+3EJHSHtzktDAhJnsYIUBvm32cVktWrc b238QP5C7rRHvV19Fqtg4JgGc9w/SCOp0mVQfZwg5HUIG5wBiT7dEEjMVr922ECN phstnNTilwLkLD/ks63ZF3bz/RowsIuyuzOUknnBJLifOt08jPW3q2KcLRJjryZt RMc2ockIpztZ+4VJdGMVSMHCGdahPkv9Ym0nJxZRqAzg33FrM+cpa8Ku+DbqBIFs EwOlvaZDGwq7Hgfi79NJ1e9B6v/2j3MyM7pG4Hpm1mKvCyXdegizEVfdF2RlsSmY YmqXaF9qw8Ofs2JD+IW7rhyoEW4vEKtjyDRqmYRLiorzOsaRjVtFmEmTZvZBF23o /EWeox+/aq1feEuOuirk7FUIXMh2MH3s2bh7+/r67oOHc0sg2ntLl+s6VPdrwykp Xv81aCURQ9C1uOQeuS14 =5x5f -----END PGP SIGNATURE----- --------------enigFA5EA8DE812F1FD1030DEC16-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 20:06:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46ABE1065670 for ; Sat, 12 Mar 2011 20:06:41 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17F2A8FC08 for ; Sat, 12 Mar 2011 20:06:40 +0000 (UTC) Received: by iwn33 with SMTP id 33so4423229iwn.13 for ; Sat, 12 Mar 2011 12:06:40 -0800 (PST) Received: by 10.42.175.193 with SMTP id bb1mr1536677icb.479.1299960400277; Sat, 12 Mar 2011 12:06:40 -0800 (PST) Received: from localhost.localdomain (68-117-126-78.static.mdsn.wi.charter.com [68.117.126.78]) by mx.google.com with ESMTPS id uf10sm4279467icb.5.2011.03.12.12.06.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 12:06:39 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Andriy Gapon" References: <4D7BBBB6.4060004@freebsd.org> Date: Sat, 12 Mar 2011 14:06:38 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <4D7BBBB6.4060004@freebsd.org> User-Agent: Opera Mail/11.10 (Linux) Cc: freebsd-stable@freebsd.org Subject: Re: Dell 850 Panic on boot 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: Sat, 12 Mar 2011 20:06:41 -0000 On Sat, 12 Mar 2011 12:30:14 -0600, Andriy Gapon wrote: > do you get exactly the same panic message with 8.2 or a slightly more > informative one? If the latter, then could please provide a screenshot > of that? > Yeah, the 8.x seemed to have more details. That happens to be a screenshot from the 7.4 disc. I don't have access to the machine until Monday but I'll post an update then. Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 22:11:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2CF1065670 for ; Sat, 12 Mar 2011 22:11:33 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1276D8FC0A for ; Sat, 12 Mar 2011 22:11:32 +0000 (UTC) Received: (qmail 20978 invoked by uid 399); 12 Mar 2011 22:11:28 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 12 Mar 2011 22:11:28 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7BEF8F.9080604@dougbarton.us> Date: Sat, 12 Mar 2011 14:11:27 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Daniel Braniss References: <2122282816.1268010.1299884622480.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rick Macklem , freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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: Sat, 12 Mar 2011 22:11:33 -0000 On 03/12/2011 02:21, Daniel Braniss wrote: > The problem with trying to get the same port for all tcp/udp/inet/inet6 > though might succeed most of the time, will fail sometimes, then what? Can you please describe the scenario when it's completely impossible to find a port that's open on all 4 families? > I saw Doug's commnent, and also the:), it's not as simple as tracking port > 80 or 25, needs some efford, but it's deterministic/programable, and worst case > you can still use the -p option (which again will fail sometimes:-). Given that Rick has already written the patch, I don't think it's at all unreasonable to put it in as the first choice, perhaps with a fallback to picking any available port if there isn't one available for all 4 families. Meanwhile, I don't think I'm the only person who has ever had trouble trying to track down network traffic from "random" ports that would prefer that doing so not be made harder by having the same service on the same host using 4 different ports. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 22:56:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC590106566B for ; Sat, 12 Mar 2011 22:56:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9428C8FC0C for ; Sat, 12 Mar 2011 22:56:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFWJe02DaFvO/2dsb2JhbACEPaJ+sFGPf4Eng0V2BIUrhyc X-IronPort-AV: E=Sophos;i="4.62,309,1297054800"; d="scan'208";a="114089583" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Mar 2011 17:56:36 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7D93DB3F49; Sat, 12 Mar 2011 17:56:36 -0500 (EST) Date: Sat, 12 Mar 2011 17:56:36 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <1745116963.1290533.1299970596486.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4D7BEF8F.9080604@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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: Sat, 12 Mar 2011 22:56:37 -0000 > On 03/12/2011 02:21, Daniel Braniss wrote: > > The problem with trying to get the same port for all > > tcp/udp/inet/inet6 > > though might succeed most of the time, will fail sometimes, then > > what? > > Can you please describe the scenario when it's completely impossible > to > find a port that's open on all 4 families? > > > I saw Doug's commnent, and also the:), it's not as simple as > > tracking port > > 80 or 25, needs some efford, but it's deterministic/programable, and > > worst case > > you can still use the -p option (which again will fail sometimes:-). > > Given that Rick has already written the patch, I don't think it's at > all > unreasonable to put it in as the first choice, perhaps with a fallback > to picking any available port if there isn't one available for all 4 > families. > I suppose the patch could be changed to switch to "allow any port#" after N failed attempts at getting the same one. (I'll admit I have troiuble seeing why getting the same port# would fail "forever" unless all ports are in use and, if that's the case, you're snookered.) My only concern with the "same port# patch" is that it is more complex and, therefore, somewhat riskier w.r.t. my having gotten it wrong. > Meanwhile, I don't think I'm the only person who has ever had trouble > trying to track down network traffic from "random" ports that would > prefer that doing so not be made harder by having the same service on > the same host using 4 different ports. > From owner-freebsd-stable@FreeBSD.ORG Sat Mar 12 23:09:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7449A106568B for ; Sat, 12 Mar 2011 23:09:00 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4A488162F07; Sat, 12 Mar 2011 23:09:00 +0000 (UTC) Message-ID: <4D7BFD0B.6000405@FreeBSD.org> Date: Sat, 12 Mar 2011 15:08:59 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Rick Macklem References: <1745116963.1290533.1299970596486.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1745116963.1290533.1299970596486.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure 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: Sat, 12 Mar 2011 23:09:00 -0000 On 03/12/2011 14:56, Rick Macklem wrote: >> On 03/12/2011 02:21, Daniel Braniss wrote: >>> The problem with trying to get the same port for all >>> tcp/udp/inet/inet6 >>> though might succeed most of the time, will fail sometimes, then >>> what? >> >> Can you please describe the scenario when it's completely impossible >> to >> find a port that's open on all 4 families? >> >>> I saw Doug's commnent, and also the:), it's not as simple as >>> tracking port >>> 80 or 25, needs some efford, but it's deterministic/programable, and >>> worst case >>> you can still use the -p option (which again will fail sometimes:-). >> >> Given that Rick has already written the patch, I don't think it's at >> all >> unreasonable to put it in as the first choice, perhaps with a fallback >> to picking any available port if there isn't one available for all 4 >> families. >> > I suppose the patch could be changed to switch to "allow any port#" > after N failed attempts at getting the same one. (I'll admit I have > troiuble seeing why getting the same port# would fail "forever" unless > all ports are in use and, if that's the case, you're snookered.) Right. :) I'm not suggesting that you do that, btw. But I'm not opposed to the idea if it proves to be necessary (which I seriously doubt). > My only concern with the "same port# patch" is that it is more complex > and, therefore, somewhat riskier w.r.t. my having gotten it wrong. Fair enough, and I'm usually the first to oppose needless complexity, but I think in this case it's worth it. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/