From owner-freebsd-stable@FreeBSD.ORG Sun Apr 8 08:58:33 2012 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 C1D8A106564A; Sun, 8 Apr 2012 08:58:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 546278FC08; Sun, 8 Apr 2012 08:58:33 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q388wWMn050814; Sun, 8 Apr 2012 08:58:32 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q388wWLX050805; Sun, 8 Apr 2012 08:58:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 8 Apr 2012 08:58:32 GMT Message-Id: <201204080858.q388wWLX050805@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 08:58:33 -0000 TB --- 2012-04-08 08:26:29 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-04-08 08:26:29 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-04-08 08:26:29 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2012-04-08 08:26:29 - cleaning the object tree TB --- 2012-04-08 08:26:29 - cvsupping the source tree TB --- 2012-04-08 08:26:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/sparc64/sparc64/supfile TB --- 2012-04-08 08:27:33 - building world TB --- 2012-04-08 08:27:33 - CROSS_BUILD_TESTING=YES TB --- 2012-04-08 08:27:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-08 08:27:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-08 08:27:33 - SRCCONF=/dev/null TB --- 2012-04-08 08:27:33 - TARGET=sparc64 TB --- 2012-04-08 08:27:33 - TARGET_ARCH=sparc64 TB --- 2012-04-08 08:27:33 - TZ=UTC TB --- 2012-04-08 08:27:33 - __MAKE_CONF=/dev/null TB --- 2012-04-08 08:27:33 - cd /src TB --- 2012-04-08 08:27:33 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 8 08:27:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -DVERSION='"9.8.1-P1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=84 -DLIBREVISION=1 -DLIBAGE=3 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/dns/.. -I/src/lib/bind/dns/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/dns/../isc -I/src/lib/bind/dns/../../../contrib/bind9/lib/l! wres/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/dns/../lwres -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns -I/src/lib/bind/dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/noatomic/include -std=gnu99 -fstack-protector -c /src/lib/bind/dns/../../../contrib/bind9/lib/dns/portlist.c cc -O2 -pipe -DVERSION='"9.8.1-P1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=84 -DLIBREVISION=1 -DLIBAGE=3 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/dns/.. -I/src/lib/bind/dns/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/dns/../isc -I/src/lib/bind/dns/../../../contrib/bind9/lib/l! wres/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/dns/../lwres -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns -I/src/lib/bind/dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/noatomic/include -std=gnu99 -fstack-protector -c /src/lib/bind/dns/../../../contrib/bind9/lib/dns/private.c cc -O2 -pipe -DVERSION='"9.8.1-P1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=84 -DLIBREVISION=1 -DLIBAGE=3 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/dns/.. -I/src/lib/bind/dns/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/dns/../isc -I/src/lib/bind/dns/../../../contrib/bind9/lib/l! wres/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/dns/../lwres -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns -I/src/lib/bind/dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/noatomic/include -std=gnu99 -fstack-protector -c /src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbt.c cc -O2 -pipe -DVERSION='"9.8.1-P1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=84 -DLIBREVISION=1 -DLIBAGE=3 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/dns/.. -I/src/lib/bind/dns/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/dns/../isc -I/src/lib/bind/dns/../../../contrib/bind9/lib/l! wres/unix/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/dns/../lwres -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/dns/../../../contrib/bind9/lib/dns -I/src/lib/bind/dns -I/src/lib/bind/dns/../../../contrib/bind9/lib/isc/noatomic/include -std=gnu99 -fstack-protector -c /src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c /src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c: In function 'rpz_findips': /src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:4711: error: 'DNS_RPZ_POLICY_NO_OP' undeclared (first use in this function) /src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:4711: error: (Each undeclared identifier is reported only once /src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:4711: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/bind/dns. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-08 08:58:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-08 08:58:32 - ERROR: failed to build world TB --- 2012-04-08 08:58:32 - 1326.50 user 243.97 system 1923.31 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Apr 8 09:34:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A7531065670; Sun, 8 Apr 2012 09:34:14 +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 DDEE68FC18; Sun, 8 Apr 2012 09:34:10 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SGoVX-000EYm-90; Sun, 08 Apr 2012 12:34:03 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Ian Lepore In-reply-to: <1332434072.8403.79.camel@revolution.hippie.lan> References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> <4F6B4FAB.1020202@gmail.com> <1332434072.8403.79.camel@revolution.hippie.lan> Comments: In-reply-to Ian Lepore message dated "Thu, 22 Mar 2012 10:34:32 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Apr 2012 12:34:02 +0300 From: Daniel Braniss Message-ID: Cc: Volodymyr Kostyrko , Tkachuk , freebsd-stable@freebsd.org, Andriy Gapon , Mike@FreeBSD.ORG Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 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, 08 Apr 2012 09:34:14 -0000 > On Thu, 2012-03-22 at 18:13 +0200, Volodymyr Kostyrko wrote: > > Andriy Gapon wrote: > > > on 22/03/2012 17:33 Volodymyr Kostyrko said the following: > > >> Andriy Gapon wrote: > > >>> on 22/03/2012 15:19 Mike Tkachuk said the following: > > >>>> kern.eventtimer.periodic: 0 > > >>> > > >>> It might make sense to try 1 here. > > >>> Also you could attempt to involve mav@ directly - here is an author of the code > > >>> and an expert on it. > > >> > > >> Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with > > >> LAPIC) interrupt rate for me. > > > > > > Does it make your system unusable? > > > Are you comparing with pre-eventtimers version of FreeBSD? > > > > In short term - no. Haven't tested it thoroughly. Results are the same > > (double interrupt rate according to `systat 1 -v`) for: > > * i386 and amd64 9-STABLE; > > * amd64 9.0. > > > > As everything related to timing/freq/acpi can be unpredictive I wouldn't > > recommend this to anyone. I own at least two Intel CPU's failing > > somewhere near timing/apic when loading cpufreq and enabling powerd. > > > > I'm not sure I understand that advice. We have someone whose system is > failing (time stops counting) when using the new event timer code. The > recommendation is to set kern.eventtimer.periodic=1, which as I > understand it makes the new code work more like it did before. That > seems to be a reasonable attempt to work around the problem. > > If it works, the system becomes 100% more usable than it is now, even if > that comes at the cost of timers interrupting twice as fast as they did > in previous OS releases. It also generates another datapoint that might > somehow help track down why the event timer code has trouble on some > hardware. Enough such datapoints may eventually lead to an "aha -- it > happens on all systems that have the xyz chipset." Just a me too: but it was running 8.2-stable! since it's a production machine, I had no choice but to reboot it. Also the BIOS time got stuck, so I had to fix the time manualy! ntpd doesn't like to advance past a certain delta. cheers, danny From owner-freebsd-stable@FreeBSD.ORG Sun Apr 8 12:55:23 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C55FE106566B; Sun, 8 Apr 2012 12:55:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 863518FC12; Sun, 8 Apr 2012 12:55:23 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q38CtN3K001809; Sun, 8 Apr 2012 12:55:23 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q38CtMTB001796; Sun, 8 Apr 2012 12:55:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 8 Apr 2012 12:55:22 GMT Message-Id: <201204081255.q38CtMTB001796@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 12:55:23 -0000 TB --- 2012-04-08 12:45:18 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-04-08 12:45:18 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-04-08 12:45:18 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2012-04-08 12:45:18 - cleaning the object tree TB --- 2012-04-08 12:45:18 - cvsupping the source tree TB --- 2012-04-08 12:45:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/ia64/ia64/supfile TB --- 2012-04-08 12:55:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2012-04-08 12:55:22 - ERROR: unable to cvsup the source tree TB --- 2012-04-08 12:55:22 - 0.03 user 0.01 system 604.23 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Apr 8 13:30:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAC43106564A; Sun, 8 Apr 2012 13:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id A5A268FC08; Sun, 8 Apr 2012 13:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q38DU2a4009348; Sun, 8 Apr 2012 13:30:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q38DU21g009340; Sun, 8 Apr 2012 13:30:02 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 8 Apr 2012 13:30:02 GMT Message-Id: <201204081330.q38DU21g009340@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 13:30:03 -0000 TB --- 2012-04-08 12:55:23 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-04-08 12:55:23 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-04-08 12:55:23 - starting RELENG_9 tinderbox run for mips/mips TB --- 2012-04-08 12:55:23 - cleaning the object tree TB --- 2012-04-08 12:55:23 - cvsupping the source tree TB --- 2012-04-08 12:55:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/mips/mips/supfile TB --- 2012-04-08 13:30:02 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2012-04-08 13:30:02 - ERROR: unable to cvsup the source tree TB --- 2012-04-08 13:30:02 - 0.06 user 0.00 system 2078.90 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Apr 8 21:12:22 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 964AC106564A for ; Sun, 8 Apr 2012 21:12:22 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4494D8FC14 for ; Sun, 8 Apr 2012 21:12:22 +0000 (UTC) Received: by iahk25 with SMTP id k25so6939224iah.13 for ; Sun, 08 Apr 2012 14:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=joFqpyoIFY3nbm+1XJwS/6FzG/nndH9CKfAigpEg9Ww=; b=IqgUtSTmTChX/4ee2c1jliUKzjy/cisYYwg2jzZ28R4RVZwXZA+VLb+mmtIr10H/4G f/LqsQDKUFhxVX2hede09dboBAhV10GaFp9mbWYUlVhoKOwClNtk6PqKAxE64d6A4BbX quG1Olf4TeDBRdjDdE3nOVWSfZR2r1WpB3G2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=joFqpyoIFY3nbm+1XJwS/6FzG/nndH9CKfAigpEg9Ww=; b=fFbU5XzH0gFDH88SnCDVmqndy73jx5AdvDvOI6ukFZquZLMu/8KEshtcHug65/HKSq AsEOSGhXnuwiKiwBqAAQ1FsqlPSsMLA9MRTi8Ei/PVIOBWQr7bzFyzbglCOVZdERUzk2 wTa8l58GSXGao9EI8lNVudxGZ6BGeYnQe5xFL3Y45I9tK2ZvOz11sSCG2XsBYn1mUbcE b68WfBFSNDkc69H9svwLNIlOiTHehXLhznJthHkj5Z55TkJANTViCsQmkhhvCjs4BiEx npFYU8kib44yiunuV9YozgMDvrKV+5Ukyao/yGlas2DaalGXDsqnSGHrWtSLbSZXBuf8 6JfA== Received: by 10.50.46.167 with SMTP id w7mr3301697igm.73.1333919541734; Sun, 08 Apr 2012 14:12:21 -0700 (PDT) Received: from DataIX.net (adsl-99-181-142-73.dsl.klmzmi.sbcglobal.net. [99.181.142.73]) by mx.google.com with ESMTPS id re5sm12965939igb.0.2012.04.08.14.12.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Apr 2012 14:12:21 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q38LCJdV062812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Apr 2012 17:12:19 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q38LCIju062811; Sun, 8 Apr 2012 17:12:18 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 8 Apr 2012 17:12:18 -0400 From: Jason Hellenthal To: Mikolaj Golub Message-ID: <20120408211218.GA62178@DataIX.net> References: <201204061632.q36GWTT2017212@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204061632.q36GWTT2017212@svn.freebsd.org> X-Gm-Message-State: ALoCoQl1w2s8KcU5EDljJhfCqz+MJ8AxQ0ibk5aC6dgVKG8BE4OXM3McqquXPB9mDTlTRO2vTbjb Cc: stable@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233953 - stable/8/usr.bin/procstat 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, 08 Apr 2012 21:12:22 -0000 This commit in action does not seem to be doing the correct thing even though it does report an error when kern.proc.pathname is not known. Running procstat -a -b produces: [...] 1848 ksh 803500 /bin/ksh procstat: sysctl: kern.proc.pathname: 2208: No such file or directory 2210 ksh 803500 /bin/ksh [...] While procstat -a produces: [...] 1848 1846 1848 1848 1848 1 jhellenthal wait FreeBSD ELF32 ksh 2208 1814 2208 2208 0 1 jhellenthal select FreeBSD ELF32 xterm 2210 2208 2210 2210 2210 1 jhellenthal wait FreeBSD ELF32 ksh [...] If process 2208 can be seen during (procstat -a) I do not see a reason to bailout and print an error when (-b) is used. Just print the orrelease as (0) and print the rest of the information that should be seen... Could someone have a closer look at this? On Fri, Apr 06, 2012 at 04:32:29PM +0000, Mikolaj Golub wrote: > Author: trociny > Date: Fri Apr 6 16:32:29 2012 > New Revision: 233953 > URL: http://svn.freebsd.org/changeset/base/233953 > > Log: > MFC r233390: > > When displaying binary information show also osreldate. > > Suggested by: kib > > Modified: > stable/8/usr.bin/procstat/procstat.1 > stable/8/usr.bin/procstat/procstat_bin.c > Directory Properties: > stable/8/usr.bin/procstat/ (props changed) > > Modified: stable/8/usr.bin/procstat/procstat.1 > ============================================================================== > --- stable/8/usr.bin/procstat/procstat.1 Fri Apr 6 16:31:29 2012 (r233952) > +++ stable/8/usr.bin/procstat/procstat.1 Fri Apr 6 16:32:29 2012 (r233953) > @@ -25,7 +25,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd March 7, 2010 > +.Dd March 23, 2012 > .Dt PROCSTAT 1 > .Os > .Sh NAME > @@ -98,6 +98,8 @@ Display the process ID, command, and pat > process ID > .It COMM > command > +.It OSREL > +osreldate for process binary > .It PATH > path to process binary (if available) > .El > > Modified: stable/8/usr.bin/procstat/procstat_bin.c > ============================================================================== > --- stable/8/usr.bin/procstat/procstat_bin.c Fri Apr 6 16:31:29 2012 (r233952) > +++ stable/8/usr.bin/procstat/procstat_bin.c Fri Apr 6 16:32:29 2012 (r233953) > @@ -42,11 +42,11 @@ void > procstat_bin(pid_t pid, struct kinfo_proc *kipp) > { > char pathname[PATH_MAX]; > - int error, name[4]; > + int error, osrel, name[4]; > size_t len; > > if (!hflag) > - printf("%5s %-16s %-53s\n", "PID", "COMM", "PATH"); > + printf("%5s %-16s %8s %s\n", "PID", "COMM", "OSREL", "PATH"); > > name[0] = CTL_KERN; > name[1] = KERN_PROC; > @@ -64,7 +64,19 @@ procstat_bin(pid_t pid, struct kinfo_pro > if (len == 0 || strlen(pathname) == 0) > strcpy(pathname, "-"); > > + name[2] = KERN_PROC_OSREL; > + > + len = sizeof(osrel); > + error = sysctl(name, 4, &osrel, &len, NULL, 0); > + if (error < 0 && errno != ESRCH) { > + warn("sysctl: kern.proc.osrel: %d", pid); > + return; > + } > + if (error < 0) > + return; > + > printf("%5d ", pid); > printf("%-16s ", kipp->ki_comm); > + printf("%8d ", osrel); > printf("%s\n", pathname); > } > _______________________________________________ > svn-src-stable-8@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-stable-8 > To unsubscribe, send any mail to "svn-src-stable-8-unsubscribe@freebsd.org" -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Mon Apr 9 05:51:25 2012 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 341021065670; Mon, 9 Apr 2012 05:51:25 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84A578FC08; Mon, 9 Apr 2012 05:51:24 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so4012600bkc.13 for ; Sun, 08 Apr 2012 22:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=61wxJDGDJOYSi0ivuFSxATeE14rKujSmG9LmqUWDAxA=; b=FwwW7XLhAm1OFqlTy5QevqdKNePd8y9VyDbrTCTTrCKyoQaN85Sj+QJX74WJUxOoNF ePsZUaWAR6Jj9KClQVKxlkwnJ8zmxjWhauT4Mo4Sez8Jx74p1mD/eNdZoT30dZYLwQxg kUzkFIeCZ0ftPMFPFknfulcuvoK90oFAOjvgU2IQq2hUpLWYvpgUs9IH6edIAY8To0bZ RT7OIFsloD1XNxfWROk8xsk/ZMyi1p0AbOlPxwCDSteYBnjc//WFfmr97wh9nhsgFXd9 JA/HJGzGKa6l9ZMU+ZUk7nn5fj9YqqXHK7GfV0vPvHbZpWb/3jeyQ1mxdq780ZQYKq4R /CFA== Received: by 10.204.156.196 with SMTP id y4mr2630968bkw.119.1333950678353; Sun, 08 Apr 2012 22:51:18 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPS id f11sm17203423bkw.6.2012.04.08.22.51.15 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Apr 2012 22:51:16 -0700 (PDT) From: Mikolaj Golub To: Jason Hellenthal Organization: TOA Ukraine References: <201204061632.q36GWTT2017212@svn.freebsd.org> <20120408211218.GA62178@DataIX.net> Sender: Mikolaj Golub Date: Mon, 09 Apr 2012 08:51:13 +0300 In-Reply-To: <20120408211218.GA62178@DataIX.net> (Jason Hellenthal's message of "Sun, 8 Apr 2012 17:12:18 -0400") Message-ID: <861unxqwq6.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stable@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233953 - stable/8/usr.bin/procstat 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, 09 Apr 2012 05:51:25 -0000 On Sun, 8 Apr 2012 17:12:18 -0400 Jason Hellenthal wrote: JH> This commit in action does not seem to be doing the correct thing even JH> though it does report an error when kern.proc.pathname is not known. JH> Running procstat -a -b produces: JH> [...] JH> 1848 ksh 803500 /bin/ksh JH> procstat: sysctl: kern.proc.pathname: 2208: No such file or directory Plese note, the error was generated by kern.proc.pathname sysctl, not kern.proc.osrel. I suppose it is because /bin/ksh binary had been reinstalled and 1848 ran the old binary. My commit has not touched the kern.proc.pathname part and the same bahavior was before the change. JH> 2210 ksh 803500 /bin/ksh JH> [...] JH> While procstat -a produces: JH> [...] JH> 1848 1846 1848 1848 1848 1 jhellenthal wait FreeBSD ELF32 ksh JH> 2208 1814 2208 2208 0 1 jhellenthal select FreeBSD ELF32 xterm JH> 2210 2208 2210 2210 2210 1 jhellenthal wait FreeBSD ELF32 ksh JH> [...] JH> If process 2208 can be seen during (procstat -a) I do not see a reason JH> to bailout and print an error when (-b) is used. Just print the JH> orrelease as (0) and print the rest of the information that should be JH> seen... JH> Could someone have a closer look at this? JH> On Fri, Apr 06, 2012 at 04:32:29PM +0000, Mikolaj Golub wrote: >> Author: trociny >> Date: Fri Apr 6 16:32:29 2012 >> New Revision: 233953 >> URL: http://svn.freebsd.org/changeset/base/233953 >> >> Log: >> MFC r233390: >> >> When displaying binary information show also osreldate. >> >> Suggested by: kib >> >> Modified: >> stable/8/usr.bin/procstat/procstat.1 >> stable/8/usr.bin/procstat/procstat_bin.c >> Directory Properties: >> stable/8/usr.bin/procstat/ (props changed) >> >> Modified: stable/8/usr.bin/procstat/procstat.1 >> ============================================================================== >> --- stable/8/usr.bin/procstat/procstat.1 Fri Apr 6 16:31:29 2012 (r233952) >> +++ stable/8/usr.bin/procstat/procstat.1 Fri Apr 6 16:32:29 2012 (r233953) >> @@ -25,7 +25,7 @@ >> .\" >> .\" $FreeBSD$ >> .\" >> -.Dd March 7, 2010 >> +.Dd March 23, 2012 >> .Dt PROCSTAT 1 >> .Os >> .Sh NAME >> @@ -98,6 +98,8 @@ Display the process ID, command, and pat >> process ID >> .It COMM >> command >> +.It OSREL >> +osreldate for process binary >> .It PATH >> path to process binary (if available) >> .El >> >> Modified: stable/8/usr.bin/procstat/procstat_bin.c >> ============================================================================== >> --- stable/8/usr.bin/procstat/procstat_bin.c Fri Apr 6 16:31:29 2012 (r233952) >> +++ stable/8/usr.bin/procstat/procstat_bin.c Fri Apr 6 16:32:29 2012 (r233953) >> @@ -42,11 +42,11 @@ void >> procstat_bin(pid_t pid, struct kinfo_proc *kipp) >> { >> char pathname[PATH_MAX]; >> - int error, name[4]; >> + int error, osrel, name[4]; >> size_t len; >> >> if (!hflag) >> - printf("%5s %-16s %-53s\n", "PID", "COMM", "PATH"); >> + printf("%5s %-16s %8s %s\n", "PID", "COMM", "OSREL", "PATH"); >> >> name[0] = CTL_KERN; >> name[1] = KERN_PROC; >> @@ -64,7 +64,19 @@ procstat_bin(pid_t pid, struct kinfo_pro >> if (len == 0 || strlen(pathname) == 0) >> strcpy(pathname, "-"); >> >> + name[2] = KERN_PROC_OSREL; >> + >> + len = sizeof(osrel); >> + error = sysctl(name, 4, &osrel, &len, NULL, 0); >> + if (error < 0 && errno != ESRCH) { >> + warn("sysctl: kern.proc.osrel: %d", pid); >> + return; >> + } >> + if (error < 0) >> + return; >> + >> printf("%5d ", pid); >> printf("%-16s ", kipp->ki_comm); >> + printf("%8d ", osrel); >> printf("%s\n", pathname); >> } >> _______________________________________________ >> svn-src-stable-8@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/svn-src-stable-8 >> To unsubscribe, send any mail to "svn-src-stable-8-unsubscribe@freebsd.org" JH> -- JH> ;s =; -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Apr 9 07:59:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0A83106564A for ; Mon, 9 Apr 2012 07:59:12 +0000 (UTC) (envelope-from fred.fliu@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45E798FC15 for ; Mon, 9 Apr 2012 07:59:12 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so7289180obb.13 for ; Mon, 09 Apr 2012 00:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=g3nvU5lhangg1ddk3EHVKAPvisqiMuXgA84Aq/KOnok=; b=HuRu3wJy01UoyqefdF2MaABAi7trOlBWQc3hpqndG9BoCXKNlfxIjBNA9En8gj/bUy VgOo7pJkT+umYdJcFptVEptzcsvQjg4SnVpk6sZks4VqOOHkH1RNbqZt8ptjQ2VMMPx2 M3LTLgXwXbAWbLLWvvPHbmVMSVGoJfuItL+lVq53nI/GjbApz+FYeXV0p7ae8ERpT+We P/L5MnnLssw9fiutTuyrv9pGwQZn8eg/8ZaJDHUZo8xpcQFKobDmHejPqtcMxF4dbnoz HiPvDX5v8UfP1cCsj83ZUH9OmgX/dntN6MpABCOb09Den4NcL3VuO25LKkLH+U5IyQ5m 1Rdw== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr8685792oea.52.1333958351436; Mon, 09 Apr 2012 00:59:11 -0700 (PDT) Received: by 10.182.16.196 with HTTP; Mon, 9 Apr 2012 00:59:11 -0700 (PDT) In-Reply-To: References: <4F68FC3E.2090401@icritical.com> <4F71FEAE.3090506@icritical.com> <4F72C588.2000204@icritical.com> <4F7309E2.4000502@icritical.com> <4F757A67.5080302@mpcdata.com> Date: Mon, 9 Apr 2012 15:59:11 +0800 Message-ID: From: Fred Liu To: freebsd-stable@freebsd.org, Matt Burke Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: Subject: SAS Drive identification LEDs 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, 09 Apr 2012 07:59:12 -0000 ---------- =D2=D1=D7=AA=B7=A2=D3=CA=BC=FE ---------- =B7=A2=BC=FE=C8=CB=A3=BA Fred Liu =C8=D5=C6=DA=A3=BA 2012=C4=EA4=D4=C29=C8=D5 =CF=C2=CE=E73:56 =D6=F7=CC=E2=A3=BA Re: SAS Drive identification LEDs =CA=D5=BC=FE=C8=CB=A3=BA Mike Pumford Thanks. Can you recommend what drive and enclosure can provide working SES in 9.0? Thanks. Fred =D4=DA 2012=C4=EA3=D4=C230=C8=D5 =CF=C2=CE=E75:18=A3=ACMike Pumford =D0=B4=B5=C0=A3=BA > Fred Liu wrote: >>> >>> >>> How would you identify such a drive on any other system? >>> >> >> Normally, there are printed labels as the backup solution. >> > You can identify SAS drives in an enclosure if the drive and enclosure > provide the information needed. > > If you issue an INQUIRY EVPD read of page 0x83 on the drive it should giv= e > you the WWN and target SAS addresses of the drive. You should then be abl= e > to tie this up with the array element in the enclosure by matching it up > with data in the SES diagnostic page 0xA from the enclosure. > > sg3_utils provides command line tools that can perform these queries. > > Mike > -- > Mike Pumford, Senior Software Engineer > MPC Data Limited > e-mail: mpumford@mpcdata.com web: www.mpcdata.com > tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601 > ddi: +44 (0) 1225 710635 > > > _______________________________________________ > 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 Mon Apr 9 16:34:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D765B106564A; Mon, 9 Apr 2012 16:34:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFF28FC19; Mon, 9 Apr 2012 16:34:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED2DDB9C2; Mon, 9 Apr 2012 12:34:48 -0400 (EDT) From: John Baldwin To: Doug Ambrisko Date: Mon, 9 Apr 2012 12:12:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201204061801.q36I1FVw041177@ambrisko.com> In-Reply-To: <201204061801.q36I1FVw041177@ambrisko.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091212.22948.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 12:34:49 -0400 (EDT) Cc: scottl@freebsd.org, Alexander Motin , freebsd-stable@freebsd.org Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach 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: Mon, 09 Apr 2012 16:34:49 -0000 On Friday, April 06, 2012 2:01:15 pm Doug Ambrisko wrote: > Alexander Motin writes: > | On 04/06/12 20:12, Doug Ambrisko wrote: > | > Alexander Motin writes: > | > | On 04/04/12 21:47, John Baldwin wrote: > | > |> On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote: > | > |>> John Baldwin writes: > | > |>> | On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote: > | > |>> |> John Baldwin writes: > | > |>> |> | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote: > | > |>> |> |> Doug Ambrisko writes: > | > |>> |> |> | John Baldwin writes: > | > |>> |> |> | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote: > | > |>> |> |> | |> Sean Bruno writes: > | > |>> |> |> | |> | Noting a failure to attach to the onboard IPMI controller > | > |> with > | > |>> | this > | > |>> |> | dell > | > |>> |> |> | |> | R815. Not sure what to start poking at and thought I'd > | > |> though > | > |>> | this > | > |>> |> | over > | > |>> |> |> | |> | here for comment. > | > |>> |> |> | |> | > | > |>> |> |> | |> | -bash-4.2$ dmesg |grep ipmi > | > |>> |> |> | |> | ipmi0: KCS mode found at io 0xca8 on acpi > | > |>> |> |> | |> | ipmi1: on isa0 > | > |>> |> |> | |> | device_attach: ipmi1 attach returned 16 > | > |>> |> |> | |> | ipmi1: on isa0 > | > |>> |> |> | |> | device_attach: ipmi1 attach returned 16 > | > |>> |> |> | |> | ipmi0: Timed out waiting for GET_DEVICE_ID > | > |>> |> |> | |> > | > |>> |> |> | |> I've run into this recently. A quick hack to fix it is: > | > |>> |> |> | |> > | > |>> |> |> | |> Index: ipmi.c > | > |>> |> |> | |> > | > [snip] > | > |>> | If you use "-ct" then you get a file you can feed into schedgraph. > | > |>> | However, just reading the log, it seems that IRQ 20 keeps preempting > | > |>> | the KCS worker thread preventing it from getting anything done. Also, > | > |>> | there seem to be a lot of threads on CPU 0's runqueue waiting for a > | > |>> | chance to run (load average of 12 or 13 the entire time). You can try > | > |>> | just bumping up the max timeout from 3 seconds to higher perhaps. Not > | > |>> | sure why IRQ 20 keeps firing though. It might be related to USB, so > | > |>> | you could try fiddling with USB options in the BIOS perhaps, or disabling > | > |>> | the USB drivers to see if that fixes IPMI. > | > |>> > | > |>> Tried without USB in kernel: > | > |>> http://people.freebsd.org/~ambrisko/ipmi_ktr_dump_no_usb.txt > | > |> > | > |> Hmm, it's still just running constantly (note that the idle thread is > | > |> _never_ scheduled). The lion's share of the time seems to be spent in > | > |> "xpt_thrd". Note that there are several places where nothing happens except > | > |> that "xpt_thrd" runs constantly (spinning) during 10's of statclock ticks. I > | > |> would maybe start debugging that to see what in the world it is doing. Maybe > | > |> it is polling some hardware down in xpt_action() (i.e., xpt_action() for a > | > |> single bus called down into a driver and it is just spinning using polling > | > |> instead of sleeping and waiting for an interrupt). > | > | > | > | "xpt_thrd" is a bus scanner thread. It is scheduled by CAM for every bus > | > | on attach and by controller driver on hot-plug events. For some > | > | controllers it may be quite CPU-hungry. For example, for legacy ATA > | > | controllers, where bus reset may take many seconds of hardware polling, > | > | while devices just spinning up. For ahci(4) it was improved about year > | > | ago to not use polling when possible, but it still may loop for some > | > | time if controller is not responding on reset. What mfi(4), mentioned in > | > | log, does during scanning, I am not sure. > | > > | > I thought that mfi(4) could be an issue. There are some ata controllers > | > with nothing attached. I built a GENERIC with USB and mfi commented out > | > and then the timeout issue went away: > | > ipmi0: KCS mode found at io 0xca8 on acpi > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 1 > | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 2211 > | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 2272 > | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 2332 > | > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 > | > > | > Without mfi and with USB and it had issues: > | > ipmi0: KCS mode found at io 0xca8 on acpi > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 > | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 > | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 > | > ipmi0: Timed out waiting for GET_DEVICE_ID > | > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 > | > > | > I can post more ktrdump traces if needed. A 1U Dell machine without > | > mfi also has this problem. As John mentioned it might be good to > | > bump up the timeout from 3s to 6s. I did that with the USB no mfi > | > kernel and that passed: > | > > | > % dmesg | grep ipmi > | > ipmi0: KCS mode found at io 0xca8 on acpi > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi1: on isa0 > | > device_attach: ipmi1 attach returned 16 > | > ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2 > | > ipmi0: DEBUG ipmi_complete_request 527 before wakeup 3137 > | > ipmi0: DEBUG ipmi_complete_request 529 after wakeup 3199 > | > ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 3259 > | > ipmi0: IPMI device rev. 0, firmware rev. 1.61, version 2.0 > | > > | > So maybe we need to agressively bump up the timeout. I put a > | > timeout since I didn't want the system to hang. Anyone have a > | > good idea of a timeout. I thought I tried 6s initially and it > | > had issues but then the machine I was playing with had 3 mfi > | > cards and various disks hanging off it. > | > | I have no idea about IPMI timeout to propose, but can't that check be > | remade opposite: if response received -- use it, otherwise -- check > | error value? Obviously it is not IPMI problem that CPU is busy, but > | ability to work in those conditions would be a bonus. > > In theory, that is what it is supposed to be doing. However, it seems > like the entire system is busy such that when the IPMI task notifies > the thread it is complete the thread even though might have got the > wakeup fails due to sleeping for to long. If this is indeed the case > I can work around this by setting a "completion" variable and then > check that instead of erroring out on the timeout failure of msleep. Well, if the kcs thread truly does run to completion and call wakeup() before the timeout, it should put the thread on the run queue and still work fine. The problem here is the kcs thread isn't getting a chance to run because of the other bug. Having a separate completion token won't do anything to solve this. > It just seems strange to put in code that effectively, says if the > CPU is to slow to do anything to complete in the required time but > did complete successfully don't treat that as an error! > > Increasing the timeout shouldn't have any negative impact in boot times > and is just a safety measure. I think we already know the HW should be > okay at this time. We can up the timeout, I'm just worried it is papering over another bug (in USB it seems) that can cause other problems. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Apr 9 18:50:41 2012 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 87CDD1065670 for ; Mon, 9 Apr 2012 18:50:41 +0000 (UTC) (envelope-from telbizov@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 3A3DE8FC18 for ; Mon, 9 Apr 2012 18:50:41 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2411295yhg.13 for ; Mon, 09 Apr 2012 11:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BvAdKVbVzdOtcg/d847dxyDn/86vuDbF+iTkyMSQT9s=; b=uiYnBf+DDcPExjcRYqgmJWtv6Kp2eFHhModODVyTpZaSQl/kJgzinmHe7Z+swtfAn4 kiNm4Vt/1Vrm/3b2vLK76EeW6b9WMGx+IGIBQRP5lbhTEJg7kr6FxLmlvxMsQ28b/5xH KgEsWFkWTTUpc7M9KsDuXOCJoRK0QPB9CZ0tOor5GKaK3Fkwbf74rGO6u5Rbojfl8NcV Qdjcc7/dHD9PYVjGJ1turisSkNzTuN14TCHnRCBPnqgTITOHAnAIM3sCV01JkckIrMpT 2ylot8yTU9j+HMkrQgQS6CU/XMCjRdCJVWP8QJdF7saO/5ooeoo4hR8DqFpQiqmmZ99y AaSw== MIME-Version: 1.0 Received: by 10.60.172.231 with SMTP id bf7mr11671785oec.45.1333997440421; Mon, 09 Apr 2012 11:50:40 -0700 (PDT) Received: by 10.182.186.10 with HTTP; Mon, 9 Apr 2012 11:50:39 -0700 (PDT) Date: Mon, 9 Apr 2012 11:50:39 -0700 Message-ID: From: Rumen Telbizov To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=bcaec54c4df6914f5604bd437b00 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS: can't read MOS 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, 09 Apr 2012 18:50:41 -0000 --bcaec54c4df6914f5604bd437b00 Content-Type: text/plain; charset=ISO-8859-1 Hello everyone, I have a ZFS FreeBSD 8.2-STABLE (Aug 30, 2011) that I am having issues with and might use some help. In a nutshell, this machine has been running fine for about a year and a half but after a recent power outage (complete colo blackout) I can't boot of the ZFS pool any more. Here's the error I get (attached screenshot as well): ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/x86 boot Default: zroot:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 I've been searching the net high and low for an actual solution but all the threads end up nowhere. I hope I can get some clue here. Thanks in advance. Here's the relevant hardware configuration of this box (serves as a backup box). - SuperMicro 4U + another 4U totalling 48 x 2TB disks - Hardware raid LSI 9261-8i holding both shelves giving 1 mfid0 device to the OS - Hardware raid 60 -- 6 x 8 raid6 groups - ZFS with gptzfsboot installed on the "single" mfid0 device. Partition table is: [root@mfsbsd /zroot/etc]# gpart show -l => 34 140554616765 mfid0 GPT (65T) 34 128 1 (null) (64k) 162 33554432 2 swap (16G) 33554594 140521062205 3 zroot (65T) - boot device is: vfs.root.mountfrom="zfs:zroot" (as per loader.conf) - zpool status is: [root@mfsbsd /zroot/etc]# zpool status pool: zroot state: ONLINE scan: scrub canceled on Mon Apr 9 09:48:14 2012 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mfid0p3 ONLINE 0 0 0 errors: No known data errors - zpool get all: [root@mfsbsd /zroot/etc]# zpool get all zroot NAME PROPERTY VALUE SOURCE zroot size 65T - zroot capacity 36% - zroot altroot - default zroot health ONLINE - zroot guid 3339338746696340707 default zroot version 28 default *zroot bootfs zroot local* zroot delegation on default zroot autoreplace off default zroot cachefile - default zroot failmode wait default zroot listsnapshots on local zroot autoexpand off default zroot dedupditto 0 default zroot dedupratio 1.00x - zroot free 41.2T - zroot allocated 23.8T - zroot readonly off - Here's what happened chronologically: - Savvis Toronto blacked out completely for 31 minutes - After power was restored this machine came up with the above error - I managed to PXE boot into mfsbsd successfully and managed to import the pool and access actual data/snapshots - no problem - Shortly after another reboot the hardware raid controller complained that it has lost it's configuration and now sees only half of the disks as foreign good and the rest as foreign bad. BIOS didn't see any boot device. - Spent some time on the phone with LSI and managed to restore the hardware RAID by basically removing any and all configuration, making disks unconfigured good and recreating the array in exactly the same way as I created it in the beginning BUT with the important exception that I did NOT initialize the array. - After this I was back to square one where I could see all the data without any loss (via mfsbsd) but cannot boot of the volume any more. - First thing I tried was to restore the boot loader without any luck: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 mfid0p1 - Then out of desperation, took zfsboot, zfsloader, gptzfsboot from 9.0-RELEASE and replaced them in /boot, reinitialized again - no luck - Currently running zdb -ccv zroot to check for any corruptions - I am afraid this will take forever since I have *23.8T* used space. No errors yet - One thing I did notice is that zdb zroot returned the metaslab information line by line very slowly (10-15 seconds a line). I don't know if it's related. - Another thing I tried (saw that in a thread) without any difference whatsoever was: # cd src/sys/boot/i386/zfsboot # make clean; make cleandir # make obj ; make depend ; make # cd i386/loader # make install # cd /usr/src/sys/boot/i386/zfsboot # make install # sysctl kern.geom.debugflags=16 # dd if=/boot/zfsboot of=/dev/da0 count=1 # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 # reboot At this point I am contemplating how to evacuate all the data from there or better yet put some USB flash to boot from. I could provide further details/execute commands if needed. Any help would be appreciated. Thank you, -- Rumen Telbizov http://telbizov.com --bcaec54c4df6914f5604bd437b00-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 10 04:34:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B019106566C for ; Tue, 10 Apr 2012 04:34:41 +0000 (UTC) (envelope-from crshd@mail.com) Received: from mailout-us.mail.com (mailout-us.mail.com [74.208.122.35]) by mx1.freebsd.org (Postfix) with SMTP id 1A7018FC0A for ; Tue, 10 Apr 2012 04:34:41 +0000 (UTC) Received: (qmail invoked by alias); 10 Apr 2012 04:34:32 -0000 Received: from unknown (EHLO localhost) [175.141.12.101] by mail.gmx.com (mp-us009) with SMTP; 10 Apr 2012 00:34:32 -0400 X-Authenticated: #114940683 X-Provags-ID: V01U2FsdGVkX19+3QUVFx5+neKPIfW2mqmRQa2Bzu9v3h+jmQxvC1 sKPhlL4eMUVxMl Date: Tue, 10 Apr 2012 12:34:28 +0800 From: Christian Brassat To: freebsd-stable@freebsd.org Message-ID: <20120410043428.GA37892@beastie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Y-GMX-Trusted: 0 Subject: Buildworld usbhidctl 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: Tue, 10 Apr 2012 04:34:41 -0000 Hi, I've been trying to update my 9-RELEASE to STABLE. Buildworld keeps compiling for quite a while, but then fails with: > ===> usr.bin/usbhidctl (all) > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=core2 > -DNDEBUG -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts > -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -c /usr/src/usr.bin/usbhidctl/usbhid.c > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=core2 > -DNDEBUG -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts > -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -L/usr/lib -L/usr/local/lib -o usbhidctl usbhid.o > -lusbhid > clang: warning: argument unused during compilation: '-std=gnu99' > usbhid.o: In function `main': > /usr/src/usr.bin/usbhidctl/usbhid.c:(.text+0x8e6): undefined reference to `hid_set_report' > /usr/src/usr.bin/usbhidctl/usbhid.c:(.text+0x9f2): undefined reference to `hid_get_report' > /usr/src/usr.bin/usbhidctl/usbhid.c:(.text+0xb89): undefined reference to `hid_get_report' > clang: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 > > Stop in /usr/src/usr.bin/usbhidctl. > *** Error code 1 > > Stop in /usr/src/usr.bin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. I'm not sure what else is needed for proper troubleshooting, so let me know if I need to provide additional information. Greetings, Christian -- I used to have a signature. But it was too embarassed to be seen with me. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 10 07:05:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB56D1065677 for ; Tue, 10 Apr 2012 07:05:19 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id E802A8FC0C for ; Tue, 10 Apr 2012 07:05:18 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q3A6e47m069477 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 10 Apr 2012 09:40:10 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4F83D5C4.3090901@digsys.bg> Date: Tue, 10 Apr 2012 09:40:04 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120315 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: can't read MOS 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, 10 Apr 2012 07:05:19 -0000 It seems your RAID controlled goofed something. I wonder, why did you use the hardware controller for RAID60, instead of ZFS (using each drive as single drive array, or JBOD). About the only way I can think out of this situation, sans having a second box or huge tape backup is to convert it to proper ZFS.. in place :) It helps that you have not used half of your capacity. You could do this: 1. remove as many drives from the RAID60 as you could, without breaking redundancy. 2. create single drive volumes out of these, or just JBOD the drives if this controller can. 3. create new zpool with these drives, again "RAID60" if you like, that is vdevs of raidz2. You need enough drives to hold at least 24TB of data. You may 'trick' ZFS by creating raidz2 groups of say 8 drives (I guess this is what you mean by having 6x8 RAID60), then remove two drives from the vdev and use these for the next vdev. I guess two raidz2 groups of 8 drives will be ok, as that gives you 24TB, but in fact slightly less, because the drives aren't really 2TB so you may need 3x8 groups... You can create 3x8 groups without redundancy (actually 3x6) with 18 drives only. 4. copy over your old zpool to the new with zfs send and zfs receive. 5. rename both pools so that the new pool becomes zroot. 6. boot off from your new pool. 7. if everything is ok, destroy the remains of the RAID60, add two drives to each non-redundant vdev in the new zpool and add the other drives as 8 drive vdevs to the zpool. 8. Now you have true ZFS pool and ZFS will be able to detect and recover any data errors on your drives. With pool such huge and so much data it is very risky to depend on 'hardware raid', especially when ZFS is available. Thinking about this again, you may not be able to extract enough 'spare' drives out of the RAID60 pool. You may get up to 12 drives and that is not enough to hold all your data. An option is to replace those with larger capacity drives, 3TB pr 4TB -- ZFS has not problem with different size drives in a zpool, but this has to be checked if this LSI controller can manage drives larger than 2TB. Or, you might be able to remove some data form the pool. Another option is if you can attach an spare drive chassis to handle the transition.. In any case, my advice is to stay away from ZFS on top of 'hardware RAID'. ZFS will be able to detect data corruption, but not do anything except inform you, even if you have lots of redundant drives. Use ZFS as designed. Daniel On 09.04.12 21:50, Rumen Telbizov wrote: > Hello everyone, > > I have a ZFS FreeBSD 8.2-STABLE (Aug 30, 2011) that I am having issues with > and might use some help. > > In a nutshell, this machine has been running fine for about a year and a > half but after a recent power > outage (complete colo blackout) I can't boot of the ZFS pool any more. > Here's the error I get (attached screenshot as well): > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 > > FreeBSD/x86 boot > Default: zroot:/boot/kernel/kernel > boot: ZFS: unexpected object set type 0 > > I've been searching the net high and low for an actual solution but all the > threads end up nowhere. > I hope I can get some clue here. Thanks in advance. > > Here's the relevant hardware configuration of this box (serves as a backup > box). > > - SuperMicro 4U + another 4U totalling 48 x 2TB disks > - Hardware raid LSI 9261-8i holding both shelves giving 1 mfid0 device > to the OS > - Hardware raid 60 -- 6 x 8 raid6 groups > - ZFS with gptzfsboot installed on the "single" mfid0 device. Partition > table is: > > [root@mfsbsd /zroot/etc]# gpart show -l > => 34 140554616765 mfid0 GPT (65T) > 34 128 1 (null) (64k) > 162 33554432 2 swap (16G) > 33554594 140521062205 3 zroot (65T) > > > > - boot device is: vfs.root.mountfrom="zfs:zroot" (as per loader.conf) > - zpool status is: > > [root@mfsbsd /zroot/etc]# zpool status > pool: zroot > state: ONLINE > scan: scrub canceled on Mon Apr 9 09:48:14 2012 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mfid0p3 ONLINE 0 0 0 > > errors: No known data errors > > > > - zpool get all: > > [root@mfsbsd /zroot/etc]# zpool get all zroot > NAME PROPERTY VALUE SOURCE > zroot size 65T - > zroot capacity 36% - > zroot altroot - default > zroot health ONLINE - > zroot guid 3339338746696340707 default > zroot version 28 default > *zroot bootfs zroot local* > zroot delegation on default > zroot autoreplace off default > zroot cachefile - default > zroot failmode wait default > zroot listsnapshots on local > zroot autoexpand off default > zroot dedupditto 0 default > zroot dedupratio 1.00x - > zroot free 41.2T - > zroot allocated 23.8T - > zroot readonly off - > > > Here's what happened chronologically: > > - Savvis Toronto blacked out completely for 31 minutes > - After power was restored this machine came up with the above error > - I managed to PXE boot into mfsbsd successfully and managed to import > the pool and access actual data/snapshots - no problem > - Shortly after another reboot the hardware raid controller complained > that it has lost > it's configuration and now sees only half of the disks as foreign good > and the > rest as foreign bad. BIOS didn't see any boot device. > - Spent some time on the phone with LSI and managed to restore the > hardware RAID > by basically removing any and all configuration, making disks > unconfigured good > and recreating the array in exactly the same way as I created it in the > beginning BUT > with the important exception that I did NOT initialize the array. > - After this I was back to square one where I could see all the data > without any loss > (via mfsbsd) but cannot boot of the volume any more. > - First thing I tried was to restore the boot loader without any luck: > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 mfid0p1 > - Then out of desperation, took zfsboot, zfsloader, gptzfsboot from > 9.0-RELEASE and replaced them in /boot, > reinitialized again - no luck > - Currently running zdb -ccv zroot to check for any corruptions - I am > afraid this will take forever since I have *23.8T* used space. No errors > yet > - One thing I did notice is that zdb zroot returned the metaslab > information line by line very slowly (10-15 seconds a line). I don't know > if it's related. > - Another thing I tried (saw that in a thread) without any difference > whatsoever was: > > # cd src/sys/boot/i386/zfsboot > # make clean; make cleandir > # make obj ; make depend ; make > # cd i386/loader > # make install > # cd /usr/src/sys/boot/i386/zfsboot > # make install > # sysctl kern.geom.debugflags=16 > # dd if=/boot/zfsboot of=/dev/da0 count=1 > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > # reboot > > > At this point I am contemplating how to evacuate all the data from there or > better yet put some USB flash to boot from. > I could provide further details/execute commands if needed. Any help would > be appreciated. > > Thank you, > > > _______________________________________________ > 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 Tue Apr 10 08:58:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3928A106566C for ; Tue, 10 Apr 2012 08:58:07 +0000 (UTC) (envelope-from fred.fliu@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ECED88FC08 for ; Tue, 10 Apr 2012 08:58:06 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc18so9190618obb.13 for ; Tue, 10 Apr 2012 01:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=n74Icalg+HSFCKjpEigm/BorL10wvc24gsOUEvK/EXE=; b=j03AdrcxcNtKckwQlxmjAJ9kbhpY1nLYuh4/ZX8ddBkiW6iIiEMmur3L2vzaiWnJm0 EwbK/GNmnLXD9M9H2Y5C1yk5Db6M2Zhghohnkr9mKUl5miQwZ5F+uCzZPxiBNLFn6g3L r0OE+ofb0Vnr5khYJL9+yCbKlaEUG05m5COp3zyJqndAX3mSEzjOrLpnN0Cim1spurHM /9hcxP2HUB4h4qTVaefX+gtqcSO4iId+ad2kWDyRi6Ic58oTJ9lMDcbwMxfD0fLJNao+ xRWVj9sFdSlXLc/D/djdWghSZAw5D6fz6aLLs+oHrxn8ASokvk23zEuaLAup+i/i5/Es 3cbg== MIME-Version: 1.0 Received: by 10.182.202.68 with SMTP id kg4mr14811371obc.42.1334048286764; Tue, 10 Apr 2012 01:58:06 -0700 (PDT) Received: by 10.182.16.196 with HTTP; Tue, 10 Apr 2012 01:58:06 -0700 (PDT) In-Reply-To: <4F83F4CB.6080409@mpcdata.com> References: <4F68FC3E.2090401@icritical.com> <4F71FEAE.3090506@icritical.com> <4F72C588.2000204@icritical.com> <4F7309E2.4000502@icritical.com> <4F757A67.5080302@mpcdata.com> <4F83F4CB.6080409@mpcdata.com> Date: Tue, 10 Apr 2012 16:58:06 +0800 Message-ID: From: Fred Liu To: Mike Pumford Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: SAS Drive identification LEDs 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, 10 Apr 2012 08:58:07 -0000 Yes. I understand. I have been seeking for long time to enable SES in my home server which is comprised of commodity hardwares. But I have got no luck. I will try sg3_utils if possible. Many thanks. Fred =D4=DA 2012=C4=EA4=D4=C210=C8=D5 =CF=C2=CE=E74:52=A3=ACMike Pumford =D0=B4=B5=C0=A3=BA > Fred Liu wrote: >> >> Thanks. Can you recommend what drive and enclosure can provide working >> SES in 9.0? >> > Sadly no. Most of my disk enclosure experience was under contract to an O= EM > provider of enclosures and I never really found out who they ended up > selling the final products too. These are large rack mount stand alone > enclosures and SES support was a universal feature. > > I'd still suggest installing sg3_utils you might find your current enclos= ure > provides enough info. > > > Mike > > -- > Mike Pumford, Senior Software Engineer > MPC Data Limited > e-mail: mpumford@mpcdata.com web: www.mpcdata.com > tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601 > ddi: +44 (0) 1225 710635 > From owner-freebsd-stable@FreeBSD.ORG Tue Apr 10 11:34:04 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0E0A106566B for ; Tue, 10 Apr 2012 11:34:04 +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 F283D8FC0A for ; Tue, 10 Apr 2012 11:34:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10668; Tue, 10 Apr 2012 14:34:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F841AA8.3030602@FreeBSD.org> Date: Tue, 10 Apr 2012 14:34:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Rumen Telbizov References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ZFS: can't read MOS 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, 10 Apr 2012 11:34:04 -0000 on 09/04/2012 21:50 Rumen Telbizov said the following: > Hello everyone, > > I have a ZFS FreeBSD 8.2-STABLE (Aug 30, 2011) that I am having issues with > and might use some help. > > In a nutshell, this machine has been running fine for about a year and a > half but after a recent power > outage (complete colo blackout) I can't boot of the ZFS pool any more. > Here's the error I get (attached screenshot as well): > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 > > FreeBSD/x86 boot > Default: zroot:/boot/kernel/kernel > boot: ZFS: unexpected object set type 0 > > I've been searching the net high and low for an actual solution but all the > threads end up nowhere. > I hope I can get some clue here. Thanks in advance. Not sure if the following could be of any help to you but ${SRC}/tools/tools/zfsboottest utility can help diagnosing and debugging such issues from userland (without requiring a reboot). See also a small nitpick below. > Here's the relevant hardware configuration of this box (serves as a backup > box). > > - SuperMicro 4U + another 4U totalling 48 x 2TB disks > - Hardware raid LSI 9261-8i holding both shelves giving 1 mfid0 device > to the OS > - Hardware raid 60 -- 6 x 8 raid6 groups > - ZFS with gptzfsboot installed on the "single" mfid0 device. Partition > table is: > > [root@mfsbsd /zroot/etc]# gpart show -l > => 34 140554616765 mfid0 GPT (65T) > 34 128 1 (null) (64k) > 162 33554432 2 swap (16G) > 33554594 140521062205 3 zroot (65T) > > > > - boot device is: vfs.root.mountfrom="zfs:zroot" (as per loader.conf) > - zpool status is: > > [root@mfsbsd /zroot/etc]# zpool status > pool: zroot > state: ONLINE > scan: scrub canceled on Mon Apr 9 09:48:14 2012 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mfid0p3 ONLINE 0 0 0 > > errors: No known data errors > > > > - zpool get all: > > [root@mfsbsd /zroot/etc]# zpool get all zroot > NAME PROPERTY VALUE SOURCE > zroot size 65T - > zroot capacity 36% - > zroot altroot - default > zroot health ONLINE - > zroot guid 3339338746696340707 default > zroot version 28 default > *zroot bootfs zroot local* > zroot delegation on default > zroot autoreplace off default > zroot cachefile - default > zroot failmode wait default > zroot listsnapshots on local > zroot autoexpand off default > zroot dedupditto 0 default > zroot dedupratio 1.00x - > zroot free 41.2T - > zroot allocated 23.8T - > zroot readonly off - > > > Here's what happened chronologically: > > - Savvis Toronto blacked out completely for 31 minutes > - After power was restored this machine came up with the above error > - I managed to PXE boot into mfsbsd successfully and managed to import > the pool and access actual data/snapshots - no problem > - Shortly after another reboot the hardware raid controller complained > that it has lost > it's configuration and now sees only half of the disks as foreign good > and the > rest as foreign bad. BIOS didn't see any boot device. > - Spent some time on the phone with LSI and managed to restore the > hardware RAID > by basically removing any and all configuration, making disks > unconfigured good > and recreating the array in exactly the same way as I created it in the > beginning BUT > with the important exception that I did NOT initialize the array. > - After this I was back to square one where I could see all the data > without any loss > (via mfsbsd) but cannot boot of the volume any more. > - First thing I tried was to restore the boot loader without any luck: > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 mfid0p1 > - Then out of desperation, took zfsboot, zfsloader, gptzfsboot from > 9.0-RELEASE and replaced them in /boot, > reinitialized again - no luck > - Currently running zdb -ccv zroot to check for any corruptions - I am > afraid this will take forever since I have *23.8T* used space. No errors > yet > - One thing I did notice is that zdb zroot returned the metaslab > information line by line very slowly (10-15 seconds a line). I don't know > if it's related. > - Another thing I tried (saw that in a thread) without any difference > whatsoever was: > > # cd src/sys/boot/i386/zfsboot > # make clean; make cleandir > # make obj ; make depend ; make > # cd i386/loader You probably wanted to do this in i386/zfsloader > # make install > # cd /usr/src/sys/boot/i386/zfsboot > # make install > # sysctl kern.geom.debugflags=16 > # dd if=/boot/zfsboot of=/dev/da0 count=1 > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > # reboot > > > At this point I am contemplating how to evacuate all the data from there or > better yet put some USB flash to boot from. > I could provide further details/execute commands if needed. Any help would > be appreciated. > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Apr 11 01:49:06 2012 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 9E550106566C; Wed, 11 Apr 2012 01:49:06 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 532448FC12; Wed, 11 Apr 2012 01:49:06 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so721418obb.13 for ; Tue, 10 Apr 2012 18:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j1iKcoF9KmNlkw1zi2bQDw7w0Jp+o4KGO9wuW1jXvtM=; b=Ko9clX8PfgZlOOp0p/jqdfSfsY4ohw/IjnP5kA6blhIexeH5YAMWHVWLLgqrvHJ+I1 bZCsqyAI3uLTttRF8wu+Ipwbo4H18F1YngBELJw+Qggs0WV8ZXBR5UGJuxkmhuZ9UVPC Yv69lLFUTcK1O772V4KLm94X59Wc0CUR7BNKsQm2psNyMDgW1NanwARQBTRA8IHKf7Lu v6zrmVhDDh6g6psILqlZK/o4Kmp1im0BZsEfdiSkfwjYfW0C1QQkjUQHTxFHS4NgpB2Y zqQUDwr7e4DIypQBfwsDi+9sTT4ad7kCAO9IECnXDPvX41LMYIT0GXkILZCn8JArJq+w PDbg== MIME-Version: 1.0 Received: by 10.182.40.7 with SMTP id t7mr18979361obk.55.1334108945745; Tue, 10 Apr 2012 18:49:05 -0700 (PDT) Received: by 10.182.186.10 with HTTP; Tue, 10 Apr 2012 18:49:05 -0700 (PDT) In-Reply-To: <4F841AA8.3030602@FreeBSD.org> References: <4F841AA8.3030602@FreeBSD.org> Date: Tue, 10 Apr 2012 18:49:05 -0700 Message-ID: From: Rumen Telbizov To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: can't read MOS 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, 11 Apr 2012 01:49:06 -0000 Thanks for your answers guys, Daniel: I know it's uncommon to use ZFS on a hardware raid block device but with this machine I tried pretty much every other option before I got here. Initially I was using an LSI 9211-8i HBA and raidz2 but after I lost more than half of the disks a couple of times and I had to rebuild the machine I gave up. Of course I realize it was probably a hardware issue, most likely due to some incompatibility between the sas expander and the HBA (both LSI though). Even before that I was using another LSI RAID controller which exported every disk into an individual raid0 of 1 disk and then raidz2 on top of it. The problem with this setup was that performance sucked. I guess it might have had something to do with the hardware raid since I've seen other cards (3ware) behaving poorly in this kind of setup. And no, those LSI card don't seem to have any real pass-through mode. The JBOD thing is really just a raid0 of 1 disk. That's pretty much how I got to the point of where I am, which turned out to be, ironically, the most stable on that specific box! Until the power outage. So yeah I know what you're advising me but unfortunately that's where I am coming from. Having said that I do have another 2 machines which are single chassis 36 disks and both use 9211-8i HBAs with a straight raidz2 and they've been perfectly fine. So it's this one box that I had to resort to hardware raid. Nevertheless thanks for the advise. I think I wouldn't go down that road since that maneuver would require to drop some snapshots (not entirely impossible) and more importantly I'll have to leave the array with no redundancy which I fear most since I have 48 disks! I'll need to take as many disks as possible -- which is 6 x 2 == 12 and this will leave all my current 6 groups without any redundancy whatsoever. What I do intend to do in case anything else fails - is simply put 2 new disks (inside the chassis, maybe old SSDs) and move the bootfs zfs filesystem on them, leave the main pool as simple storage and forget about booting from it. Way easier, safer and quicker. That's my last resort though. Andriy: Thanks a lot for pointing out that script. I saw it somewhere during my search but my 8.2-STABLE doesn't have it. I took the files from the svn and managed to compile and ran the script. I'll finish with it tomorrow and I'll update the list with my findings. Having a better understanding on *exactly* what is causing the problem is what I want to have first and foremost. Hopefully this script will help me. Thanks to both of you guys. Cheers, Rumen Telbizov On Tue, Apr 10, 2012 at 4:34 AM, Andriy Gapon wrote: > on 09/04/2012 21:50 Rumen Telbizov said the following: > > Hello everyone, > > > > I have a ZFS FreeBSD 8.2-STABLE (Aug 30, 2011) that I am having issues > with > > and might use some help. > > > > In a nutshell, this machine has been running fine for about a year and a > > half but after a recent power > > outage (complete colo blackout) I can't boot of the ZFS pool any more. > > Here's the error I get (attached screenshot as well): > > > > ZFS: i/o error - all block copies unavailable > > ZFS: can't read MOS > > ZFS: unexpected object set type 0 > > ZFS: unexpected object set type 0 > > > > FreeBSD/x86 boot > > Default: zroot:/boot/kernel/kernel > > boot: ZFS: unexpected object set type 0 > > > > I've been searching the net high and low for an actual solution but all > the > > threads end up nowhere. > > I hope I can get some clue here. Thanks in advance. > > Not sure if the following could be of any help to you but > ${SRC}/tools/tools/zfsboottest utility can help diagnosing and debugging > such > issues from userland (without requiring a reboot). > > See also a small nitpick below. > > > Here's the relevant hardware configuration of this box (serves as a > backup > > box). > > > > - SuperMicro 4U + another 4U totalling 48 x 2TB disks > > - Hardware raid LSI 9261-8i holding both shelves giving 1 mfid0 device > > to the OS > > - Hardware raid 60 -- 6 x 8 raid6 groups > > - ZFS with gptzfsboot installed on the "single" mfid0 device. > Partition > > table is: > > > > [root@mfsbsd /zroot/etc]# gpart show -l > > => 34 140554616765 mfid0 GPT (65T) > > 34 128 1 (null) (64k) > > 162 33554432 2 swap (16G) > > 33554594 140521062205 3 zroot (65T) > > > > > > > > - boot device is: vfs.root.mountfrom="zfs:zroot" (as per loader.conf) > > - zpool status is: > > > > [root@mfsbsd /zroot/etc]# zpool status > > pool: zroot > > state: ONLINE > > scan: scrub canceled on Mon Apr 9 09:48:14 2012 > > config: > > > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > mfid0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > > > > > > > - zpool get all: > > > > [root@mfsbsd /zroot/etc]# zpool get all zroot > > NAME PROPERTY VALUE SOURCE > > zroot size 65T - > > zroot capacity 36% - > > zroot altroot - default > > zroot health ONLINE - > > zroot guid 3339338746696340707 default > > zroot version 28 default > > *zroot bootfs zroot local* > > zroot delegation on default > > zroot autoreplace off default > > zroot cachefile - default > > zroot failmode wait default > > zroot listsnapshots on local > > zroot autoexpand off default > > zroot dedupditto 0 default > > zroot dedupratio 1.00x - > > zroot free 41.2T - > > zroot allocated 23.8T - > > zroot readonly off - > > > > > > Here's what happened chronologically: > > > > - Savvis Toronto blacked out completely for 31 minutes > > - After power was restored this machine came up with the above error > > - I managed to PXE boot into mfsbsd successfully and managed to import > > the pool and access actual data/snapshots - no problem > > - Shortly after another reboot the hardware raid controller complained > > that it has lost > > it's configuration and now sees only half of the disks as foreign good > > and the > > rest as foreign bad. BIOS didn't see any boot device. > > - Spent some time on the phone with LSI and managed to restore the > > hardware RAID > > by basically removing any and all configuration, making disks > > unconfigured good > > and recreating the array in exactly the same way as I created it in > the > > beginning BUT > > with the important exception that I did NOT initialize the array. > > - After this I was back to square one where I could see all the data > > without any loss > > (via mfsbsd) but cannot boot of the volume any more. > > - First thing I tried was to restore the boot loader without any luck: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 mfid0p1 > > - Then out of desperation, took zfsboot, zfsloader, gptzfsboot from > > 9.0-RELEASE and replaced them in /boot, > > reinitialized again - no luck > > - Currently running zdb -ccv zroot to check for any corruptions - I am > > afraid this will take forever since I have *23.8T* used space. No > errors > > yet > > - One thing I did notice is that zdb zroot returned the metaslab > > information line by line very slowly (10-15 seconds a line). I don't > know > > if it's related. > > - Another thing I tried (saw that in a thread) without any difference > > whatsoever was: > > > > # cd src/sys/boot/i386/zfsboot > > # make clean; make cleandir > > # make obj ; make depend ; make > > # cd i386/loader > > You probably wanted to do this in i386/zfsloader > > > # make install > > # cd /usr/src/sys/boot/i386/zfsboot > > # make install > > # sysctl kern.geom.debugflags=16 > > # dd if=/boot/zfsboot of=/dev/da0 count=1 > > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > > # reboot > > > > > > At this point I am contemplating how to evacuate all the data from there > or > > better yet put some USB flash to boot from. > > I could provide further details/execute commands if needed. Any help > would > > be appreciated. > > > > > > -- > Andriy Gapon > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Wed Apr 11 15:20:18 2012 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 83E09106566B for ; Wed, 11 Apr 2012 15:20:18 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 06C108FC19 for ; Wed, 11 Apr 2012 15:20:17 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so1031449lbb.13 for ; Wed, 11 Apr 2012 08:20:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=BntxONT9in2IX6vAZXk4/BXfearz4U60ZMPO7eF8+O8=; b=HSc/EuT1MvmD7SFGqWc4P/Uid9eVS1MW4/1D0wcuZ0smoclIKYCjrl/K/NfRsw2UMP ZDqRX2mPhr6S4jAZ9rs0th9/4EZaXIpXOoLwEZgLQ2BmAlqBL+fNPkPm/oaKhBvlL+gy ppI9qyu4SR/4LQ+9q0fqgxeIh471SLLW6WnhQcGWJi2CRdwapC4zuIWaXGevSrA/jmak 7uDKxt8ECBbHR1K72rmLuqkodGdXomcsaaFJJWYo01CnrisQiG6IeQS4kwoITrFBwb9A GNoTsMDpemKdNiaxOHYDlph1kq0VbxHRduWDnyUqNIQ6IlWNZDRByjleahzZLSV4dEQu ij6g== MIME-Version: 1.0 Received: by 10.152.129.74 with SMTP id nu10mr18295954lab.50.1334157610688; Wed, 11 Apr 2012 08:20:10 -0700 (PDT) Received: by 10.112.54.41 with HTTP; Wed, 11 Apr 2012 08:20:10 -0700 (PDT) X-Originating-IP: [209.66.78.50] Date: Wed, 11 Apr 2012 11:20:10 -0400 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmaBibkULZTqBvColoy5LlSiK10AgG2TN8a4XZVqsmoKR6+fZh7Y5mEgCdJ92m8F1GNQ8JX Subject: Panic after converting Softupdates to journaled softupdates 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, 11 Apr 2012 15:20:18 -0000 Hell All I wanted to share this with you before sending a pr . I did not find anything that matched it and I wanted to see if I did something wrong procedurally . I upgraded a 7.4-RELEASE amd64 box to 9.0-STABLE sources from yesterday 10 Apr 2012. Every thing worked well. I was able to boot and run off 9.0-STABLE my apps worked ; So I wanted to swap out soft updates for journaed soft updates. The box used 3 UFS slices that were glabled. Note root and var had softupdates but /usr/local/mysql/data did not # Device Mountpoint FStype Options Dump Pass# /dev/label/rootfs / ufs rw 1 1 /dev/label/var /var ufs rw 2 2 /dev/label/SWAP none swap sw 0 0 /dev/label/data /usr/local/mysql/data ufs rw 2 2 Here is what I did to convert them. --------- # tunefs -n disable / tunefs: soft updates cleared tunefs: file system reloaded # tunefs -n disable /var tunefs: soft updates cleared # fsck -y / ** /dev/label/rootfs ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 271768 files, 4336411 used, 59997908 free (136692 frags, 7482652 blocks, 0.2% fragmentation) ***** FILE SYSTEM IS CLEAN ***** # fsck -y /var ** /dev/label/var ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 24792 files, 141287 used, 3919776 free (1232 frags, 489818 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** # fsck -y /usr/local/mysql/data ** /dev/label/data ** Last Mounted on /usr/local/mysql/data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 89528 files, 18246873 used, 51166840 free (59080 frags, 6388470 blocks, 0.1% fragmentation) ***** FILE SYSTEM IS CLEAN ***** # tunefs -j enable / Using inode 7 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set tunefs: file system reloaded # tunefs -j enable /var Using inode 4 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set # tunefs -j enable /usr/local/mysql/data Using inode 425 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set # reboot Apr 11 11:08:58 init: single user shell terminated. Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 0 done All buffers synced. panic: /: ffs_sync: modification on read-only filesystem cpuid = 0 KDB: stack backtrace: #0 0xffffffff808c283e at kdb_backtrace+0x5e #1 0xffffffff8088d017 at panic+0x187 #2 0xffffffff80abc51d at ffs_sync+0x50d #3 0xffffffff809303e1 at vfs_write_suspend+0x111 #4 0xffffffff80abcbd8 at ffs_unmount+0x3f8 #5 0xffffffff8091b2ce at dounmount+0x26e #6 0xffffffff80921ea2 at vfs_unmountall+0x42 #7 0xffffffff8088ce30 at kern_reboot+0x7a0 #8 0xffffffff8088d19c at sys_reboot+0x6c #9 0xffffffff80b77260 at amd64_syscall+0x500 #10 0xffffffff80b62257 at Xfast_syscall+0xf7 Uptime: 6m38s Automatic reboot in 15 seconds - press a key on the console to abort Now the box locked up hard and It would not reboot automatically. I am waiting to see if I can get a coredump after it comes back up. I have walk over an kick it over manually now. So does anyone have any insight into what happened here ? -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Apr 11 17:00:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09B9C106566C for ; Wed, 11 Apr 2012 17:00:21 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63ED88FC0C for ; Wed, 11 Apr 2012 17:00:21 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so1137793lbb.13 for ; Wed, 11 Apr 2012 10:00:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=Ot622ZFixG6HFt34ND7F59HnqL+h/NA16UWJnzKEsXs=; b=TS25hjSW28+yPRy0IfALqRzwFaiie4vynEVGa9+6b3Y4Lbv+UUPkXthWAWqyKTqceO vJ7gvoCoUeAbl5GJHzScFZU3BsjupLO+5tIADT1eLmXdZPmIUBJLR1kJlI/CHvMD7VJl G9sFpV47xLwFDzS1CsmPZ/Sm+cyM61t3erCadJzkZp2JMnVGRtzR6HD5cLflOoftr9yf oyzjhbM2fDsLxV13ZGAvZEUrWZCznTZoh8HFqnZR/dndKpLpmCzX9fq7VeScWfvzq0Lq btYJyxtxq5bj1pjrYIewwEJLgrewRNkHdgGvCDKuGBeOOF+19TcRmqo3W9eRn+9QTx3P ZaoA== MIME-Version: 1.0 Received: by 10.112.26.73 with SMTP id j9mr3285338lbg.21.1334163619385; Wed, 11 Apr 2012 10:00:19 -0700 (PDT) Received: by 10.112.54.41 with HTTP; Wed, 11 Apr 2012 10:00:19 -0700 (PDT) X-Originating-IP: [209.66.78.50] In-Reply-To: References: Date: Wed, 11 Apr 2012 13:00:19 -0400 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkimtSUoXbeSJAxAu2M64U6Gk0DKUOkYrL+MPMrYgD58SGoN995SNLhN3q/pNM83sJSs68l Subject: Re: Panic after converting Softupdates to journaled softupdates 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, 11 Apr 2012 17:00:22 -0000 On Wed, Apr 11, 2012 at 11:20 AM, Mark Saad wrote: > Hell All > =C2=A0I wanted to share this with you before sending a pr . I did not fin= d > anything that matched it and I wanted to see if I did something wrong > procedurally . > > I upgraded a 7.4-RELEASE amd64 box to 9.0-STABLE sources from > yesterday 10 Apr 2012. > > Every thing worked well. I was able to boot and run off 9.0-STABLE my > apps worked ; So I wanted to =C2=A0swap out soft updates for journaed sof= t > updates. > > The box used 3 UFS slices that were glabled. Note root and var had > softupdates but > /usr/local/mysql/data did not > > > # Device =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mountpoin= t =C2=A0 =C2=A0 =C2=A0FStype =C2=A0Options =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dump= =C2=A0 =C2=A0Pass# > /dev/label/rootfs =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ufs =C2=A0 =C2=A0 rw =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 1 > /dev/label/var =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/var =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0ufs =C2=A0 =C2=A0 rw =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02 =C2=A0 =C2=A0 =C2=A0 2 > /dev/label/SWAP =C2=A0 =C2=A0 =C2=A0 =C2=A0 none =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0swap =C2=A0 =C2=A0sw =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 0 > /dev/label/data =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/local/mysql/data =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ufs =C2=A0 =C2=A0 rw > =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 2 > > > Here is what I did to convert them. > > --------- > > # tunefs -n disable / > tunefs: soft updates cleared > tunefs: file system reloaded > # tunefs -n disable /var > tunefs: soft updates cleared > # fsck -y / > ** /dev/label/rootfs > ** Last Mounted on / > ** Root file system > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 271768 files, 4336411 used, 59997908 free (136692 frags, 7482652 > blocks, 0.2% fragmentation) > > ***** FILE SYSTEM IS CLEAN ***** > # fsck -y /var > ** /dev/label/var > ** Last Mounted on /var > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 24792 files, 141287 used, 3919776 free (1232 frags, 489818 blocks, > 0.0% fragmentation) > > ***** FILE SYSTEM IS CLEAN ***** > > # fsck -y /usr/local/mysql/data > ** /dev/label/data > ** Last Mounted on /usr/local/mysql/data > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 89528 files, 18246873 used, 51166840 free (59080 frags, 6388470 > blocks, 0.1% fragmentation) > > ***** FILE SYSTEM IS CLEAN ***** > > # tunefs -j enable / > Using inode 7 in cg 0 for 33554432 byte journal > tunefs: soft updates journaling set > tunefs: file system reloaded > # tunefs -j enable /var > Using inode 4 in cg 0 for 33554432 byte journal > tunefs: soft updates journaling set > # tunefs -j enable /usr/local/mysql/data > Using inode 425 in cg 0 for 33554432 byte journal > tunefs: soft updates journaling set > # reboot > Apr 11 11:08:58 init: single user shell terminated. > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 0 done > All buffers synced. > panic: /: ffs_sync: modification on read-only filesystem > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff808c283e at kdb_backtrace+0x5e > #1 0xffffffff8088d017 at panic+0x187 > #2 0xffffffff80abc51d at ffs_sync+0x50d > #3 0xffffffff809303e1 at vfs_write_suspend+0x111 > #4 0xffffffff80abcbd8 at ffs_unmount+0x3f8 > #5 0xffffffff8091b2ce at dounmount+0x26e > #6 0xffffffff80921ea2 at vfs_unmountall+0x42 > #7 0xffffffff8088ce30 at kern_reboot+0x7a0 > #8 0xffffffff8088d19c at sys_reboot+0x6c > #9 0xffffffff80b77260 at amd64_syscall+0x500 > #10 0xffffffff80b62257 at Xfast_syscall+0xf7 > Uptime: 6m38s > Automatic reboot in 15 seconds - press a key on the console to abort > > > Now the box locked up hard and It would not reboot automatically. > > I am waiting to see if I can get a coredump after it comes back up. I > have walk over an kick it over manually now. > > So does anyone have any insight into what happened here ? > > -- > mark saad | nonesuch@longcount.org short follow up , savecore did not work no dump was saved to swap. Also there was no apparent impact from this crash other then the need to power cycle the box. So far su+j appears to be working. I will stress the disks a bit more and pull the power to see if it actually works later. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Apr 11 19:50:12 2012 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 8C02C1065675 for ; Wed, 11 Apr 2012 19:50:12 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta04.eastlink.ca (mta04.eastlink.ca [24.224.136.10]) by mx1.freebsd.org (Postfix) with ESMTP id A03968FC0A for ; Wed, 11 Apr 2012 19:50:06 +0000 (UTC) Received: from ip03.eastlink.ca ([24.222.39.36]) by mta04.eastlink.ca (Oracle Communications Messaging Exchange Server 7u4-21.01 64bit (built Feb 16 2011)) with ESMTP id <0M2B00FV5Z3C7MT0@mta04.eastlink.ca> for freebsd-stable@freebsd.org; Wed, 11 Apr 2012 16:50:00 -0300 (ADT) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.0 cv=ccSpXg/M c=1 sm=1 a=zSyOyUf+KSrCn7tXbosjdg==:17 a=qV7Q8s93BacA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=1xAcdQvbvX8Ok3sSDCQA:9 a=zIiBjJqeb4kCgQECExQA:7 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=DmyEpWUMMhXtPeL8:21 a=MN7suVGGxg2vQQaO:21 a=k1w2ZutsjhWYawe+LO1aOw==:117 Received: from invio.ca (HELO AA-Edge2007.acsi.ca) ([24.222.10.82]) by ip03.eastlink.ca with ESMTP; Wed, 11 Apr 2012 16:50:00 -0300 Received: from server7.acsi.ca (192.168.9.7) by AA-Edge2007.acsi.ca (192.168.9.15) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 11 Apr 2012 16:49:58 -0300 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Wed, 11 Apr 2012 16:49:57 -0300 From: Chris Forgeron To: "freebsd-stable@freebsd.org" Date: Wed, 11 Apr 2012 16:49:56 -0300 Thread-topic: ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does Thread-index: Acz77EIiknVfmVMKSfWwJL+A/rPijgS1BEsQAF702cAB9/224A== Message-id: References: In-reply-to: Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 Subject: RE: ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does 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, 11 Apr 2012 19:50:12 -0000 I think there's still some problems with LACP in the ixgbe 2.4.4 code. When I use 2.4.4, I am able to establish the LACP link, as stated below. Pi= ngs, and light traffic all works well. However, if I start driving some hea= vier NFS traffic 20-40+ MB/s) across the link from an ESXi server, I run i= nto networking issues where the NFS shares hosted by FreeBSD over the ixgbe= LACP link disappear, timeouts on the ESXi end, etc. If I set the FreeBSD ixgbe ports to FEC instead of LACP, everything continu= es to work. This is on FreeBSD 9.0-STABLE as of March 17th. My feeling is that something subtle is wrong still in the LACP code for ixg= be? LACP links for bce work fine under the same Dell PowerConnect switch, but t= hose are 1 gig links, not 10 gig links. In my tests, my LAG is set to Dyna= mic, not static, and has the proper MTU's (all set to 9000).=20 Only with LACP mode for the laggport do I have these problems.=20 How can I help Jack (or others) diagnose and test this further? Thanks. -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd= .org] On Behalf Of Chris Forgeron Sent: Tuesday, March 06, 2012 7:01 PM To: freebsd-stable@freebsd.org Subject: ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does I have a few systems with Intel X520-DA2 PCIe network cards (10 Gig). The problem I've been running into is with a fresh 9.0-STABLE or 9.0-RELEAS= E install. I can't get a LACP connection established over the ix0 and ix1 p= orts. It's showing COLLECTING and DISTRIBUTING, but not ACTIVE.=20 I've noticed that older 9.0-BETA copies with the 2.3.10 ixgbe driver are wo= rking with the same switch without problems. The 9.0-STABLE that I was doing the most work with had an ixgbe of 2.3.11 After some digging around, I downloaded the ixgbe 2.4.4 from the Intel sit= e, compiled the .ko (a little editing due to the bool typdef), and now my 9= .0-STABLE systems can properly setup a LACP link over ixgbe devices. I'm sure others will run into this in time - Can we get the 2.4.4 into 9-S= TABLE?=20 Thanks. _______________________________________________ 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 Apr 12 14:08:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41506106564A for ; Thu, 12 Apr 2012 14:08:49 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0D118FC0C for ; Thu, 12 Apr 2012 14:08:48 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1917714vcm.13 for ; Thu, 12 Apr 2012 07:08:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=32fXKsiuhFGE0kJkore1gp2E4j2l9HwuTOvkI0eQ3vA=; b=fV3OFfO1JgUR07+hWnRpkrm1CP9vXADOfI0Sokr3WxN7+isVjaZhszIWmSErq+vi9P MZ3iAfy0JbYqLGYubu6gOAmYoMwF5J3OanMGQUrc3fLp/6z7cJ3hOE9k5pry37oQvfy/ Ywf32qAfSAKwyW+mVscS3DBYAxDl/0qdeIl+pv5WZPHeX0pjPIiqBL8LyV97S3Okk4Cp 5ueTZTDO7if2Y3VGKJkBsvpNGjwd0WdbCbcRMDGuSiTp8CscqeAukcn3y/ciIegAJkxl EYe/ACmGJ45lOcjbbB9AkXHW8qQIqudbQ7Qws5Y6/U7GvlFUtFaJZukxCOoRQDsZdBTS 6r+g== MIME-Version: 1.0 Received: by 10.220.210.20 with SMTP id gi20mr1331466vcb.42.1334239728050; Thu, 12 Apr 2012 07:08:48 -0700 (PDT) Received: by 10.52.26.42 with HTTP; Thu, 12 Apr 2012 07:08:48 -0700 (PDT) Date: Thu, 12 Apr 2012 16:08:48 +0200 Message-ID: From: Damien Fleuriot To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk6RcJibrmfxY3dRIS0WRQrXemic2qI8SzBiQ3k/W7cd/qGmmyoihaIM+dVFE7SP1XsKXxe Subject: PF - pf not loading non-persist tables from main ruleset on 8.3-PRERELEASE 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, 12 Apr 2012 14:08:49 -0000 Hello list, I installed a box recently and updated it to 8.3-PRERELEASE on 2012/04/11 I'm experiencing this extremely weird behavior where PF refuses to load standard and const table definitions from the main ruleset. - persist tables load just fine - normal and const tables inside anchors load just fine Does anyone else have the same problem ? I'll try to update the kernel again, you never know. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 12 17:10:49 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91F971065687 for ; Thu, 12 Apr 2012 17:10:49 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 446038FC0C for ; Thu, 12 Apr 2012 17:10:49 +0000 (UTC) Received: by iahk25 with SMTP id k25so3963866iah.13 for ; Thu, 12 Apr 2012 10:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition; bh=JltkTzIiQjJ20RGVx+uFIm6lC7O4T0O9fNSK0Ye18os=; b=gEqFMQwXusI/zfs4QLwiYbPgHrMMVDKzkzOkw46mnoITAsnjokKD86kDFxBrJNDrac QiKBshQ/mfb/iJVyC0F+vwKowuz1ekRrTqnKiELum6p50cqs6ZSHN9NK1I1ibhy7l5x0 lFgjaFqC0lFLKH8uarPS/uuRCGbsBNatlWIXA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:x-gm-message-state; bh=JltkTzIiQjJ20RGVx+uFIm6lC7O4T0O9fNSK0Ye18os=; b=ecq2qdTBvU7who8P5PhLkYcC7WR9S+umkgycR+IYJm0lctobezpn93EbDLRlld1YUV bW4h6BiGT1pJWbSJiD5uCV+lOJzDg3qVJE9quGIAXeb8tvUJHdkLHJ04762p6TdXXoPL A5T7v3TozzJSsjjUFV7+tpgX5qR1NN+g3PSHgs37d0Okdl17nwIS47Q1kx5tyUChGdw2 AXGiTew5pCRcmM6TMQdiEFJ6gckmZ46gakw8vrfgavZRpbVHB0vbPJHc2UDf4u/qy4Kx QHS6/EbveeEXYn/oYI7QdGd/gfqjN8OvBGD5huMbbnSnoklMs2PdHNi9Mm8lRNVdbZh+ apBQ== Received: by 10.50.190.167 with SMTP id gr7mr3365192igc.8.1334250648875; Thu, 12 Apr 2012 10:10:48 -0700 (PDT) Received: from DataIX.net (adsl-99-181-142-73.dsl.klmzmi.sbcglobal.net. [99.181.142.73]) by mx.google.com with ESMTPS id iu5sm18725854igc.14.2012.04.12.10.10.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 10:10:48 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3CHAkEa073735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 13:10:46 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3CHAkGH073734; Thu, 12 Apr 2012 13:10:46 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 12 Apr 2012 13:10:46 -0400 From: Jason Hellenthal To: stable@freebsd.org Message-ID: <20120412171046.GA73570@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Gm-Message-State: ALoCoQkKwbAhYcBZ6MID54il59Vkj/z0sAaxe+OLpzTwves/TMOc3VvieibNxpZ+N3if+daLBzJl Cc: bz@freebsd.org Subject: BURN_BRIDGES & /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib' 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, 12 Apr 2012 17:10:49 -0000 While attempting to burn bridges... yeah yeah I know, may include some civil infractions ;) On stable/8 i386 Last Changed Rev: 234180 fresh build linking kernel.debug ip6_output.o(.text+0x334f): In function `ip6_output': /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib' -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Thu Apr 12 18:10:53 2012 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 145C8106564A for ; Thu, 12 Apr 2012 18:10:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 931D08FC0A for ; Thu, 12 Apr 2012 18:10:52 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6EF6D25D385D; Thu, 12 Apr 2012 18:10:51 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 92167BE4B26; Thu, 12 Apr 2012 18:10:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id WIzbRz-wgt2x; Thu, 12 Apr 2012 18:10:48 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C8B7BBE4B25; Thu, 12 Apr 2012 18:10:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120412171046.GA73570@DataIX.net> Date: Thu, 12 Apr 2012 18:10:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <14882DCF-7A41-4899-B20D-09241AF12F2E@lists.zabbadoz.net> References: <20120412171046.GA73570@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org Subject: Re: BURN_BRIDGES & /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib' 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, 12 Apr 2012 18:10:53 -0000 On 12. Apr 2012, at 17:10 , Jason Hellenthal wrote: >=20 > While attempting to burn bridges... yeah yeah I know, may include some > civil infractions ;) >=20 > On stable/8 i386 Last Changed Rev: 234180 fresh build >=20 > linking kernel.debug > ip6_output.o(.text+0x334f): In function `ip6_output': > /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to > `in6_selectroute_fib' It's basically a marker to not use this function anywhere new in the = stable/ branches. It will change in HEAD soon given the code has now = been in for almost two months (in HEAD) without further needs to = re-adjustment. I am not sure we ever allowed compiling with = BURN_BRIDGES set but I can change the #ifndef to = THIS_IS_PART_OF_THE_PUBLIC_STABLE_KPI or something if needed. See the comment above it: = http://svnweb.freebsd.org/base/stable/8/sys/netinet6/in6_src.c?annotate=3D= 232552#l820 /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-stable@FreeBSD.ORG Thu Apr 12 19:13:35 2012 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 7E84A106564A for ; Thu, 12 Apr 2012 19:13:35 +0000 (UTC) (envelope-from zmiterby@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C44068FC12 for ; Thu, 12 Apr 2012 19:13:34 +0000 (UTC) Received: by wern13 with SMTP id n13so1985336wer.13 for ; Thu, 12 Apr 2012 12:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ta93nYkiUSQHAdLqwTTLo8W1tQ9rRRDsDQVqYncV8+0=; b=XBfJqrcf0CAw/NmOj1Oir2SQhqLIs2oglT1/wNjeh9FJbrUv9jA15nHYrpzASa1Ez8 FNBLrJ/RWnf+yL3vKCdW+SqG1IGiVTgZ2Agm0zGFYanYx15bOEL9Bcl5ltYNPtVCDINq Du+xH6R0J5ONhwxS74VFrPVr5Q0sxQEUfCOYr0tnNDifBIX9iij37buZVBRhqIu2s64j y9w+g/UvU26I6WyScd1RoxRC50DAzVU68MQv7dGS+j5CJe7RN1ulCVyVyigjeXG/VFGs qMdS8eQM9KjVG9FzoMZdra1QGEKitqq9Xt63kfZ9m/xbQBCUyICDNmrjOUyLjs4ovlkB dOtw== Received: by 10.216.139.67 with SMTP id b45mr2487334wej.0.1334258013933; Thu, 12 Apr 2012 12:13:33 -0700 (PDT) Received: from [192.168.100.50] ([178.121.136.168]) by mx.google.com with ESMTPS id ex2sm24583645wib.8.2012.04.12.12.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 12:13:31 -0700 (PDT) Message-ID: <4F87295F.3080801@gmail.com> Date: Thu, 12 Apr 2012 22:13:35 +0300 From: Zmiter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <659350866.20100120151602@mail.ru> In-Reply-To: <659350866.20100120151602@mail.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: IPSec NAT-T in transport mode 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, 12 Apr 2012 19:13:35 -0000 Hello. Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in broken state? I need to connect NATed VPN clients through L2TP/IPSec and seeing nothing in mpd5 logs, but growing counters of bad checksums in udp packets. After some research I found an opened kern/146190 with some sort of solving the problem through disabling checksum validation, but it still not work. Every incoming UDP encapsulated ESP packet toggles two counters: udp no checksums (because of 0 value in every incoming packet udp checksum) and udp bad checksums (hmmm..., I thought it shouldn't be happen with a magic patch). So, can anyone tell me is it possible to connect my NATed VPN clients through L2TP/IPSec or it's impossible nowadays? Thanks a lot. Zmiter 12.04.2012 From owner-freebsd-stable@FreeBSD.ORG Thu Apr 12 22:18:58 2012 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 7CDFF106564A for ; Thu, 12 Apr 2012 22:18:58 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5178FC15 for ; Thu, 12 Apr 2012 22:18:58 +0000 (UTC) Received: by iahk25 with SMTP id k25so4377227iah.13 for ; Thu, 12 Apr 2012 15:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=uU81gcNTefVjlwpnjPMZCax57vZkGo6U+7WAmKN9eSc=; b=N7JpH4Mg/Qr+13bkgRDdm7JJw2fyTu1/vx7VF8EBj7nlE1mXseu43Bo51begCXEagm dedJCTHm6/5jVS6k9kEu/r62IWvYplTr6EgADUj0VBrD9BXomGSvOMfKaIUmQzxFbKLx MR1qEFxzKwzVkYIhfsnfg8eAkVsIxUfJ0wkS8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=uU81gcNTefVjlwpnjPMZCax57vZkGo6U+7WAmKN9eSc=; b=GrByv8J6TZBpVBVKv/48aNUopLUfH7sza70SqKh0oCG0eJktax4e8evCiH6E79xXcJ w9BcbsArkKc+OJznj+Ewc3utmXqqkjHcTckVH3rWk1WISY9/kQ7dca3DhofmglLZbfCx GBsPWDRiHLe9915GNXaLRORGiIon3ghYTrBk1wBtaLxEE4P8h0dZ2xYB4k5l8YpkSiUz nJf1O/eRdZvEfCDrNh+iTham06Oj1Oqx+KLyxt/Zm6YCGuNt9cSl+KrVltpR19cHdIOy cvr3u43a4+effLA52Cer51Eh+m0QgQsEa0MIdd9fkTlf5HkjuhXMfQCR0Ta1ziLmYJhB RVIg== Received: by 10.50.189.200 with SMTP id gk8mr4149527igc.8.1334269137867; Thu, 12 Apr 2012 15:18:57 -0700 (PDT) Received: from DataIX.net (adsl-99-181-142-73.dsl.klmzmi.sbcglobal.net. [99.181.142.73]) by mx.google.com with ESMTPS id cw5sm222566igc.17.2012.04.12.15.18.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 15:18:57 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3CMItYY086870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 18:18:55 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3CMIsZ5086869; Thu, 12 Apr 2012 18:18:54 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 12 Apr 2012 18:18:54 -0400 From: Jason Hellenthal To: "Bjoern A. Zeeb" Message-ID: <20120412221854.GB86016@DataIX.net> References: <20120412171046.GA73570@DataIX.net> <14882DCF-7A41-4899-B20D-09241AF12F2E@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14882DCF-7A41-4899-B20D-09241AF12F2E@lists.zabbadoz.net> X-Gm-Message-State: ALoCoQkWXJPIlJqrLTmn5rq6Q3kZMkXF9Kx0tgnAHYygZi0TPM9/jtPpQmle7DbDiG00AcJsnn01 Cc: stable@freebsd.org Subject: Re: BURN_BRIDGES & /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to `in6_selectroute_fib' 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, 12 Apr 2012 22:18:58 -0000 On Thu, Apr 12, 2012 at 06:10:47PM +0000, Bjoern A. Zeeb wrote: > > On 12. Apr 2012, at 17:10 , Jason Hellenthal wrote: > > > > > While attempting to burn bridges... yeah yeah I know, may include some > > civil infractions ;) > > > > On stable/8 i386 Last Changed Rev: 234180 fresh build > > > > linking kernel.debug > > ip6_output.o(.text+0x334f): In function `ip6_output': > > /usr/src/sys/netinet6/ip6_output.c:582: undefined reference to > > `in6_selectroute_fib' > > It's basically a marker to not use this function anywhere new in the stable/ branches. It will change in HEAD soon given the code has now been in for almost two months (in HEAD) without further needs to re-adjustment. I am not sure we ever allowed compiling with BURN_BRIDGES set but I can change the #ifndef to THIS_IS_PART_OF_THE_PUBLIC_STABLE_KPI or something if needed. Yeah compiling for me here was just a fundamental test but when I found that I figured I should at least let someone know in case it was useful. Thanks Bjoern > > See the comment above it: > http://svnweb.freebsd.org/base/stable/8/sys/netinet6/in6_src.c?annotate=232552#l820 > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you do! > -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Fri Apr 13 04:28:55 2012 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 605F4106566B for ; Fri, 13 Apr 2012 04:28:55 +0000 (UTC) (envelope-from zmiterby@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E287F8FC0A for ; Fri, 13 Apr 2012 04:28:54 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2628256wgb.31 for ; Thu, 12 Apr 2012 21:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ta93nYkiUSQHAdLqwTTLo8W1tQ9rRRDsDQVqYncV8+0=; b=taeuCgVZ9hRnaUstt3hTyYWHJhat7dfje9nZ9MBuJz4MRdURHgUc5up4LVNWYV5tUk OkFdUA2llUZ7YBvHWo00eDGfe+LEUrU+VNmMhXo31T0j0IFAbLvPcrYARocRwZlin/dK mJZGlB1Gt9wdeMFWWBDwaz0KVZDOzgfNXlnuttQg89qlTf51eAV8tGtyBBHaPsU2hVCB eBcyQX5AeAwbg8qlaGOmrsCp5b10jUGcbNXJkDmwV2AKc9t4viCWIN5yB37o9G4DpSON qU8mxUm58h0BfrNX++ZgWj60tF+vL7S+EjE5tEJDkuEljE/4FolAJFeA2wcxyF6bWhbD 1GSw== Received: by 10.180.107.132 with SMTP id hc4mr453232wib.21.1334291333733; Thu, 12 Apr 2012 21:28:53 -0700 (PDT) Received: from [127.0.0.1] ([178.121.136.168]) by mx.google.com with ESMTPS id n20sm3535725wiw.5.2012.04.12.21.28.51 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 21:28:52 -0700 (PDT) Message-ID: <4F87AB6F.4050504@gmail.com> Date: Fri, 13 Apr 2012 07:28:31 +0300 From: Zmiter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Support for IPSec NAT-T in transoprt mode 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, 13 Apr 2012 04:28:55 -0000 Hello. Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in broken state? I need to connect NATed VPN clients through L2TP/IPSec and seeing nothing in mpd5 logs, but growing counters of bad checksums in udp packets. After some research I found an opened kern/146190 with some sort of solving the problem through disabling checksum validation, but it still not work. Every incoming UDP encapsulated ESP packet toggles two counters: udp no checksums (because of 0 value in every incoming packet udp checksum) and udp bad checksums (hmmm..., I thought it shouldn't be happen with a magic patch). So, can anyone tell me is it possible to connect my NATed VPN clients through L2TP/IPSec or it's impossible nowadays? Thanks a lot. Zmiter 12.04.2012 From owner-freebsd-stable@FreeBSD.ORG Fri Apr 13 14:49:15 2012 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 AD6B51065686 for ; Fri, 13 Apr 2012 14:49:15 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC6698FC1F for ; Fri, 13 Apr 2012 14:49:14 +0000 (UTC) Received: by wern13 with SMTP id n13so2671836wer.13 for ; Fri, 13 Apr 2012 07:49:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=XCHY/uVtA7idcc0WGEV60PGdJLVtpWubSmQqnLouNpo=; b=g5LcEnim+0yLYBpJWODcpt47CbEfwP/ha55xaApxohrErSho7mRQY6qov8DRJfLGLA 7b+A3wa+u9ZupBXdNOAZN9pN9VY/9C72LxRY16K4zKrjm2IXDjo60clTDLEO0Av+xVkL tXjEyOdJRQ5KkOoawilPZzxADV0yZlautb4ahFsF+LHDBSOLnwR5hO1Xe0XRRr4hr/Ph e5DF7ca4n12dL5XiB/R+CK/iEChpv82fyNfOUWv+L+4nrEFznz9VDyavUiUCDPaVc+mR zwMx8jUKgdriLP2tYtWAO675KeqrReiKGtAKdAbNyZKkwAzUhmM1EClNF3sjBkbPTRqd gJ4Q== MIME-Version: 1.0 Received: by 10.180.91.168 with SMTP id cf8mr4630772wib.0.1334328553747; Fri, 13 Apr 2012 07:49:13 -0700 (PDT) Received: by 10.180.80.230 with HTTP; Fri, 13 Apr 2012 07:49:13 -0700 (PDT) X-Originating-IP: [95.108.170.198] Date: Fri, 13 Apr 2012 18:49:13 +0400 Message-ID: From: Andrey Zonov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQntOYGWVHlngJxcF6wgX59YSD0Jbwn79SF/7jVD24SfXTgHfS4TtcTCYrtZvCVxqIdpp3xa Subject: gmirror causes panic under 9.0-STABLE 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, 13 Apr 2012 14:49:15 -0000 Hi, I've got repeatable panics with gmirror and ufs. The test case is the following: # gmirror label -v test /dev/da1b # newfs /dev/mirror/test # while :; do gmirror label -v test /dev/da1b; mount /dev/mirror/test /mnt; dd if=/dev/zero of=/mnt/test count=100 bs=1m; umount -f /mnt; gmirror remove test da1b; done After a while I've got panic with such DDB backtrace: db:0:kdb.enter.default> bt Tracing pid 5240 tid 100075 td 0xfffffe0001e47460 _sx_xlock_hard() at _sx_xlock_hard+0xb3 g_mirror_access() at g_mirror_access+0x262 g_access() at g_access+0x162 g_vfs_open() at g_vfs_open+0xb3 ffs_mount() at ffs_mount+0xb4b vfs_donmount() at vfs_donmount+0x1072 sys_nmount() at sys_nmount+0x66 amd64_syscall() at amd64_syscall+0x5bf Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a8746c, rsp = 0x7fffffffcb58, rbp = 0x801008048 --- -- Andrey Zonov From owner-freebsd-stable@FreeBSD.ORG Fri Apr 13 23:13:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 084591065675 for ; Fri, 13 Apr 2012 23:13:37 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 847438FC08 for ; Fri, 13 Apr 2012 23:13:36 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so5972088wib.13 for ; Fri, 13 Apr 2012 16:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+iiMWqr13hz/CSEFo+bDkIlN0HQ+eVRk4Xsgv2Tf6sc=; b=ktwkTG64fvJYcH+SZcHeM2WEdMpvhpbfJ4U/lF04woFIBMF4iWbiaiKyegVwiy16ZS I2kDwtZnulBHQWesSyQUSvImkKw2Cb9FkeabKwyQD4gR5b+F/VlzDLI0FQ1F+BFVkT6v ohxS6i/FHoGy+ACuQXhpx30A+U9TJytrmM9JgVZwfqU93Ia/eNLe0r38WbNGbIqFvPAy 9K2xfMNs+FiZYuR1OKlsLkdhZQb/wUzydBFCXII8hiN034HJrMQzjHROeYrYbZf4ilxF E7AwclPOa0bMfIuqb6AP12KqFMfvD0MSSdtsnnArLoYZzN3d5UOLA2mZF4YEIWDPZxKi x5Ag== MIME-Version: 1.0 Received: by 10.180.82.136 with SMTP id i8mr46454wiy.19.1334358810458; Fri, 13 Apr 2012 16:13:30 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 13 Apr 2012 16:13:30 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 13 Apr 2012 16:13:30 -0700 (PDT) In-Reply-To: References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Sat, 14 Apr 2012 08:43:30 +0930 Message-ID: From: Matt Thyer To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system 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, 13 Apr 2012 23:13:37 -0000 On Apr 7, 2012 2:38 PM, "Matt Thyer" wrote: > > On 7 April 2012 14:31, Matt Thyer wrote: >> Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no longer having that disk evicted from the raidz2 pool with write errors and I thought that the high interrupt rate issue had also been solved but it's back again. >> >> This is on 8-STABLE at revision 230921 (before the new driver hit 8-STABLE). >> >> So now I need to go back to trying to determine what the cause is. >> > vmstat -i has shown that the issue was on irq 16. > > Unfortunately there seems to be a lot of things on irq 16: > > $ dmesg | grep "irq 16" > > pcib1: irq 16 at device 1.0 on pci0 > mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdfffff,0xfbd80000-0xfbdbffff irq 16 at device 0.0 on pci1 > vgapci0: port 0xff00-0xff07 mem 0xfb400000-0xfb7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pcib3: irq 16 at device 28.4 on pci0 > atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 > > Any idea how to isolate which bit of hardware could be triggering the interrupts ? > > Unfortunately the only device I could remove would be the SuperMicro AOC-USAS2-L8i (so yes I could eliminate that). > > My biggest problem right now is not knowing how to trigger the issue. > > At this stage I'm going to upgrade to 9-STABLE and see if it returns. The problem does not occur with 9-STABLE. Who knows what the problem was ? USB maybe ? From owner-freebsd-stable@FreeBSD.ORG Sat Apr 14 16:59:20 2012 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 EADE21065780 for ; Sat, 14 Apr 2012 16:59:20 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id A01D08FC12 for ; Sat, 14 Apr 2012 16:59:20 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C7B0125D3A00; Sat, 14 Apr 2012 16:59:19 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F0E9ABE4D58; Sat, 14 Apr 2012 16:59:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id NCRqPkxyRSSc; Sat, 14 Apr 2012 16:59:18 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1A59ABE4D57; Sat, 14 Apr 2012 16:59:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F87AB6F.4050504@gmail.com> Date: Sat, 14 Apr 2012 16:59:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <22CC7FDB-162E-44CD-8EEA-0B5B8B560F8B@lists.zabbadoz.net> References: <4F87AB6F.4050504@gmail.com> To: Zmiter X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org Subject: Re: Support for IPSec NAT-T in transoprt mode 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, 14 Apr 2012 16:59:21 -0000 On 13. Apr 2012, at 04:28 , Zmiter wrote: > Hello. > Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's = still in broken state? It's not broken; it was never implemented. No FreeBSD tree shipped does support transport mode at this time. There are patches but you also = need to fix ipsec-tools or your ike daemon. If you do the latter I can = commit the former. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!