From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 06:36:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 559E6353; Sun, 21 Jul 2013 06:36:23 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 0C16464F; Sun, 21 Jul 2013 06:36:22 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6L6aBIi045316; Sat, 20 Jul 2013 23:36:17 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6L6a6oC045313; Sat, 20 Jul 2013 23:36:06 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 20 Jul 2013 23:36:06 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Sat, 20 Jul 2013 23:36:06 -0700 (PDT) Subject: Re: Trouble building release with docs From: "Chris H" To: freebsd-doc@freebsd.org, "freebsd-stable stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 06:36:23 -0000 > On Sat, 20 Jul 2013, Daniel O'Connor wrote: > >> Hi, >> I am trying to do a full (customised) release of 9.1 but I am having trouble building the >> docs. If I use NODOC it builds fine, but without that I get.. >> [andenes 7:04] /usr/src/release #/usr/bin/time make release BUILDNAME=$BUILDNAME >> make -C /usr/src/release BUILDNAME=9.1-GENESIS obj >> make -C /usr/src/release BUILDNAME=9.1-GENESIS ftp cdrom memstick >> cd /usr/src/release/doc && make all install clean 'FORMATS=html txt' >> INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES DOCDIR=/usr/obj/usr/src/release/rdoc >> ===> en_US.ISO8859-1 (all) >> ===> en_US.ISO8859-1/relnotes (all) >> /usr/bin/grep '^' article.xml > article.parsed.xml.tmp >> grep: article.xml: No such file or directory >> *** [article.parsed.xml] Error code 2 >> >> Stop in /usr/src/release/doc/en_US.ISO8859-1/relnotes. >> *** [all] Error code 1 >> >> Stop in /usr/src/release/doc/en_US.ISO8859-1. >> *** [all] Error code 1 >> >> Stop in /usr/src/release/doc. >> *** [reldoc] Error code 1 >> >> Stop in /usr/src/release. >> *** [release] Error code 1 >> >> Stop in /usr/src/release. >> 0.48 real 0.37 user 0.10 sys >> >> There is article.sgml though.. I have installed textproc/docproj and I can build /usr/docs >> fine. > > What does svn say about that file? > > % cd /usr/src/release/doc/en_US.ISO8859-1/relnotes/ > % svn stat > > The article.sgml suggests a leftover file from an earlier /usr/src that > was not removed before svn checkout. That does not explain why > article.xml is missing, though. It is present on my 9-stable and > 8-stable checkouts. Maybe a mixed or partial checkout? FWIW, it wasn't in my checkout from July 2, either (8-STABLE) --Chris > _______________________________________________ > 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 Sun Jul 21 06:49:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 103D2533; Sun, 21 Jul 2013 06:49:37 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) by mx1.freebsd.org (Postfix) with ESMTP id DF1B76BD; Sun, 21 Jul 2013 06:49:36 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 2EF917520; Sun, 21 Jul 2013 06:49:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 2EF917520 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 21 Jul 2013 02:49:31 -0400 From: Glen Barber To: Daniel O'Connor Subject: Re: Trouble building release with docs Message-ID: <20130721064931.GB2344@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-doc@freebsd.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 06:49:37 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jul 20, 2013 at 04:44:56PM +0930, Daniel O'Connor wrote: > Hi, > I am trying to do a full (customised) release of 9.1 but I am > having trouble building the docs. If I use NODOC it builds fine, > but without that I get.. [...] May I ask why 9.1? Glen --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR64R7AAoJEFJPDDeguUajSVgIALEySb1MG7FwT/PVcUoZEtc6 SqfYRKgXlGHZBL4v4zqCCNCHfO2qG/uK5b3hCWo9hB0HXwOuO0B9n3Z5K/DZ2hn3 RO4x+mVrxronJn6Q6qpXpAF4FqKlQnYbMd4Z7d7jbg9K9fKtG4pCYKh4CXc2U8iU 6n+DAEsX4+m9Ou14gaZbgBbiFUGsPSxSVlLfAMcY7Jsy4g2YQVITXXs/k+JbP9Tj 4OtxMrR+1IW+QvMdnVxwYLBqYe6dsctNMrtWtlI2TnH/LC9xtvMGcdJwSydSClzg XVHuRMUN//4SNk+V9tLNSIlcfbM+H3gcuaBIONU35AJGO1uT/RwrbHrpRP5yDUI= =hY5A -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 07:49:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FB1916D; Sun, 21 Jul 2013 07:49:58 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id BB9A5947; Sun, 21 Jul 2013 07:49:57 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-143-198.lns20.adl6.internode.on.net [118.210.143.198]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r6L7nbhD017995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Jul 2013 17:19:42 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Trouble building release with docs Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CE716022-33BE-4130-8D43-FDDBF0ED801C"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: <20130721064931.GB2344@glenbarber.us> Date: Sun, 21 Jul 2013 17:19:23 +0930 Message-Id: <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> References: <20130721064931.GB2344@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1508) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-doc@freebsd.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 07:49:58 -0000 --Apple-Mail=_CE716022-33BE-4130-8D43-FDDBF0ED801C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 21/07/2013, at 16:19, Glen Barber wrote: > On Sat, Jul 20, 2013 at 04:44:56PM +0930, Daniel O'Connor wrote: >> Hi, >> I am trying to do a full (customised) release of 9.1 but I am >> having trouble building the docs. If I use NODOC it builds fine, >> but without that I get.. > > [...] > > May I ask why 9.1? Actually that's an excellent question :) I though 9.1 was coming out not 9.2 but that is not correct. So, if I rebuild with 9.2 checked out will the docs build? Thanks -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_CE716022-33BE-4130-8D43-FDDBF0ED801C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iD8DBQFR65KR5ZPcIHs/zowRArW2AJ4hnRH9+30qBusLevl6umpxmD1xXgCghji3 eZllL+zQA2CMXBGN9uiuXzQ= =jNnO -----END PGP SIGNATURE----- --Apple-Mail=_CE716022-33BE-4130-8D43-FDDBF0ED801C-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 07:50:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD7382BB; Sun, 21 Jul 2013 07:50:50 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) by mx1.freebsd.org (Postfix) with ESMTP id B8D58968; Sun, 21 Jul 2013 07:50:50 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 37F897A56; Sun, 21 Jul 2013 07:50:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 37F897A56 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 21 Jul 2013 03:50:43 -0400 From: Glen Barber To: Daniel O'Connor Subject: Re: Trouble building release with docs Message-ID: <20130721075043.GE2344@glenbarber.us> References: <20130721064931.GB2344@glenbarber.us> <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HeFlAV5LIbMFYYuh" Content-Disposition: inline In-Reply-To: <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-doc@freebsd.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 07:50:50 -0000 --HeFlAV5LIbMFYYuh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 05:19:23PM +0930, Daniel O'Connor wrote: >=20 > On 21/07/2013, at 16:19, Glen Barber wrote: >=20 > > On Sat, Jul 20, 2013 at 04:44:56PM +0930, Daniel O'Connor wrote: > >> Hi, > >> I am trying to do a full (customised) release of 9.1 but I am > >> having trouble building the docs. If I use NODOC it builds fine, > >> but without that I get.. > >=20 > > [...] > >=20 > > May I ask why 9.1? >=20 >=20 > Actually that's an excellent question :) >=20 > I though 9.1 was coming out not 9.2 but that is not correct. >=20 > So, if I rebuild with 9.2 checked out will the docs build? >=20 Yes. Glen --HeFlAV5LIbMFYYuh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR65LTAAoJEFJPDDeguUajkJMH/A6aXEJNfWIJOP5DNl2tWL6M 4t1UkTNMgfRWkSvSBVdo7nV5svhtB+DAD6Az+i15KTfIeHRI7Z7wqkVDxCHiIO/K m7tu3lmBIMJJHvNb2qmF1donUXoUCq3EXVC/WwYUVIszOFK+WtNfl4IX6LcsFzxP 105B8MrBTQos8X1gF5XSXmvkgwy5zFj/ZHq+MbuWwq3Hue3diVAU0DuAv124h60Z cDEXWbw/GdLGQFpGnZXyc7AHX7y/yE5lAhMaMr6Tln7LNEts8mUdOuNus54yALpi pOLkEYdibt/jKL1AdSM4T5M8Bcy+l1ri9M+nFGssJlnx9Nk5qZM1Lr4EW3+5nu8= =roN0 -----END PGP SIGNATURE----- --HeFlAV5LIbMFYYuh-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 13:45:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id 78053A38; Sun, 21 Jul 2013 13:45:48 +0000 (UTC) Date: Sun, 21 Jul 2013 13:45:48 +0000 From: John To: FreeBSD-Stable Subject: Panic: 9.2-PRERELEASE - enc_daemon & usb LOR? Message-ID: <20130721134548.GA78666@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 13:45:48 -0000 Hi Folks, I'm seeing a panic with the 9.2-PRERELEASE code. The system will stay up for anywhere from a couple of seconds to a few hours and then panic. Fatal trap 12: page fault while in kernel mode cpuid = 31; apic id = 2f fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d2b018 stack pointer = 0x28:0xffffffbfd0fea080 frame pointer = 0x28:0xffffffbfd0fea0b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 25 (enc_daemon7) and: db:0:kdb.enter.default> show pcpu cpuid = 31 dynamic pcpu = 0xffffff807f203880 curthread = 0xfffffe0032f53920: pid 25 "enc_daemon7" curpcb = 0xffffffbfd0feabc0 fpcurthread = none idlethread = 0xfffffe002600b920: tid 100034 "idle: cpu31" curpmap = 0xffffffff8141b510 tssp = 0xffffffff81489e98 commontssp = 0xffffffff81489e98 rsp0 = 0xffffffbfd0feabc0 gs32p = 0xffffffff81487fd0 ldt = 0xffffffff81488010 tss = 0xffffffff81488000 This looks like a bug I started tracing down a while back with the new enclosure services (r246437 and later). I added witness into the kernel and received the following LOR: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex MPT2SAS lock (MPT2SAS lock) r = 0 (0xffffff8003c851b8) locked @ cam/cam_periph.h:192 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffffbfd0f3cb20 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffffbfd0f3cbe0 _witness_debugger() at _witness_debugger+0x2c/frame 0xffffffbfd0f3cc00 witness_warn() at witness_warn+0x2d2/frame 0xffffffbfd0f3cd40 trap_pfault() at trap_pfault+0x6a/frame 0xffffffbfd0f3cdd0 trap() at trap+0x344/frame 0xffffffbfd0f3cfd0 calltrap() at calltrap+0x8/frame 0xffffffbfd0f3cfd0 --- trap 0xc, rip = 0xffffffff80ca8478, rsp = 0xffffffbfd0f3d090, rbp = 0xffffffbfd0f3d0c0 --- memcpy() at memcpy+0x8/frame 0xffffffbfd0f3d0c0 ses_setphyspath_callback() at ses_setphyspath_callback+0xb3/frame 0xffffffbfd0f3d1d0 ses_path_iter_devid_callback() at ses_path_iter_devid_callback+0x1c6/frame 0xffffffbfd0f3d770 ses_devids_iter() at ses_devids_iter+0xb1/frame 0xffffffbfd0f3d7f0 ses_paths_iter() at ses_paths_iter+0x20/frame 0xffffffbfd0f3d810 ses_publish_physpaths() at ses_publish_physpaths+0x264/frame 0xffffffbfd0f3da40 enc_daemon() at enc_daemon+0x2a4/frame 0xffffffbfd0f3daa0 fork_exit() at fork_exit+0x11d/frame 0xffffffbfd0f3daf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffffbfd0f3daf0 --- trap 0, rip = 0, rsp = 0xffffffbfd0f3dbb0, rbp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 8; apic id = 08 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ca8478 stack pointer = 0x28:0xffffffbfd0f3d090 frame pointer = 0x28:0xffffffbfd0f3d0c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 30 (enc_daemon12) lock order reversal: (Giant after non-sleepable) 1st 0xffffff8003c851b8 MPT2SAS lock (MPT2SAS lock) @ cam/cam_periph.h:192 2nd 0xffffffff8139bc80 Giant (Giant) @ dev/usb/input/ukbd.c:1942 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm wondering if there is a bad interaction here. The system has 8 DS2700 shelves dual attached to a pair of LSI 8e cards, thus the kernel configuration with an increased msgbuf size. Kernel conf: include GENERIC ident ZFS options DDB options KDB options WITNESS options MSGBUF_SIZE=(32768*16) And some ddb output: db:0:kdb.enter.default> run lockinfo db:1:lockinfo> show locks exclusive sleep mutex MPT2SAS lock (MPT2SAS lock) r = 0 (0xffffff8003c851b8) locked @ cam/cam_periph.h:192 db:1:locks> show alllocks Process 30 (enc_daemon12) thread 0xfffffe003421a000 (100155) exclusive sleep mutex MPT2SAS lock (MPT2SAS lock) r = 0 (0xffffff8003c851b8) locked @ cam/cam_periph.h:192 db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.default> show pcpu cpuid = 8 dynamic pcpu = 0xffffff807f1e4800 curthread = 0xfffffe003421a000: pid 30 "enc_daemon12" curpcb = 0xffffffbfd0f3dbc0 fpcurthread = none idlethread = 0xfffffe0021ffe490: tid 100011 "idle: cpu8" curpmap = 0xffffffff81399590 tssp = 0xffffffff815a5640 commontssp = 0xffffffff815a5640 rsp0 = 0xffffffbfd0f3dbc0 gs32p = 0xffffffff815a3778 ldt = 0xffffffff815a37b8 tss = 0xffffffff815a37a8 spin locks held: db:0:kdb.enter.default> bt Tracing pid 30 tid 100155 td 0xfffffe003421a000 memcpy() at memcpy+0x8/frame 0xffffffbfd0f3d0c0 ses_setphyspath_callback() at ses_setphyspath_callback+0xb3/frame 0xffffffbfd0f3d1d0 ses_path_iter_devid_callback() at ses_path_iter_devid_callback+0x1c6/frame 0xffffffbfd0f3d770 ses_devids_iter() at ses_devids_iter+0xb1/frame 0xffffffbfd0f3d7f0 ses_paths_iter() at ses_paths_iter+0x20/frame 0xffffffbfd0f3d810 ses_publish_physpaths() at ses_publish_physpaths+0x264/frame 0xffffffbfd0f3da40 enc_daemon() at enc_daemon+0x2a4/frame 0xffffffbfd0f3daa0 fork_exit() at fork_exit+0x11d/frame 0xffffffbfd0f3daf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffffbfd0f3daf0 --- trap 0, rip = 0, rsp = 0xffffffbfd0f3dbb0, rbp = 0 --- Any thoughts/ideas are appreciated. I've reviewed the code and don't see anything obvious. Thanks, John From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 13:57:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6CEEE36 for ; Sun, 21 Jul 2013 13:57:45 +0000 (UTC) (envelope-from perox@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id AADA8E24 for ; Sun, 21 Jul 2013 13:57:45 +0000 (UTC) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout2.freenet.de with esmtpa (ID perox@freenet.de) (port 25) (Exim 4.80.1 #3) id 1V0u8u-0006Yg-7D for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 15:57:44 +0200 Received: from localhost ([::1]:43136 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID perox@freenet.de) (Exim 4.80.1 #4) id 1V0u8u-00059l-33 for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 15:57:44 +0200 Received: from mx17.freenet.de ([195.4.92.27]:38706) by mjail1.freenet.de with esmtpa (ID perox@freenet.de) (Exim 4.80.1 #4) id 1V0u6t-0004K8-2a for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 15:55:39 +0200 Received: from web16.emo.freenet-rz.de ([194.97.107.138]:48230 helo=web17.emo.freenet-rz.de) by mx17.freenet.de with esmtpa (ID perox@freenet.de) (port 587) (Exim 4.80.1 #4) id 1V0u6s-0000Tt-UW for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 15:55:39 +0200 Received: from localhost ([127.0.0.1] helo=emo.freenet.de) by web17.emo.freenet-rz.de with esmtpa (Exim 4.72 1 (Panther_1)) id 1V0u6s-0007JS-QX for ; Sun, 21 Jul 2013 15:55:38 +0200 Date: Sun, 21 Jul 2013 15:55:38 +0200 Received: from [91.19.40.150] by web16.emo.freenet-rz.de with http; Sun, 21 Jul 2013 15:55:38 +0200 From: perox@freenet.de Subject: Problem entering GELI password at boot To: freebsd-stable@freebsd.org X-Priority: 3 MIME-Version: 1.0 X-Abuse: 500871696 / 91.19.40.150 Message-Id: <02530f38f832c15c88170dc038450c2e@email.freenet.de> User-Agent: freenetMail Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 13:57:46 -0000 SGksDQoNCkkgcmVjZW50bHkgdXAgY29uc2lzdHMgb2YgYSBaRlMgUkFJRC0xIHVwb24gYSBHRUxJ LWVuY3J5cHRlZCBjb250YWluZXIuIEJlZm9yZSB0aGUgdXBkYXRlIEkgY291bGQgZW50ZXIgdGhl IHBhc3NwaHJhc2VzIGR1cmluZyBib290IChiZWZvcmUgcm9vdCBtb3VudCkgdmlhIG15IFVTQiBr ZXlib2FyZCBhbmQgZ2VsaSB3b3VsZCBjcmVhdGVkIHRoZSBub2RlcyBhbmQgcm9vdCBjb3VsZCBi ZSBtb3VudGVkLg0KSW4gOC4wIEkgaGFkIGEgcmVsYXRlZCBwcm9ibGVtIChzb21lIGtleXN0cm9r ZXMgd291bGQgbm90IGJlIHJlY29nbml6ZWQpIGJ1dCB0aGlzIGhhcyBiZWVuIGZpeGVkIHNpbmNl LiBOb3cgdGhlIGtleWJvYXJkIGlzIGZ1bmN0aW9uYWwgKEkgY2FuIHNjcm9sbCB1cCBhbmQgZG93 bikgYnV0IEdFTEkgZG9lc24ndCByZWNvZ25pemUgYW55dGhpbmcgKG5vdCBldmVuICdyZXR1cm4n KS4NCg0KQW55IGlkZWFzIG9yIGhpbnRzPw0KDQpUaGFua3MhDQoNCg0KCgotLS0KQWxsZSBQb3N0 ZsOkY2hlciBhbiBlaW5lbSBPcnQuIEpldHp0IHdlY2hzZWxuIHVuZCBFLU1haWwtQWRyZXNzZSBt aXRuZWhtZW4hIGh0dHA6Ly9lbWFpbC5mcmVlbmV0LmRlL2Jhc2ljL0luZm9ybWF0aW9uZW4K From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 14:13:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C4248293 for ; Sun, 21 Jul 2013 14:13:07 +0000 (UTC) (envelope-from perox@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 87AEAF22 for ; Sun, 21 Jul 2013 14:13:07 +0000 (UTC) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout0.freenet.de with esmtpa (ID perox@freenet.de) (port 25) (Exim 4.80.1 #4) id 1V0uNm-0001ol-2s for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 16:13:06 +0200 Received: from localhost ([::1]:41589 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID perox@freenet.de) (Exim 4.80.1 #4) id 1V0uNl-000424-TC for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 16:13:06 +0200 Received: from mx10.freenet.de ([195.4.92.20]:43187) by mjail2.freenet.de with esmtpa (ID perox@freenet.de) (Exim 4.80.1 #4) id 1V0uLO-0002PH-Bf for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 16:10:38 +0200 Received: from web2.emo.freenet-rz.de ([194.97.107.235]:38692 helo=web17.emo.freenet-rz.de) by mx10.freenet.de with esmtpa (ID perox@freenet.de) (port 587) (Exim 4.80.1 #4) id 1V0uLO-0001Hs-6y for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 16:10:38 +0200 Received: from localhost ([127.0.0.1] helo=emo.freenet.de) by web17.emo.freenet-rz.de with esmtpa (Exim 4.72 1 (Panther_1)) id 1V0uLO-0007nU-1U for ; Sun, 21 Jul 2013 16:10:38 +0200 Date: Sun, 21 Jul 2013 16:10:37 +0200 Received: from [91.19.40.150] by web2.emo.freenet-rz.de with http; Sun, 21 Jul 2013 16:10:37 +0200 From: perox@freenet.de Subject: RE: Problem entering GELI password at boot To: freebsd-stable@freebsd.org X-Priority: 3 MIME-Version: 1.0 X-Abuse: 500871696 / 91.19.40.150 Message-Id: <58e9e83b6c344aca30e339bb13a74a1b@email.freenet.de> User-Agent: freenetMail Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 14:13:07 -0000 c29ycnkgSSBhY2NpZGVudGFsbHkgbWVzc2VkIHVwIHRoZSBsYXN0IG1lc3NhZ2U6ICAgICAgICAN Cg0KSSByZWNlbnRseSB1cCBjb25zaXN0cyBvZiBhIFpGUyBSQUlELTEgdXBvbiBhIEdFTEktZW5j cnlwdGVkIGNvbnRhaW5lci4gQmVmb3JlIHRoZSB1cGRhdGUgSSBjb3VsZCBlbnRlciB0aGUgcGFz c3BocmFzZXMgZHVyaW5nIGJvb3QgKGJlZm9yZSByb290IG1vdW50KSB2aWEgbXkgVVNCIGtleWJv YXJkIGFuZCBnZWxpIHdvdWxkIGNyZWF0ZWQgdGhlIG5vZGVzIGFuZCByb290IGNvdWxkIGJlIG1v dW50ZWQuIEluIDguMCBJIGhhZCBhIHJlbGF0ZWQgcHJvYmxlbSAoc29tZSBrZXlzdHJva2VzIHdv dWxkIG5vdCBiZSByZWNvZ25pemVkKSBidXQgdGhpcyBoYXMgYmVlbiBmaXhlZCBzaW5jZS4gTm93 IHRoZSBrZXlib2FyZCBpcyBmdW5jdGlvbmFsIChJIGNhbiBzY3JvbGwgdXAgYW5kIGRvd24pIGJ1 dCBHRUxJIGRvZXNuJ3QgcmVjb2duaXplIGFueXRoaW5nIChub3QgZXZlbiAncmV0dXJuJykuDQoN Cg0KCgotLS0KQWxsZSBQb3N0ZsOkY2hlciBhbiBlaW5lbSBPcnQuIEpldHp0IHdlY2hzZWxuIHVu ZCBFLU1haWwtQWRyZXNzZSBtaXRuZWhtZW4hIGh0dHA6Ly9lbWFpbC5mcmVlbmV0LmRlL2Jhc2lj L0luZm9ybWF0aW9uZW4KCg== From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 14:26:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E1F4D8FF; Sun, 21 Jul 2013 14:26:08 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A2F07FD0; Sun, 21 Jul 2013 14:26:08 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r6LEQ7uP038043; Sun, 21 Jul 2013 08:26:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r6LEQ68k038040; Sun, 21 Jul 2013 08:26:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 21 Jul 2013 08:26:06 -0600 (MDT) From: Warren Block To: Glen Barber Subject: Re: Trouble building release with docs In-Reply-To: <20130721075043.GE2344@glenbarber.us> Message-ID: References: <20130721064931.GB2344@glenbarber.us> <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> <20130721075043.GE2344@glenbarber.us> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 21 Jul 2013 08:26:07 -0600 (MDT) Cc: freebsd-doc@freebsd.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 14:26:09 -0000 On Sun, 21 Jul 2013, Glen Barber wrote: > On Sun, Jul 21, 2013 at 05:19:23PM +0930, Daniel O'Connor wrote: >> >> On 21/07/2013, at 16:19, Glen Barber wrote: >> >>> On Sat, Jul 20, 2013 at 04:44:56PM +0930, Daniel O'Connor wrote: >>>> Hi, >>>> I am trying to do a full (customised) release of 9.1 but I am >>>> having trouble building the docs. If I use NODOC it builds fine, >>>> but without that I get.. >>> >>> [...] >>> >>> May I ask why 9.1? >> >> >> Actually that's an excellent question :) >> >> I though 9.1 was coming out not 9.2 but that is not correct. >> >> So, if I rebuild with 9.2 checked out will the docs build? >> > > Yes. Depending on the use, just downloading the built documents from ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/ could be more effective. From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 16:40:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E4E61EA for ; Sun, 21 Jul 2013 16:40:06 +0000 (UTC) (envelope-from allicient3141@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 3E16F972 for ; Sun, 21 Jul 2013 16:40:06 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so7176447obc.20 for ; Sun, 21 Jul 2013 09:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=N9LPeZx8Sqq1WoGvSXGNPUV/oJTA4b8+ftP8DbUOJBs=; b=veMLILRRUQAMqaL3m9iJ1luTtr4xk5ZMEesW8e3jf6DppoYJRAmxneU3+vIK48BW7C 8U8vnhqiyjYjDg6tKI+n9GpMuX05/phoiUXW+DsQxXlwuXy69eGZaBaEgRwJ9U94vWNl +SFGjd86Ie8wy8wt6WDMzqAvFDvF7l6uhzAFGMkV9EMIN65//nadcRxQUd1RSbSv9MMY yQk2UTBGAggmSsgoWR3N9uzNr7Jaf0MMZ+A7wlKoQMWJl1m0ShBeqZBGZYW0vlFc4V1Y vJsx82afekkZS8GMTba5NhdwOU+o9geaDmI7aFEj57ZxPcj4n8x9ao6TgcwLm3AwiLhW qzlg== X-Received: by 10.60.121.103 with SMTP id lj7mr6946549oeb.25.1374424805769; Sun, 21 Jul 2013 09:40:05 -0700 (PDT) MIME-Version: 1.0 Sender: allicient3141@gmail.com Received: by 10.182.204.70 with HTTP; Sun, 21 Jul 2013 09:39:35 -0700 (PDT) In-Reply-To: <02530f38f832c15c88170dc038450c2e@email.freenet.de> References: <02530f38f832c15c88170dc038450c2e@email.freenet.de> From: Peter Maxwell Date: Sun, 21 Jul 2013 17:39:35 +0100 X-Google-Sender-Auth: 9EEUREeC4bcCJkdSaSf-nydPfCA Message-ID: Subject: Re: Problem entering GELI password at boot To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 16:40:06 -0000 I've seen similar behaviour recently intermittently on releng-9.1 on an laptop (HP) with USB keyboard, and like you said I had also seen it a number of years ago when 8.0 first came out with a desktop with USB keyboard (iirc, it was an HP as well). It seems fine most of the time but occasionally it won't respond to keyboard input, especially if I've accidentally left the computer for a few moments before attempting to enter the passphrase. Vaguely remember it was something to do with AHCI but it was years ago and given it's not a massive problem the now I haven't bothered to look it up again. On 21 July 2013 14:55, wrote: > Hi, > > I recently up consists of a ZFS RAID-1 upon a GELI-encrypted container. > Before the update I could enter the passphrases during boot (before root > mount) via my USB keyboard and geli would created the nodes and root coul= d > be mounted. > In 8.0 I had a related problem (some keystrokes would not be recognized) > but this has been fixed since. Now the keyboard is functional (I can scro= ll > up and down) but GELI doesn't recognize anything (not even 'return'). > > Any ideas or hints? > > Thanks! > > > > > --- > Alle Postf=C3=A4cher an einem Ort. Jetzt wechseln und E-Mail-Adresse mitn= ehmen! > http://email.freenet.de/basic/Informationen > _______________________________________________ > 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 Sun Jul 21 19:10:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B552EB77 for ; Sun, 21 Jul 2013 19:10:32 +0000 (UTC) (envelope-from hartzell@alacrity.alerce.com) Received: from griffon.alerce.com (griffon.alerce.com [206.125.171.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB57DF1 for ; Sun, 21 Jul 2013 19:10:32 +0000 (UTC) Received: from griffon.alerce.com (localhost [127.0.0.1]) by griffon.alerce.com (Postfix) with ESMTP id 83C3A2842A; Sun, 21 Jul 2013 12:10:26 -0700 (PDT) Received: from alacrity.alerce.com (75-149-38-78-SFBA.hfc.comcastbusiness.net [75.149.38.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by griffon.alerce.com (Postfix) with ESMTPSA id 6601428424; Sun, 21 Jul 2013 12:10:26 -0700 (PDT) Received: by alacrity.alerce.com (Postfix, from userid 503) id 0C4CC1529F68; Sun, 21 Jul 2013 12:10:21 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20972.12828.973631.17998@gargle.gargle.HOWL> Date: Sun, 21 Jul 2013 12:10:20 -0700 To: hartzell@alerce.com Subject: Re: Help with filing a [maybe] ZFS/mmap bug. In-Reply-To: <20969.35970.217377.274868@gargle.gargle.HOWL> References: <20967.760.95825.310085@gargle.gargle.HOWL> <20968.14003.813473.517439@gargle.gargle.HOWL> <20130718192624.GA45917@ichotolot.servalan.com> <20969.30467.601461.313726@gargle.gargle.HOWL> <20969.35970.217377.274868@gargle.gargle.HOWL> X-Mailer: VM 8.2.0b under 24.2.1 (x86_64-apple-darwin) X-Virus-Scanned: ClamAV using ClamSMTP Cc: Richard Todd , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 19:10:32 -0000 George Hartzell writes: > George Hartzell writes: > > [...] > > So, it would seem that there's something about the filesystem in which > > my home directory resides that contributes to the problem. > > [...] > > Another data point. > > [...] Yet another data point or three. I took an unused disk, set it up with a single pool and copied everything from my two disk system to it using zfs send & recv. I was hoping that if there was something goofy about the state of the filesystems on the older two disk pool it might get cleaned up in the transfer. I tagged the entire set of flac files, they were all successfully validated via the plugin. After exiting Picard, one failed validation. After rebooting, many failed validation. Next I created a new filesystem on this new pool, mounted it, configured Picard to save to that filesystem and ran through all of the tracks. They validated fine via the plugin and by hand after exiting Picard. They also validated properly after unmounting and remounting the filesystem and after a reboot. Sigh. Then I destroyed all of the snapshots on the filesystems that I transfered over from my "real" dual-disk system. Tagging all of the flac files into my home directory generated errors from the validation plugin and by hand after exiting picard. I didn't bother rebooting and checking. So it seems to be something about the filesystem{s} themselves. I'm running a scrub now. g. From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 19:38:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 903355F6 for ; Sun, 21 Jul 2013 19:38:41 +0000 (UTC) (envelope-from perox@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 4C176EF4 for ; Sun, 21 Jul 2013 19:38:41 +0000 (UTC) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout1.freenet.de with esmtpa (ID perox@freenet.de) (port 25) (Exim 4.80.1 #3) id 1V0zSp-00027K-81 for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 21:38:39 +0200 Received: from localhost ([::1]:51495 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID perox@freenet.de) (Exim 4.80.1 #4) id 1V0zSo-0003Rd-Qb for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 21:38:39 +0200 Received: from mx4.freenet.de ([195.4.92.14]:37835) by mjail2.freenet.de with esmtpa (ID perox@freenet.de) (Exim 4.80.1 #4) id 1V0zQ0-0002K0-I6 for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 21:35:44 +0200 Received: from web5.emo.freenet-rz.de ([194.97.107.218]:45849) by mx4.freenet.de with esmtpa (ID perox@freenet.de) (port 587) (Exim 4.80.1 #4) id 1V0zQ0-0001HJ-Dd for freebsd-stable@freebsd.org; Sun, 21 Jul 2013 21:35:44 +0200 Received: from localhost ([127.0.0.1] helo=emo.freenet.de) by web5.emo.freenet-rz.de with esmtpa (Exim 4.72 1 (Panther_1)) id 1V0zQ0-0007Jq-7r for ; Sun, 21 Jul 2013 21:35:44 +0200 Date: Sun, 21 Jul 2013 21:35:44 +0200 Received: from [91.19.40.150] by web5.emo.freenet-rz.de with http; Sun, 21 Jul 2013 21:35:44 +0200 From: perox@freenet.de Subject: Re: Problem entering GELI password at boot To: freebsd-stable@freebsd.org X-Priority: 3 MIME-Version: 1.0 X-Abuse: 500871696 / 91.19.40.150 Message-Id: <91f6258d508c555e0ac72e40c3486045@email.freenet.de> User-Agent: freenetMail Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 19:38:41 -0000 VGhpcyB3ZWJtYWlsIGNyYXAga2VlcHMgdHJ1bmNhdGluZyBteSBtYWlscy4gSSBob3BlIHRoaXMg dGltZSBpdCdsbCB3b3JrLi4uDQoNCkkgY2Fubm90IHNheSB3aXRoIGNlcnRhaW50eSB0aGF0IHRo ZSBwcm9ibGVtIGlzIHJlbGF0ZWQgdG8gdGhlIDguMCB0aGluZyBidXQgaXQgc3VyZSBmZWVscyBs aWtlIGl0LiBBdCBsZWFzdA0KYWNjb3JkaW5nIHRvIHN1YnZlcnNpb24gdGhlIEdFTEkgY29kZSBp biAtU1RBQkxFIGhhc24ndCBiZWVuIGNoYW5nZWQgZm9yIG92ZXIgMTIgbW9udGhzIG5vdy4gVGhl cmVmb3JlIEkNCmFzc3VtZSwgR0VMSSBpcyBub3QgdG8gYmxhbWUuDQpUaGUgdGhpbmcgd2l0aCBt eSBzeXN0ZW0gaXMgdGhhdCBpdCBvbmx5IGFsbG93cyBhIFVTQiBrZXlib2FyZCwgaGVuY2UgSSBj YW5ub3QgYWNjZXNzIGFueXRoaW5nIGN1cnJlbnRseQ0Kd2hpY2ggcmVuZGVycyB0aGUgcHJvYmxl bSByYXRoZXIgc2V2ZXJlIGZvciBtZS4gSSwgdG9vLCByZWNhbGwgdGhhdCB0aGUgb2xkICg4LjAp IHByb2JsZW0gd2FzIHJlbGF0ZWQgdG8NCmludGVycnVwdHMgc3Rvcm1zIGR1ZSB0byBmYXVsdHko PykgQUhDSSBjb2RlL2hhcmR3YXJlLiBTaW5jZSB0aGVuLCBJIGtlZXAgQUhDSSBkaXNhYmxlZCBv biBteSBzeXN0ZW0gc28gdGhpcw0KY2FuJ3QgYmUgdGhlIGNhdXNlIHRoaXMgdGltZS4NCg0KDQoN Cg0KDQoNCg0KCgotLS0KQWxsZSBQb3N0ZsOkY2hlciBhbiBlaW5lbSBPcnQuIEpldHp0IHdlY2hz ZWxuIHVuZCBFLU1haWwtQWRyZXNzZSBtaXRuZWhtZW4hIGh0dHA6Ly9lbWFpbC5mcmVlbmV0LmRl L2Jhc2ljL0luZm9ybWF0aW9uZW4K From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 22:25:23 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2F19146; Sun, 21 Jul 2013 22:25:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF197A1; Sun, 21 Jul 2013 22:25:22 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-143-198.lns20.adl6.internode.on.net [118.210.143.198]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r6LMP4U9059507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 07:55:10 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Trouble building release with docs Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Mon, 22 Jul 2013 07:55:03 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <536E44AB-D485-492E-86AD-987B3018DDD0@gsoft.com.au> References: <20130721064931.GB2344@glenbarber.us> <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> <20130721075043.GE2344@glenbarber.us> To: Warren Block X-Mailer: Apple Mail (2.1508) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Glen Barber , freebsd-doc@FreeBSD.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 22:25:23 -0000 On 21/07/2013, at 23:56, Warren Block wrote: >>> So, if I rebuild with 9.2 checked out will the docs build? >>>=20 >>=20 >> Yes. >=20 > Depending on the use, just downloading the built documents from = ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/ could be more = effective. I can build /usr/doc OK, I am having trouble building = /usr/src/release/doc. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 22:28:56 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 73D24371; Sun, 21 Jul 2013 22:28:56 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1267CE; Sun, 21 Jul 2013 22:28:56 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 1125777ED; Sun, 21 Jul 2013 22:28:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 1125777ED Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 21 Jul 2013 18:28:53 -0400 From: Glen Barber To: Daniel O'Connor Subject: Re: Trouble building release with docs Message-ID: <20130721222853.GM2344@glenbarber.us> References: <20130721064931.GB2344@glenbarber.us> <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> <20130721075043.GE2344@glenbarber.us> <536E44AB-D485-492E-86AD-987B3018DDD0@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dzI2QqkSBOAresgT" Content-Disposition: inline In-Reply-To: <536E44AB-D485-492E-86AD-987B3018DDD0@gsoft.com.au> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , freebsd-doc@FreeBSD.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 22:28:56 -0000 --dzI2QqkSBOAresgT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 07:55:03AM +0930, Daniel O'Connor wrote: >=20 > On 21/07/2013, at 23:56, Warren Block wrote: > >>> So, if I rebuild with 9.2 checked out will the docs build? > >>>=20 > >>=20 > >> Yes. > >=20 > > Depending on the use, just downloading the built documents from > > ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/ could be > > more effective. >=20 >=20 > I can build /usr/doc OK, I am having trouble building /usr/src/release/do= c. >=20 doc/ build as of at least r253470 is fine for stable/9 branch. Are you saying you are still having a problem? Glen --dzI2QqkSBOAresgT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR7GClAAoJEFJPDDeguUajl/QIAK4oiEd4GSTxHJQ/SK9YZJU1 OLH/bh5KOp+J8m/2ChYPHJF1ULPgO0bxaADZQg5r+3lEjXjpJHOoPKW9Kon/4//8 ucLzd+C5HAYagsFSzSCZ9bEo5hrTvbNbr+5RqnZizNsgGNaI7k8idkRhRfpCJ/eA ovgTcpm1kAT60fmlwpM5Ccs4ecp/pj4usSaD9rIGwsfEhpSapIQsiFc8RFJQz6vG BZKWp3LDEDh5jpxeZRtWf9lZs5YmdhGwtdE4Q0FhqdZx09sLdtajCXc9I6q0ZXP+ 2pJJBEFKBZbUkaBMN7um+QIR/6H5dmsOrEoWavprhBNiaMnk7kRUt2+IrgML4Eg= =6AJs -----END PGP SIGNATURE----- --dzI2QqkSBOAresgT-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 21 23:25:46 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5666EC63; Sun, 21 Jul 2013 23:25:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id B7563927; Sun, 21 Jul 2013 23:25:45 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-143-198.lns20.adl6.internode.on.net [118.210.143.198]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r6LNPUVq062338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 08:55:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Trouble building release with docs Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7E375154-DCC5-43AD-84A2-79B0E48646FC"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: <20130721222853.GM2344@glenbarber.us> Date: Mon, 22 Jul 2013 08:55:28 +0930 Message-Id: <26085B56-30C6-4589-AFEF-5AE11AC1CFEB@gsoft.com.au> References: <20130721064931.GB2344@glenbarber.us> <677C5665-5530-44F7-B4DB-A150B7EAB172@gsoft.com.au> <20130721075043.GE2344@glenbarber.us> <536E44AB-D485-492E-86AD-987B3018DDD0@gsoft.com.au> <20130721222853.GM2344@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1508) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Warren Block , freebsd-doc@FreeBSD.org, freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Jul 2013 23:25:46 -0000 --Apple-Mail=_7E375154-DCC5-43AD-84A2-79B0E48646FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22/07/2013, at 7:58, Glen Barber wrote: > On Mon, Jul 22, 2013 at 07:55:03AM +0930, Daniel O'Connor wrote: >>=20 >> On 21/07/2013, at 23:56, Warren Block wrote: >>>>> So, if I rebuild with 9.2 checked out will the docs build? >>>>>=20 >>>>=20 >>>> Yes. >>>=20 >>> Depending on the use, just downloading the built documents from >>> ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/ could be >>> more effective. >>=20 >>=20 >> I can build /usr/doc OK, I am having trouble building = /usr/src/release/doc. >>=20 >=20 > doc/ build as of at least r253470 is fine for stable/9 branch. Are = you > saying you are still having a problem? No, it builds now (after I checked out r253470). Sorry for the = confusion. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_7E375154-DCC5-43AD-84A2-79B0E48646FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iD8DBQFR7G3q5ZPcIHs/zowRAmvUAKCSdvN1kOMTnxckgVoFbS26iJ4njACfetgi 2i9deeZMdVxNkcfNN08DbEE= =I/ns -----END PGP SIGNATURE----- --Apple-Mail=_7E375154-DCC5-43AD-84A2-79B0E48646FC-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 08:04:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65E3E14D for ; Mon, 22 Jul 2013 08:04:23 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 196FB2801 for ; Mon, 22 Jul 2013 08:04:22 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.norma.com [192.168.7.159] (may be forged)) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r6M84J2R072332 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 22 Jul 2013 14:04:19 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <51ECE783.8050207@norma.perm.ru> Date: Mon, 22 Jul 2013 14:04:19 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130709 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable stable Subject: zpool on a zvol inside zpool Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 22 Jul 2013 14:04:19 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 08:04:23 -0000 Hi. I'm moving some of my geli installation to a new machine. On an old machine it was running UFS. I use ZFS on a new machine, but I don't have an encrypted main pool (and I don't want to), so I'm kinda considering a way where I will make a zpool on a zvol encrypted by geli. Would it be completely insane (should I use UFS instead ?) or would it be still valid ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 09:50:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3001FC50 for ; Mon, 22 Jul 2013 09:50:32 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id EC3222EF2 for ; Mon, 22 Jul 2013 09:50:31 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 701968625C for ; Mon, 22 Jul 2013 11:50:24 +0200 (CEST) Message-ID: <51ED0060.2050502@bsdforen.de> Date: Mon, 22 Jul 2013 11:50:24 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: stopping amd causes a freeze Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 09:50:32 -0000 Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. # uname -a FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r253413: Wed Jul 17 13:12:46 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-91/amd64/usr/src/sys/HP6510b-91 amd64 That's amd's starting message: Jul 22 11:32:28 mobileKamikaze amd[8176]/info: no logfile defined; using stderr Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AM-UTILS VERSION INFORMATION: Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1997-2006 Erez Zadok Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 Jan-Simon Pendry Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 Imperial College of Science, Technology & Medicine Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 The Regents of the University of California. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: am-utils version 6.1.5 (build 901505). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Report bugs to https://bugzilla.am-utils.org/ or am-utils@am-utils.org. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Configured by David O'Brien on date 4-December-2007 PST. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Built by root@mobileKamikaze.norad. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: cpu=amd64 (little-endian), arch=amd64, karch=amd64. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: full_os=freebsd9.2, os=freebsd9, osver=9.2, vendor=undermydesk, distro=The FreeBSD Project. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: domain=norad, host=mobileKamikaze, hostd=mobileKamikaze.norad. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Map support for: root, passwd, union, nis, ndbm, file, exec, error. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, ufs, cdfs, Jul 22 11:32:28 mobileKamikaze amd[8176]/info: pcfs, auto, direct, toplvl, error, inherit. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: FS: cd9660, nfs, nfs3, nullfs, msdosfs, ufs, unionfs. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 1: wire="192.168.1.0" (netnumber=192.168.1). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 2: wire="192.168.0.0" (netnumber=192.168). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: My ip addr is 127.0.0.1 amd is called with the flags -r -p -a -c 4 -w 2 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 10:07:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14ECF1AE for ; Mon, 22 Jul 2013 10:07:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F8532043 for ; Mon, 22 Jul 2013 10:07:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6MA7KGu050719; Mon, 22 Jul 2013 13:07:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6MA7KGu050719 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6MA7KUU050718; Mon, 22 Jul 2013 13:07:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 Jul 2013 13:07:20 +0300 From: Konstantin Belousov To: Dominic Fandrey Subject: Re: stopping amd causes a freeze Message-ID: <20130722100720.GI5991@kib.kiev.ua> References: <51ED0060.2050502@bsdforen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EYAXRszTzQPG7bQS" Content-Disposition: inline In-Reply-To: <51ED0060.2050502@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 10:07:31 -0000 --EYAXRszTzQPG7bQS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: > Occasionally stopping amd freezes my system. It's a rare occurrence, > and I haven't found a reliable way to reproduce it. >=20 > It's also a real freeze, so there's no way to get into the debugger > or grab a core dump. I only can perform the 4 seconds hard shutdown to > revive the system. >=20 > I run amd through sysutils/automounter, which is a scripting solution > that generates an amd.map file based on encountered devices and devd > events. The SIGHUP it sends to amd to tell it the map file was updated > does not cause problems, only a SIGKILL may cause the freeze. >=20 > Nothing was mounted (by amd) during the last freeze. >=20 > I don't see any angle to tackle this, but I'm throwing it out here > any way, in the hopes that someone actually has an idea how to approach > the issue. Are you sure that the machine did not paniced ? Do you have serial console= ? The amd(8) locks itself into memory, most likely due to the fear of deadlock. There are some known issues with user wirings in stable/9. If the problem you see is indeed due to wiring, you might try to apply r253187-r253191. --EYAXRszTzQPG7bQS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7QRXAAoJEJDCuSvBvK1BQGMP/Re0zPwC0wsnZSu09NzjaX4W BgoABPormA5xG3gNCfHpmfZ0VqGCwRF0yi5ZQaVjZtiDYv2Xh1bs4DC+rIezAOjY pCy0eb44/ewYaSjNLctran9IGYsFY5lCdONmEHbJ1D6VAWjrjABUuZVHCfn0+cl9 rZ5q3bIcr2C4sUEOC3x8krDjMOdgFbMtEcyqnQ4Lc5qig79EANFNWQss+xWUlswE +fww+VJDbV8UzXS1bTTTCUE556Qp7BAG4vhcAbdhw/RtWfQHdh+XzQgFYvBIBgf7 fEu9BDrx84bQYKvnb+dOVrrNGEvnKHL4lGwpK3Y1xKslkl93eUVJAoOgHCBSFVYj 73let6+uxfsRTKDfaYHPwEJx4+RiWh1WYM7jAqY6OzVZvLV28rHHp0wD3BdNfNW1 3ELwT8mHbQr9BnMeh/KENJVaZQzlGCY+r/PKUSFbdUNxJ+1LPiuRBvSR9qZAjubb NSRKFnnRvhRCC5S87JbUlQP/pjKBog+OdZVl5lI5/L97PKkwCPZHa8IWcsl9g66S F9SE58S4GrbMYDshjhfILHeMJNJ8RtX5Hy8t0GGDtqsKxbfuW55Y266vi4SckSVr jRr3cohy7hC8RCQivKD7IBMq+Meev8SRsvwX234LM+csCm5Bv1GPNS0yAkPof5Jr bpe2WGacwtgoivpgMrSs =tgeZ -----END PGP SIGNATURE----- --EYAXRszTzQPG7bQS-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 10:24:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 04C83713 for ; Mon, 22 Jul 2013 10:24:24 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm25-vm5.bullet.mail.ird.yahoo.com (nm25-vm5.bullet.mail.ird.yahoo.com [212.82.109.206]) by mx1.freebsd.org (Postfix) with SMTP id 2978821B0 for ; Mon, 22 Jul 2013 10:24:22 +0000 (UTC) Received: from [77.238.189.55] by nm25.bullet.mail.ird.yahoo.com with NNFMP; 22 Jul 2013 10:24:16 -0000 Received: from [46.228.39.95] by tm8.bullet.mail.ird.yahoo.com with NNFMP; 22 Jul 2013 10:24:16 -0000 Received: from [127.0.0.1] by smtp132.mail.ir2.yahoo.com with NNFMP; 22 Jul 2013 10:24:16 -0000 X-Yahoo-Newman-Id: 510309.67761.bm@smtp132.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SsYkqsIVM1kOgeTNsHe4vjTjkWSj5MLqfQQCnuqDpQeN6p4 XUQHOBiv0kQZF48.XCZc2aZlxtQGxRAi1fjVGzILsPXNvGnylTP5Nu1Re8oi svj20jNHKMJ8UKXE3vZ05qaFWTMr0f.rvyDJV1dnUXitMm.l9Cw_8NhH5MD6 Zrx7Au_FKVI0RF5RfDA9fDy3qZzYQxJtVb2JdBRRyxXXbg7jGkuPq1sl_S6I pVMBWfCOEgs.O4mHP.ciAwjnUqlZPeE95TWpYA6DyyQVMGFqHUW8NplxqONS RAwmo7ZWatnbOyIndjvZDdzzA8XORAWodghDGAb6EmQzR0_667MYAAbZG0E0 rh2R5ys06M5J1yApz8WmsqUn.hNTT_VGXKLltTVm0fL1x0qAOQg8FBe3gLaR 4ob8bmGMbq.aTyEkhgg0h3_vDdmz6aDO1RPZML7yn.i6vLKIhnoJKZ82I1Xs GCN4Hal2SUliwK4lqH8rp5rdoSTArYrk5skUWaOn.ApihWr8hNNaOWQ_4Vba CBrM- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.26] (se@84.149.244.111 with ) by smtp132.mail.ir2.yahoo.com with SMTP; 22 Jul 2013 10:24:16 +0000 UTC Message-ID: <51ED084D.1050308@freebsd.org> Date: Mon, 22 Jul 2013 12:24:13 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eugene M. Zheganin" Subject: Re: zpool on a zvol inside zpool References: <51ECE783.8050207@norma.perm.ru> In-Reply-To: <51ECE783.8050207@norma.perm.ru> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 10:24:24 -0000 Am 22.07.2013 10:04, schrieb Eugene M. Zheganin: > Hi. > > I'm moving some of my geli installation to a new machine. On an old > machine it was running UFS. I use ZFS on a new machine, but I don't have > an encrypted main pool (and I don't want to), so I'm kinda considering a > way where I will make a zpool on a zvol encrypted by geli. Would it be > completely insane (should I use UFS instead ?) or would it be still > valid ? I have configured a system in just that way, a few weeks ago. It seems to work just fine. This is a workgroup server for a small company, which is meant to provide secure storage for documents. The system has a separate boot/root pool and a large pool for data (both as ZFS mirrors). On the data pool there is a ZVOL which is GELI encrypted to provide a "disk" for the encrypted ZFS that holds the documents. The system is running headless in some datacenter. It must boot multi-user and start a SSHD for remote entry of the passphrase, therefore solutions where a GELI key is on a USB key or entered via a console during boot were not possible. Performance is reasonable and far exceeds the 100Mbit/s Ethernet port ordered in the data-center, so I did not bother to measure throughput of this ZFS on GELI encrypted ZPOOL. For low load scenarios, this seems to be the easiest configuration. If you have hardware crypto or expect high load, then a ZFS mirror of GELI encrypted disks may show better performance, though. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 11:06:52 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8992B4A5 for ; Mon, 22 Jul 2013 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EBD424B0 for ; Mon, 22 Jul 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6MB6qC6053842 for ; Mon, 22 Jul 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6MB6paX053840 for freebsd-stable@FreeBSD.org; Mon, 22 Jul 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jul 2013 11:06:51 GMT Message-Id: <201307221106.r6MB6paX053840@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-stable@FreeBSD.org Subject: Current problem reports assigned to freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/179112 stable 9.1 installer panics with a kmem_malloc() failure on i 1 problem total. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 12:19:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61C022BA for ; Mon, 22 Jul 2013 12:19:49 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 26DE82A81 for ; Mon, 22 Jul 2013 12:19:48 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id C26AE7E8CB; Mon, 22 Jul 2013 14:19:44 +0200 (CEST) Message-ID: <51ED2360.2060104@bsdforen.de> Date: Mon, 22 Jul 2013 14:19:44 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> In-Reply-To: <20130722100720.GI5991@kib.kiev.ua> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 12:19:49 -0000 On 22/07/2013 12:07, Konstantin Belousov wrote: > On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: >> Occasionally stopping amd freezes my system. It's a rare occurrence, >> and I haven't found a reliable way to reproduce it. >> >> It's also a real freeze, so there's no way to get into the debugger >> or grab a core dump. I only can perform the 4 seconds hard shutdown to >> revive the system. >> >> I run amd through sysutils/automounter, which is a scripting solution >> that generates an amd.map file based on encountered devices and devd >> events. The SIGHUP it sends to amd to tell it the map file was updated >> does not cause problems, only a SIGKILL may cause the freeze. >> >> Nothing was mounted (by amd) during the last freeze. >> >> I don't see any angle to tackle this, but I'm throwing it out here >> any way, in the hopes that someone actually has an idea how to approach >> the issue. > > Are you sure that the machine did not paniced ? Do you have serial console ? No, I don't have one. All that I can tell is that everything freezes (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a reaction. And the system doesn't respond to ICMP queries. > The amd(8) locks itself into memory, most likely due to the fear of > deadlock. There are some known issues with user wirings in stable/9. > If the problem you see is indeed due to wiring, you might try to apply > r253187-r253191. >From head? That may be worth a try. It would be better for testing if I managed to reproduce the problem reliably, before I test patches. I see it's scheduled for MFC, soon. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 12:35:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE7408BC for ; Mon, 22 Jul 2013 12:35:50 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 715762B71 for ; Mon, 22 Jul 2013 12:35:50 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V1FL3-0000Ab-Eu; Mon, 22 Jul 2013 14:35:41 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V1FL3-00064T-RE; Mon, 22 Jul 2013 14:35:41 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Konstantin Belousov" , "Dominic Fandrey" Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51ED2360.2060104@bsdforen.de> Date: Mon, 22 Jul 2013 14:35:37 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <51ED2360.2060104@bsdforen.de> User-Agent: Opera Mail/12.16 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: ba572e8a3bde05b4b19613c12a9e49fc Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 12:35:50 -0000 On Mon, 22 Jul 2013 14:19:44 +0200, Dominic Fandrey wrote: > On 22/07/2013 12:07, Konstantin Belousov wrote: >> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: >>> Occasionally stopping amd freezes my system. It's a rare occurrence, >>> and I haven't found a reliable way to reproduce it. >>> >>> It's also a real freeze, so there's no way to get into the debugger >>> or grab a core dump. I only can perform the 4 seconds hard shutdown to >>> revive the system. >>> >>> I run amd through sysutils/automounter, which is a scripting solution >>> that generates an amd.map file based on encountered devices and devd >>> events. The SIGHUP it sends to amd to tell it the map file was updated >>> does not cause problems, only a SIGKILL may cause the freeze. >>> >>> Nothing was mounted (by amd) during the last freeze. >>> >>> I don't see any angle to tackle this, but I'm throwing it out here >>> any way, in the hopes that someone actually has an idea how to approach >>> the issue. >> >> Are you sure that the machine did not paniced ? Do you have serial >> console ? > > No, I don't have one. All that I can tell is that everything freezes > (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a > reaction. And the system doesn't respond to ICMP queries. > >> The amd(8) locks itself into memory, most likely due to the fear of >> deadlock. There are some known issues with user wirings in stable/9. >> If the problem you see is indeed due to wiring, you might try to apply >> r253187-r253191. > > From head? That may be worth a try. It would be better for testing if I > managed to reproduce the problem reliably, before I test patches. > > I see it's scheduled for MFC, soon. > Did you try a run with the INVARIANTS, etc. options in the kernel? That enables more sanity checking for locks which is too slow for production. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 12:42:05 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E53EEB56; Mon, 22 Jul 2013 12:42:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A24502BCB; Mon, 22 Jul 2013 12:42:04 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6AA467504; Mon, 22 Jul 2013 12:42:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 6AA467504 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 22 Jul 2013 08:42:01 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 9.2-BETA1 now available Message-ID: <20130722124201.GP2265@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OmL7C/BU0IhhC9Of" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 12:42:05 -0000 --OmL7C/BU0IhhC9Of Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The first BETA build of the 9.2-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and ia64 architectures. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.2/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use "stable/9". Please be aware that cvsup and CVS are both deprecated, and are not supported methods of updating the src/ tree. Important note to freebsd-update(8) users: Due to a last minute problem found in the 9.2-BETA1 freebsd-update(8) builds, freebsd-update(8) is NOT supported for 9.2-BETA1 upgrades. Please do not use freebsd-update(8) to upgrade to 9.2-BETA1. Checksums: amd64: SHA256 (FreeBSD-9.2-BETA1-amd64-bootonly.iso) = b458c7080d9b8938e50def7c4ee296fda656ad41a25b41af05963872733bd550 SHA256 (FreeBSD-9.2-BETA1-amd64-disc1.iso) = 4593581e7e3dc066170ed4f5f228082317f7284737e5834e1d0c2da2d58c4532 SHA256 (FreeBSD-9.2-BETA1-amd64-memstick.img) = 6cff61f5d6074286757d6f8f0160c051f15c1e970f7ff9187603afad92993a84 MD5 (FreeBSD-9.2-BETA1-amd64-bootonly.iso) = 504f8709da876df27388c2bac1eeb1e1 MD5 (FreeBSD-9.2-BETA1-amd64-disc1.iso) = 06b2150ba9c83496acb74e7b15392f41 MD5 (FreeBSD-9.2-BETA1-amd64-memstick.img) = a308cfb3d409a6806e974e5394e9740f i386: SHA256 (FreeBSD-9.2-BETA1-i386-bootonly.iso) = ae8393fdeea97be1abe29a3119349360b1c1f896a736b715c256b0e59972bbb1 SHA256 (FreeBSD-9.2-BETA1-i386-disc1.iso) = 3eff3de4f245237970b743bbc85eaa4f6ce65d7ecbe9d5b96f2e19c11e9f0e81 SHA256 (FreeBSD-9.2-BETA1-i386-memstick.img) = a934ded850fba472a10b2e869a02d717a041a6771398958e82400dcb6c0bd6d7 MD5 (FreeBSD-9.2-BETA1-i386-bootonly.iso) = 58f6be4a3edb9235bf81cef4bb9d0a8e MD5 (FreeBSD-9.2-BETA1-i386-disc1.iso) = aac3a0ad51a9cc4b5f003616effd73f5 MD5 (FreeBSD-9.2-BETA1-i386-memstick.img) = e0d8c8139dcf1eae1eb6a33d58c4dd7f ia64: SHA256 (FreeBSD-9.2-BETA1-ia64-bootonly.iso) = 88b3350e4bbd522855029b4ece284a5ffb363be098c7d08d9b4006917e4474a4 SHA256 (FreeBSD-9.2-BETA1-ia64-disc1.iso) = fd401b1f7f9bf301a72d2bd03c8a83d6aa5d1f2e037370968ca6af0577e7d9b4 SHA256 (FreeBSD-9.2-BETA1-ia64-memstick.img) = dac5a9f712cb46fffcfd2f8db7fe4e50848f5401a9b9841cf8e533a7996350d3 MD5 (FreeBSD-9.2-BETA1-ia64-bootonly.iso) = fb1e4d7ce557b22564bb788d5bd0540f MD5 (FreeBSD-9.2-BETA1-ia64-disc1.iso) = b1fbe310909e5c6f9bb8315b24a7f00b MD5 (FreeBSD-9.2-BETA1-ia64-memstick.img) = a71c2ef0f5ccfe6b3f015f1a79129ad4 Glen --OmL7C/BU0IhhC9Of Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR7SiZAAoJEFJPDDeguUajVZQH/1SEdRGeJCIj0b58njAtzxRl Cs9s15f0xYX6OXFwKrChvWaOw5F5lfLuIupxaho06xG3fYZ/n3j8Jskx3b11bitD aKW7n1mIZFlsbfospeT0g9VEJW8JA/iWcu7Z5F5dZ0+Fw7Y8n7+tDF9l04Ql0o7S JSTxyOFV52DYNxxaiS1Y6p7ykAbxkvnA/5JzdoaSfuCYf2vQOUKcQxuXlyvLPg19 JPlALiqaC1RFUVIeeZhvkonEkqY3cN7lyHsqXoHPw263HFaMeHU1PgCtFqEFdtNz vxkeCJ3pplx4teSL3WjLPuqCRsjdZFWJF86sIAhKJUdzxWKHazlRwvzv1a6VYZs= =dj7b -----END PGP SIGNATURE----- --OmL7C/BU0IhhC9Of-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 12:58:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F579351 for ; Mon, 22 Jul 2013 12:58:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 446E12C96 for ; Mon, 22 Jul 2013 12:58:57 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 4878686219; Mon, 22 Jul 2013 14:58:55 +0200 (CEST) Message-ID: <51ED2C8F.7040009@bsdforen.de> Date: Mon, 22 Jul 2013 14:58:55 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Ronald Klop Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51ED2360.2060104@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 12:58:57 -0000 On 22/07/2013 14:35, Ronald Klop wrote: > On Mon, 22 Jul 2013 14:19:44 +0200, Dominic Fandrey wrote: > >> On 22/07/2013 12:07, Konstantin Belousov wrote: >>> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: >>>> Occasionally stopping amd freezes my system. It's a rare occurrence, >>>> and I haven't found a reliable way to reproduce it. >>>> >>>> It's also a real freeze, so there's no way to get into the debugger >>>> or grab a core dump. I only can perform the 4 seconds hard shutdown to >>>> revive the system. >>>> >>>> I run amd through sysutils/automounter, which is a scripting solution >>>> that generates an amd.map file based on encountered devices and devd >>>> events. The SIGHUP it sends to amd to tell it the map file was updated >>>> does not cause problems, only a SIGKILL may cause the freeze. >>>> >>>> Nothing was mounted (by amd) during the last freeze. >>>> >>>> I don't see any angle to tackle this, but I'm throwing it out here >>>> any way, in the hopes that someone actually has an idea how to approach >>>> the issue. >>> >>> Are you sure that the machine did not paniced ? Do you have serial console ? >> >> No, I don't have one. All that I can tell is that everything freezes >> (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a >> reaction. And the system doesn't respond to ICMP queries. >> >>> The amd(8) locks itself into memory, most likely due to the fear of >>> deadlock. There are some known issues with user wirings in stable/9. >>> If the problem you see is indeed due to wiring, you might try to apply >>> r253187-r253191. >> >> From head? That may be worth a try. It would be better for testing if I >> managed to reproduce the problem reliably, before I test patches. >> >> I see it's scheduled for MFC, soon. >> > > Did you try a run with the INVARIANTS, etc. options in the kernel? That enables more sanity checking for locks which is too slow for production. No I didn't, but I managed to reproduce it in combination with heavy tmpfs load. So now I've got a working test case and will be able to determine whether the suggested fix works. I suppose INVARIANTS would be the next step. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 13:57:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7658986D; Mon, 22 Jul 2013 13:57:12 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by mx1.freebsd.org (Postfix) with ESMTP id 822372FD4; Mon, 22 Jul 2013 13:57:11 +0000 (UTC) Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail06.adl6.internode.on.net with ESMTP; 22 Jul 2013 23:27:09 +0930 Message-ID: <51ED3A32.2090604@ShaneWare.Biz> Date: Mon, 22 Jul 2013 23:27:06 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130516 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stefan Esser Subject: Re: zpool on a zvol inside zpool References: <51ECE783.8050207@norma.perm.ru> <51ED084D.1050308@freebsd.org> In-Reply-To: <51ED084D.1050308@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Eugene M. Zheganin" , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 13:57:12 -0000 On 22/07/2013 19:54, Stefan Esser wrote: > Am 22.07.2013 10:04, schrieb Eugene M. Zheganin: >> Hi. >> >> I will make a zpool on a zvol encrypted by geli. > > I have configured a system in just that way, a few weeks ago. > It seems to work just fine. It sounds like a fix may exist in head but if you want to use snapshots you may want to read kern/161968 first From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 14:22:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C470219 for ; Mon, 22 Jul 2013 14:22:20 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [176.9.9.186]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF0452139 for ; Mon, 22 Jul 2013 14:22:19 +0000 (UTC) Received: from [192.168.18.53] (cpe.atm4-0-1301038.hknxx5.dk.customer.tdc.net [80.160.242.134]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id A1B69182062; Mon, 22 Jul 2013 16:22:08 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.5.2 mail.tyknet.dk A1B69182062 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1374502931; bh=co8ibrHWK4zwAS03YFHVEST4Pq7IQ/c5k3hsGniH2jA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=PxgI/+MifDZCLszZPqk6sYCYUXKLwFSzGuMyatoOm1/9k+pSq8y98PDYnus1rNegx 0CxpBc3HjoK4AQZ4Ri9kRxIrV24JDKLijmmjrhj82CEzZy3ZZP084fCY2qbhvuZlFi xC/jVNC5Yn4o5VrDSkXkPS9ow42y+lPMZfvPHSLE= Message-ID: <51ED400A.1080507@gibfest.dk> Date: Mon, 22 Jul 2013 16:22:02 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eugene M. Zheganin" Subject: Re: zpool on a zvol inside zpool References: <51ECE783.8050207@norma.perm.ru> In-Reply-To: <51ECE783.8050207@norma.perm.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 14:22:20 -0000 On 22-07-2013 10:04, Eugene M. Zheganin wrote: > Hi. > > I'm moving some of my geli installation to a new machine. On an old > machine it was running UFS. I use ZFS on a new machine, but I don't have > an encrypted main pool (and I don't want to), so I'm kinda considering a > way where I will make a zpool on a zvol encrypted by geli. Would it be > completely insane (should I use UFS instead ?) or would it be still > valid ? Hello, I've used this setup for a while on several servers, it works but it is slow. I am migrating my servers to have two zpools instead, a small one with the base system and nothing else, the other one on top of a geli device. This performs much better and is IMO a better solution. YMMV :) I have this method documented on my wiki here: http://wiki.tyk.nu/index.php?title=Ezjail_host#Further_disk_configuration Best regards, Thomas Steen Rasmussen From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 14:30:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61B5CA31; Mon, 22 Jul 2013 14:30:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31AA921BA; Mon, 22 Jul 2013 14:30:36 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id w11so6817515pde.23 for ; Mon, 22 Jul 2013 07:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=9XxWkVPd6fDXbvPO/INfpwth5IfMmz7zGtzAg/3wDt0=; b=RRhcgt4m1cSaW8S2r6SR/VGumOpgsIt56v+VnQ3vTNMDBRLTS9chbLpu7RV/RJUuF1 E4HWe6smLZL3Ds6N36E20QtqUveDHXg5MW/iBNUuvDwYdHmv6b4K+k/LkAVMuaHkP9Fi X//OiAV41YgX3UxKGBeHYu6v4zQxtUf/vPIarPZB87nr0yowcwPWdftvBWIcsUINNRoK 0xfuLI233ycIRZTuMPKfVOnh42hmq0KUaCRFlOujGYTc36P3CNefBtV6bp0pw7Q0buuk BqWY0DyLpU9oQD72eJQxElwORsvH0hE/5fwd4i5YXggM1BXhz1CjObwLhx466AsHonKy Nw2Q== X-Received: by 10.68.211.233 with SMTP id nf9mr28509074pbc.26.1374503435840; Mon, 22 Jul 2013 07:30:35 -0700 (PDT) Received: from [192.168.20.5] (c-98-203-241-95.hsd1.wa.comcast.net. [98.203.241.95]) by mx.google.com with ESMTPSA id e7sm23028461pbc.11.2013.07.22.07.30.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 07:30:35 -0700 (PDT) From: Garrett Cooper Content-Type: multipart/mixed; boundary="Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F" Subject: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 07:30:32 -0700 Message-Id: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> To: freebsd-fs@freebsd.org, freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 14:30:36 -0000 --Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a KERNCONF that previously had PS/2 support compiled into the = kernel. If I comment out the following lines like so: # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard then I'm able to mount root again (it was failing with ENOXDEV). The working kernel was as follows: $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 = gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-st= able-9/sys/BAYONETTA gcc version 4.2.1 20070831 patched [FreeBSD] FreeBSD 9.1-STABLE BAYONETTA $ cd /usr/src; git log 0304216 commit 03042167f73c213732b44218a24d8e1bbea00f8c Merge: 2edcad2 974abfb Author: Garrett Cooper Date: Mon Jun 24 19:00:45 2013 -0700 Merge remote-tracking branch 'upstream/stable/9' into stable/9 The working kernel [with atkbdc] was as follows: FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun = Jul 21 20:19:38 PDT 2013 = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 $ git log c178034 commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 Author: avg Date: Tue Jul 9 08:30:31 2013 +0000 zfsboottest.sh: remove checks for things that are not strictly = required =20 MFC after: 10 days (Yes, I had to backport some things because they are busted on stable/9 = due to other incomplete/missing MFCs). I can test out patches, but I don't have time to bisect the actual = commit that caused the failure. That being said my intuition says it's = this commit should be looked at first: commit 28f961058b0667841d7e9d8639bfd02ed8689faa Author: jhb Date: Wed Jul 17 14:04:18 2013 +0000 MFC 252576: Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. = If we are probing a PCI-PCI bridge it is because we found one by = enumerating the devices on a PCI bus, so the bridge is definitely present. A = few BIOSes report incorrect status (_STA) for some bridges that claimed = they were not present when in fact they were. =20 While here, move this check earlier for Host-PCI bridges so attach = fails before doing any work that needs to be torn down. =20 PR: kern/91594 Approved by: re (marius) More data spew follows. Thanks, -Garrett --Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F Content-Disposition: attachment; filename=diagnostic-noise.txt Content-Type: text/plain; x-unix-mode=0644; name="diagnostic-noise.txt" Content-Transfer-Encoding: quoted-printable hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x836b1043 = chip=3D0x34058086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub to ESI Port' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x836b1043 = chip=3D0x34088086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 1' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:3:0: class=3D0x060400 card=3D0x836b1043 = chip=3D0x340a8086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 3' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:7:0: class=3D0x060400 card=3D0x836b1043 = chip=3D0x340e8086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 7' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:20:0: class=3D0x080000 card=3D0x00000000 = chip=3D0x342e8086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub System Management Registers' class =3D base peripheral subclass =3D interrupt controller none1@pci0:0:20:1: class=3D0x080000 card=3D0x00000000 = chip=3D0x34228086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub GPIO and Scratch Pad = Registers' class =3D base peripheral subclass =3D interrupt controller none2@pci0:0:20:2: class=3D0x080000 card=3D0x00000000 = chip=3D0x34238086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub Control Status and RAS = Registers' class =3D base peripheral subclass =3D interrupt controller none3@pci0:0:20:3: class=3D0x080000 card=3D0x00000000 = chip=3D0x34388086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub Throttle Registers' class =3D base peripheral subclass =3D interrupt controller uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a378086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a388086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci2@pci0:0:26:2: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a398086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0x82d41043 = chip=3D0x3a3c8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB2 EHCI Controller' class =3D serial bus subclass =3D USB pcib6@pci0:0:28:0: class=3D0x060400 card=3D0x82ea1043 = chip=3D0x3a408086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) PCI Express Root Port 1' class =3D bridge subclass =3D PCI-PCI pcib7@pci0:0:28:1: class=3D0x060400 card=3D0x82ea1043 = chip=3D0x3a428086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) PCI Express Port 2' class =3D bridge subclass =3D PCI-PCI uhci3@pci0:0:29:0: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a348086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci4@pci0:0:29:1: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a358086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci5@pci0:0:29:2: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a368086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0x82d41043 = chip=3D0x3a3a8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB2 EHCI Controller' class =3D serial bus subclass =3D USB pcib8@pci0:0:30:0: class=3D0x060401 card=3D0x82d41043 = chip=3D0x244e8086 rev=3D0x90 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0x82d41043 = chip=3D0x3a168086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JIR (ICH10R) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA ahci0@pci0:0:31:2: class=3D0x010601 card=3D0x82d41043 = chip=3D0x3a228086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) SATA AHCI Controller' class =3D mass storage subclass =3D SATA ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x82d41043 = chip=3D0x3a308086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) SMBus Controller' class =3D serial bus subclass =3D SMBus pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x01251033 rev=3D0x06 hdr=3D0x01 vendor =3D 'NEC Corporation' device =3D 'uPD720400 PCI Express - PCI/PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:1:0:1: class=3D0x060400 card=3D0x00000000 = chip=3D0x01251033 rev=3D0x06 hdr=3D0x01 vendor =3D 'NEC Corporation' device =3D 'uPD720400 PCI Express - PCI/PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI mfi0@pci0:4:0:0: class=3D0x010400 card=3D0x92411000 = chip=3D0x00731000 rev=3D0x03 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'MegaRAID SAS 9240' class =3D mass storage subclass =3D RAID vgapci0@pci0:5:0:0: class=3D0x030000 card=3D0xc9543842 = chip=3D0x064010de rev=3D0xa1 hdr=3D0x00 vendor =3D 'nVidia Corporation' device =3D 'G96 [GeForce 9500 GT]' class =3D display subclass =3D VGA re0@pci0:6:0:0: class=3D0x020000 card=3D0x83671043 chip=3D0x816810ec = rev=3D0x02 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet = controller' class =3D network subclass =3D ethernet hostb1@pci0:255:0:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c418086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QuickPath Architecture Generic = Non-Core Registers' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:255:0:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c018086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QuickPath Architecture System = Address Decoder' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:255:2:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c108086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Link 0' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:255:2:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c118086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Physical 0' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:255:3:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c188086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:255:3:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c198086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Target Address Decoder' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:255:3:4: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c1c8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Test = Registers' class =3D bridge subclass =3D HOST-PCI hostb8@pci0:255:4:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c208086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb9@pci0:255:4:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c218086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb10@pci0:255:4:2: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c228086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb11@pci0:255:4:3: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c238086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI hostb12@pci0:255:5:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c288086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb13@pci0:255:5:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c298086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb14@pci0:255:5:2: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c2a8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb15@pci0:255:5:3: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c2b8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI hostb16@pci0:255:6:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c308086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb17@pci0:255:6:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c318086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb18@pci0:255:6:2: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c328086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb19@pci0:255:6:3: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c338086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI # dmidecode 2.11 SMBIOS 2.5 present. 77 structures occupying 2896 bytes. Table at 0x000F0700. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 1205 =20 Release Date: 09/24/2010 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 2048 kB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.15 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: System manufacturer Product Name: System Product Name Version: System Version Serial Number: System Serial Number UUID: 6069001E-8C00-00BD-6E33-E0CB4E01476B Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: To Be Filled By O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P6T WS PRO Version: Rev 1.xx Serial Number: 102642390000140 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: Chassis Manufacture Type: Desktop Lock: Not Present Version: Chassis Version Serial Number: Chassis Serial Number Asset Tag: Asset-1234567890 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000001 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 40 bytes Processor Information Socket Designation: LGA1366 Type: Central Processor Family: Xeon Manufacturer: Intel =20 ID: A5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 26, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz =20 Voltage: 1.2 V External Clock: 133 MHz Max Speed: 2666 MHz Current Speed: 2666 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 4 Core Enabled: 4 Thread Count: 8 Characteristics: 64-bit capable Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Parity System Type: Instruction Associativity: 4-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Through Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 8192 kB Maximum Size: 8192 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x0008, DMI type 5, 28 bytes Memory Controller Information Error Detecting Method: 64-bit ECC Error Correcting Capabilities: None Supported Interleave: One-way Interleave Current Interleave: One-way Interleave Maximum Memory Module Size: 4096 MB Maximum Total Memory Size: 24576 MB Supported Speeds: 70 ns 60 ns Supported Memory Types: DIMM SDRAM Memory Module Voltage: 3.3 V Associated Memory Slots: 6 0x0009 0x000A 0x000B 0x000C 0x000D 0x000E Enabled Error Correcting Capabilities: None Handle 0x0009, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM0 Bank Connections: 1 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000A, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM1 Bank Connections: 2 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000B, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM2 Bank Connections: 3 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000C, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM3 Bank Connections: 4 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000D, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM4 Bank Connections: 5 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000E, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM5 Bank Connections: 6 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: PS/2 Keyboard Internal Connector Type: None External Reference Designator: PS/2 Keyboard External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB12 Internal Connector Type: None External Reference Designator: USB12 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB34 Internal Connector Type: None External Reference Designator: USB34 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB56 Internal Connector Type: None External Reference Designator: USB56 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB78 Internal Connector Type: None External Reference Designator: USB78 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0014, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: IE1394_1 Internal Connector Type: None External Reference Designator: IEEE1394 1 External Connector Type: IEEE 1394 Port Type: Firewire (IEEE P1394) Handle 0x0015, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: ESATA Internal Connector Type: None External Reference Designator: ESATA External Connector Type: IEEE 1394 Port Type: SATA Handle 0x0016, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: LAN1 Internal Connector Type: None External Reference Designator: GbE LAN 1 External Connector Type: RJ-45 Port Type: Network Port Handle 0x0017, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: LAN2 Internal Connector Type: None External Reference Designator: GbE LAN 2 External Connector Type: RJ-45 Port Type: Network Port Handle 0x0018, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: AUDIO Internal Connector Type: None External Reference Designator: AUDIO External Connector Type: Other Port Type: Audio Port Handle 0x0019, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out1 Internal Connector Type: None External Reference Designator: Audio Line Out1 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out2 Internal Connector Type: None External Reference Designator: Audio Line Out2 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out3 Internal Connector Type: None External Reference Designator: Audio Line Out3 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out4 Internal Connector Type: None External Reference Designator: Audio Line Out4 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out5 Internal Connector Type: None External Reference Designator: Audio Line Out5 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out6 Internal Connector Type: None External Reference Designator: Audio Line Out6 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA1 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0020, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA2 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0021, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA3 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0022, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA4 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0023, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA5 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0024, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA6 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0025, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SAS1 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0026, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SAS2 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0027, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB9_10 Internal Connector Type: Access Bus (USB) External Reference Designator: Not Specified External Connector Type: None Port Type: USB Handle 0x0028, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB11_12 Internal Connector Type: Access Bus (USB) External Reference Designator: Not Specified External Connector Type: None Port Type: USB Handle 0x0029, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: IE1394_2 Internal Connector Type: IEEE 1394 External Reference Designator: Not Specified External Connector Type: None Port Type: Firewire (IEEE P1394) Handle 0x002A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CD Internal Connector Type: On Board Sound Input =46rom CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x002B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: AAFP Internal Connector Type: Mini Jack (headphones) External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x002C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CPU_FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x002D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: PWR_FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x002E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CHA_FAN1 Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x002F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CHA_FAN2 Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0030, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CHA_FAN3 Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0031, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SPDIF_OUT Internal Connector Type: On Board Sound Input =46rom CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0032, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: FP_AUDIO Internal Connector Type: On Board Sound Input =46rom CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0033, DMI type 9, 13 bytes System Slot Information Designation: PCIEX1_1 Type: 32-bit PCI Express Current Usage: Available Length: Short ID: 32 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0034, DMI type 9, 13 bytes System Slot Information Designation: PCIEX16_1 Type: 64-bit PCI Express Current Usage: In Use Length: Short ID: 51 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0035, DMI type 9, 13 bytes System Slot Information Designation: PCIX_1 Type: 32-bit PCI-X Current Usage: Available Length: Short ID: 6 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0036, DMI type 9, 13 bytes System Slot Information Designation: PCIX_2 Type: 32-bit PCI-X Current Usage: Available Length: Short ID: 7 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0037, DMI type 9, 13 bytes System Slot Information Designation: PCIEX16_2 Type: 32-bit PCI Express Current Usage: Available Length: Short ID: 55 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0038, DMI type 9, 13 bytes System Slot Information Designation: PCI_1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 3 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0039, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet Handle 0x003A, DMI type 11, 5 bytes OEM Strings String 1: To Be Filled By O.E.M. String 2: To Be Filled By O.E.M. String 3: To Be Filled By O.E.M. String 4: To Be Filled By O.E.M. Handle 0x003B, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Long Installable Languages: 6 en|US|iso8859-1 zh|ZH|iso8859-1 de|DE|iso8859-1 cn|CN|iso8859-1 fr|FR|iso8859-1 ja|JP|unicode-1 Currently Installed Language: en|US|iso8859-1 Handle 0x003C, DMI type 15, 55 bytes System Event Log Area Length: 1008 bytes Header Start Offset: 0x2010 Data Start Offset: 0x2010 Access Method: OEM-specific Access Address: Unknown Status: Valid, Not Full Change Token: 0x00000000 Header Format: No Header Supported Log Type Descriptors: 1 Descriptor 1: OEM-specific Data Format 1: POST results bitmap Handle 0x003D, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 24 GB Error Information Handle: Not Provided Number Of Devices: 6 Handle 0x003E, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Array Handle: 0x003D Partition Width: 1 Handle 0x003F, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM0 Bank Locator: BANK0 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer00 Serial Number: SerNum00 Asset Tag: AssetTagNum0 Part Number: ModulePartNumber00 Handle 0x0040, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x003F Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0041, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM1 Bank Locator: BANK1 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer01 Serial Number: SerNum01 Asset Tag: AssetTagNum1 Part Number: ModulePartNumber01 Handle 0x0042, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0041 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0043, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM2 Bank Locator: BANK2 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer02 Serial Number: SerNum02 Asset Tag: AssetTagNum2 Part Number: ModulePartNumber02 Handle 0x0044, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0043 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0045, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM3 Bank Locator: BANK3 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer03 Serial Number: SerNum03 Asset Tag: AssetTagNum3 Part Number: ModulePartNumber03 Handle 0x0046, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0045 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0047, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM4 Bank Locator: BANK4 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer04 Serial Number: SerNum04 Asset Tag: AssetTagNum4 Part Number: ModulePartNumber04 Handle 0x0048, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0047 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0049, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM5 Bank Locator: BANK5 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer05 Serial Number: SerNum05 Asset Tag: AssetTagNum5 Part Number: ModulePartNumber05 Handle 0x004A, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0049 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x004B, DMI type 32, 20 bytes System Boot Information Status: No errors detected Handle 0x004C, DMI type 127, 4 bytes End Of Table Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz (2672.78-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Family =3D 0x6 Model =3D = 0x1a Stepping =3D 5 = Features=3D0xbfebfbff = Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 12884901888 (12288 MB) avail memory =3D 12344569856 (11772 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <092410 APIC1941> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd0 at kbdmux0 acpi0: <092410 XSDT1941> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci3: on pcib2 pcib3: mem 0xf7effc00-0xf7effc7f irq 28 at device = 0.1 on pci1 pci2: on pcib3 pcib4: at device 3.0 on pci0 pci4: on pcib4 mfi0: port 0xc000-0xc0ff mem = 0xf7ffc000-0xf7ffffff,0xf7f80000-0xf7fbffff irq 24 at device 0.0 on pci4 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23=20 pcib5: at device 7.0 on pci0 pci5: on pcib5 vgapci0: port 0xdc00-0xdc7f mem = 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 30 = at device 0.0 on pci5 pci0: at device 20.0 (no driver = attached) pci0: at device 20.1 (no driver = attached) pci0: at device 20.2 (no driver = attached) pci0: at device 20.3 (no driver = attached) uhci0: port 0xb800-0xb81f = irq 16 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0xb880-0xb89f = irq 21 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0xbc00-0xbc1f = irq 19 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem = 0xf7dff000-0xf7dff3ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib6: irq 17 at device 28.0 on pci0 pci7: on pcib6 pcib7: irq 16 at device 28.1 on pci0 pci6: on pcib7 pci6: at device 0.0 (no driver attached) uhci3: port 0xb080-0xb09f = irq 23 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0xb400-0xb41f = irq 19 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0xb480-0xb49f = irq 18 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem = 0xf7dfe000-0xf7dfe3ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib8: at device 30.0 on pci0 pci8: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port = 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f = mem 0xf7dfc000-0xf7dfc7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x400-0x41f mem = 0xf7dfd000-0xf7dfd0ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 qpi0: on motherboard pcib9: pcibus 255 on qpi0 pci255: on pcib9 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on = isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 mfi0: 6139 (427754086s/0x0020/info) - Shutdown command received from = host mfi0: 6140 (boot + 3s/0x0020/info) - Firmware initialization started = (PCI ID 0073/1000/9241/1000) mfi0: 6141 (boot + 3s/0x0020/info) - Firmware version 2.130.364-1847 mfi0: 6142 (boot + 5s/0x0020/info) - Package version 20.10.1-0119 mfi0: 6143 (boot + 5s/0x0020/info) - Board Revision 03A mfi0: 6144 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) mfi0: 6145 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D02, = sasAddr=3D4433221103000000,0000000000000000 mfi0: 6146 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) mfi0: 6147 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D00, = sasAddr=3D4433221100000000,0000000000000000 mfi0: 6148 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) mfi0: 6149 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D01, = sasAddr=3D4433221102000000,0000000000000000 mfi0: 6150 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) mfi0: 6151 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D03, = sasAddr=3D4433221101000000,0000000000000000 mfi0: 6152 (boot + 26s/0x0001/info) - Consistency Check started on VD = 00/0 mfi0: 6153 (427754117s/0x0020/info) - Time established as 07/21/13 = 20:35:17; (28 seconds since power on) mfi0: 6155 (boot + 3s/0x0020/info) - Firmware initialization started = (PCI ID 0073/1000/9241/1000) mfi0: 6156 (boot + 3s/0x0020/info) - Firmware version 2.130.364-1847 mfi0: 6157 (boot + 5s/0x0020/info) - Package version 20.10.1-0119 mfi0: 6158 (boot + 5s/0x0020/info) - Board Revision 03A mfi0: 6159 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) mfi0: 6160 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D03, = sasAddr=3D4433221103000000,0000000000000000 mfi0: 6161 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) mfi0: 6162 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D00, = sasAddr=3D4433221100000000,0000000000000000 mfi0: 6163 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) mfi0: 6164 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D02, = sasAddr=3D4433221102000000,0000000000000000 mfi0: 6165 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) mfi0: 6166 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D01, = sasAddr=3D4433221101000000,0000000000000000 mfi0: 6167 (boot + 26s/0x0001/info) - Consistency Check started on VD = 00/0 mfi0: 6168 (427754185s/0x0020/info) - Time established as 07/21/13 = 20:36:25; (28 seconds since power on) ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 mfid0 on mfi0 mfid0: 5722044MB (11718746112 sectors) RAID volume (no label) is optimal ada0 at ahcich4 bus 0 scbus4 target 0 lun 0 ada0: ATA-8 SATA 2.x device cd0 at ahcich0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO = 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray closed ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1336390186 Hz quality 1000 Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 = usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from zfs:sac []... ugen4.2: at usbus4 ukbd0: on usbus4 kbd1 at ukbd0 uhid0: on usbus4 re0: port = 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xf6ef0000-0xf6efffff irq 17 at = device 0.0 on pci6 re0: Using 1 MSI-X message re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 re0: Ethernet address: e0:cb:4e:01:49:32 miibus0: on re0 rgephy0: PHY 1 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow --Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 16:18:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAF81389; Mon, 22 Jul 2013 16:18:53 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D12B26EB; Mon, 22 Jul 2013 16:18:53 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id C557D29E2; Mon, 22 Jul 2013 18:18:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (scan.wasikowski.net [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id PAWpI5Iq-Iii; Mon, 22 Jul 2013 18:18:50 +0200 (CEST) Received: from [192.168.168.1] (89-71-136-148.dynamic.chello.pl [89.71.136.148]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wasikowski.net (Postfix) with ESMTPSA id 5A0F229DF; Mon, 22 Jul 2013 18:18:50 +0200 (CEST) Message-ID: <51ED5B69.8050200@wasikowski.net> Date: Mon, 22 Jul 2013 18:18:49 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: ZFS: can't read MOS of pool X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 16:18:53 -0000 Hi, I've got a problem with booting zfs-on-root FreeBSD 9.2-PRERELEASE. I'm getting: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool klawisz gptzfsboot: failed to mount default pool klawisz Machine is VM running under KVM on Proxmox 2.3-13. VM has 8 GB of RAM, 400 GB of local storage with SCSI Controller type: Default (lsi). I'm not sure what I did to make this VM unbootable. I've installed 9.2-PRERELEASE, did source based upgrade to r253470, mergemaster, reinstalled bootcode and rebooted. To this point VM was bootable. Then I did installworld from /usr/src to ezjail's basejail (ezjail-admin update -i), did mergemaster for jails, install some ports - none of this should mess with booting. I rebooted VM and got unbootable system. When I boot from liveCD I can import this pool (scrub shows no errors), mount it, chroot to it, and work with it. I just can't get it to boot. Some information about the system: http://pastie.org/private/mtfhkx0wx0vve29xn0plw I've tried to downgrade to r252316 - no luck, system is still unbootable. Any hints how to go from here? -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 17:45:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAD3C72; Mon, 22 Jul 2013 17:45:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 893E22AD0; Mon, 22 Jul 2013 17:45:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E6A8B917; Mon, 22 Jul 2013 13:45:45 -0400 (EDT) From: John Baldwin To: Garrett Cooper Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 12:08:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> In-Reply-To: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307221208.22060.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 13:45:45 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 17:45:47 -0000 On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: > I have a KERNCONF that previously had PS/2 support compiled into the kernel. If I comment out the following lines like so: > > # atkbdc0 controls both the keyboard and the PS/2 mouse > #device atkbdc # AT keyboard controller > #device atkbd # AT keyboard > > then I'm able to mount root again (it was failing with ENOXDEV). > > The working kernel was as follows: > > $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA > @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA > gcc version 4.2.1 20070831 patched [FreeBSD] > FreeBSD > 9.1-STABLE > BAYONETTA > $ cd /usr/src; git log 0304216 > commit 03042167f73c213732b44218a24d8e1bbea00f8c > Merge: 2edcad2 974abfb > Author: Garrett Cooper > Date: Mon Jun 24 19:00:45 2013 -0700 > > Merge remote-tracking branch 'upstream/stable/9' into stable/9 > > The working kernel [with atkbdc] was as follows: > > FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA amd64 > $ git log c178034 > commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 > Author: avg > Date: Tue Jul 9 08:30:31 2013 +0000 > > zfsboottest.sh: remove checks for things that are not strictly required > > MFC after: 10 days > > (Yes, I had to backport some things because they are busted on stable/9 due to other incomplete/missing MFCs). > > I can test out patches, but I don't have time to bisect the actual commit that caused the failure. That being said my intuition says it's this commit should be looked at first: > > commit 28f961058b0667841d7e9d8639bfd02ed8689faa > Author: jhb > Date: Wed Jul 17 14:04:18 2013 +0000 > > MFC 252576: > Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If > we are probing a PCI-PCI bridge it is because we found one by enumerating > the devices on a PCI bus, so the bridge is definitely present. A few > BIOSes report incorrect status (_STA) for some bridges that claimed they > were not present when in fact they were. > > While here, move this check earlier for Host-PCI bridges so attach fails > before doing any work that needs to be torn down. > > PR: kern/91594 > Approved by: re (marius) I strongly doubt that this is related. It would be most helpful if you could obtain a dmesg from the new kernel however (perhaps via a serial console) to rule it out. All you would need to see is if the new kernel sees more "pcib" devices than the old one to see if this change even has an effect on your system. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 17:58:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C22C7AD1; Mon, 22 Jul 2013 17:58:47 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF762BD8; Mon, 22 Jul 2013 17:58:47 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id w15so7682411iea.36 for ; Mon, 22 Jul 2013 10:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=kWmkwYMeHRk5XVvakdsFTtiyQxa+DCus0uTLfKaOuXc=; b=mh1LD4g+Mz4K0oSCzTZNScpfCyExpfNG0H/2BRsDMPDiAYhxNlsUPxz6vSDOGQH4oJ QCWVuizbr36S9Ej/vpIvLBaoYAso/m2l58HyCM80TKfWBrAG5Iynmtyasaz2D0b+aq1z Pkb/Dw3h1E0tl0hCfKxbvvUEUlfJULcZOTfCxqWVXL6gpUYsxz4+TU47kR9n3zOsetvS +ZlR3r4is4RAOtXFIhoJ6DUbQFLrenh088E6C/lXv5pNr61WhUCdLYkSFSpI6k3h4V1w EEuLRmVojiYm2wc0uqrIhCsgWxgfhLF7bE6GUAfGb0yA7xoMpVpPgiLTNw/kdsAugxXz BGOw== X-Received: by 10.50.126.36 with SMTP id mv4mr19874670igb.45.1374515926742; Mon, 22 Jul 2013 10:58:46 -0700 (PDT) Received: from [10.176.148.89] (mobile-166-147-083-154.mycingular.net. [166.147.83.154]) by mx.google.com with ESMTPSA id t10sm434548igz.9.2013.07.22.10.58.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 10:58:46 -0700 (PDT) References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <201307221208.22060.jhb@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <201307221208.22060.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Garrett Cooper Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 10:58:36 -0700 To: John Baldwin Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 17:58:47 -0000 On Jul 22, 2013, at 9:08 AM, John Baldwin wrote: > On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: >> I have a KERNCONF that previously had PS/2 support compiled into the kern= el. If I comment out the following lines like so: >>=20 >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> #device atkbdc # AT keyboard controller >> #device atkbd # AT keyboard >>=20 >> then I'm able to mount root again (it was failing with ENOXDEV). >>=20 >> The working kernel was as follows: >>=20 >> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA >> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >> gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebs= d-stable-9/sys/BAYONETTA >> gcc version 4.2.1 20070831 patched [FreeBSD] >> FreeBSD >> 9.1-STABLE >> BAYONETTA >> $ cd /usr/src; git log 0304216 >> commit 03042167f73c213732b44218a24d8e1bbea00f8c >> Merge: 2edcad2 974abfb >> Author: Garrett Cooper >> Date: Mon Jun 24 19:00:45 2013 -0700 >>=20 >> Merge remote-tracking branch 'upstream/stable/9' into stable/9 >>=20 >> The working kernel [with atkbdc] was as follows: >>=20 >> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Ju= l 21 20:19:38 PDT 2013 =20 > root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 >> $ git log c178034 >> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 >> Author: avg >> Date: Tue Jul 9 08:30:31 2013 +0000 >>=20 >> zfsboottest.sh: remove checks for things that are not strictly require= d >>=20 >> MFC after: 10 days >>=20 >> (Yes, I had to backport some things because they are busted on stable/9 d= ue to other incomplete/missing MFCs). >>=20 >> I can test out patches, but I don't have time to bisect the actual commit= that caused the failure. That being said my intuition says it's this > commit should be looked at first: >>=20 >> commit 28f961058b0667841d7e9d8639bfd02ed8689faa >> Author: jhb >> Date: Wed Jul 17 14:04:18 2013 +0000 >>=20 >> MFC 252576: >> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. I= f >> we are probing a PCI-PCI bridge it is because we found one by enumerat= ing >> the devices on a PCI bus, so the bridge is definitely present. A few >> BIOSes report incorrect status (_STA) for some bridges that claimed th= ey >> were not present when in fact they were. >>=20 >> While here, move this check earlier for Host-PCI bridges so attach fai= ls >> before doing any work that needs to be torn down. >>=20 >> PR: kern/91594 >> Approved by: re (marius) >=20 > I strongly doubt that this is related. It would be most helpful if you co= uld > obtain a dmesg from the new kernel however (perhaps via a serial console) t= o > rule it out. All you would need to see is if the new kernel sees more "pc= ib" > devices than the old one to see if this change even has an effect on your > system. Unfortunately the USB keyboard is broken as well at the mount root prompt an= d the workstation doesn't have a uart on it that I can play with (it's my ho= me box), so I'm dead in the water when it panics at the mount root prompt ri= ght now. I guess I can revert this and a handful of other amd64/ata_cam/zfs commits t= o see if this goes away, but I won't be getting to that before next Sunday p= robably as this is my file server and DNS server now. Thanks!= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 18:05:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 309B7E96 for ; Mon, 22 Jul 2013 18:05:03 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E805B2C37 for ; Mon, 22 Jul 2013 18:05:02 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ij15so455395vcb.30 for ; Mon, 22 Jul 2013 11:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9mm1DhZmGGs3kE1QJC6YIwszYiNSlaa6vgrUv7LmmZE=; b=EJ/dKKzPieMAtTtYXIME8va6BqWKuEDKFn0WFHDxUmGWPzfmp7HISdI85c4I6oIf0u qGEQGDxGmX5O9ILQH2+svoVUJj9mDBicruvPLEMui+uSJ4ktbieHpZksTN6LVqjijnh9 n2lNwzbIQjhei6g7MoxiKcj3PLOs16SvanD4CbWKW5p4WQKHwqkXNqQPtJMER/k38foh 6nbncCutbij42fNfHiOnEiJGHD5DdeQBD/da228M4ltNNtXwojydoLSoiva6XPoHt0PN iuPOzTYyXJ7n68qxEACBzKakslWYD1GsowOBAe0glDVY8rTMMvION7yuGzE5xYBZZFdM 7OsA== MIME-Version: 1.0 X-Received: by 10.220.77.6 with SMTP id e6mr9788209vck.50.1374516301452; Mon, 22 Jul 2013 11:05:01 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.221.41.6 with HTTP; Mon, 22 Jul 2013 11:05:01 -0700 (PDT) In-Reply-To: <51ED0060.2050502@bsdforen.de> References: <51ED0060.2050502@bsdforen.de> Date: Mon, 22 Jul 2013 11:05:01 -0700 X-Google-Sender-Auth: z0raREGqTUBssiib0WJPeFQwrGo Message-ID: Subject: Re: stopping amd causes a freeze From: Artem Belevich To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 18:05:03 -0000 On Mon, Jul 22, 2013 at 2:50 AM, Dominic Fandrey wrote: > Occasionally stopping amd freezes my system. It's a rare occurrence, > and I haven't found a reliable way to reproduce it. > > It's also a real freeze, so there's no way to get into the debugger > or grab a core dump. I only can perform the 4 seconds hard shutdown to > revive the system. > > I run amd through sysutils/automounter, which is a scripting solution > that generates an amd.map file based on encountered devices and devd > events. The SIGHUP it sends to amd to tell it the map file was updated > does not cause problems, only a SIGKILL may cause the freeze. > > Nothing was mounted (by amd) during the last freeze. > > amd itself is a primitive NFS server as far as system is concerned and amd mount points are mounted from it. If you just KILL it without giving it a chance to clean things up you'll potentially end up in a situation similar to mounting from remote NFS server that's unresponsive. From mount_nfs(8): If the server becomes unresponsive while an NFS file system is mounted, any new or outstanding file operations on that file system will hang uninterruptibly until the server comes back. To modify this default be- haviour, see the intr and soft options. > I don't see any angle to tackle this, but I'm throwing it out here > any way, in the hopes that someone actually has an idea how to approach > the issue. > Don't use KILL or make sure that nobody tries to use amd mountpoints until new instance starts. Manually unmounting them before killing amd may help. Why not let amd do it itself with "/etc/rc.d/amd stop" ? --Artem > > # uname -a > FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 > r253413: Wed Jul 17 13:12:46 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-91/amd64/usr/src/sys/HP6510b-91 > amd64 > > That's amd's starting message: > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: no logfile defined; using > stderr > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AM-UTILS VERSION > INFORMATION: > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1997-2006 > Erez Zadok > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 > Jan-Simon Pendry > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 > Imperial College of Science, Technology & Medicine > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 The > Regents of the University of California. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: am-utils version 6.1.5 > (build 901505). > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Report bugs to > https://bugzilla.am-utils.org/ or am-utils@am-utils.org. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Configured by David > O'Brien on date 4-December-2007 PST. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Built by > root@mobileKamikaze.norad. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: cpu=amd64 (little-endian), > arch=amd64, karch=amd64. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: full_os=freebsd9.2, > os=freebsd9, osver=9.2, vendor=undermydesk, distro=The FreeBSD Project. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: domain=norad, > host=mobileKamikaze, hostd=mobileKamikaze.norad. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Map support for: root, > passwd, union, nis, ndbm, file, exec, error. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AMFS: nfs, link, nfsx, > nfsl, host, linkx, program, union, ufs, cdfs, > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: pcfs, auto, direct, > toplvl, error, inherit. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: FS: cd9660, nfs, nfs3, > nullfs, msdosfs, ufs, unionfs. > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 1: > wire="192.168.1.0" (netnumber=192.168.1). > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 2: > wire="192.168.0.0" (netnumber=192.168). > Jul 22 11:32:28 mobileKamikaze amd[8176]/info: My ip addr is 127.0.0.1 > > amd is called with the flags -r -p -a -c 4 -w 2 > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > _______________________________________________ > 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 Jul 22 19:21:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B11E760 for ; Mon, 22 Jul 2013 19:21:39 +0000 (UTC) (envelope-from gausus@house.gausus.net) Received: from house.gausus.net (house.gausus.net [193.0.66.108]) by mx1.freebsd.org (Postfix) with ESMTP id EB8402FA2 for ; Mon, 22 Jul 2013 19:21:38 +0000 (UTC) Received: by house.gausus.net (Postfix, from userid 1000) id A117C7FC68; Mon, 22 Jul 2013 21:13:56 +0200 (CEST) Date: Mon, 22 Jul 2013 21:13:56 +0200 From: Maciej Jan Broniarz To: freebsd-stable@freebsd.org Subject: FreeBSD LVS replacement Message-ID: <20130722191356.GA28044@house.gausus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 19:21:39 -0000 Hello, I'm looking for a functional FreeBSD replacement of the Linux LVS software? There is an LVS port for FreeBSD but it looks deat since 2005. Is there anything comparable or better? All best, mjb From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 19:47:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E02ECFA4 for ; Mon, 22 Jul 2013 19:47:59 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B27A920E4 for ; Mon, 22 Jul 2013 19:47:59 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.local [192.168.5.2]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id r6MJlp16007282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 22 Jul 2013 14:47:52 -0500 (CDT) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 22 Jul 2013 14:47:51 -0500 From: dweimer To: freebsd-stable@freebsd.org Subject: Re: FreeBSD LVS replacement Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <20130722191356.GA28044@house.gausus.net> References: <20130722191356.GA28044@house.gausus.net> Message-ID: <3f47fcd1b956354876c0e01a50b61bba@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 19:47:59 -0000 On 07/22/2013 2:13 pm, Maciej Jan Broniarz wrote: > Hello, > > I'm looking for a functional FreeBSD replacement of the Linux LVS > software? > There is an LVS port for FreeBSD but it looks deat since 2005. Is > there anything comparable or better? > > All best, > mjb > > _______________________________________________ > 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" Perhaps CARP is what you are looking for -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 19:54:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F254223 for ; Mon, 22 Jul 2013 19:54:50 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7E2B2153 for ; Mon, 22 Jul 2013 19:54:49 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fo12so5588449lab.39 for ; Mon, 22 Jul 2013 12:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wgops.com; s=gm01; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sdCbPWwZP6QzkCa/eD+SEMJiFAOvx/IKDT0byCL15Mo=; b=ROJyyl8W0Nf1zSLPLRZxbjdcIF2WC4pw8DtgXWiXgFvgCpmwh22GQEFh5WQhRYY3qG R/m7FU8VndbE/PZ47n7yKlyjURsZV9KN8dCHWfOwHPDv8NUw2klIu8KQseyeeJL8Lt4S 1d7jSJO5Y/ew60c5aMsHj3khXB3IpjQwBO5cs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=sdCbPWwZP6QzkCa/eD+SEMJiFAOvx/IKDT0byCL15Mo=; b=QOFAwLgxvpFY0KlGafrxwNeG27nWVrjgI4ZX6pOIj/A8NHUI7XJcQO6wCUKRuHF2dk tsk3+YIGwHEoQLbizp9fgfcXZaPB6xe2oQS+EhKBlMu5/APabSSUwHSYA2/0xa6Kit8j uM9FLi7Tejts1dEY/32PQTM0MfojQ6SzA9KZM9somngqO6USTudriT0UMcLJHUMeL/Rs mKExbmySjbLBQplHwVOimlGtifDpyN4up55ucbmLhoPh2x+bulj7blmfSSW64ToGEcND iyML/f0yqo59BKiMrRJlun60IW1tT+i2NDe7koWHivmNLlovJI6UP71e1ynLXLEXqxO9 5/yw== MIME-Version: 1.0 X-Received: by 10.112.58.135 with SMTP id r7mr13138537lbq.89.1374522887743; Mon, 22 Jul 2013 12:54:47 -0700 (PDT) Received: by 10.112.151.66 with HTTP; Mon, 22 Jul 2013 12:54:47 -0700 (PDT) In-Reply-To: <3f47fcd1b956354876c0e01a50b61bba@dweimer.net> References: <20130722191356.GA28044@house.gausus.net> <3f47fcd1b956354876c0e01a50b61bba@dweimer.net> Date: Mon, 22 Jul 2013 12:54:47 -0700 Message-ID: Subject: Re: FreeBSD LVS replacement From: Michael Loftis To: dweimer@dweimer.net Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkkN37Uj1j3yrl2uxnT1qFgwWiNgS4Mnm7YydcwNA+oeQx0HVS6ABsYMrXHhDa+bRGAVAj2 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 19:54:50 -0000 On Mon, Jul 22, 2013 at 12:47 PM, dweimer wrote: > Perhaps CARP is what you are looking for > Not even remotely close to the same thing. LVS is a kernel level load balancer/director. Combined with some userspace to keep the table of live real servers up to date it makes a very robust, very high speed load balancer for HTTP and non HTTP applications. IDK of any kernel side stuff in FreeBSD, and I don't know that there are any "general purpose" replacements like LVS is but for HTTP - varnish, nginx, and HAProxy. HAProxy can also do things other than HTTP. But these are all user space proxies. Not lower level like LVS where it doe packet rewriting/NAT. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 20:10:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DAF26E7 for ; Mon, 22 Jul 2013 20:10:28 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id D59E5221B for ; Mon, 22 Jul 2013 20:10:27 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 09C0C3B0AD; Mon, 22 Jul 2013 22:10:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id qlMlLWO_AR3r; Mon, 22 Jul 2013 22:10:20 +0200 (CEST) Received: from [192.168.2.103] (dslb-178-005-090-069.pools.arcor-ip.net [178.5.90.69]) by mail.vx.sk (Postfix) with ESMTPSA id 5F6FC3B0A4; Mon, 22 Jul 2013 22:10:20 +0200 (CEST) Message-ID: <51ED91AB.5040208@FreeBSD.org> Date: Mon, 22 Jul 2013 22:10:19 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Maciej Jan Broniarz Subject: Re: FreeBSD LVS replacement References: <20130722191356.GA28044@house.gausus.net> In-Reply-To: <20130722191356.GA28044@house.gausus.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 20:10:28 -0000 Hi Maciej, you may also want to take a look at the OpenBSD relayd port (net/relayd). Cheers, mm On 2013-07-22 21:13, Maciej Jan Broniarz wrote: > Hello, > > I'm looking for a functional FreeBSD replacement of the Linux LVS software? > There is an LVS port for FreeBSD but it looks deat since 2005. Is there anything comparable or better? > > All best, > mjb > > _______________________________________________ > 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 Jul 22 20:13:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 41DD680D for ; Mon, 22 Jul 2013 20:13:02 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 10A84223D for ; Mon, 22 Jul 2013 20:13:01 +0000 (UTC) Received: from [192.168.2.21] (186.211.187.81.in-addr.arpa [81.187.211.186]) by relay.exonetric.net (Postfix) with ESMTPSA id C549B2C8EC; Mon, 22 Jul 2013 21:06:50 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: FreeBSD LVS replacement From: Mark Blackman In-Reply-To: Date: Mon, 22 Jul 2013 21:06:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8140738D-907E-4BC5-A77C-B3F67CB54A98@exonetric.com> References: <20130722191356.GA28044@house.gausus.net> <3f47fcd1b956354876c0e01a50b61bba@dweimer.net> To: Michael Loftis X-Mailer: Apple Mail (2.1508) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 20:13:02 -0000 On 22 Jul 2013, at 20:54, Michael Loftis wrote: > On Mon, Jul 22, 2013 at 12:47 PM, dweimer wrote: >=20 >> Perhaps CARP is what you are looking for >> >=20 > Not even remotely close to the same thing. LVS is a kernel level load > balancer/director. Combined with some userspace to keep the table of > live real servers up to date it makes a very robust, very high speed > load balancer for HTTP and non HTTP applications. IDK of any kernel > side stuff in FreeBSD, and I don't know that there are any "general > purpose" replacements like LVS is but for HTTP - varnish, nginx, and > HAProxy. HAProxy can also do things other than HTTP. But these are > all user space proxies. Not lower level like LVS where it doe packet > rewriting/NAT. The combination of FreeBSD pf and the FreeBSD port of relayd should buy = you what you're looking for. I believe the FreeBSD version of pf and relayd are close enough to the = following tutorial assumptions. https://calomel.org/relayd.html You can drop CARP into the mix to get redundancy for the load balancer = itself, i.e as a pair. To be honest, it's simpler to just install a pfsense installation for = the whole package though. - Mark= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 22:25:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C09DDCB0 for ; Mon, 22 Jul 2013 22:25:17 +0000 (UTC) (envelope-from kdunn@acm.org) Received: from fly.hiwaay.net (fly.hiwaay.net [216.180.54.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 891042832 for ; Mon, 22 Jul 2013 22:25:17 +0000 (UTC) Received: from fly.hiwaay.net (localhost.localdomain [127.0.0.1]) by fly.hiwaay.net (8.13.8/8.13.8/fly) with ESMTP id r6MMMTmm025291; Mon, 22 Jul 2013 17:22:30 -0500 Received: from localhost (kldunn@localhost) by fly.hiwaay.net (8.13.8/8.13.8/fly-submit) with ESMTP id r6MMMTWt025287; Mon, 22 Jul 2013 17:22:29 -0500 X-Authentication-Warning: fly.hiwaay.net: kldunn owned process doing -bs Date: Mon, 22 Jul 2013 17:22:29 -0500 (CDT) From: Karl Dunn X-X-Sender: kldunn@fly.hiwaay.net To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 and PERC H200 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Karl Dunn List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 22:25:17 -0000 I got a Dell T110-II server on 2013-July-19. It has two 1Tbyte drives that the PERC H200 controls, RAID 1. I tried to install FreeBSD-9.1-RELEASE from a DVD from FreebsdMall. The autopart segfaulted, evidently because it could not find any disks. I think there is a PR about the segfaulting (bad bug, no messages). I worked around the problem by going to the loader prompt when the initial boot choice screen came up; it's option 2. I gave the commands: load mps.ko boot Install went fine. I had to create (last bsdinstall screen, shell option) the file /boot/loader.conf, containing the single line: mps_load="YES" The system boots, and seems to be OK. The 9.1-Release kernel does not contain the mps module, so the above installs it, and the probe finds it as it should. I hope this helps. Karl Dunn kdunn@acm.org For reference, this message was the last of a thread posted 2012-May-21: > Message: 5 > Date: Mon, 21 May 2012 14:27:50 -0500 > From: Efra?n D?ctor > Subject: Re: FreeBSD 9 and PERC H200 > To: > Cc: Ollivier Robert > Message-ID: <2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC> > Content-Type: text/plain; format=flowed; charset="UTF-8"; > reply-type=original > > -----Mensaje original----- > From: Ollivier Robert > Sent: Monday, May 21, 2012 10:53 AM > To: Efra??n D??ctor > Cc: Ollivier Robert ; > Subject: Re: FreeBSD 9 and PERC H200 > > > Le 21 mai 2012 ?? 16:51, Efra??n D??ctor a > ??crit > > Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is > > compatible with PERC H200?. > > It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should > work > > -----Mensaje original----- > > Cool, I'll give it a try. Thank you so much. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 22:36:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7759FE88 for ; Mon, 22 Jul 2013 22:36:11 +0000 (UTC) (envelope-from prvs=19159ab51a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 197E52892 for ; Mon, 22 Jul 2013 22:36:10 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005109091.msg for ; Mon, 22 Jul 2013 23:35:02 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 22 Jul 2013 23:35:02 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19159ab51a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <70D2D492BDB44A36B0B499802A661053@multiplay.co.uk> From: "Steven Hartland" To: "Karl Dunn" , References: Subject: Re: FreeBSD 9 and PERC H200 Date: Mon, 22 Jul 2013 23:35:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 22:36:11 -0000 mps has been in FreeBSD for years surely older than 9.1 are you sure you have a generic kernel? Regards Steve ----- Original Message ----- From: "Karl Dunn" To: Sent: Monday, July 22, 2013 11:22 PM Subject: Re: FreeBSD 9 and PERC H200 >I got a Dell T110-II server on 2013-July-19. It has two 1Tbyte drives > that the PERC H200 controls, RAID 1. I tried to install > FreeBSD-9.1-RELEASE from a DVD from FreebsdMall. The autopart segfaulted, > evidently because it could not find any disks. I think there is a PR > about the segfaulting (bad bug, no messages). > > I worked around the problem by going to the loader prompt when the initial > boot choice screen came up; it's option 2. I gave the commands: > > load mps.ko > boot > > Install went fine. I had to create (last bsdinstall screen, shell option) > the file /boot/loader.conf, containing the single line: > > mps_load="YES" > > The system boots, and seems to be OK. > > The 9.1-Release kernel does not contain the mps module, so the above > installs it, and the probe finds it as it should. > > I hope this helps. > > Karl Dunn > kdunn@acm.org > > For reference, this message was the last of a thread posted 2012-May-21: > >> Message: 5 >> Date: Mon, 21 May 2012 14:27:50 -0500 >> From: Efra?n D?ctor >> Subject: Re: FreeBSD 9 and PERC H200 >> To: >> Cc: Ollivier Robert >> Message-ID: <2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC> >> Content-Type: text/plain; format=flowed; charset="UTF-8"; >> reply-type=original >> >> -----Mensaje original----- >> From: Ollivier Robert >> Sent: Monday, May 21, 2012 10:53 AM >> To: Efra??n D??ctor >> Cc: Ollivier Robert ; >> Subject: Re: FreeBSD 9 and PERC H200 >> >> >> Le 21 mai 2012 ?? 16:51, Efra??n D??ctor a >> ??crit >> > Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is >> > compatible with PERC H200?. >> >> It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should >> work >> >> -----Mensaje original----- >> >> Cool, I'll give it a try. Thank you so much. > _______________________________________________ > 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" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 22 22:50:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2CB5132A for ; Mon, 22 Jul 2013 22:50:06 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3B55292C for ; Mon, 22 Jul 2013 22:50:05 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.7/8.14.6) with ESMTP id r6MMnxps078826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 23:49:59 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <51EDB716.70209@unsane.co.uk> Date: Mon, 22 Jul 2013 23:49:58 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Steven Hartland Subject: Re: FreeBSD 9 and PERC H200 References: <70D2D492BDB44A36B0B499802A661053@multiplay.co.uk> In-Reply-To: <70D2D492BDB44A36B0B499802A661053@multiplay.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Karl Dunn , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 22:50:06 -0000 On 22/07/2013 23:35, Steven Hartland wrote: > mps has been in FreeBSD for years surely older than 9.1 are you > sure you have a generic kernel? > > Regards > Steve Its certainly in GENERIC for 9.1-RELEASE in amd64 http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808&view=markup but not in the i386 GENERIC http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808&view=markup as per the svn log http://svnweb.freebsd.org/base?view=revision&revision=212420 Vince > > ----- Original Message ----- From: "Karl Dunn" > To: > Sent: Monday, July 22, 2013 11:22 PM > Subject: Re: FreeBSD 9 and PERC H200 > > >> I got a Dell T110-II server on 2013-July-19. It has two 1Tbyte >> drives that the PERC H200 controls, RAID 1. I tried to install >> FreeBSD-9.1-RELEASE from a DVD from FreebsdMall. The autopart >> segfaulted, evidently because it could not find any disks. I think >> there is a PR about the segfaulting (bad bug, no messages). >> >> I worked around the problem by going to the loader prompt when the >> initial boot choice screen came up; it's option 2. I gave the commands: >> >> load mps.ko >> boot >> >> Install went fine. I had to create (last bsdinstall screen, shell >> option) the file /boot/loader.conf, containing the single line: >> >> mps_load="YES" >> >> The system boots, and seems to be OK. >> >> The 9.1-Release kernel does not contain the mps module, so the above >> installs it, and the probe finds it as it should. >> >> I hope this helps. >> >> Karl Dunn >> kdunn@acm.org >> >> For reference, this message was the last of a thread posted 2012-May-21: >> >>> Message: 5 >>> Date: Mon, 21 May 2012 14:27:50 -0500 >>> From: Efra?n D?ctor >>> Subject: Re: FreeBSD 9 and PERC H200 >>> To: >>> Cc: Ollivier Robert >>> Message-ID: <2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC> >>> Content-Type: text/plain; format=flowed; charset="UTF-8"; >>> reply-type=original >>> >>> -----Mensaje original----- >>> From: Ollivier Robert >>> Sent: Monday, May 21, 2012 10:53 AM >>> To: Efra??n D??ctor >>> Cc: Ollivier Robert ; >>> Subject: Re: FreeBSD 9 and PERC H200 >>> >>> >>> Le 21 mai 2012 ?? 16:51, Efra??n D??ctor >>> a ??crit >>> > Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is >>> > compatible with PERC H200?. >>> >>> It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 >>> should >>> work >>> >>> -----Mensaje original----- >>> >>> Cool, I'll give it a try. Thank you so much. >> _______________________________________________ >> 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" >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > 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 Jul 22 23:04:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA495804 for ; Mon, 22 Jul 2013 23:04:11 +0000 (UTC) (envelope-from prvs=19159ab51a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D01D29C2 for ; Mon, 22 Jul 2013 23:04:10 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005109286.msg for ; Tue, 23 Jul 2013 00:04:09 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 23 Jul 2013 00:04:09 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19159ab51a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <72A2C34C97504C528D060B43EF35E587@multiplay.co.uk> From: "Steven Hartland" To: "Vincent Hoffman" References: <70D2D492BDB44A36B0B499802A661053@multiplay.co.uk> <51EDB716.70209@unsane.co.uk> Subject: Re: FreeBSD 9 and PERC H200 Date: Tue, 23 Jul 2013 00:04:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Karl Dunn , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Jul 2013 23:04:11 -0000 ----- Original Message ----- From: "Vincent Hoffman" > On 22/07/2013 23:35, Steven Hartland wrote: >> mps has been in FreeBSD for years surely older than 9.1 are you >> sure you have a generic kernel? >> >> Regards >> Steve > > Its certainly in GENERIC for 9.1-RELEASE in amd64 > http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808&view=markup > but not in the i386 GENERIC > http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808&view=markup > as per the svn log > http://svnweb.freebsd.org/base?view=revision&revision=212420 Ahh I never user i386 ;-) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 23 01:25:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8200ACC for ; Tue, 23 Jul 2013 01:25:18 +0000 (UTC) (envelope-from kdunn@acm.org) Received: from fly.hiwaay.net (fly.hiwaay.net [216.180.54.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C0F82E03 for ; Tue, 23 Jul 2013 01:25:17 +0000 (UTC) Received: from fly.hiwaay.net (localhost.localdomain [127.0.0.1]) by fly.hiwaay.net (8.13.8/8.13.8/fly) with ESMTP id r6N1PGMx025618; Mon, 22 Jul 2013 20:25:16 -0500 Received: from localhost (kldunn@localhost) by fly.hiwaay.net (8.13.8/8.13.8/fly-submit) with ESMTP id r6N1PFYq025605; Mon, 22 Jul 2013 20:25:16 -0500 X-Authentication-Warning: fly.hiwaay.net: kldunn owned process doing -bs Date: Mon, 22 Jul 2013 20:25:15 -0500 (CDT) From: Karl Dunn X-X-Sender: kldunn@fly.hiwaay.net To: Steven Hartland Subject: Re: FreeBSD 9 and PERC H200 In-Reply-To: <72A2C34C97504C528D060B43EF35E587@multiplay.co.uk> Message-ID: References: <70D2D492BDB44A36B0B499802A661053@multiplay.co.uk> <51EDB716.70209@unsane.co.uk> <72A2C34C97504C528D060B43EF35E587@multiplay.co.uk> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Vincent Hoffman X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Karl Dunn List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 01:25:18 -0000 On Tue, 23 Jul 2013, Steven Hartland wrote: > ----- Original Message ----- From: "Vincent Hoffman" > > >> On 22/07/2013 23:35, Steven Hartland wrote: >>> mps has been in FreeBSD for years surely older than 9.1 are you >>> sure you have a generic kernel? >>> >>> Regards >>> Steve >> >> Its certainly in GENERIC for 9.1-RELEASE in amd64 >> http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808&view=markup >> but not in the i386 GENERIC >> http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808&view=markup >> as per the svn log >> http://svnweb.freebsd.org/base?view=revision&revision=212420 > > Ahh I never user i386 ;-) > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > Indeed: root@newserver#/root(1)# uname -a FreeBSD newserver.kad-hg.org 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Thanks for the clarification. I didn't try 9.1-release amd64. I have no intention of using amd64 because of past trouble with alignment in some ports. No need anyway: I am using 8.1-release i386 on our current T105, and am essentially going to clone all the functionality for the T110, and then abandon the T105. I am about halfway through that effort so far, no trouble at all. It will serve a LAN with about 20 clients. The T105 is hardly loaded at all; the T110 is replacing it for two reasons: T105 is six years old and has had two major failures recently (PS quit, and a drive wore out); needed more HD space. So bought a new machine. I do run 8.2-release amd64 on my laptop - a Dell E6520. Nice. Karl Dunn kdunn@acm.org From owner-freebsd-stable@FreeBSD.ORG Tue Jul 23 03:19:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3AE4E2B8 for ; Tue, 23 Jul 2013 03:19:13 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA1F722E7 for ; Tue, 23 Jul 2013 03:19:12 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r6N3IZCm079921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jul 2013 12:48:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jul 2013 12:48:35 +0930 Subject: kern.geom.conftxt broken in the presence of geom_raid To: freebsd-stable stable Message-Id: <7539E32C-FB2A-4E84-9E58-17F5FED8B284@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Spam-Score: -3.633 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jul 2013 03:19:13 -0000 I am trying to write a script which generates a list of devices to = install on (hopefully with some vaguely descriptive message next to it) = and I noticed that kern.geom.conftxt is mangled when there is a graid = volume present, eg.. root@test92:/root # sysctl kern.geom.conftxt | less kern.geom.conftxt: 0 DISK ada2 500107862016 512 hd 16 sc 63 1 RAID raid/r0 500104691712 512(null)Intel RAID1 volume (null) (null)RAID1 (null)RAID1 (null)2 (null)65536 (null)OPTIMAL (null)No (null)ada1 (ACTIVE), ada2 (ACTIVE) 2 PART raid/r0p6 471372660736 512 i 6 o 27917370368 ty freebsd-ufs xs = GPT xt 516e7cb6-6ecf-11d6-8ff8-00022d09712b 3 LABEL gptid/821a18d0-efb3-11e2-855b-002590d071b5 471372660736 512 i 0 = o 0 3 LABEL ufsid/51e7fdbd167c3fbb 471372660736 512 i 0 o 0 2 PART raid/r0p5 21474836480 512 i 5 o 6442533888 ty freebsd-ufs xs GPT = xt 516e7cb6-6ecf-11d6-8ff8-00022d09712b It looks like the tag has been pushed in where it shouldn't be. So, I guess I'll have to find some other way to generate my list :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Tue Jul 23 08:27:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB985AA2 for ; Tue, 23 Jul 2013 08:27:33 +0000 (UTC) (envelope-from prvs=1916be8aae=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E2182041 for ; Tue, 23 Jul 2013 08:27:32 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005112935.msg for ; Tue, 23 Jul 2013 09:27:28 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 23 Jul 2013 09:27:28 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1916be8aae=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Karl Dunn" References: <70D2D492BDB44A36B0B499802A661053@multiplay.co.uk> <51EDB716.70209@unsane.co.uk> <72A2C34C97504C528D060B43EF35E587@multiplay.co.uk> Subject: Re: FreeBSD 9 and PERC H200 Date: Tue, 23 Jul 2013 09:27:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, Vincent Hoffman X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jul 2013 08:27:33 -0000 ----- Original Message ----- From: "Karl Dunn" To: "Steven Hartland" >>> On 22/07/2013 23:35, Steven Hartland wrote: >>>> mps has been in FreeBSD for years surely older than 9.1 are you >>>> sure you have a generic kernel? >>> >>> Its certainly in GENERIC for 9.1-RELEASE in amd64 >>> http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808&view=markup >>> but not in the i386 GENERIC >>> http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808&view=markup >>> as per the svn log >>> http://svnweb.freebsd.org/base?view=revision&revision=212420 >> >> Ahh I never user i386 ;-) > Indeed: > > root@newserver#/root(1)# uname -a > FreeBSD newserver.kad-hg.org 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: > Tue Dec 4 06:55:39 UTC 2012 > root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > Thanks for the clarification. I didn't try 9.1-release amd64. > > I have no intention of using amd64 because of past trouble with alignment > in some ports. I really wouldn't worry about that, I've been using amd64 for literally years and never seen an alignment issue with ports. There may well have been in the past for specific ports but I suspect thats long since been resolved :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 23 15:24:52 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E23DA2F for ; Tue, 23 Jul 2013 15:24:52 +0000 (UTC) (envelope-from icedragon696@ya.ru) Received: from forward6.mail.yandex.net (forward6.mail.yandex.net [IPv6:2a02:6b8:0:202::7]) by mx1.freebsd.org (Postfix) with ESMTP id DC4302427 for ; Tue, 23 Jul 2013 15:24:51 +0000 (UTC) Received: from web25e.yandex.ru (web25e.yandex.ru [77.88.61.5]) by forward6.mail.yandex.net (Yandex) with ESMTP id 7EE921121696 for ; Tue, 23 Jul 2013 19:24:47 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web25e.yandex.ru (Yandex) with ESMTP id 36D9D1520071; Tue, 23 Jul 2013 19:24:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1374593087; bh=NXPB5b6lba80GZj1eI21c16GOwO33g0iW8mUgEE2pYg=; h=From:To:Subject:Date; b=JpoRFM1fSFV2zlyw+1B7iRA9LTnLHMFZnE/BHZcn0BeWh1b08gOA6Z3VxLgMvzs+G /JdaaJGyV2X3z2l1rQnpZflLxyK+n7Wgcoptx70uomMuTn8fXNJMNG7Mf/IAUi/Ktb 9OizLvRdZDf4/yNk6dYoxiT5/pwxLc5ZCooZ+yX0= Received: from 95-27-118-215.broadband.corbina.ru (95-27-118-215.broadband.corbina.ru [95.27.118.215]) by web25e.yandex.ru with HTTP; Tue, 23 Jul 2013 19:24:47 +0400 From: icedragon696@ya.ru Envelope-From: ICEDRAGON696@yandex.ru To: stable@freebsd.org Subject: stable@freebsd.org MIME-Version: 1.0 Message-Id: <130381374593087@web25e.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 23 Jul 2013 19:24:47 +0400 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jul 2013 15:24:52 -0000 Hello, i have a problem with Adobe Flash. http://www.freebsd.org/cgi/query-pr.cgi?pr=180766 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 23 17:43:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38AB4E0C; Tue, 23 Jul 2013 17:43:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCD32B93; Tue, 23 Jul 2013 17:43:03 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 18CF786261; Tue, 23 Jul 2013 19:43:01 +0200 (CEST) Message-ID: <51EEC0A4.7010508@bsdforen.de> Date: Tue, 23 Jul 2013 19:43:00 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Artem Belevich Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jul 2013 17:43:04 -0000 On 22/07/2013 20:05, Artem Belevich wrote: > On Mon, Jul 22, 2013 at 2:50 AM, Dominic Fandrey wrote: > >> Occasionally stopping amd freezes my system. It's a rare occurrence, >> and I haven't found a reliable way to reproduce it. >> >> It's also a real freeze, so there's no way to get into the debugger >> or grab a core dump. I only can perform the 4 seconds hard shutdown to >> revive the system. >> >> I run amd through sysutils/automounter, which is a scripting solution >> that generates an amd.map file based on encountered devices and devd >> events. The SIGHUP it sends to amd to tell it the map file was updated >> does not cause problems, only a SIGKILL may cause the freeze. >> >> Nothing was mounted (by amd) during the last freeze. >> >> > ... > > >> I don't see any angle to tackle this, but I'm throwing it out here >> any way, in the hopes that someone actually has an idea how to approach >> the issue. >> > > Don't use KILL or make sure that nobody tries to use amd mountpoints until > new instance starts. Manually unmounting them before killing amd may help. > Why not let amd do it itself with "/etc/rc.d/amd stop" ? That was a typo, I'm using SIGTERM. Sorry about that. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Tue Jul 23 18:52:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BA763C5 for ; Tue, 23 Jul 2013 18:52:59 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E7312EC1 for ; Tue, 23 Jul 2013 18:52:59 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id ha11so540787vcb.35 for ; Tue, 23 Jul 2013 11:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=R5rJZNZdb/yxStbCSG+EdpVfB8tu1KXKuD7sgmIb/wQ=; b=VhepD5dMYS1GrD06s9yGqpgEWbu082A+tcB4PgRadMFFCFKZWtQN6vDs7HhbcOvHDX HyBlMYly3X4xAfpt82T1ctBIgtHgKj5V/Bxzxxcw/Dkd+3eD7atb9Gxt9XncZ95FaUll 5Yr7SiHq6oKC+vHOYE1sI/xoakQ4cmHyTr0pW9gLP5R52wmUqOfMbv6iOIcOFb55hNqu Ry59CjzBcL+SN+pKq9uq4tjRM0bIze9k8XwMumAWkKl5TSYa+V3iOIWENJIW8jVG7HPg 2bZMf8WnBn2eQqhwjIpAyZylrvYCPwavxdDJZ+RGDgyVhEBX3RsV9KrQ75dJP2LW3XSn 4LzA== MIME-Version: 1.0 X-Received: by 10.220.201.138 with SMTP id fa10mr12463093vcb.18.1374605578217; Tue, 23 Jul 2013 11:52:58 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.221.41.6 with HTTP; Tue, 23 Jul 2013 11:52:58 -0700 (PDT) In-Reply-To: <51EEC0A4.7010508@bsdforen.de> References: <51ED0060.2050502@bsdforen.de> <51EEC0A4.7010508@bsdforen.de> Date: Tue, 23 Jul 2013 11:52:58 -0700 X-Google-Sender-Auth: _lXpd3XUTRaa8Qqiy6XXwJjJ5Uc Message-ID: Subject: Re: stopping amd causes a freeze From: Artem Belevich To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jul 2013 18:52:59 -0000 On Tue, Jul 23, 2013 at 10:43 AM, Dominic Fandrey wrote: > > Don't use KILL or make sure that nobody tries to use amd mountpoints > until > > new instance starts. Manually unmounting them before killing amd may > help. > > Why not let amd do it itself with "/etc/rc.d/amd stop" ? > > That was a typo, I'm using SIGTERM. Sorry about that. > > On SIGTERM amd will attempt to unmount its mountpoints. If someone is using them, unmount may not succeed. I've no clue what amd does in such case. The point is that you should treat amd restart as reboot of an NFS server. amd map reload does not really require amd restart. In some cases you may have to manually unmount some automounted filesystem if underlying map had changed, but that's the only case I can think of off the top of my head. In most of the cases "amq -f" worked well enough for me. By the way, are you absolutely sure that your script that restarts amd is guaranteed not to touch anything mounted with amd? Otherwise you're risking a deadlock. For example, if PATH contains amd-mounted directory then when it's time to execute next command your script may attempt to touch such path and may hang waiting for amd to respond which will never happen because the script can't start it. Now, back to debugging your problem. One way to check what's going on would be to figure out where do the processes get stuck. Start with "ps -axl" and see STAT field. CHances are that stuck processes will be in uninterruptible sleep state 'D'. Check MWCHAN field for those. Hitting '^T' which normally sends SIGINFO should also produce a message that includes process' wait channel and is convenient to use when you have console where you've started the app that is hung. Dig further into the sleeping process with "procstat -kk PID" -- it will give you in-kernel stack trace for process' threads which should whos what's going on. You may want to do it from a root login with local host directory and minimalistic PATH so it does not touch any amd mount points. --Artem From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 08:24:27 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1AF3231 for ; Wed, 24 Jul 2013 08:24:27 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93DE820D2 for ; Wed, 24 Jul 2013 08:24:27 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 36C5028427; Wed, 24 Jul 2013 10:24:19 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 28E7328426; Wed, 24 Jul 2013 10:24:17 +0200 (CEST) Message-ID: <51EF8F31.3050505@quip.cz> Date: Wed, 24 Jul 2013 10:24:17 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: d@delphij.net Subject: Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks) References: <51C4DBFE.1010809@quip.cz> <51C4F5D4.6000802@delphij.net> In-Reply-To: <51C4F5D4.6000802@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Xin Li X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jul 2013 08:24:27 -0000 Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 06/21/13 16:04, Miroslav Lachman wrote: >> 1) Is there some way to create relative symlinks with OpenSSH 6.1? > > No. It seems like a regression and can not be worked around. I do > have a patch (attached; against crypto/openssh/), and my test shows > that it would fix the problem. > >> 2) Was OpenSSH 6.1 tested before importing in to the base of >> FreeBSD 8.4 release? These two bugs seems serious to me. > > This code is not new: it was in OpenBSD 3 years ago, and in FreeBSD > for more than 2 years (r221420 or 2011-05-04); OpenSSH 6.1 was > imported last September. This issue you have just raised have been > there since FreeBSD 9.0-RELEASE. > > So to me it seems like that the two issues are either rarely hit by > the general public (counting myself in: I have never used sftp to > create symbolic link remotely and have thus learned something new > today), or those who hit this have choose to keep silent about it. > Fortunately we have you noticed and reported the problem. > > As a community effort, we really *need* people to grab in-development > snapshots and provide us the feedback. > >> 3) Is there any chance to fix these bugs in FreeBSD repository, or >> do we need to be "bug to bug" compatible with other systems using >> OpenSSH 6.x? > > I can not make a promise as I am not the maintainer. However, I have > already reported this issue to upstream OpenBSD developers, so if this > was accepted by the upstream, we will commit the change locally to fix > the issue. > > Unfortunately, it is too late to fix this for 8.4-RELEASE, and unless > we see widespread complain, I don't think the problem would affect a > significant amount of users to warrant a "errata" for supported > release (8.4-RELEASE, 9.1-RELEASE), however, if it would be fixed, the > fix would be merged to 8-STABLE and 9-STABLE and will be shipped with > future releases, if the fix enters the development branch before them. Do you have any news from upstream about integrating your patch in to OpenSSH? I didn't test FreeBSD 9.2-BETA1 yet - will this fix be included in 9.2 RELEASE? And last, is it possible to write a note about my reported problem with empty VersionAdendum in to Release Notes / Errata for 9.2 RELEASE? kind regards Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 08:51:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E01E6D6A; Wed, 24 Jul 2013 08:51:03 +0000 (UTC) (envelope-from freebsd@tzim.net) Received: from orlith.tzim.net (orlith.tzim.net [IPv6:2001:41d0:8:be42::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A6F4622D7; Wed, 24 Jul 2013 08:51:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tzim.net; s=B; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=d6jaZGnTQIWyV3xomrAoONy3qZW+dVaINqfqkNCITJA=; b=blfbv5rnLxt3qXVlgq4cATk+dvYgLy+RgfNH89iQZvCPbJYntjYwxqkG2aM9s7NnpMYTYmV65KnjJaTTKaYrzEdYX23tKJ7dBn2wPzL8/jB6YbNjwPVcazJfC10oDMPSQae3xO9+XBn+++tA3e5rLRtT99RMyJrT6qF1verQbso=; Received: from [194.199.107.7] (helo=[10.60.11.82]) by orlith.tzim.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V1umj-000EMF-3h; Wed, 24 Jul 2013 10:51:01 +0200 Message-ID: <51EF9574.6090007@tzim.net> Date: Wed, 24 Jul 2013 10:51:00 +0200 From: Arnaud Houdelette User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-java@freebsd.org Subject: java (openjdk6) segfaults when built with 9-stable clang Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jul 2013 08:51:03 -0000 Hi I recently upgraded my home NAS from 9.1-RELEASE to 9-stable (r253470 (9.2-BETA1)) I also upgraded my poudriere building jail. Since then, multimedia/xbmc port fails to build in configure stage : java segfaults (sig11). I use WITH_CLANG_IS_CC=YES, for world and build-jails. I found following workarounds: - use previously (with 9.1-RELEASE world and clang) build openjdk6 pkg (same version). - use USE_GCC=YES for java port. It's the only one place I use java (openjdk6-b27_4). So I cannot say if java works otherwise. Is this a java or clang bug ? Should I open a PR ? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 11:19:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 413891F0; Wed, 24 Jul 2013 11:19:46 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF8032A47; Wed, 24 Jul 2013 11:19:45 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V1x6V-0003Hu-60; Wed, 24 Jul 2013 13:19:36 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V1x6V-0006AY-JL; Wed, 24 Jul 2013 13:19:35 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Julian H. Stacey" , "Maurizio Vairani" Subject: Re: [SOLVED] Re: Shutdown problem with an USB memory stick as ZFS cache device References: <201307171529.r6HFT4EK063849@fire.js.berklix.net> <51E79EAD.5040602@cloverinformatica.it> Date: Wed, 24 Jul 2013 13:19:30 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <51E79EAD.5040602@cloverinformatica.it> User-Agent: Opera Mail/12.16 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 12808661ad9e64cdb46d03b2a0987e23 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jul 2013 11:19:46 -0000 On Thu, 18 Jul 2013 09:52:13 +0200, Maurizio Vairani wrote: > On 17/07/2013 17:29, Julian H. Stacey wrote: >> Maurizio Vairani wrote: >>> On 17/07/2013 11:50, Ronald Klop wrote: >>>> On Wed, 17 Jul 2013 10:27:09 +0200, Maurizio Vairani >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>> on a Compaq Presario laptop I have just installed the latest stable >>>>> >>>>> >>>>> #uname -a >>>>> >>>>> FreeBSD presario 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0: Tue Jul 16 >>>>> 16:32:39 CEST 2013 root@presario:/usr/obj/usr/src/sys/GENERIC >>>>> amd64 >>>>> >>>>> >>>>> For speed up the compilation I have added to the pool, tank0, a >>>>> SanDisk memory stick as cache device with the command: >>>>> >>>>> >>>>> # zpool add tank0 cache /dev/da0 >>>>> >>>>> >>>>> But when I shutdown the laptop the process will halt with this screen >>>>> shot: >>>>> >>>>> >>>>> http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html >>>>> >>>>> >>>>> >>>>> and I need to press the power button for more than 4 seconds to >>>>> switch off the laptop. >>>>> >>>>> The problem is always reproducible. >>>> Does sysctl hw.usb.no_shutdown_wait=1 help? >>>> >>>> Ronald. >>> Thank you Ronald it works ! >>> >>> In /boot/loader.conf added the line >>> hw.usb.no_shutdown_wait=1 >>> >>> Maurizio >> I wonder (from ignorance as I dont use ZFS yet), >> if that merely masks the symptom or cures the fault ? >> >> Presumably one should use a ZFS command to disassociate whatever >> might have the cache open ? (in case something might need to be >> written out from cache, if it was a writeable cache ?) >> >> I too had a USB shutdown problem (non ZFS, now solved)& several people >> made useful comments on shutdown scripts etc, so I'm cross referencing: >> >> http://lists.freebsd.org/pipermail/freebsd-mobile/2013-July/012803.html >> >> Cheers, >> Julian > Probably it masks the symptom. Andriy Gapon hypothesizes a bug in the > ZFS clean up code: > http://lists.freebsd.org/pipermail/freebsd-fs/2013-July/017857.html > > Surely one can use a startup script with the command: > zpool add tank0 cache /dev/da0 > and a shutdown script with: > zpool remove tank0 /dev/da0 > but this mask the symptom too. > > I prefer the Ronald solution because: > - is simpler: it adds only one line (hw.usb.no_shutdown_wait=1) to one > file (/boot/loader.conf). > - is fastest: the zpool add/remove commands take time and > “hw.usb.no_shutdown_wait=1” in /boot/loader.conf speeds up the shutdown > process. > - is cleaner: the zpool add/remove commands pair will fill up the tank0 > pool history. > > Regards > Maurizio Keep an eye on this commit when it is merged to 9-stable. http://svnweb.freebsd.org/changeset/base/253606 It might be the fix of the problem. Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 12:18:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B831AF2A for ; Wed, 24 Jul 2013 12:18:33 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (unknown [IPv6:2001:470:8:162::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8953D2CCD for ; Wed, 24 Jul 2013 12:18:33 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V1y1T-000K1v-0u; Wed, 24 Jul 2013 08:18:27 -0400 Date: Wed, 24 Jul 2013 08:18:26 -0400 From: Gary Palmer To: Kurt Jaeger Subject: Re: Interpreting MCA error output Message-ID: <20130724121826.GA70888@in-addr.com> References: <20130716154743.GR2947@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130716154743.GR2947@home.opsec.eu> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, freebsd@jdc.parodius.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jul 2013 12:18:33 -0000 On Tue, Jul 16, 2013 at 05:47:43PM +0200, Kurt Jaeger wrote: > Hi! > > Approx. two years ago there was a thread on -stable about MCA output. > > See > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064083.html > > for a post from Jeremy Chadwick with a link to a AMD paper on > that topic ? > > http://www.amd.com/us/Documents/47644A_ecc_embedded.pdf > > which is no longer available 8-( Anyone has a copy ? Check archive.org e.g. http://web.archive.org/web/20120201000000*/http://www.amd.com/us/Documents/47644A_ecc_embedded.pdf Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 16:47:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1835CED for ; Wed, 24 Jul 2013 16:47:11 +0000 (UTC) (envelope-from hartzell@alacrity.alerce.com) Received: from griffon.alerce.com (griffon.alerce.com [206.125.171.162]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B03C2CAD for ; Wed, 24 Jul 2013 16:47:11 +0000 (UTC) Received: from griffon.alerce.com (localhost [127.0.0.1]) by griffon.alerce.com (Postfix) with ESMTP id 3A9742842A; Wed, 24 Jul 2013 09:47:01 -0700 (PDT) Received: from alacrity.alerce.com (75-149-38-78-SFBA.hfc.comcastbusiness.net [75.149.38.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by griffon.alerce.com (Postfix) with ESMTPSA id DCD1C28424; Wed, 24 Jul 2013 09:47:00 -0700 (PDT) Received: by alacrity.alerce.com (Postfix, from userid 503) id 830E715478DF; Wed, 24 Jul 2013 09:46:57 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20976.1281.477385.398891@gargle.gargle.HOWL> Date: Wed, 24 Jul 2013 09:46:57 -0700 To: hartzell@alerce.com Subject: Re: Help with filing a [maybe] ZFS/mmap bug. In-Reply-To: <20972.12828.973631.17998@gargle.gargle.HOWL> References: <20967.760.95825.310085@gargle.gargle.HOWL> <20968.14003.813473.517439@gargle.gargle.HOWL> <20130718192624.GA45917@ichotolot.servalan.com> <20969.30467.601461.313726@gargle.gargle.HOWL> <20969.35970.217377.274868@gargle.gargle.HOWL> <20972.12828.973631.17998@gargle.gargle.HOWL> X-Mailer: VM 8.2.0b under 24.2.1 (x86_64-apple-darwin) X-Virus-Scanned: ClamAV using ClamSMTP Cc: Richard Todd , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:47:11 -0000 George Hartzell writes: > > George Hartzell writes: > > George Hartzell writes: > > > [...] > > > So, it would seem that there's something about the filesystem in which > > > my home directory resides that contributes to the problem. > > > [...] > > > > Another data point. > > > > [...] > > Yet another data point or three. > > I took an unused disk, set it up with a single pool and copied > everything from my two disk system to it using zfs send & recv. I was > hoping that if there was something goofy about the state of the > filesystems on the older two disk pool it might get cleaned up in the > transfer. > > I tagged the entire set of flac files, they were all successfully > validated via the plugin. After exiting Picard, one failed > validation. After rebooting, many failed validation. > > Next I created a new filesystem on this new pool, mounted it, > configured Picard to save to that filesystem and ran through all of > the tracks. They validated fine via the plugin and by hand after > exiting Picard. They also validated properly after unmounting and > remounting the filesystem and after a reboot. Sigh. > > Then I destroyed all of the snapshots on the filesystems that I > transfered over from my "real" dual-disk system. Tagging all of the > flac files into my home directory generated errors from the validation > plugin and by hand after exiting picard. I didn't bother rebooting > and checking. > > So it seems to be something about the filesystem{s} themselves. > [...] A [small] breakthrough. I understand why saving to a freshly created filesystem never led to any errors. I'd tentatively concluded that there was something hinky with the filesystem itself that was causing the problem, something that came along when I recreated the filesystem via zfs send/recv. This was based on my inability to trigger the problem when I saved the files to a newly created zfs filesystem. Yesterday I used dump and restore to transfer my trouble-free home directory from its UFS partition to a newly created zfs filesystem (I hadn't know that restore would write to a zfs filesystem but it appears to...). The resulting system generated errors when I ran through my "test case", even though it wasn't a zfs send/recv copy. Next I created a new zfs filesystem and arranged to write the tagged files there. The resulting files were error free, even after a reboot. Next I copied the untagged source flacs onto the newly created zfs filesystem and ran through the test routine, saving the tagged files to the newly created zfs filesystem. This resulted in a glorious pile of errors. Conclusion: my test case only generates errors when the untagged files are on the fileysystem to which the tagged files will be written. A bit of poking around in the sources provided the explanation. Picard tries to move the tagged file to its final destination. If it's within the same filesystem this ends up being a rename operation and I'm left with the inconsistent flac file. If the destination is in another fileysystem then it copies the file, which ends up reading the clean memory-resident data. So, now I have a smaller test version of my workflow that doesn't involve rebooting my machine to generate the error. I'll get back to trying to come up with a variant of Richard's stand alone bug-tickler. phew. g. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 21:26:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05489E34 for ; Wed, 24 Jul 2013 21:26:47 +0000 (UTC) (envelope-from prvs=091745d76a=michael@esosoft.com) Received: from eagle.esosoft.net (eagle.esosoft.net [66.241.144.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3C8E2CBD for ; Wed, 24 Jul 2013 21:26:46 +0000 (UTC) Received: from [74.100.23.197] (port=7674 helo=michaelimac.castillodelsol.com) by eagle.esosoft.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V26Hs-000Lau-Fc; Wed, 24 Jul 2013 14:07:56 -0700 From: Michael Tratz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jul 2013 14:07:56 -0700 Subject: NFS deadlock on 9.2-Beta1 To: freebsd-stable@freebsd.org Message-Id: <1EBB997A-B4FD-4F13-BFBE-5AFF460B524A@esosoft.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Jul 2013 21:26:47 -0000 Two machines (NFS Server: running ZFS / Client: disk-less), both are = running FreeBSD r253506. The NFS client starts to deadlock processes = within a few hours. It usually gets worse from there on. The processes = stay in "D" state. I haven't been able to reproduce it when I want it to = happen. I only have to wait a few hours until the deadlocks occur when = traffic to the client machine starts to pick up. The only way to fix the = deadlocks is to reboot the client. Even an ls to the path which is = deadlocked, will deadlock ls itself. It's totally random what part of = the file system gets deadlocked. The NFS server itself has no problem at = all to access the files/path when something is deadlocked on the client. Last night I decided to put an older kernel on the system r252025 (June = 20th). The NFS server stayed untouched. So far 0 deadlocks on the client = machine (it should have deadlocked by now). FreeBSD is working hard like = it always does. :-) There are a few changes to the NFS code from the = revision which seems to work until Beta1. I haven't tried to narrow it = down if one of those commits are causing the problem. Maybe someone has = an idea what could be wrong and I can test a patch or if it's something = else, because I'm not a kernel expert. :-) I have run several procstat -kk on the processes including the ls which = deadlocked. You can see them here: http://pastebin.com/1RPnFT6r I have tried to mount the file system with and without nolockd. It = didn't make a difference. Other than that it is mounted with: rw,nfsv3,tcp,noatime,rsize=3D32768,wsize=3D32768 Let me know if you need me to do something else or if some other output = is required. I would have to go back to the problem kernel and wait = until the deadlock occurs to get that information. Thanks for your help, Michael From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 00:25:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2DDB1ED3 for ; Thu, 25 Jul 2013 00:25:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E8FD62339 for ; Thu, 25 Jul 2013 00:25:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEADBw8FGDaFve/2dsb2JhbABbgztKBoMJuluBLHSCJAEBAQMBAQEBICsdAwsFFhgCAg0ZAikBCSYGCAcEAQgUBIdpBgcFqCqRSIEojSZ7NAeCX4EhA5UYg3CLAYUjgzAgMoEDOQ X-IronPort-AV: E=Sophos;i="4.89,738,1367985600"; d="scan'208";a="41380351" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 24 Jul 2013 20:25:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2A55CB404F; Wed, 24 Jul 2013 20:25:10 -0400 (EDT) Date: Wed, 24 Jul 2013 20:25:10 -0400 (EDT) From: Rick Macklem To: Michael Tratz Message-ID: <960930050.1702791.1374711910151.JavaMail.root@uoguelph.ca> In-Reply-To: <1EBB997A-B4FD-4F13-BFBE-5AFF460B524A@esosoft.com> Subject: Re: NFS deadlock on 9.2-Beta1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 00:25:20 -0000 Michael Tratz wrote: > Two machines (NFS Server: running ZFS / Client: disk-less), both are > running FreeBSD r253506. The NFS client starts to deadlock processes > within a few hours. It usually gets worse from there on. The > processes stay in "D" state. I haven't been able to reproduce it > when I want it to happen. I only have to wait a few hours until the > deadlocks occur when traffic to the client machine starts to pick > up. The only way to fix the deadlocks is to reboot the client. Even > an ls to the path which is deadlocked, will deadlock ls itself. It's > totally random what part of the file system gets deadlocked. The NFS > server itself has no problem at all to access the files/path when > something is deadlocked on the client. > > Last night I decided to put an older kernel on the system r252025 > (June 20th). The NFS server stayed untouched. So far 0 deadlocks on > the client machine (it should have deadlocked by now). FreeBSD is > working hard like it always does. :-) There are a few changes to the > NFS code from the revision which seems to work until Beta1. I > haven't tried to narrow it down if one of those commits are causing > the problem. Maybe someone has an idea what could be wrong and I can > test a patch or if it's something else, because I'm not a kernel > expert. :-) > Well, the only NFS client change committed between r252025 and r253506 is r253124. It fixes a file corruption problem caused by a previous commit that delayed the vnode_pager_setsize() call until after the nfs node mutex lock was unlocked. If you can test with only r253124 reverted to see if that gets rid of the hangs, it would be useful, although from the procstats, I doubt it. > I have run several procstat -kk on the processes including the ls > which deadlocked. You can see them here: > > http://pastebin.com/1RPnFT6r All the processes you show seem to be stuck waiting for a vnode lock or in __utmx_op_wait. (I`m not sure what the latter means.) What is missing is what processes are holding the vnode locks and what they are stuck on. A starting point might be ``ps axhl``, to see what all the threads are doing (particularily the WCHAN for them all). If you can drop into the debugger when the NFS mounts are hung and do a ```show alllocks`` that could help. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html I`ll admit I`d be surprised if r253124 caused this, but who knows. If there have been changes to your network device driver between r252025 and r253506, I`d try reverting those. (If an RPC gets stuck waiting for a reply while holding a vnode lock, that would do it.) Good luck with it and maybe someone else can think of a commit between r252025 and r253506 that could cause vnode locking or network problems. rick > > I have tried to mount the file system with and without nolockd. It > didn't make a difference. Other than that it is mounted with: > > rw,nfsv3,tcp,noatime,rsize=32768,wsize=32768 > > Let me know if you need me to do something else or if some other > output is required. I would have to go back to the problem kernel > and wait until the deadlock occurs to get that information. > > Thanks for your help, > > Michael > > > _______________________________________________ > 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 Jul 25 00:33:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05A0B1B3 for ; Thu, 25 Jul 2013 00:33:40 +0000 (UTC) (envelope-from prvs=19184a477b=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9873F2388 for ; Thu, 25 Jul 2013 00:33:39 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005140653.msg for ; Thu, 25 Jul 2013 01:33:36 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 25 Jul 2013 01:33:36 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19184a477b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <079DC3E4DCDB4072A8F8443AEF727C2B@multiplay.co.uk> From: "Steven Hartland" To: "Rick Macklem" , "Michael Tratz" References: <960930050.1702791.1374711910151.JavaMail.root@uoguelph.ca> Subject: Re: NFS deadlock on 9.2-Beta1 Date: Thu, 25 Jul 2013 01:34:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 00:33:40 -0000 ----- Original Message ----- From: "Rick Macklem" To: "Michael Tratz" Cc: Sent: Thursday, July 25, 2013 1:25 AM Subject: Re: NFS deadlock on 9.2-Beta1 > Michael Tratz wrote: >> Two machines (NFS Server: running ZFS / Client: disk-less), both are >> running FreeBSD r253506. The NFS client starts to deadlock processes >> within a few hours. It usually gets worse from there on. The >> processes stay in "D" state. I haven't been able to reproduce it >> when I want it to happen. I only have to wait a few hours until the >> deadlocks occur when traffic to the client machine starts to pick >> up. The only way to fix the deadlocks is to reboot the client. Even >> an ls to the path which is deadlocked, will deadlock ls itself. It's >> totally random what part of the file system gets deadlocked. The NFS >> server itself has no problem at all to access the files/path when >> something is deadlocked on the client. >> >> Last night I decided to put an older kernel on the system r252025 >> (June 20th). The NFS server stayed untouched. So far 0 deadlocks on >> the client machine (it should have deadlocked by now). FreeBSD is >> working hard like it always does. :-) There are a few changes to the >> NFS code from the revision which seems to work until Beta1. I >> haven't tried to narrow it down if one of those commits are causing >> the problem. Maybe someone has an idea what could be wrong and I can >> test a patch or if it's something else, because I'm not a kernel >> expert. :-) >> > Well, the only NFS client change committed between r252025 and r253506 > is r253124. It fixes a file corruption problem caused by a previous > commit that delayed the vnode_pager_setsize() call until after the > nfs node mutex lock was unlocked. > > If you can test with only r253124 reverted to see if that gets rid of > the hangs, it would be useful, although from the procstats, I doubt it. > >> I have run several procstat -kk on the processes including the ls >> which deadlocked. You can see them here: >> >> http://pastebin.com/1RPnFT6r > > All the processes you show seem to be stuck waiting for a vnode lock > or in __utmx_op_wait. (I`m not sure what the latter means.) > > What is missing is what processes are holding the vnode locks and > what they are stuck on. > > A starting point might be ``ps axhl``, to see what all the threads > are doing (particularily the WCHAN for them all). If you can drop into > the debugger when the NFS mounts are hung and do a ```show alllocks`` > that could help. See: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > I`ll admit I`d be surprised if r253124 caused this, but who knows. > > If there have been changes to your network device driver between > r252025 and r253506, I`d try reverting those. (If an RPC gets stuck > waiting for a reply while holding a vnode lock, that would do it.) > > Good luck with it and maybe someone else can think of a commit > between r252025 and r253506 that could cause vnode locking or network > problems. You could break to the debugger when it happens and run: show sleepchain and show lockchain to see whats waiting on what. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 07:57:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 31CA721F for ; Thu, 25 Jul 2013 07:57:08 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id E82A32372 for ; Thu, 25 Jul 2013 07:57:07 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 0EB1186215; Thu, 25 Jul 2013 09:56:59 +0200 (CEST) Message-ID: <51F0DA4B.3000809@bsdforen.de> Date: Thu, 25 Jul 2013 09:56:59 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> In-Reply-To: <20130722100720.GI5991@kib.kiev.ua> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 07:57:08 -0000 On 22/07/2013 12:07, Konstantin Belousov wrote: > On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: >> ... >> >> I run amd through sysutils/automounter, which is a scripting solution >> that generates an amd.map file based on encountered devices and devd >> events. The SIGHUP it sends to amd to tell it the map file was updated >> does not cause problems, only a -SIGKILL- SIGTERM may cause the freeze. >> >> Nothing was mounted (by amd) during the last freeze. >> >> ... > > Are you sure that the machine did not paniced ? Do you have serial console ? > > The amd(8) locks itself into memory, most likely due to the fear of > deadlock. There are some known issues with user wirings in stable/9. > If the problem you see is indeed due to wiring, you might try to apply > r253187-r253191. I tried that. Applying the diff was straightforward enough. But the resulting kernel paniced as soon as it tried to mount the root fs. So I'll wait for the MFC from someone who knows what he/she is doing. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 10:00:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 469803EA for ; Thu, 25 Jul 2013 10:00:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 986052D08 for ; Thu, 25 Jul 2013 10:00:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6PA0bfg083931; Thu, 25 Jul 2013 13:00:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6PA0bfg083931 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6PA0bTB083929; Thu, 25 Jul 2013 13:00:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Jul 2013 13:00:37 +0300 From: Konstantin Belousov To: Dominic Fandrey Subject: Re: stopping amd causes a freeze Message-ID: <20130725100037.GM5991@kib.kiev.ua> References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o0dA3wbhdegQN8Av" Content-Disposition: inline In-Reply-To: <51F0DA4B.3000809@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 10:00:47 -0000 --o0dA3wbhdegQN8Av Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 09:56:59AM +0200, Dominic Fandrey wrote: > On 22/07/2013 12:07, Konstantin Belousov wrote: > > On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: > >> ... > >> > >> I run amd through sysutils/automounter, which is a scripting solution > >> that generates an amd.map file based on encountered devices and devd > >> events. The SIGHUP it sends to amd to tell it the map file was updated > >> does not cause problems, only a -SIGKILL- SIGTERM may cause the freeze. > >> > >> Nothing was mounted (by amd) during the last freeze. > >> > >> ... > >=20 > > Are you sure that the machine did not paniced ? Do you have serial con= sole ? > >=20 > > The amd(8) locks itself into memory, most likely due to the fear of > > deadlock. There are some known issues with user wirings in stable/9. > > If the problem you see is indeed due to wiring, you might try to apply > > r253187-r253191. >=20 > I tried that. Applying the diff was straightforward enough. But the > resulting kernel paniced as soon as it tried to mount the root fs. You did provided a useful info to diagnose the issue. Patch should keep KBI compatible, but, just in case, if you have any third-party module, rebuild it. >=20 > So I'll wait for the MFC from someone who knows what he/she is doing. Patch below booted for me, and I run some sanity check tests for the mlockall(2), which also did not resulted in misbehaviour. Index: kern/vfs_bio.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kern/vfs_bio.c (revision 253643) +++ kern/vfs_bio.c (working copy) @@ -1614,7 +1614,8 @@ brelse(struct buf *bp) (PAGE_SIZE - poffset) : resid; =20 KASSERT(presid >=3D 0, ("brelse: extra page")); - vm_page_set_invalid(m, poffset, presid); + if (pmap_page_wired_mappings(m) =3D=3D 0) + vm_page_set_invalid(m, poffset, presid); if (had_bogus) printf("avoided corruption bug in bogus_page/brelse code\n"); } Index: vm/vm_fault.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vm/vm_fault.c (revision 253643) +++ vm/vm_fault.c (working copy) @@ -286,6 +286,19 @@ RetryFault:; (u_long)vaddr); } =20 + if (fs.entry->eflags & MAP_ENTRY_IN_TRANSITION && + fs.entry->wiring_thread !=3D curthread) { + vm_map_unlock_read(fs.map); + vm_map_lock(fs.map); + if (vm_map_lookup_entry(fs.map, vaddr, &fs.entry) && + (fs.entry->eflags & MAP_ENTRY_IN_TRANSITION)) { + fs.entry->eflags |=3D MAP_ENTRY_NEEDS_WAKEUP; + vm_map_unlock_and_wait(fs.map, 0); + } else + vm_map_unlock(fs.map); + goto RetryFault; + } + /* * Make a reference to this object to prevent its disposal while we * are messing with it. Once we have the reference, the map is free Index: vm/vm_map.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vm/vm_map.c (revision 253643) +++ vm/vm_map.c (working copy) @@ -2272,6 +2272,7 @@ vm_map_unwire(vm_map_t map, vm_offset_t start, vm_ * above.) */ entry->eflags |=3D MAP_ENTRY_IN_TRANSITION; + entry->wiring_thread =3D curthread; /* * Check the map for holes in the specified region. * If VM_MAP_WIRE_HOLESOK was specified, skip this check. @@ -2304,8 +2305,24 @@ done: else KASSERT(result, ("vm_map_unwire: lookup failed")); } - entry =3D first_entry; - while (entry !=3D &map->header && entry->start < end) { + for (entry =3D first_entry; entry !=3D &map->header && entry->start < end; + entry =3D entry->next) { + /* + * If VM_MAP_WIRE_HOLESOK was specified, an empty + * space in the unwired region could have been mapped + * while the map lock was dropped for draining + * MAP_ENTRY_IN_TRANSITION. Moreover, another thread + * could be simultaneously wiring this new mapping + * entry. Detect these cases and skip any entries + * marked as in transition by us. + */ + if ((entry->eflags & MAP_ENTRY_IN_TRANSITION) =3D=3D 0 || + entry->wiring_thread !=3D curthread) { + KASSERT((flags & VM_MAP_WIRE_HOLESOK) !=3D 0, + ("vm_map_unwire: !HOLESOK and new/changed entry")); + continue; + } + if (rv =3D=3D KERN_SUCCESS && (!user_unwire || (entry->eflags & MAP_ENTRY_USER_WIRED))) { if (user_unwire) @@ -2321,15 +2338,15 @@ done: entry->object.vm_object->type =3D=3D OBJT_SG)); } } - KASSERT(entry->eflags & MAP_ENTRY_IN_TRANSITION, - ("vm_map_unwire: in-transition flag missing")); + KASSERT((entry->eflags & MAP_ENTRY_IN_TRANSITION) !=3D 0, + ("vm_map_unwire: in-transition flag missing")); entry->eflags &=3D ~MAP_ENTRY_IN_TRANSITION; + entry->wiring_thread =3D NULL; if (entry->eflags & MAP_ENTRY_NEEDS_WAKEUP) { entry->eflags &=3D ~MAP_ENTRY_NEEDS_WAKEUP; need_wakeup =3D TRUE; } vm_map_simplify_entry(map, entry); - entry =3D entry->next; } vm_map_unlock(map); if (need_wakeup) @@ -2423,6 +2440,7 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_of * above.) */ entry->eflags |=3D MAP_ENTRY_IN_TRANSITION; + entry->wiring_thread =3D curthread; if ((entry->protection & (VM_PROT_READ | VM_PROT_EXECUTE)) =3D=3D 0 || (entry->protection & prot) !=3D prot) { entry->eflags |=3D MAP_ENTRY_WIRE_SKIPPED; @@ -2514,10 +2532,27 @@ done: else KASSERT(result, ("vm_map_wire: lookup failed")); } - entry =3D first_entry; - while (entry !=3D &map->header && entry->start < end) { + for (entry =3D first_entry; entry !=3D &map->header && entry->start < end; + entry =3D entry->next) { if ((entry->eflags & MAP_ENTRY_WIRE_SKIPPED) !=3D 0) goto next_entry_done; + + /* + * If VM_MAP_WIRE_HOLESOK was specified, an empty + * space in the unwired region could have been mapped + * while the map lock was dropped for faulting in the + * pages or draining MAP_ENTRY_IN_TRANSITION. + * Moreover, another thread could be simultaneously + * wiring this new mapping entry. Detect these cases + * and skip any entries marked as in transition by us. + */ + if ((entry->eflags & MAP_ENTRY_IN_TRANSITION) =3D=3D 0 || + entry->wiring_thread !=3D curthread) { + KASSERT((flags & VM_MAP_WIRE_HOLESOK) !=3D 0, + ("vm_map_wire: !HOLESOK and new/changed entry")); + continue; + } + if (rv =3D=3D KERN_SUCCESS) { if (user_wire) entry->eflags |=3D MAP_ENTRY_USER_WIRED; @@ -2542,15 +2577,18 @@ done: } } next_entry_done: - KASSERT(entry->eflags & MAP_ENTRY_IN_TRANSITION, - ("vm_map_wire: in-transition flag missing")); - entry->eflags &=3D ~(MAP_ENTRY_IN_TRANSITION|MAP_ENTRY_WIRE_SKIPPED); + KASSERT((entry->eflags & MAP_ENTRY_IN_TRANSITION) !=3D 0, + ("vm_map_wire: in-transition flag missing %p", entry)); + KASSERT(entry->wiring_thread =3D=3D curthread, + ("vm_map_wire: alien wire %p", entry)); + entry->eflags &=3D ~(MAP_ENTRY_IN_TRANSITION | + MAP_ENTRY_WIRE_SKIPPED); + entry->wiring_thread =3D NULL; if (entry->eflags & MAP_ENTRY_NEEDS_WAKEUP) { entry->eflags &=3D ~MAP_ENTRY_NEEDS_WAKEUP; need_wakeup =3D TRUE; } vm_map_simplify_entry(map, entry); - entry =3D entry->next; } vm_map_unlock(map); if (need_wakeup) @@ -3185,6 +3223,7 @@ vmspace_fork(struct vmspace *vm1, vm_ooffset_t *fo *new_entry =3D *old_entry; new_entry->eflags &=3D ~(MAP_ENTRY_USER_WIRED | MAP_ENTRY_IN_TRANSITION); + new_entry->wiring_thread =3D NULL; new_entry->wired_count =3D 0; if (new_entry->eflags & MAP_ENTRY_VN_WRITECNT) { vnode_pager_update_writecount(object, @@ -3219,6 +3258,7 @@ vmspace_fork(struct vmspace *vm1, vm_ooffset_t *fo */ new_entry->eflags &=3D ~(MAP_ENTRY_USER_WIRED | MAP_ENTRY_IN_TRANSITION | MAP_ENTRY_VN_WRITECNT); + new_entry->wiring_thread =3D NULL; new_entry->wired_count =3D 0; new_entry->object.vm_object =3D NULL; new_entry->cred =3D NULL; Index: vm/vm_map.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vm/vm_map.h (revision 253643) +++ vm/vm_map.h (working copy) @@ -116,6 +116,7 @@ struct vm_map_entry { int wired_count; /* can be paged if =3D 0 */ vm_pindex_t next_read; /* index of the next sequential read */ struct ucred *cred; /* tmp storage for creator ref */ + struct thread *wiring_thread; }; =20 #define MAP_ENTRY_NOSYNC 0x0001 Index: vm/vm_object.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vm/vm_object.c (revision 253643) +++ vm/vm_object.c (working copy) @@ -1033,9 +1033,9 @@ vm_object_sync(vm_object_t object, vm_ooffset_t of */ flags =3D OBJPR_NOTMAPPED; else if (old_msync) - flags =3D 0; + flags =3D OBJPR_NOTWIRED; else - flags =3D OBJPR_CLEANONLY; + flags =3D OBJPR_CLEANONLY | OBJPR_NOTWIRED; vm_object_page_remove(object, OFF_TO_IDX(offset), OFF_TO_IDX(offset + size + PAGE_MASK), flags); } @@ -1866,7 +1866,8 @@ again: vm_page_lock(p); if ((wirings =3D p->wire_count) !=3D 0 && (wirings =3D pmap_page_wired_mappings(p)) !=3D p->wire_count) { - if ((options & OBJPR_NOTMAPPED) =3D=3D 0) { + if ((options & (OBJPR_NOTWIRED | OBJPR_NOTMAPPED)) =3D=3D + 0) { pmap_remove_all(p); /* Account for removal of wired mappings. */ if (wirings !=3D 0) @@ -1876,8 +1877,7 @@ again: p->valid =3D 0; vm_page_undirty(p); } - vm_page_unlock(p); - continue; + goto next; } if (vm_page_sleep_if_busy(p, TRUE, "vmopar")) goto again; @@ -1886,12 +1886,12 @@ again: if ((options & OBJPR_CLEANONLY) !=3D 0 && p->valid !=3D 0) { if ((options & OBJPR_NOTMAPPED) =3D=3D 0) pmap_remove_write(p); - if (p->dirty) { - vm_page_unlock(p); - continue; - } + if (p->dirty) + goto next; } if ((options & OBJPR_NOTMAPPED) =3D=3D 0) { + if ((options & OBJPR_NOTWIRED) !=3D 0 && wirings !=3D 0) + goto next; pmap_remove_all(p); /* Account for removal of wired mappings. */ if (wirings !=3D 0) { @@ -1903,6 +1903,7 @@ again: } } vm_page_free(p); +next: vm_page_unlock(p); } vm_object_pip_wakeup(object); Index: vm/vm_object.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vm/vm_object.h (revision 253643) +++ vm/vm_object.h (working copy) @@ -176,6 +176,7 @@ struct vm_object { */ #define OBJPR_CLEANONLY 0x1 /* Don't remove dirty pages. */ #define OBJPR_NOTMAPPED 0x2 /* Don't unmap pages. */ +#define OBJPR_NOTWIRED 0x4 /* Don't remove wired pages. */ =20 TAILQ_HEAD(object_q, vm_object); =20 Index: vm/vm_page.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- vm/vm_page.c (revision 253643) +++ vm/vm_page.c (working copy) @@ -2639,8 +2639,6 @@ vm_page_set_invalid(vm_page_t m, int base, int siz vm_page_bits_t bits; =20 VM_OBJECT_LOCK_ASSERT(m->object, MA_OWNED); - KASSERT((m->oflags & VPO_BUSY) =3D=3D 0, - ("vm_page_set_invalid: page %p is busy", m)); bits =3D vm_page_bits(base, size); if (m->valid =3D=3D VM_PAGE_BITS_ALL && bits !=3D 0) pmap_remove_all(m); Index: . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- . (revision 253643) +++ . (working copy) Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/sys:r253187-253191 --o0dA3wbhdegQN8Av Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR8PdEAAoJEJDCuSvBvK1B1HkP/00UJGRIcAGjHQNJehkq9bSQ DI0KClTl+1Jz2OkoObz2DeVIKlX0v3wKZYIhvKdHIxjUx3YbttqXr5a7MACQbPWZ NFN0OoiNB9rSNxQogZzxWOKVeepegyTOaXmT5k1B+Swv8zdxVwKnbb4AHoD9+7B1 5uOqpCTruYvLGTHqab4/xIMkvvw4bzcWBiXfX3+dXFQIgtf+yVs9iCmhkKyPyotf l/hmXuFWvCe8Mq+7RiCWbbeXjYlGN7wt9Vl5thTVQDYrX04/8deae5jeOuRWWRtF j6oYSqI9o4xojFclZLGSJG/kbEDTBOLEAXjjNSn5OLm3/PSUu/uRpdWqsEZzPkCt wJRI5nlylCKLbnQN8gUqYojnr8IOu/PcHtWYtvB0n7/aeGxeZNkSL93+148CS5YB fBVRZ86goo95r9XcafN3wRmh60555sisshtniLExtE6b39mfNY3ckf7FCOCn/KKb sThwGT/svinjO2HED4aGQZ0XYT6aTucV6TR+TLFgAetIXgcNa/DVWiDjEFWs+8BJ R+aq3zgAVdyEwPhzew9+Zn8yh1n7D7sZ6uihq4DbjwokwJiVxRPAeVKqJkeECvFj Y2EUPjfF+IAHjZyENMC8R3bD8RwJoKxnG1dEflQ3OsgBieglEaYOFbW4uBpPsyQi z6qywP+JCtVyAiYsxQnM =sxJQ -----END PGP SIGNATURE----- --o0dA3wbhdegQN8Av-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 13:52:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F2006B94 for ; Thu, 25 Jul 2013 13:52:27 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4A9D2A07 for ; Thu, 25 Jul 2013 13:52:27 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V2Lxw-0005YF-Ho; Thu, 25 Jul 2013 15:52:25 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V2Lxw-0008U6-DY; Thu, 25 Jul 2013 15:52:24 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "freebsd-stable stable" , "Eugene M. Zheganin" Subject: Re: zpool on a zvol inside zpool References: <51ECE783.8050207@norma.perm.ru> Date: Thu, 25 Jul 2013 15:52:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <51ECE783.8050207@norma.perm.ru> User-Agent: Opera Mail/12.16 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.1 X-Scan-Signature: 523f42b60907f92a5b98f162865e3e4b X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 13:52:28 -0000 On Mon, 22 Jul 2013 10:04:19 +0200, Eugene M. Zheganin wrote: > Hi. > > I'm moving some of my geli installation to a new machine. On an old > machine it was running UFS. I use ZFS on a new machine, but I don't have > an encrypted main pool (and I don't want to), so I'm kinda considering a > way where I will make a zpool on a zvol encrypted by geli. Would it be > completely insane (should I use UFS instead ?) or would it be still > valid ? > > Thanks. > Eugene. I think that depends on your configuration and situation. If you have a spare disk to use for GELI+UFS. That is more simple to configure/maintain. But if you are running a big fileserver than the overhead of ZFS+GELI+UFS might be negligible. Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 16:40:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 62A8B7C9 for ; Thu, 25 Jul 2013 16:40:55 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3C8A2330 for ; Thu, 25 Jul 2013 16:40:54 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.7/8.14.7) with ESMTP id r6PGemjZ045683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 18:40:48 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.7/8.14.7/Submit) with ESMTP id r6PGemC5045680; Thu, 25 Jul 2013 18:40:48 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 25 Jul 2013 18:40:48 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Lukasz Wasikowski Subject: Re: ZFS: can't read MOS of pool In-Reply-To: <51ED5B69.8050200@wasikowski.net> Message-ID: References: <51ED5B69.8050200@wasikowski.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-1321781957-1374770448=:35028" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 16:40:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-1321781957-1374770448=:35028 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 22 Jul 2013 18:18+0200, ?ukasz W?sikowski wrote: > Hi, > > I've got a problem with booting zfs-on-root FreeBSD 9.2-PRERELEASE. I'm > getting: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool klawisz > gptzfsboot: failed to mount default pool klawisz > > Machine is VM running under KVM on Proxmox 2.3-13. VM has 8 GB of RAM, > 400 GB of local storage with SCSI Controller type: Default (lsi). > > I'm not sure what I did to make this VM unbootable. I've installed > 9.2-PRERELEASE, did source based upgrade to r253470, mergemaster, > reinstalled bootcode and rebooted. To this point VM was bootable. > > Then I did installworld from /usr/src to ezjail's basejail (ezjail-admin > update -i), did mergemaster for jails, install some ports - none of this > should mess with booting. I rebooted VM and got unbootable system. > > When I boot from liveCD I can import this pool (scrub shows no errors), > mount it, chroot to it, and work with it. I just can't get it to boot. > > Some information about the system: > http://pastie.org/private/mtfhkx0wx0vve29xn0plw > > I've tried to downgrade to r252316 - no luck, system is still unbootable. > > Any hints how to go from here? I'm only subscribed to freebsd-stable@, but as far as I can tell, no one from freebsd-fs@ nor freebsd-stable@ has yet replied. I'm only replying to freebsd-stable@. First, just some quick questions: Have you by chance upgraded the pool format without upgrading the boot blocks? Or was the pool already at 5000? You didn't mention if you have made any attempt at updating the boot blocks after playing with ezjail-admin. Perhaps you should consider updating the boot blocks once more: 1. Boot from the live CD. 2. Import the pool read-only without mounting any fs: zpool import -f -N -o readonly=on klawisz 3. Mount the root fs read-only: mount -r -t zfs klawisz/ROOTFS /tmp/zroot 4. Update the boot blocks from the files stored in the root fs: gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 ada0 5. Unmount the root fs: umount /tmp/zroot 6. Reboot the system, do NOT export the pool. Hopefully, the updated gptzfsboot stored in ada0p1 will be able to read the MOS. That's all I can think of at the moment. Best of luck. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestĝl, | Trond Endrestĝl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjĝvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-1321781957-1374770448=:35028-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 18:45:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A0D5E995 for ; Thu, 25 Jul 2013 18:45:11 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D77C295B for ; Thu, 25 Jul 2013 18:45:11 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id 7D8AD2281; Thu, 25 Jul 2013 20:45:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([91.204.91.44]) by mail.wasikowski.net (scan.wasikowski.net [91.204.91.44]) (amavisd-new, port 10026) with ESMTP id NFpgZE0hxRtB; Thu, 25 Jul 2013 20:45:08 +0200 (CEST) Received: from [192.168.168.1] (89-71-136-148.dynamic.chello.pl [89.71.136.148]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wasikowski.net (Postfix) with ESMTPSA id 0DAB5227E; Thu, 25 Jul 2013 20:45:07 +0200 (CEST) Message-ID: <51F17233.4080903@wasikowski.net> Date: Thu, 25 Jul 2013 20:45:07 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?VHJvbmQgRW5kcmVzdMO4bA==?= Subject: Re: ZFS: can't read MOS of pool References: <51ED5B69.8050200@wasikowski.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 18:45:11 -0000 W dniu 2013-07-25 18:40, Trond Endrest¸l pisze: >> Any hints how to go from here? > > I'm only subscribed to freebsd-stable@, but as far as I can tell, no > one from freebsd-fs@ nor freebsd-stable@ has yet replied. I'm only > replying to freebsd-stable@. > > First, just some quick questions: > > Have you by chance upgraded the pool format without upgrading the boot > blocks? Or was the pool already at 5000? > > You didn't mention if you have made any attempt at updating the boot > blocks after playing with ezjail-admin. > > Perhaps you should consider updating the boot blocks once more: > > 1. Boot from the live CD. > > 2. Import the pool read-only without mounting any fs: > > zpool import -f -N -o readonly=on klawisz > > 3. Mount the root fs read-only: > > mount -r -t zfs klawisz/ROOTFS /tmp/zroot > > 4. Update the boot blocks from the files stored in the root fs: > > gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 ada0 > > 5. Unmount the root fs: > > umount /tmp/zroot > > 6. Reboot the system, do NOT export the pool. > > Hopefully, the updated gptzfsboot stored in ada0p1 will be able to > read the MOS. > > That's all I can think of at the moment. > > Best of luck. Thank you for your reply. The pool was created with version 5000. I have updated the boot blocks before (but with exporting pool after). I don't think that ezjail-admin has anything to do with booting. I did as you suggested and it didn't help, still MOS can't be read. I'm pretty sure I can reproduce this problem. I will try to do detailed guide and post it here. -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 20:04:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D851136; Thu, 25 Jul 2013 20:04:56 +0000 (UTC) (envelope-from freebsd@tzim.net) Received: from orlith.tzim.net (orlith.tzim.net [IPv6:2001:41d0:8:be42::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DF712D10; Thu, 25 Jul 2013 20:04:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tzim.net; s=B; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=jMGEs6kGjeZlOq6vj2wbekY0KBB329ocsuHfQlmI1PQ=; b=QsbM5mF/JIARubJZ80b6e6Om5E8wUk8cyxwT20ncPUsgR6FeqLbxV3r5HogZr2Tyj8kyWWFaF8c8lpc4IP+UhXPlmUue9IUMp90sST0QQInMa+VbDlo0jxibaOn+oDveCM7c32S+zS3wosg/Dyo2dQof4RBU86BB6wFMqZzaNT4=; Received: from courdesi.tzim.net ([82.230.24.82] helo=[10.1.0.10]) by orlith.tzim.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V2RmQ-000Idr-Df; Thu, 25 Jul 2013 22:04:54 +0200 Message-ID: <51F184E6.4090302@tzim.net> Date: Thu, 25 Jul 2013 22:04:54 +0200 From: Arnaud Houdelette User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-java@freebsd.org Subject: Re: java (openjdk6) segfaults when built with 9-stable clang References: <51EF9574.6090007@tzim.net> In-Reply-To: <51EF9574.6090007@tzim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 20:04:56 -0000 On 24/07/2013 10:51, Arnaud Houdelette wrote: > Hi > > I recently upgraded my home NAS from 9.1-RELEASE to 9-stable (r253470 > (9.2-BETA1)) > > I also upgraded my poudriere building jail. Since then, > multimedia/xbmc port fails to build in configure stage : java > segfaults (sig11). > I use WITH_CLANG_IS_CC=YES, for world and build-jails. > > I found following workarounds: > - use previously (with 9.1-RELEASE world and clang) build openjdk6 > pkg (same version). > - use USE_GCC=YES for java port. > > It's the only one place I use java (openjdk6-b27_4). So I cannot say > if java works otherwise. > > Is this a java or clang bug ? > > Should I open a PR ? > Solved in openjdk6-b27_6. See http://lists.freebsd.org/pipermail/freebsd-ports/2013-July/085074.html regards, Arnaud From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 20:23:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4F77490 for ; Thu, 25 Jul 2013 20:23:49 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 179872DED for ; Thu, 25 Jul 2013 20:23:48 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.7/8.14.7) with ESMTP id r6PKNiDL047295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 22:23:44 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.7/8.14.7/Submit) with ESMTP id r6PKNiQh047292; Thu, 25 Jul 2013 22:23:44 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 25 Jul 2013 22:23:44 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Subject: Re: ZFS: can't read MOS of pool In-Reply-To: <51F17233.4080903@wasikowski.net> Message-ID: References: <51ED5B69.8050200@wasikowski.net> <51F17233.4080903@wasikowski.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-1228286545-1374783824=:35028" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 20:23:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-1228286545-1374783824=:35028 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 25 Jul 2013 20:45+0200, ?ukasz W?sikowski wrote: > W dniu 2013-07-25 18:40, Trond Endrestĝl pisze: > > >> Any hints how to go from here? > > > > I'm only subscribed to freebsd-stable@, but as far as I can tell, no > > one from freebsd-fs@ nor freebsd-stable@ has yet replied. I'm only > > replying to freebsd-stable@. > > > > First, just some quick questions: > > > > Have you by chance upgraded the pool format without upgrading the boot > > blocks? Or was the pool already at 5000? > > > > You didn't mention if you have made any attempt at updating the boot > > blocks after playing with ezjail-admin. > > > > Perhaps you should consider updating the boot blocks once more: > > > > 1. Boot from the live CD. > > > > 2. Import the pool read-only without mounting any fs: > > > > zpool import -f -N -o readonly=on klawisz > > > > 3. Mount the root fs read-only: > > > > mount -r -t zfs klawisz/ROOTFS /tmp/zroot > > > > 4. Update the boot blocks from the files stored in the root fs: > > > > gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 ada0 > > > > 5. Unmount the root fs: > > > > umount /tmp/zroot > > > > 6. Reboot the system, do NOT export the pool. > > > > Hopefully, the updated gptzfsboot stored in ada0p1 will be able to > > read the MOS. > > > > That's all I can think of at the moment. > > > > Best of luck. > > Thank you for your reply. The pool was created with version 5000. I have > updated the boot blocks before (but with exporting pool after). I don't > think that ezjail-admin has anything to do with booting. Never ever leave a pool you intend to boot from in the exported state. Period. ;-) At least that was a big no-no when I started using ZFS a couple of years ago. Maybe this has changed since FreeBSD no longer relies on the zpool.cache file. > I did as you suggested and it didn't help, still MOS can't be read. I'm > pretty sure I can reproduce this problem. I will try to do detailed > guide and post it here. Reading through your post once more, http://pastie.org/private/mtfhkx0wx0vve29xn0plw , I noticed the following: 1. The bootfs property is set to klawisz/ROOTFS for the klawisz pool. 2. The mountpoint property is set to / for the klawisz filesystem. 3. The mountpoint property is set to legacy for the klawisz/ROOTFS filesystem. Maybe item 2 is the cause of all this confusion. I see nothing wrong with items 1 and 3. Perhaps you should reset the mountpoint property for klawisz, using: zfs set mountpoint=legacy klawisz At the same time you may let klawisz/ROOTFS inherit the mountpoint property from klawisz by running: zfs inherit mountpoint klawisz/ROOTFS You should also check the mountpoint properties of all the other filesystems you intend to mount automatically. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestĝl, | Trond Endrestĝl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjĝvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-1228286545-1374783824=:35028-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 25 22:05:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26DCF1FF; Thu, 25 Jul 2013 22:05:56 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80C2622F3; Thu, 25 Jul 2013 22:05:55 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so142022wiv.3 for ; Thu, 25 Jul 2013 15:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ZZ6T8EAhaYXbel48wflN7PE18cK0tdfpMa/DC1dWu2A=; b=HudQnp1fanA59SNtYAL0j4eX4kUgT4cS2iH4QxJV/E41hjtTuKOqmjzaiPuLQswWIM XS2Uao8jZZL4udJo2TOk3uNFmmijyHJyu/p+1oHFvuqC5BZowcXBvMUVgYHSYhvoefn7 PWdVp27NZsDNWzZXHUxtHN3vVimKgrJzgq/fOoJMjLhvxurhNI/CUiZ71Qz8N8JWhuQq aLxpVLfF9S3eDmmlVafznTjy8OX7LBa6k/yBGFDP5J26kPXNfs7DoCc0eiAGpF4zRElG quQ7WtxE3eNfyZYgyAhvrh45a/Xf9xjw1adb2gc8I+j9gdgefk5q0JiUcvI/woSwYsay GkJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ZZ6T8EAhaYXbel48wflN7PE18cK0tdfpMa/DC1dWu2A=; b=NuyVhG7OtG5Ypvkuk4iKiYz8Y79ylKWz/+yDZ8+oE6yLrq0zmvAE0uilhP+Kz62Ivz mccDuiUWmf18GfNhhW3gZm94108kUvw+4VghExmIj0rprAH0vibLHQLTKy/7L6ok9BT3 ajysSwv+KzJ8opJf7WIE5XDbw6ZteEKui10mOxzC/IKbTSbfKTGnHCfY+C2Ug6oVCHgy V5xSUWLWjYlxLar6DtSVC2Eqy277yg8SNycbrh4suqvEiUD4CO3PzbfIOIkcpkoxomnH i1mA2dzRfy9lTvAkNxAQ1xvlXBqyjf9BKiEdrRXqwBjPFZkdoY0W+Tbmo5pJqGyDkQaD x+FQ== X-Received: by 10.180.83.68 with SMTP id o4mr3653773wiy.5.1374789953836; Thu, 25 Jul 2013 15:05:53 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id i1sm793065wiz.6.2013.07.25.15.05.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 15:05:52 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 26 Jul 2013 00:05:50 +0200 From: Baptiste Daroussin To: Arnaud Houdelette Subject: Re: java (openjdk6) segfaults when built with 9-stable clang Message-ID: <20130725220550.GR61207@ithaqua.etoilebsd.net> References: <51EF9574.6090007@tzim.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZaW/dtY/7oMe/vLp" Content-Disposition: inline In-Reply-To: <51EF9574.6090007@tzim.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, freebsd-java@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Jul 2013 22:05:56 -0000 --ZaW/dtY/7oMe/vLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 10:51:00AM +0200, Arnaud Houdelette wrote: > Hi >=20 > I recently upgraded my home NAS from 9.1-RELEASE to 9-stable (r253470 =20 > (9.2-BETA1)) >=20 > I also upgraded my poudriere building jail. Since then, multimedia/xbmc= =20 > port fails to build in configure stage : java segfaults (sig11). > I use WITH_CLANG_IS_CC=3DYES, for world and build-jails. >=20 > I found following workarounds: > - use previously (with 9.1-RELEASE world and clang) build openjdk6 pkg= =20 > (same version). > - use USE_GCC=3DYES for java port. >=20 > It's the only one place I use java (openjdk6-b27_4). So I cannot say if= =20 > java works otherwise. >=20 > Is this a java or clang bug ? >=20 Here is the bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D6636110 Fixed in b27_6 regards, Bapt --ZaW/dtY/7oMe/vLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHxoT4ACgkQ8kTtMUmk6EyodgCgi3n9YVWGsNVr/HgLUpuMupnv jI4An0mYY1VDxPqOIvKGDHxSK0DIiGaP =3X02 -----END PGP SIGNATURE----- --ZaW/dtY/7oMe/vLp-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 26 03:06:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0443DBE for ; Fri, 26 Jul 2013 03:06:09 +0000 (UTC) (envelope-from prvs=091960a35b=michael@esosoft.com) Received: from eagle.esosoft.net (eagle.esosoft.net [66.241.144.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA22F2F0E for ; Fri, 26 Jul 2013 03:06:09 +0000 (UTC) Received: from [74.100.23.197] (port=37654 helo=michaelimac.castillodelsol.com) by eagle.esosoft.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V2YLw-0006Cr-97; Thu, 25 Jul 2013 20:06:00 -0700 Subject: Re: NFS deadlock on 9.2-Beta1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Michael Tratz In-Reply-To: <960930050.1702791.1374711910151.JavaMail.root@uoguelph.ca> Date: Thu, 25 Jul 2013 20:05:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <780BC2DB-3BBA-4396-852B-0EBDF30BF985@esosoft.com> References: <960930050.1702791.1374711910151.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1508) Cc: Steven Hartland , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jul 2013 03:06:09 -0000 On Jul 24, 2013, at 5:25 PM, Rick Macklem wrote: > Michael Tratz wrote: >> Two machines (NFS Server: running ZFS / Client: disk-less), both are >> running FreeBSD r253506. The NFS client starts to deadlock processes >> within a few hours. It usually gets worse from there on. The >> processes stay in "D" state. I haven't been able to reproduce it >> when I want it to happen. I only have to wait a few hours until the >> deadlocks occur when traffic to the client machine starts to pick >> up. The only way to fix the deadlocks is to reboot the client. Even >> an ls to the path which is deadlocked, will deadlock ls itself. It's >> totally random what part of the file system gets deadlocked. The NFS >> server itself has no problem at all to access the files/path when >> something is deadlocked on the client. >>=20 >> Last night I decided to put an older kernel on the system r252025 >> (June 20th). The NFS server stayed untouched. So far 0 deadlocks on >> the client machine (it should have deadlocked by now). FreeBSD is >> working hard like it always does. :-) There are a few changes to the >> NFS code from the revision which seems to work until Beta1. I >> haven't tried to narrow it down if one of those commits are causing >> the problem. Maybe someone has an idea what could be wrong and I can >> test a patch or if it's something else, because I'm not a kernel >> expert. :-) >>=20 > Well, the only NFS client change committed between r252025 and r253506 > is r253124. It fixes a file corruption problem caused by a previous > commit that delayed the vnode_pager_setsize() call until after the > nfs node mutex lock was unlocked. >=20 > If you can test with only r253124 reverted to see if that gets rid of > the hangs, it would be useful, although from the procstats, I doubt = it. >=20 >> I have run several procstat -kk on the processes including the ls >> which deadlocked. You can see them here: >>=20 >> http://pastebin.com/1RPnFT6r >=20 > All the processes you show seem to be stuck waiting for a vnode lock > or in __utmx_op_wait. (I`m not sure what the latter means.) >=20 > What is missing is what processes are holding the vnode locks and > what they are stuck on. >=20 > A starting point might be ``ps axhl``, to see what all the threads > are doing (particularily the WCHAN for them all). If you can drop into > the debugger when the NFS mounts are hung and do a ```show alllocks`` > that could help. See: > = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html >=20 > I`ll admit I`d be surprised if r253124 caused this, but who knows. >=20 > If there have been changes to your network device driver between > r252025 and r253506, I`d try reverting those. (If an RPC gets stuck > waiting for a reply while holding a vnode lock, that would do it.) >=20 > Good luck with it and maybe someone else can think of a commit > between r252025 and r253506 that could cause vnode locking or network > problems. >=20 > rick >=20 >>=20 >> I have tried to mount the file system with and without nolockd. It >> didn't make a difference. Other than that it is mounted with: >>=20 >> rw,nfsv3,tcp,noatime,rsize=3D32768,wsize=3D32768 >>=20 >> Let me know if you need me to do something else or if some other >> output is required. I would have to go back to the problem kernel >> and wait until the deadlock occurs to get that information. >>=20 Thanks Rick and Steven for your quick replies. I spoke too soon regarding r252025 fixing the problem. The same issue = started to show up after about 1 day and a few hours of uptime. "ps axhl" shows all those stuck processes in newnfs I recompiled the GENERIC kernel for Beta1 with the debugging options: = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html ps and debugging output: http://pastebin.com/1v482Dfw (I only listed processes matching newnfs, if you need the whole list, = please let me know) The first PID showing up having that problem is 14001. Certainly the = "show alllocks" command shows interesting information for that PID. I looked through the commit history for those files mentioned in the = output to see if there is something obvious to me. But I don't know. :-) I hope that information helps you to dig deeper into the issue what = might be causing those deadlocks. I did include the pciconf -lv, because you mentioned network device = drivers. It's Intel igb. The same hardware is running a kernel from = January 19th, 2013 also as an NFS client. That machine is rock solid. No = problems at all. I also went to r251611. That's before r251641 (The NFS FHA changes). = Same problem. Here is another debugging output from that kernel: http://pastebin.com/ryv8BYc4 If I should test something else or provide some other output, please let = me know. Again thank you! Michael From owner-freebsd-stable@FreeBSD.ORG Fri Jul 26 14:40:26 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19323FF9; Fri, 26 Jul 2013 14:40:26 +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 F052B2EC0; Fri, 26 Jul 2013 14:40:24 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA27064; Fri, 26 Jul 2013 17:40:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2jBu-000IA3-So; Fri, 26 Jul 2013 17:40:22 +0300 Message-ID: <51F28A33.7040209@FreeBSD.org> Date: Fri, 26 Jul 2013 17:39:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , freebsd-stable List Subject: [HEADS UP] change in devfs path matching logic X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jul 2013 14:40:26 -0000 I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/253677 Jaakko Heinonen (jh@) has full credit for the code while I have full responsibility for any consequences of the commit. Before this change the logic of matching the devfs paths to the patterns in devfs rules was quite arcane. Now this logic should be much simpler and logical (sorry for tautology). Please note that nothing changes with respect to matching simple paths like /dev/something. It is the complex paths that involve subdirectories that are affected. I think that if you knew how the old logic worked and were able to devise rules for it, then you will have no problem to change those rules for the new logic. Just please don't forget to do it when you upgrade! I hope that overall you will find this change to be an improvement. P.S. I notify stable@ because I currently plan to MFC this change after 1 month period. If you know a reason why the MFC should not be done, please alert me to it. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 26 15:08:45 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1FD25EB0; Fri, 26 Jul 2013 15:08:45 +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 1BB05208D; Fri, 26 Jul 2013 15:08:43 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA27281; Fri, 26 Jul 2013 18:08:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2jdK-000ICZ-7H; Fri, 26 Jul 2013 18:08:42 +0300 Message-ID: <51F290C2.3090808@FreeBSD.org> Date: Fri, 26 Jul 2013 18:07:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , freebsd-stable List Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> In-Reply-To: <51F28A33.7040209@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jul 2013 15:08:45 -0000 on 26/07/2013 17:39 Andriy Gapon said the following: > Please note that nothing changes with respect to matching simple paths like > /dev/something. I must add: and thus rules in etc/defaults/devfs.rules should not be affected except for their unintended side-effects. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 26 17:10:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09997B22 for ; Fri, 26 Jul 2013 17:10:54 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id BEC28271A for ; Fri, 26 Jul 2013 17:10:53 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id DFCFA8628A; Fri, 26 Jul 2013 19:10:36 +0200 (CEST) Message-ID: <51F2AD8C.1000003@bsdforen.de> Date: Fri, 26 Jul 2013 19:10:36 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> <20130725100037.GM5991@kib.kiev.ua> In-Reply-To: <20130725100037.GM5991@kib.kiev.ua> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jul 2013 17:10:54 -0000 On 25/07/2013 12:00, Konstantin Belousov wrote: > On Thu, Jul 25, 2013 at 09:56:59AM +0200, Dominic Fandrey wrote: >> On 22/07/2013 12:07, Konstantin Belousov wrote: >>> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: >>>> ... >>>> >>>> I run amd through sysutils/automounter, which is a scripting solution >>>> that generates an amd.map file based on encountered devices and devd >>>> events. The SIGHUP it sends to amd to tell it the map file was updated >>>> does not cause problems, only a -SIGKILL- SIGTERM may cause the freeze. >>>> >>>> Nothing was mounted (by amd) during the last freeze. >>>> >>>> ... >>> >>> Are you sure that the machine did not paniced ? Do you have serial console ? >>> >>> The amd(8) locks itself into memory, most likely due to the fear of >>> deadlock. There are some known issues with user wirings in stable/9. >>> If the problem you see is indeed due to wiring, you might try to apply >>> r253187-r253191. >> >> I tried that. Applying the diff was straightforward enough. But the >> resulting kernel paniced as soon as it tried to mount the root fs. > You did provided a useful info to diagnose the issue. > > Patch should keep KBI compatible, but, just in case, if you have any > third-party module, rebuild it. > >> >> So I'll wait for the MFC from someone who knows what he/she is doing. > > Patch below booted for me, and I run some sanity check tests for the > mlockall(2), which also did not resulted in misbehaviour. > Your patch applied cleanly and the system booted with the resulting kernel. Amd exhibits several very strange behaviours. a) During the first start it writes the wrong PID into the pidfile, it however still reacts to SIGTERM. b) After starting it again, it no longer reacts to SIGTERM. c) It appear to be no longer reacting to SIGHUP, which is required to tell it that the amd.map was updated. d) It doesn't work at all, I only get: # cd /media/ufs/FreeBSD_Install /media/ufs/FreeBSD_Install: Too many levels of symbolic links. e) A SIGKILL without load will terminate the process. A SIGKILL while there is heavy file system load panics the system. I'll try a clean buildworld buildkernel and repeat. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri Jul 26 17:20:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8A3C8D99 for ; Fri, 26 Jul 2013 17:20:37 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E382277E for ; Fri, 26 Jul 2013 17:20:36 +0000 (UTC) Received: from [98.138.90.52] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jul 2013 17:20:36 -0000 Received: from [98.138.84.45] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jul 2013 17:20:36 -0000 Received: from [127.0.0.1] by smtp113.mail.ne1.yahoo.com with NNFMP; 26 Jul 2013 17:20:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1374859236; bh=SCyn+682TULL8JEzMI5dglPWibz5XDORpY99LMq8GsY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=xXF7fQd9JXepsxU4s8nx3euKhkK0v6Hu4vlWwDf610S0AXTFGIULlpH3VguDWzh6r6/CInppa0hroX3D3OTJsNZXO7kuDVGg6OGB+4bTgnXsmxh9+EbXTlrgbGwJMMao+mDTyO+LHJjGkIZDr8e65N9LBiBqhILlapUbXSTf7Fg= X-Yahoo-Newman-Id: 249987.44819.bm@smtp113.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o5n9o84VM1nP2jFt2uGfi.9jX_b3gvqXFrFsr6UCmBaY_Sw xSgdUEuiqnAGvbeRqIm6yGVSfYL5rypz_GBs7ERejn.6bXtn6Y13_q5c9M47 dQEX6ztt3Vj0ZdsB1jeDHJ22mH305yficSAMUsLM5dcn.c2rg1TbbqTDOf_7 FRxRJU.dyF2L5.1klsCS4.PCFRGtoe8Jr277U9rxDwGOJX75YXt_tljz4TnC Z2DTJn85ZYsUHMinXpqbk5g41raPOVaDf7uhIO0u_QPGvFzGPl9AvF5A9Pg2 18eAhJpvbOyJ7YZwHHujUtZPoEdPqFlFRcIL3asZbVVW7Kc0mmswR62OaJ84 08IErHI6uQGWE6h2LkA7xlB2Ran0COclRzpgGV_JtEfTpw8uldQdKtYOqIIg zssIEdlpQDYRpXzRufBvi44JB.mHlZwDcxqEBPHbEUWC2AaPJKYm2Ypx4VHk 7ey0nrc2x_9.A86SsJfIwollU_HRmAFJrFVFpeZDuyym1laTwdC99DCpWrc8 hmDcsdluU9APon1.j5rkE42WePwPxZQH7zA-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp113.mail.ne1.yahoo.com with SMTP; 26 Jul 2013 10:20:36 -0700 PDT Subject: Re: bce and "Warning: bootcode thinks driver is absent." From: Sean Bruno To: Larry Baird In-Reply-To: <20130717155531.GA52015@gta.com> References: <20130717155531.GA52015@gta.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OD/S2/Q3eHrAhKRV0hlR" Date: Fri, 26 Jul 2013 10:20:35 -0700 Message-ID: <1374859235.2321.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 17:20:37 -0000 --=-OD/S2/Q3eHrAhKRV0hlR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2013-07-17 at 11:55 -0400, Larry Baird wrote: > Recently under amd64 and 9.1-STABLE I am seeing issues with the bce > driver. Message is "Warning: bootcode thinks driver is absent". After > this message, the box appears to be wedged. After rebooting, it got the > same message during fsck. So we installed 9.2 pre-release using a snapsh= ot > iso from 7/13/13. Shortly after boot we got the same message. We are no= w in > the process of installing 9.1 release to verify this is a driver issue an= d > not hardware flaking out. Anybody else seen this issue? >=20 > Thank you for your time, > Larry >=20 Hey, looks like we might be seeing similar things. I've been investigating the fact that FreeBSD appears to be smashing the mangement firmware because of the ipmi(4) code attempting to attach to the ACPI and ISA versions of the BMC. =20 Do you see attempts to attach to "ipmi1" and do you see various cases where you get a "NMI" of some kind on an ifconfig up of your network interfaces? Sean --=-OD/S2/Q3eHrAhKRV0hlR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJR8q/jAAoJEBkJRdwI6BaHOgIH/2MNeikj6iwWG1bFkIWQh7vd f45+/iFGzTZSOkL+4FArQlcIHOsinpmJchYDK8ZQ46E12klSN8+TZUViH3qaXUSU UkwuW4fa/EMo2+0rPAtSQCm6JIj+V3uTZgnKr4WCI7zrcxC8mFChLnxUWy6sw7pU RyU6FsWO+NP403si+MzJgDpg2FHXbzgl0oHdUDm7+0qCz03y8EqVfjpg/WlQ+vgs fngYpjjVRaDLNFwVVHO+DNn1ynp2b/KCywt48gVhdgUr6a+61TQwMh7/mzlB245R s0A8TihqSxtuaOiYJCBSo609EVYRXRxRB7XRtdnNyOeqkH7LeD9/pKhwUugrH6A= =rNIH -----END PGP SIGNATURE----- --=-OD/S2/Q3eHrAhKRV0hlR-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 26 18:37:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 552B861D for ; Fri, 26 Jul 2013 18:37:22 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12E1F2A91 for ; Fri, 26 Jul 2013 18:37:22 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id x17so1459204vbf.38 for ; Fri, 26 Jul 2013 11:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=crAq4YqTrvawgMcvQCkUU7V/Xo1t9Dxqo5XdqIBlkLw=; b=u/b6xZwa400e7sW/qyaIEXnrMBGJi36ahXBlDHForoxaNiVMNgOeUzXjf/OUgeqfSa sSmoRWuF0vkwrwpUHcC6qQ+7DzPf7jPh+/vvqUOQjWRzMQByi0HBQSKkOh+YOblu+08p 8SZM2JC7v944jojPWY8jxoiKf2vrVRumdlCZ44/ljG15MbXdpS1hLhJ+/biocYled1W6 ruZJuuWyka4x+D9XA4wCd8FAfbXWwn+kZPL1B8mpJ5bmsiR++QHJ8v5w3npxcnWqc1uW kv05y3G8I3sI1PFBHIe+GZxJbmNBs8fDF2SNpnomzfc+CXwhV3IcjrurULGKw/sN0dWh GdQg== MIME-Version: 1.0 X-Received: by 10.220.201.138 with SMTP id fa10mr4071851vcb.18.1374863841128; Fri, 26 Jul 2013 11:37:21 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.221.41.6 with HTTP; Fri, 26 Jul 2013 11:37:21 -0700 (PDT) In-Reply-To: <51F2AD8C.1000003@bsdforen.de> References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> <20130725100037.GM5991@kib.kiev.ua> <51F2AD8C.1000003@bsdforen.de> Date: Fri, 26 Jul 2013 11:37:21 -0700 X-Google-Sender-Auth: NlBlkEYHyIXtDXo1lbwjXPa-OmE Message-ID: Subject: Re: stopping amd causes a freeze From: Artem Belevich To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jul 2013 18:37:22 -0000 On Fri, Jul 26, 2013 at 10:10 AM, Dominic Fandrey wrote: > Amd exhibits several very strange behaviours. > > a) > During the first start it writes the wrong PID into the pidfile, > it however still reacts to SIGTERM. > > b) > After starting it again, it no longer reacts to SIGTERM. > amd does block off signals in some of its sub-processes. For instance amd process that works as NFS server and handles amd mount points does block off INT/TERM/CHLD/HUP. See /usr/src/contrib/amd/amd/nfs_start.c > > c) > It appear to be no longer reacting to SIGHUP, which is required to > tell it that the amd.map was updated. > > Try using 'amq -f' which would ask amd to reload its maps via RPC and should work regardless of whether you know the right PID. Strangely enough amd man page does not mention SIGHUP at all. amd/doc/am-utils.texi in the source tree does, but only when it talks about hlfsd or about 'type:=auto' maps with 'cache' option. Documentation on am-utils.org matches am-utils.texi. As far as I can tell 'amq -f' is the official way to tell amd that it should reload maps. --Artem > d) > It doesn't work at all, I only get: > # cd /media/ufs/FreeBSD_Install > /media/ufs/FreeBSD_Install: Too many levels of symbolic links. > > e) > A SIGKILL without load will terminate the process. A SIGKILL while > there is heavy file system load panics the system. > > I'll try a clean buildworld buildkernel and repeat. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > _______________________________________________ > 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 Fri Jul 26 18:48:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5E9B0911 for ; Fri, 26 Jul 2013 18:48:05 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0EBD12B24 for ; Fri, 26 Jul 2013 18:48:04 +0000 (UTC) Received: (qmail 3583 invoked by uid 1000); 26 Jul 2013 14:41:21 -0400 Date: Fri, 26 Jul 2013 14:41:21 -0400 From: Larry Baird To: sbruno@freebsd.org Subject: Re: bce and "Warning: bootcode thinks driver is absent." Message-ID: <20130726184121.GA99576@gta.com> References: <20130717155531.GA52015@gta.com> <1374859235.2321.4.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1374859235.2321.4.camel@localhost> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Jul 2013 18:48:05 -0000 Sean, On Fri, Jul 26, 2013 at 10:20:35AM -0700, Sean Bruno wrote: > On Wed, 2013-07-17 at 11:55 -0400, Larry Baird wrote: > > Recently under amd64 and 9.1-STABLE I am seeing issues with the bce > > driver. Message is "Warning: bootcode thinks driver is absent". After > > this message, the box appears to be wedged. After rebooting, it got the > > same message during fsck. So we installed 9.2 pre-release using a snapshot > > iso from 7/13/13. Shortly after boot we got the same message. We are now in > > the process of installing 9.1 release to verify this is a driver issue and > > not hardware flaking out. Anybody else seen this issue? > > Hey, looks like we might be seeing similar things. I've been > investigating the fact that FreeBSD appears to be smashing the mangement > firmware because of the ipmi(4) code attempting to attach to the ACPI > and ISA versions of the BMC. > > Do you see attempts to attach to "ipmi1" and do you see various cases > where you get a "NMI" of some kind on an ifconfig up of your network > interfaces? My issues with the bce(4) seem to have been a non-issue. I still see "bce0: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state = 0x00000006)" when booting, but the boxes themselves no longer seem to have an issue. Looking through recent mods to the bce driver I think I was barking up the wrong tree. All of the recent changes seem beneign. Something else in the stable tree was causing my system deadlocks. Current stable seems to be running without an issue for me. Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 27 06:54:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD942851 for ; Sat, 27 Jul 2013 06:54:38 +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]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 217AF29EC for ; Sat, 27 Jul 2013 06:54:37 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1V2yCy-000PdF-Ms; Sat, 27 Jul 2013 09:42:29 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Michael Tratz Subject: Re: NFS deadlock on 9.2-Beta1 In-reply-to: <780BC2DB-3BBA-4396-852B-0EBDF30BF985@esosoft.com> References: <960930050.1702791.1374711910151.JavaMail.root@uoguelph.ca> <780BC2DB-3BBA-4396-852B-0EBDF30BF985@esosoft.com> Comments: In-reply-to Michael Tratz message dated "Thu, 25 Jul 2013 20:05:59 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jul 2013 09:42:28 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Rick Macklem , Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 06:54:38 -0000 > > On Jul 24, 2013, at 5:25 PM, Rick Macklem wrote: > > > Michael Tratz wrote: > >> Two machines (NFS Server: running ZFS / Client: disk-less), both are > >> running FreeBSD r253506. The NFS client starts to deadlock processes > >> within a few hours. It usually gets worse from there on. The > >> processes stay in "D" state. I haven't been able to reproduce it > >> when I want it to happen. I only have to wait a few hours until the > >> deadlocks occur when traffic to the client machine starts to pick > >> up. The only way to fix the deadlocks is to reboot the client. Even > >> an ls to the path which is deadlocked, will deadlock ls itself. It's > >> totally random what part of the file system gets deadlocked. The NFS > >> server itself has no problem at all to access the files/path when > >> something is deadlocked on the client. > >> > >> Last night I decided to put an older kernel on the system r252025 > >> (June 20th). The NFS server stayed untouched. So far 0 deadlocks on > >> the client machine (it should have deadlocked by now). FreeBSD is > >> working hard like it always does. :-) There are a few changes to the > >> NFS code from the revision which seems to work until Beta1. I > >> haven't tried to narrow it down if one of those commits are causing > >> the problem. Maybe someone has an idea what could be wrong and I can > >> test a patch or if it's something else, because I'm not a kernel > >> expert. :-) > >> > > Well, the only NFS client change committed between r252025 and r253506 > > is r253124. It fixes a file corruption problem caused by a previous > > commit that delayed the vnode_pager_setsize() call until after the > > nfs node mutex lock was unlocked. > > > > If you can test with only r253124 reverted to see if that gets rid of > > the hangs, it would be useful, although from the procstats, I doubt it. > > > >> I have run several procstat -kk on the processes including the ls > >> which deadlocked. You can see them here: > >> > >> http://pastebin.com/1RPnFT6r > > > > All the processes you show seem to be stuck waiting for a vnode lock > > or in __utmx_op_wait. (I`m not sure what the latter means.) > > > > What is missing is what processes are holding the vnode locks and > > what they are stuck on. > > > > A starting point might be ``ps axhl``, to see what all the threads > > are doing (particularily the WCHAN for them all). If you can drop into > > the debugger when the NFS mounts are hung and do a ```show alllocks`` > > that could help. See: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > I`ll admit I`d be surprised if r253124 caused this, but who knows. > > > > If there have been changes to your network device driver between > > r252025 and r253506, I`d try reverting those. (If an RPC gets stuck > > waiting for a reply while holding a vnode lock, that would do it.) > > > > Good luck with it and maybe someone else can think of a commit > > between r252025 and r253506 that could cause vnode locking or network > > problems. > > > > rick > > > >> > >> I have tried to mount the file system with and without nolockd. It > >> didn't make a difference. Other than that it is mounted with: > >> > >> rw,nfsv3,tcp,noatime,rsize=32768,wsize=32768 > >> > >> Let me know if you need me to do something else or if some other > >> output is required. I would have to go back to the problem kernel > >> and wait until the deadlock occurs to get that information. > >> > > Thanks Rick and Steven for your quick replies. > > I spoke too soon regarding r252025 fixing the problem. The same issue started to show up after about 1 day and a few hours of uptime. > > "ps axhl" shows all those stuck processes in newnfs > > I recompiled the GENERIC kernel for Beta1 with the debugging options: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > ps and debugging output: > > http://pastebin.com/1v482Dfw > > (I only listed processes matching newnfs, if you need the whole list, please let me know) > > The first PID showing up having that problem is 14001. Certainly the "show alllocks" command shows interesting information for that PID. > I looked through the commit history for those files mentioned in the output to see if there is something obvious to me. But I don't know. :-) > I hope that information helps you to dig deeper into the issue what might be causing those deadlocks. > > I did include the pciconf -lv, because you mentioned network device drivers. It's Intel igb. The same hardware is running a kernel from January 19th, 2013 also as an NFS client. That machine is rock solid. No problems at all. > > I also went to r251611. That's before r251641 (The NFS FHA changes). Same problem. Here is another debugging output from that kernel: > > http://pastebin.com/ryv8BYc4 > > If I should test something else or provide some other output, please let me know. > > Again thank you! > > Michael just a quick 'me too', It usually happens on our ftp server, and it's been happening for a long time. It's diskless, and it happens randomly, so it's difficult to reproduce. We have many other diskless servers running quiet smoothly. danny From owner-freebsd-stable@FreeBSD.ORG Sat Jul 27 08:17:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 946984F2; Sat, 27 Jul 2013 08:17:54 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id C44AE2C02; Sat, 27 Jul 2013 08:17:53 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id D994286203; Sat, 27 Jul 2013 10:17:48 +0200 (CEST) Message-ID: <51F3822C.3080905@bsdforen.de> Date: Sat, 27 Jul 2013 10:17:48 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Artem Belevich Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> <20130725100037.GM5991@kib.kiev.ua> <51F2AD8C.1000003@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 08:17:54 -0000 On 26/07/2013 20:37, Artem Belevich wrote: > On Fri, Jul 26, 2013 at 10:10 AM, Dominic Fandrey wrote: > >> Amd exhibits several very strange behaviours. >> >> a) >> During the first start it writes the wrong PID into the pidfile, >> it however still reacts to SIGTERM. >> >> b) >> After starting it again, it no longer reacts to SIGTERM. >> > > amd does block off signals in some of its sub-processes. For instance amd > process that works as NFS server and handles amd mount points does block > off INT/TERM/CHLD/HUP. See /usr/src/contrib/amd/amd/nfs_start.c Didn't know that. But so sending signals to the process in the pidfile, used to work™. >> c) >> It appear to be no longer reacting to SIGHUP, which is required to >> tell it that the amd.map was updated. >> >> > Try using 'amq -f' which would ask amd to reload its maps via RPC and > should work regardless of whether you know the right PID. amq -m or amq -p just hang there and do nothing right now. As soon as amd is unbroken this is good to know, though. Sending a SIGINFO: load: 0.58 cmd: amq 6071 [kqread] 4.71r 0.00u 0.00s 0% 2132k -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sat Jul 27 08:33:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 69F5E745 for ; Sat, 27 Jul 2013 08:33:22 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id D9B2F2C51 for ; Sat, 27 Jul 2013 08:33:21 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 244208624A; Sat, 27 Jul 2013 10:33:18 +0200 (CEST) Message-ID: <51F385CE.1030606@bsdforen.de> Date: Sat, 27 Jul 2013 10:33:18 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: stopping amd causes a freeze References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> <20130725100037.GM5991@kib.kiev.ua> <51F2AD8C.1000003@bsdforen.de> In-Reply-To: <51F2AD8C.1000003@bsdforen.de> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 08:33:22 -0000 On 26/07/2013 19:10, Dominic Fandrey wrote: > On 25/07/2013 12:00, Konstantin Belousov wrote: >> On Thu, Jul 25, 2013 at 09:56:59AM +0200, Dominic Fandrey wrote: >>> On 22/07/2013 12:07, Konstantin Belousov wrote: >>>> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: >>>>> ... >>>>> >>>>> I run amd through sysutils/automounter, which is a scripting solution >>>>> that generates an amd.map file based on encountered devices and devd >>>>> events. The SIGHUP it sends to amd to tell it the map file was updated >>>>> does not cause problems, only a -SIGKILL- SIGTERM may cause the freeze. >>>>> >>>>> Nothing was mounted (by amd) during the last freeze. >>>>> >>>>> ... >>>> >>>> Are you sure that the machine did not paniced ? Do you have serial console ? >>>> >>>> The amd(8) locks itself into memory, most likely due to the fear of >>>> deadlock. There are some known issues with user wirings in stable/9. >>>> If the problem you see is indeed due to wiring, you might try to apply >>>> r253187-r253191. >>> >>> I tried that. Applying the diff was straightforward enough. But the >>> resulting kernel paniced as soon as it tried to mount the root fs. >> You did provided a useful info to diagnose the issue. >> >> Patch should keep KBI compatible, but, just in case, if you have any >> third-party module, rebuild it. >> >>> >>> So I'll wait for the MFC from someone who knows what he/she is doing. >> >> Patch below booted for me, and I run some sanity check tests for the >> mlockall(2), which also did not resulted in misbehaviour. >> > > Your patch applied cleanly and the system booted with the resulting > kernel. > > Amd exhibits several very strange behaviours. ... I can verify the whole thing with a clean world and kernel. This time I'll concentrate on the first instance of amd: # tail -n3 /var/log/messages Jul 27 10:08:56 mobileKamikaze kernel: newnfs server pid5868@mobileKamikaze:/var/run/automounter.amd.mnt: not responding Jul 27 10:09:41 mobileKamikaze kernel: newnfs server pid5868@mobileKamikaze:/var/run/automounter.amd.mnt: not responding Jul 27 10:11:41 mobileKamikaze last message repeated 3 times The process, it turns out, simply doesn't exist. There is another process, though: # ps auxww | grep -F sbin/amd root 5869 0.0 0.1 12036 8020 ?? S 10:08am 0:00.01 /usr/sbin/amd -r -p -a /var/run/automounter.amd -c 4 -w 2 /var/run/automounter.amd.mnt /var/run/automounter.amd.map # cat /var/run/automounter.amd.pid 5868 Here is what I think happens, amd forks a subprocess and the main process, silently dies after it wrote its pidfile. For completeness: # mount /dev/ufs/5root on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ufs/5stor on /pool/5stor (ufs, local, noatime, soft-updates) /pool/5stor/usr on /usr (nullfs, local, noatime) /pool/5stor/var on /var (nullfs, local, noatime) /usr/home/root on /root (nullfs, local, noatime) tmpfs on /var/log (tmpfs, local) tmpfs on /var/run (tmpfs, local) tmpfs on /tmp (tmpfs, local) Everything else seems to work. I'll revert your patch for now and wait for the MFC. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sat Jul 27 20:21:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 38FA7D24 for ; Sat, 27 Jul 2013 20:21:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C160A2363 for ; Sat, 27 Jul 2013 20:21:14 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAH0r9FGDaFve/2dsb2JhbABbgztKBoMPukeBMHSCJAEBBAEjSA4FFhgCAg0ZAlkGEwmIAQYHBacLkHaBKI4hNAeCY4EiA5kIiwCFI4MwIIFu X-IronPort-AV: E=Sophos;i="4.89,758,1367985600"; d="scan'208";a="42376045" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 27 Jul 2013 16:20:49 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 87602B40E6; Sat, 27 Jul 2013 16:20:49 -0400 (EDT) Date: Sat, 27 Jul 2013 16:20:49 -0400 (EDT) From: Rick Macklem To: Michael Tratz Message-ID: <806421474.2797338.1374956449542.JavaMail.root@uoguelph.ca> In-Reply-To: <780BC2DB-3BBA-4396-852B-0EBDF30BF985@esosoft.com> Subject: Re: NFS deadlock on 9.2-Beta1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Steven Hartland , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 20:21:15 -0000 Michael Tratz wrote: > > On Jul 24, 2013, at 5:25 PM, Rick Macklem > wrote: > > > Michael Tratz wrote: > >> Two machines (NFS Server: running ZFS / Client: disk-less), both > >> are > >> running FreeBSD r253506. The NFS client starts to deadlock > >> processes > >> within a few hours. It usually gets worse from there on. The > >> processes stay in "D" state. I haven't been able to reproduce it > >> when I want it to happen. I only have to wait a few hours until > >> the > >> deadlocks occur when traffic to the client machine starts to pick > >> up. The only way to fix the deadlocks is to reboot the client. > >> Even > >> an ls to the path which is deadlocked, will deadlock ls itself. > >> It's > >> totally random what part of the file system gets deadlocked. The > >> NFS > >> server itself has no problem at all to access the files/path when > >> something is deadlocked on the client. > >> > >> Last night I decided to put an older kernel on the system r252025 > >> (June 20th). The NFS server stayed untouched. So far 0 deadlocks > >> on > >> the client machine (it should have deadlocked by now). FreeBSD is > >> working hard like it always does. :-) There are a few changes to > >> the > >> NFS code from the revision which seems to work until Beta1. I > >> haven't tried to narrow it down if one of those commits are > >> causing > >> the problem. Maybe someone has an idea what could be wrong and I > >> can > >> test a patch or if it's something else, because I'm not a kernel > >> expert. :-) > >> > > Well, the only NFS client change committed between r252025 and > > r253506 > > is r253124. It fixes a file corruption problem caused by a previous > > commit that delayed the vnode_pager_setsize() call until after the > > nfs node mutex lock was unlocked. > > > > If you can test with only r253124 reverted to see if that gets rid > > of > > the hangs, it would be useful, although from the procstats, I doubt > > it. > > > >> I have run several procstat -kk on the processes including the ls > >> which deadlocked. You can see them here: > >> > >> http://pastebin.com/1RPnFT6r > > > > All the processes you show seem to be stuck waiting for a vnode > > lock > > or in __utmx_op_wait. (I`m not sure what the latter means.) > > > > What is missing is what processes are holding the vnode locks and > > what they are stuck on. > > > > A starting point might be ``ps axhl``, to see what all the threads > > are doing (particularily the WCHAN for them all). If you can drop > > into > > the debugger when the NFS mounts are hung and do a ```show > > alllocks`` > > that could help. See: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > I`ll admit I`d be surprised if r253124 caused this, but who knows. > > > > If there have been changes to your network device driver between > > r252025 and r253506, I`d try reverting those. (If an RPC gets stuck > > waiting for a reply while holding a vnode lock, that would do it.) > > > > Good luck with it and maybe someone else can think of a commit > > between r252025 and r253506 that could cause vnode locking or > > network > > problems. > > > > rick > > > >> > >> I have tried to mount the file system with and without nolockd. It > >> didn't make a difference. Other than that it is mounted with: > >> > >> rw,nfsv3,tcp,noatime,rsize=32768,wsize=32768 > >> > >> Let me know if you need me to do something else or if some other > >> output is required. I would have to go back to the problem kernel > >> and wait until the deadlock occurs to get that information. > >> > > Thanks Rick and Steven for your quick replies. > > I spoke too soon regarding r252025 fixing the problem. The same issue > started to show up after about 1 day and a few hours of uptime. > > "ps axhl" shows all those stuck processes in newnfs > > I recompiled the GENERIC kernel for Beta1 with the debugging options: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > ps and debugging output: > > http://pastebin.com/1v482Dfw > > (I only listed processes matching newnfs, if you need the whole list, > please let me know) > Is your "show alllocks" complete? If not, a complete list of locks would definitely help. As for "ps axhl", a complete list of processes/threads might be useful, but not as much, I think. > The first PID showing up having that problem is 14001. Certainly the > "show alllocks" command shows interesting information for that PID. > I looked through the commit history for those files mentioned in the > output to see if there is something obvious to me. But I don't know. > :-) > I hope that information helps you to dig deeper into the issue what > might be causing those deadlocks. > Well, pid 14001 is interesting in that it holds both the sleep lock acquired by sblock() and an NFS vnode lock, but is waiting for another NFS vnode lock, if I read the pastebin stuff correctly. I suspect that this process is somewhere in kern_sendfile(), since that seems to be where sblock() gets called before vn_lock(). It's just a "shot in the dark", but if you can revert r250907 (dated May 22), it might be worth a try. It adds a bunch of stuff to kern_sendfile(), including vn_lock() calls and the date sounds about right. rick ps: I've added kib@ to the cc list, in case he can help with this. He appears to have been involved in the commits MFC'd by r250907. > I did include the pciconf -lv, because you mentioned network device > drivers. It's Intel igb. The same hardware is running a kernel from > January 19th, 2013 also as an NFS client. That machine is rock > solid. No problems at all. > Ok, so it sounds like we are looking for a post-January 19 commit. > I also went to r251611. That's before r251641 (The NFS FHA changes). The FHA changes are server related and my understanding is that the problem is showing up in an NFS client. > Same problem. Here is another debugging output from that kernel: > > http://pastebin.com/ryv8BYc4 > > If I should test something else or provide some other output, please > let me know. > > Again thank you! > > Michael > > > From owner-freebsd-stable@FreeBSD.ORG Sat Jul 27 20:58:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C62C190C for ; Sat, 27 Jul 2013 20:58:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4920724EA for ; Sat, 27 Jul 2013 20:58:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6RKwFfg086812; Sat, 27 Jul 2013 23:58:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6RKwFfg086812 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6RKwFtR086811; Sat, 27 Jul 2013 23:58:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 27 Jul 2013 23:58:15 +0300 From: Konstantin Belousov To: Rick Macklem Subject: Re: NFS deadlock on 9.2-Beta1 Message-ID: <20130727205815.GC4972@kib.kiev.ua> References: <780BC2DB-3BBA-4396-852B-0EBDF30BF985@esosoft.com> <806421474.2797338.1374956449542.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5QAgd0e35j3NYeGe" Content-Disposition: inline In-Reply-To: <806421474.2797338.1374956449542.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org, Steven Hartland , Michael Tratz X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 20:58:26 -0000 --5QAgd0e35j3NYeGe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 27, 2013 at 04:20:49PM -0400, Rick Macklem wrote: > Michael Tratz wrote: > >=20 > > On Jul 24, 2013, at 5:25 PM, Rick Macklem > > wrote: > >=20 > > > Michael Tratz wrote: > > >> Two machines (NFS Server: running ZFS / Client: disk-less), both > > >> are > > >> running FreeBSD r253506. The NFS client starts to deadlock > > >> processes > > >> within a few hours. It usually gets worse from there on. The > > >> processes stay in "D" state. I haven't been able to reproduce it > > >> when I want it to happen. I only have to wait a few hours until > > >> the > > >> deadlocks occur when traffic to the client machine starts to pick > > >> up. The only way to fix the deadlocks is to reboot the client. > > >> Even > > >> an ls to the path which is deadlocked, will deadlock ls itself. > > >> It's > > >> totally random what part of the file system gets deadlocked. The > > >> NFS > > >> server itself has no problem at all to access the files/path when > > >> something is deadlocked on the client. > > >>=20 > > >> Last night I decided to put an older kernel on the system r252025 > > >> (June 20th). The NFS server stayed untouched. So far 0 deadlocks > > >> on > > >> the client machine (it should have deadlocked by now). FreeBSD is > > >> working hard like it always does. :-) There are a few changes to > > >> the > > >> NFS code from the revision which seems to work until Beta1. I > > >> haven't tried to narrow it down if one of those commits are > > >> causing > > >> the problem. Maybe someone has an idea what could be wrong and I > > >> can > > >> test a patch or if it's something else, because I'm not a kernel > > >> expert. :-) > > >>=20 > > > Well, the only NFS client change committed between r252025 and > > > r253506 > > > is r253124. It fixes a file corruption problem caused by a previous > > > commit that delayed the vnode_pager_setsize() call until after the > > > nfs node mutex lock was unlocked. > > >=20 > > > If you can test with only r253124 reverted to see if that gets rid > > > of > > > the hangs, it would be useful, although from the procstats, I doubt > > > it. > > >=20 > > >> I have run several procstat -kk on the processes including the ls > > >> which deadlocked. You can see them here: > > >>=20 > > >> http://pastebin.com/1RPnFT6r > > >=20 > > > All the processes you show seem to be stuck waiting for a vnode > > > lock > > > or in __utmx_op_wait. (I`m not sure what the latter means.) > > >=20 > > > What is missing is what processes are holding the vnode locks and > > > what they are stuck on. > > >=20 > > > A starting point might be ``ps axhl``, to see what all the threads > > > are doing (particularily the WCHAN for them all). If you can drop > > > into > > > the debugger when the NFS mounts are hung and do a ```show > > > alllocks`` > > > that could help. See: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/= kerneldebug-deadlocks.html > > >=20 > > > I`ll admit I`d be surprised if r253124 caused this, but who knows. > > >=20 > > > If there have been changes to your network device driver between > > > r252025 and r253506, I`d try reverting those. (If an RPC gets stuck > > > waiting for a reply while holding a vnode lock, that would do it.) > > >=20 > > > Good luck with it and maybe someone else can think of a commit > > > between r252025 and r253506 that could cause vnode locking or > > > network > > > problems. > > >=20 > > > rick > > >=20 > > >>=20 > > >> I have tried to mount the file system with and without nolockd. It > > >> didn't make a difference. Other than that it is mounted with: > > >>=20 > > >> rw,nfsv3,tcp,noatime,rsize=3D32768,wsize=3D32768 > > >>=20 > > >> Let me know if you need me to do something else or if some other > > >> output is required. I would have to go back to the problem kernel > > >> and wait until the deadlock occurs to get that information. > > >>=20 > >=20 > > Thanks Rick and Steven for your quick replies. > >=20 > > I spoke too soon regarding r252025 fixing the problem. The same issue > > started to show up after about 1 day and a few hours of uptime. > >=20 > > "ps axhl" shows all those stuck processes in newnfs > >=20 > > I recompiled the GENERIC kernel for Beta1 with the debugging options: > >=20 > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html > >=20 > > ps and debugging output: > >=20 > > http://pastebin.com/1v482Dfw > >=20 > > (I only listed processes matching newnfs, if you need the whole list, > > please let me know) > >=20 > Is your "show alllocks" complete? If not, a complete list of locks > would definitely help. As for "ps axhl", a complete list of processes/thr= eads > might be useful, but not as much, I think. >=20 > > The first PID showing up having that problem is 14001. Certainly the > > "show alllocks" command shows interesting information for that PID. > > I looked through the commit history for those files mentioned in the > > output to see if there is something obvious to me. But I don't know. > > :-) > > I hope that information helps you to dig deeper into the issue what > > might be causing those deadlocks. > >=20 > Well, pid 14001 is interesting in that it holds both the sleep lock > acquired by sblock() and an NFS vnode lock, but is waiting for another > NFS vnode lock, if I read the pastebin stuff correctly. >=20 > I suspect that this process is somewhere in kern_sendfile(), since that > seems to be where sblock() gets called before vn_lock(). 14001 is multithreaded, two its threads own shared vnode lock, and third thread sleeps for a lock. >=20 > It's just a "shot in the dark", but if you can revert > r250907 (dated May 22), it might be worth a try. It adds a bunch of > stuff to kern_sendfile(), including vn_lock() calls and the date sounds > about right. The output provided is not useful. I need the data listed in the referenced 'debugging deadlocks' page. >=20 > rick > ps: I've added kib@ to the cc list, in case he can help with this. He > appears to have been involved in the commits MFC'd by r250907. >=20 > > I did include the pciconf -lv, because you mentioned network device > > drivers. It's Intel igb. The same hardware is running a kernel from > > January 19th, 2013 also as an NFS client. That machine is rock > > solid. No problems at all. > >=20 > Ok, so it sounds like we are looking for a post-January 19 commit. >=20 > > I also went to r251611. That's before r251641 (The NFS FHA changes). > The FHA changes are server related and my understanding is that the > problem is showing up in an NFS client. >=20 > > Same problem. Here is another debugging output from that kernel: > >=20 > > http://pastebin.com/ryv8BYc4 > >=20 > > If I should test something else or provide some other output, please > > let me know. > >=20 > > Again thank you! > >=20 > > Michael > >=20 > >=20 > >=20 > _______________________________________________ > 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" --5QAgd0e35j3NYeGe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR9DRmAAoJEJDCuSvBvK1BUeMQAIyH669RB0mjpEVe+b63WOwg aM/bMaIOPinum4uLEuqHgGkhBx5pBtjyLNAswbQ9hfwJtoguDt91tGRHDqaGgZID mJn4xEDv9H5mR+W9+2orkRQ/JS42eub5Wo1+IBGvaSxMvZqqKmyIPClGbC7ldfHL Uto2SsPWoX89cdGOhKA1doji6ixtJ3QEEMY+9Y1OLdRT9wN9XCOEM7ggiEQg2jqV /p/nvMgZ7qA8tqR6roRDPBtMkOeOFYwzDp8/XphNiUx20TgtQpLAazse5NIKHGrb AT6mDAtCjbggCMqypHcavkpCGbLJDoBWLT5cVgph3EvDqT9CPqvJipztlky0XhGz pHygUSl7BzeaIkvoZmD+b7/dmeTW1Ivm9uKN1QJMQhnMincuLmcjDtVuHq9vlrO6 lCGzRBuHLjlngN74OI3GS6rWNOzabz/ls71+WX2rKOQ9BvLo8u6n1QGkpHJbsMgB N2/eq4JYIz+6rTUDMkGqU//ASFHsq1RZvmJDRgkt/NLSKF3VKZQjkfQ7+XhQT17D 5ZZOz6AgIy98MRzEMSlVxx5iYFPuxsvtINkdAPYVL4cQs5dem3aUcnE077fucABS U82vqROseE+s5+D8nYU5FzjZQtgN8Zt4fVoftoE91dIOhlZbXPFH6SFAp2VycD1t IMsQyDw1ggyozOOGDG/O =mF3a -----END PGP SIGNATURE----- --5QAgd0e35j3NYeGe-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 27 22:13:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED8608C0 for ; Sat, 27 Jul 2013 22:13:08 +0000 (UTC) (envelope-from prvs=09200d4ca8=michael@esosoft.com) Received: from eagle.esosoft.net (eagle.esosoft.net [66.241.144.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D04A5274B for ; Sat, 27 Jul 2013 22:13:08 +0000 (UTC) Received: from [74.100.23.197] (port=63588 helo=michaelimac.castillodelsol.com) by eagle.esosoft.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V3CjU-0001eZ-G2; Sat, 27 Jul 2013 15:13:00 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: NFS deadlock on 9.2-Beta1 From: Michael Tratz In-Reply-To: <806421474.2797338.1374956449542.JavaMail.root@uoguelph.ca> Date: Sat, 27 Jul 2013 15:13:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45B457AB-D948-425F-ACE6-F4652036C4A0@esosoft.com> References: <806421474.2797338.1374956449542.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1508) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 22:13:09 -0000 On Jul 27, 2013, at 1:20 PM, Rick Macklem wrote: > Michael Tratz wrote: >>=20 >> On Jul 24, 2013, at 5:25 PM, Rick Macklem >> wrote: >>=20 >>> Michael Tratz wrote: >>>> Two machines (NFS Server: running ZFS / Client: disk-less), both >>>> are >>>> running FreeBSD r253506. The NFS client starts to deadlock >>>> processes >>>> within a few hours. It usually gets worse from there on. The >>>> processes stay in "D" state. I haven't been able to reproduce it >>>> when I want it to happen. I only have to wait a few hours until >>>> the >>>> deadlocks occur when traffic to the client machine starts to pick >>>> up. The only way to fix the deadlocks is to reboot the client. >>>> Even >>>> an ls to the path which is deadlocked, will deadlock ls itself. >>>> It's >>>> totally random what part of the file system gets deadlocked. The >>>> NFS >>>> server itself has no problem at all to access the files/path when >>>> something is deadlocked on the client. >>>>=20 >>>> Last night I decided to put an older kernel on the system r252025 >>>> (June 20th). The NFS server stayed untouched. So far 0 deadlocks >>>> on >>>> the client machine (it should have deadlocked by now). FreeBSD is >>>> working hard like it always does. :-) There are a few changes to >>>> the >>>> NFS code from the revision which seems to work until Beta1. I >>>> haven't tried to narrow it down if one of those commits are >>>> causing >>>> the problem. Maybe someone has an idea what could be wrong and I >>>> can >>>> test a patch or if it's something else, because I'm not a kernel >>>> expert. :-) >>>>=20 >>> Well, the only NFS client change committed between r252025 and >>> r253506 >>> is r253124. It fixes a file corruption problem caused by a previous >>> commit that delayed the vnode_pager_setsize() call until after the >>> nfs node mutex lock was unlocked. >>>=20 >>> If you can test with only r253124 reverted to see if that gets rid >>> of >>> the hangs, it would be useful, although from the procstats, I doubt >>> it. >>>=20 >>>> I have run several procstat -kk on the processes including the ls >>>> which deadlocked. You can see them here: >>>>=20 >>>> http://pastebin.com/1RPnFT6r >>>=20 >>> All the processes you show seem to be stuck waiting for a vnode >>> lock >>> or in __utmx_op_wait. (I`m not sure what the latter means.) >>>=20 >>> What is missing is what processes are holding the vnode locks and >>> what they are stuck on. >>>=20 >>> A starting point might be ``ps axhl``, to see what all the threads >>> are doing (particularily the WCHAN for them all). If you can drop >>> into >>> the debugger when the NFS mounts are hung and do a ```show >>> alllocks`` >>> that could help. See: >>> = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html >>>=20 >>> I`ll admit I`d be surprised if r253124 caused this, but who knows. >>>=20 >>> If there have been changes to your network device driver between >>> r252025 and r253506, I`d try reverting those. (If an RPC gets stuck >>> waiting for a reply while holding a vnode lock, that would do it.) >>>=20 >>> Good luck with it and maybe someone else can think of a commit >>> between r252025 and r253506 that could cause vnode locking or >>> network >>> problems. >>>=20 >>> rick >>>=20 >>>>=20 >>>> I have tried to mount the file system with and without nolockd. It >>>> didn't make a difference. Other than that it is mounted with: >>>>=20 >>>> rw,nfsv3,tcp,noatime,rsize=3D32768,wsize=3D32768 >>>>=20 >>>> Let me know if you need me to do something else or if some other >>>> output is required. I would have to go back to the problem kernel >>>> and wait until the deadlock occurs to get that information. >>>>=20 >>=20 >> Thanks Rick and Steven for your quick replies. >>=20 >> I spoke too soon regarding r252025 fixing the problem. The same issue >> started to show up after about 1 day and a few hours of uptime. >>=20 >> "ps axhl" shows all those stuck processes in newnfs >>=20 >> I recompiled the GENERIC kernel for Beta1 with the debugging options: >>=20 >> = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html >>=20 >> ps and debugging output: >>=20 >> http://pastebin.com/1v482Dfw >>=20 >> (I only listed processes matching newnfs, if you need the whole list, >> please let me know) >>=20 > Is your "show alllocks" complete? If not, a complete list of locks > would definitely help. As for "ps axhl", a complete list of = processes/threads > might be useful, but not as much, I think. Yes that was the entire output for show alllocks. =20 >=20 >> The first PID showing up having that problem is 14001. Certainly the >> "show alllocks" command shows interesting information for that PID. >> I looked through the commit history for those files mentioned in the >> output to see if there is something obvious to me. But I don't know. >> :-) >> I hope that information helps you to dig deeper into the issue what >> might be causing those deadlocks. >>=20 > Well, pid 14001 is interesting in that it holds both the sleep lock > acquired by sblock() and an NFS vnode lock, but is waiting for another > NFS vnode lock, if I read the pastebin stuff correctly. >=20 > I suspect that this process is somewhere in kern_sendfile(), since = that > seems to be where sblock() gets called before vn_lock(). >=20 > It's just a "shot in the dark", but if you can revert > r250907 (dated May 22), it might be worth a try. It adds a bunch of > stuff to kern_sendfile(), including vn_lock() calls and the date = sounds > about right. >=20 > rick > ps: I've added kib@ to the cc list, in case he can help with this. He > appears to have been involved in the commits MFC'd by r250907. Thanks for adding kib. He already responded and it looks like he needs = more data. I'll give your suggestion a try, too. I already was thinking I'm going = to build some kernels from the revision I know is working fine till we = hit one which starts that issue. Then it will be easier to narrow it down what commit might be causing = the problem. >=20 >> I did include the pciconf -lv, because you mentioned network device >> drivers. It's Intel igb. The same hardware is running a kernel from >> January 19th, 2013 also as an NFS client. That machine is rock >> solid. No problems at all. >>=20 > Ok, so it sounds like we are looking for a post-January 19 commit. I did more testing in the meantime. I added another machine. Using = kernel r253698. Same thing after a few hours deadlocks. I did capture a show alllocks of this deadlock. But it's probably not = going to be useful for kib. http://pastebin.com/MnpVZN85 The machine which was the original problem child has been running = without a hitch with that Jan 19 kernel (r245665) for almost 2 days.=20 I accidentally found out if a NFS server is freshly rebooted, the = deadlock usually happens within an hour or two. That allows me now to = pretty much reproduce the problem quickly. I'll test more and I'll also see what data kib needs and provide that to = him. >=20 >> I also went to r251611. That's before r251641 (The NFS FHA changes). > The FHA changes are server related and my understanding is that the > problem is showing up in an NFS client. That's correct. Only the NFS client is having a problem. The NFS server = remained unchanged during all the testing and is running r253506. I was just stumbling around in the dark and trying out different things. = :-) >=20 >> Same problem. Here is another debugging output from that kernel: >>=20 >> http://pastebin.com/ryv8BYc4 >>=20 >> If I should test something else or provide some other output, please >> let me know. >>=20 >> Again thank you! >>=20 >> Michael >>=20 >>=20 >>=20 > _______________________________________________ > 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 Sat Jul 27 22:13:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9BDCE8C1 for ; Sat, 27 Jul 2013 22:13:11 +0000 (UTC) (envelope-from prvs=09200d4ca8=michael@esosoft.com) Received: from eagle.esosoft.net (eagle.esosoft.net [66.241.144.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80BD6274C for ; Sat, 27 Jul 2013 22:13:11 +0000 (UTC) Received: from [74.100.23.197] (port=63588 helo=michaelimac.castillodelsol.com) by eagle.esosoft.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V3CjZ-0001eZ-9H; Sat, 27 Jul 2013 15:13:05 -0700 Subject: Re: NFS deadlock on 9.2-Beta1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Michael Tratz In-Reply-To: <20130727205815.GC4972@kib.kiev.ua> Date: Sat, 27 Jul 2013 15:13:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <602747E8-0EBE-4BB1-8019-C02C25B75FA1@esosoft.com> References: <780BC2DB-3BBA-4396-852B-0EBDF30BF985@esosoft.com> <806421474.2797338.1374956449542.JavaMail.root@uoguelph.ca> <20130727205815.GC4972@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Steven Hartland , Rick Macklem , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Jul 2013 22:13:11 -0000 On Jul 27, 2013, at 1:58 PM, Konstantin Belousov = wrote: > On Sat, Jul 27, 2013 at 04:20:49PM -0400, Rick Macklem wrote: >> Michael Tratz wrote: >>>=20 >>> On Jul 24, 2013, at 5:25 PM, Rick Macklem >>> wrote: >>>=20 >>>> Michael Tratz wrote: >>>>> Two machines (NFS Server: running ZFS / Client: disk-less), both >>>>> are >>>>> running FreeBSD r253506. The NFS client starts to deadlock >>>>> processes >>>>> within a few hours. It usually gets worse from there on. The >>>>> processes stay in "D" state. I haven't been able to reproduce it >>>>> when I want it to happen. I only have to wait a few hours until >>>>> the >>>>> deadlocks occur when traffic to the client machine starts to pick >>>>> up. The only way to fix the deadlocks is to reboot the client. >>>>> Even >>>>> an ls to the path which is deadlocked, will deadlock ls itself. >>>>> It's >>>>> totally random what part of the file system gets deadlocked. The >>>>> NFS >>>>> server itself has no problem at all to access the files/path when >>>>> something is deadlocked on the client. >>>>>=20 >>>>> Last night I decided to put an older kernel on the system r252025 >>>>> (June 20th). The NFS server stayed untouched. So far 0 deadlocks >>>>> on >>>>> the client machine (it should have deadlocked by now). FreeBSD is >>>>> working hard like it always does. :-) There are a few changes to >>>>> the >>>>> NFS code from the revision which seems to work until Beta1. I >>>>> haven't tried to narrow it down if one of those commits are >>>>> causing >>>>> the problem. Maybe someone has an idea what could be wrong and I >>>>> can >>>>> test a patch or if it's something else, because I'm not a kernel >>>>> expert. :-) >>>>>=20 >>>> Well, the only NFS client change committed between r252025 and >>>> r253506 >>>> is r253124. It fixes a file corruption problem caused by a previous >>>> commit that delayed the vnode_pager_setsize() call until after the >>>> nfs node mutex lock was unlocked. >>>>=20 >>>> If you can test with only r253124 reverted to see if that gets rid >>>> of >>>> the hangs, it would be useful, although from the procstats, I doubt >>>> it. >>>>=20 >>>>> I have run several procstat -kk on the processes including the ls >>>>> which deadlocked. You can see them here: >>>>>=20 >>>>> http://pastebin.com/1RPnFT6r >>>>=20 >>>> All the processes you show seem to be stuck waiting for a vnode >>>> lock >>>> or in __utmx_op_wait. (I`m not sure what the latter means.) >>>>=20 >>>> What is missing is what processes are holding the vnode locks and >>>> what they are stuck on. >>>>=20 >>>> A starting point might be ``ps axhl``, to see what all the threads >>>> are doing (particularily the WCHAN for them all). If you can drop >>>> into >>>> the debugger when the NFS mounts are hung and do a ```show >>>> alllocks`` >>>> that could help. See: >>>> = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html >>>>=20 >>>> I`ll admit I`d be surprised if r253124 caused this, but who knows. >>>>=20 >>>> If there have been changes to your network device driver between >>>> r252025 and r253506, I`d try reverting those. (If an RPC gets stuck >>>> waiting for a reply while holding a vnode lock, that would do it.) >>>>=20 >>>> Good luck with it and maybe someone else can think of a commit >>>> between r252025 and r253506 that could cause vnode locking or >>>> network >>>> problems. >>>>=20 >>>> rick >>>>=20 >>>>>=20 >>>>> I have tried to mount the file system with and without nolockd. It >>>>> didn't make a difference. Other than that it is mounted with: >>>>>=20 >>>>> rw,nfsv3,tcp,noatime,rsize=3D32768,wsize=3D32768 >>>>>=20 >>>>> Let me know if you need me to do something else or if some other >>>>> output is required. I would have to go back to the problem kernel >>>>> and wait until the deadlock occurs to get that information. >>>>>=20 >>>=20 >>> Thanks Rick and Steven for your quick replies. >>>=20 >>> I spoke too soon regarding r252025 fixing the problem. The same = issue >>> started to show up after about 1 day and a few hours of uptime. >>>=20 >>> "ps axhl" shows all those stuck processes in newnfs >>>=20 >>> I recompiled the GENERIC kernel for Beta1 with the debugging = options: >>>=20 >>> = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html >>>=20 >>> ps and debugging output: >>>=20 >>> http://pastebin.com/1v482Dfw >>>=20 >>> (I only listed processes matching newnfs, if you need the whole = list, >>> please let me know) >>>=20 >> Is your "show alllocks" complete? If not, a complete list of locks >> would definitely help. As for "ps axhl", a complete list of = processes/threads >> might be useful, but not as much, I think. >>=20 >>> The first PID showing up having that problem is 14001. Certainly the >>> "show alllocks" command shows interesting information for that PID. >>> I looked through the commit history for those files mentioned in the >>> output to see if there is something obvious to me. But I don't know. >>> :-) >>> I hope that information helps you to dig deeper into the issue what >>> might be causing those deadlocks. >>>=20 >> Well, pid 14001 is interesting in that it holds both the sleep lock >> acquired by sblock() and an NFS vnode lock, but is waiting for = another >> NFS vnode lock, if I read the pastebin stuff correctly. >>=20 >> I suspect that this process is somewhere in kern_sendfile(), since = that >> seems to be where sblock() gets called before vn_lock(). > 14001 is multithreaded, two its threads own shared vnode lock, and > third thread sleeps for a lock. >=20 >>=20 >> It's just a "shot in the dark", but if you can revert >> r250907 (dated May 22), it might be worth a try. It adds a bunch of >> stuff to kern_sendfile(), including vn_lock() calls and the date = sounds >> about right. > The output provided is not useful. >=20 > I need the data listed in the referenced 'debugging deadlocks' page. Now that I have a way of pretty much reproducing the problem quite = quickly, I can get you the data. I never debugged a kernel before so it's a new territory for me. A first = for everything right? :-) If you can help me with the commands I can = retrieve it. I found this paper talking about "Live Debugging DDB" http://people.freebsd.org/~jhb/papers/bsdcan/2008/article/node3.html Let's assume the pid which started the deadlock is 14001 (it will be a = different pid when we get the results, because the machine has been = restarted) I type: show proc 14001 I get the thread numbers from that output and type: show thread xxxxx for each one. And a trace for each thread with the command? tr xxxx Anything else I should try to get or do? Or is that not the data at all = you are looking for? >=20 >>=20 >> rick >> ps: I've added kib@ to the cc list, in case he can help with this. He >> appears to have been involved in the commits MFC'd by r250907. >>=20 >>> I did include the pciconf -lv, because you mentioned network device >>> drivers. It's Intel igb. The same hardware is running a kernel from >>> January 19th, 2013 also as an NFS client. That machine is rock >>> solid. No problems at all. >>>=20 >> Ok, so it sounds like we are looking for a post-January 19 commit. >>=20 >>> I also went to r251611. That's before r251641 (The NFS FHA changes). >> The FHA changes are server related and my understanding is that the >> problem is showing up in an NFS client. >>=20 >>> Same problem. Here is another debugging output from that kernel: >>>=20 >>> http://pastebin.com/ryv8BYc4 >>>=20 >>> If I should test something else or provide some other output, please >>> let me know. >>>=20 >>> Again thank you! >>>=20 >>> Michael >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> 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"