From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 19:20:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5AE3106564A for ; Sat, 17 Jul 2010 19:20:10 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by mx1.freebsd.org (Postfix) with ESMTP id ACD7D8FC08 for ; Sat, 17 Jul 2010 19:20:10 +0000 (UTC) Received: from aldan.narawntapu ([unknown] [173.70.194.135]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5P00FAPS8OSKA2@vms173015.mailsrvcs.net> for freebsd-stable@freebsd.org; Sat, 17 Jul 2010 13:19:41 -0500 (CDT) Message-id: <4C41F437.2060209@aldan.algebra.com> Date: Sat, 17 Jul 2010 14:19:35 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk; rv:1.9.1.10) Gecko/20100716 Thunderbird/3.0.5 MIME-version: 1.0 To: Jeremy Chadwick References: <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> In-reply-to: <20100717134149.GA40907@icarus.home.lan> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Sun, 18 Jul 2010 00:26:28 +0000 Cc: Reko Turja , freebsd-stable@freebsd.org, Henrik /KaarPoSoft , Joerg Pulz Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 19:20:10 -0000 On 17.07.2010 09:41, Jeremy Chadwick wrote: > The test system is amd64. I'm not doubting the issue may be more > apparent/easier to occur on i386, but "pure luck on amd64" is a bit > surprising. > > I'll build an i386 version of my testbox and start the procedure over > again. > Set the malloc(3) flags to paranoid (like "AJ" or "AZ"). You should then be able to reproduce it on any platform... Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 02:20:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02B391065672 for ; Sun, 18 Jul 2010 02:20:55 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id A48028FC08 for ; Sun, 18 Jul 2010 02:20:54 +0000 (UTC) Received: from visi.gothic.net.au (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id DCB7541F21 for ; Sun, 18 Jul 2010 12:20:52 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by visi.gothic.net.au (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id 4L58f5ZhJPFi for ; Sun, 18 Jul 2010 12:20:44 +1000 (EST) Received: from [10.168.1.181] (dhcp181.gothic.net.au [10.168.1.181]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id 0675641F18 for ; Sun, 18 Jul 2010 12:20:43 +1000 (EST) Message-ID: <4C4264F1.4010708@gothic.net.au> Date: Sun, 18 Jul 2010 12:20:33 +1000 From: Sean User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100717152455.GA61987@ravenloft.kiev.ua> In-Reply-To: <20100717152455.GA61987@ravenloft.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 02:20:55 -0000 On 18/07/2010 1:24 AM, Alex Kozlov wrote: > Hi, stable > > After updating my buildbox from 26 April 8-STABLE > to 8.1-RC2 I constantly getting SIGEPIPE > [snip] I'm getting the same thing; what shell are you using? I changed my shell on one machine from /bin/tcsh to /usr/local/bin/bash and problem disappeared. > > -- > Adios > _______________________________________________ > 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 18 02:38:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA15106566C for ; Sun, 18 Jul 2010 02:38:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3878FC15 for ; Sun, 18 Jul 2010 02:38:21 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id jDgV1e0041GXsucAFEeMum; Sun, 18 Jul 2010 02:38:21 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta07.emeryville.ca.mail.comcast.net with comcast id jEeK1e0083LrwQ28UEeLGa; Sun, 18 Jul 2010 02:38:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B66969B425; Sat, 17 Jul 2010 19:38:19 -0700 (PDT) Date: Sat, 17 Jul 2010 19:38:19 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100718023819.GA58471@icarus.home.lan> References: <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Benjamin Lee , "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft , Joerg Pulz Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 02:38:22 -0000 On Sun, Jul 18, 2010 at 01:37:06AM +0300, Reko Turja wrote: > > >Can you try reproducing the issue on 8-STABLE? > > > >I recently submitted a Heimdal patch against 8.1-STABLE and > >9.0-CURRENT that resolves some libgssapi-related issues: > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454 > > > >The patch breaks ABI, so you'll have to rebuild libgssapi-dependent > >applications. > > When linking cyrus-sasl2 against gssapi library from either the > 1.0.1 official port or the inofficial 1.2.1 patchset cyradm works as > expected and it logs a message from gssapi/kerberos telling that no > KDC's are available - which is to be expected on a system that isn't > using gssapi/kerberos in authenticating. > > So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday > the 5th is clearly some kind of regression as system gsslib doesn't > seem to recognize the mech used or segfaults. > > Benjamin, can you clarify how to apply your patch against the source > tree - I tried 'patch < the_patchset.diff' in /usr/src but it just > created a bunch of files in the /usr/src which I think isn't the > intention. Those following this thread will be happy to hear that I'm able to reproduce the problem on the i386 test box: testbox# pkg_info cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer) db41-4.1.25_4 The Berkeley DB package, revision 4.1 libtool-2.2.6b Generic shared library support script perl-5.10.1_1 Practical Extraction and Report Language portaudit-0.5.15 Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411 Vi "workalike", with many additional features (Lite package testbox# cyradm localhost Segmentation fault (core dumped) Jul 17 19:35:40 testbox imap[72119]: executed Jul 17 19:35:40 testbox imap[72119]: accepted connection Jul 17 19:35:46 testbox kernel: pid 72118 (perl5.10.1), uid 0: exited on signal 11 (core dumped) -rw------- 1 root wheel 4448256 Jul 17 19:35 perl5.10.1.core (gdb) bt #0 free (ptr=0x280861c0) at /usr/src/lib/libc/stdlib/malloc.c:3890 #1 0x287edce2 in gss_release_buffer (minor_status=0xbfbfe698, buffer=0x280861cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 #2 0x287ed6b2 in _gss_mg_error (m=0x28455bc0, maj=851968, min=2) at /usr/src/lib/libgssapi/gss_display_status.c:240 #3 0x287ea009 in gss_init_sec_context (minor_status=0xbfbfe7a8, initiator_cred_handle=0x0, context_handle=0x28837354, target_name=0x285bff60, input_mech_type=0x0, req_flags=58, time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, output_token=0xbfbfe790, ret_flags=0xbfbfe7a0, time_rec=0x0) at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 #4 0x287e1aef in gssapi_client_mech_step (conn_context=0x28837350, params=0x2841e480, serverin=0x0, serverinlen=0, prompt_need=0xbfbfea70, clientout=0xbfbfea6c, clientoutlen=0xbfbfea68, oparams=0x2846b860) at gssapi.c:1418 #5 0x283ef591 in sasl_client_step (conn=0x2846b000, serverin=0x0, serverinlen=0, prompt_need=0xbfbfea70, clientout=0xbfbfea6c, clientoutlen=0xbfbfea68) at client.c:655 #6 0x283f0215 in sasl_client_start (conn=0x2846b000, mechlist=0x288878c0 "GSSAPI ", prompt_need=0xbfbfea70, clientout=0xbfbfea6c, clientoutlen=0xbfbfea68, mech=0xbfbfea78) at client.c:603 #7 0x2832ab1a in imclient_authenticate (imclient=0x288b4000, mechlist=0x28887880 "GSSAPI ", service=0x288877e8 "imap", user=0x28801754 "", minssf=0, maxssf=10000) at imclient.c:1288 #8 0x28327131 in XS_Cyrus__IMAP__authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #9 0x2811d2e5 in Perl_pp_entersub () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so #10 0x2811b7e5 in Perl_runops_standard () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so #11 0x280c20d4 in perl_run () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so #12 0x08048944 in main () I'll poke more at this. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 03:08:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E961065676 for ; Sun, 18 Jul 2010 03:08:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 00AA38FC16 for ; Sun, 18 Jul 2010 03:08:09 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta04.emeryville.ca.mail.comcast.net with comcast id jEin1e0051Y3wxoA4F89Ui; Sun, 18 Jul 2010 03:08:09 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id jF881e0083LrwQ28bF88mV; Sun, 18 Jul 2010 03:08:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 319BE9B425; Sat, 17 Jul 2010 20:08:08 -0700 (PDT) Date: Sat, 17 Jul 2010 20:08:08 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100718030808.GA58818@icarus.home.lan> References: <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> <20100718023819.GA58471@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100718023819.GA58471@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Benjamin Lee , "Mikhail T." , freebsd-stable@freebsd.org, Joerg Pulz , Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 03:08:10 -0000 On Sat, Jul 17, 2010 at 07:38:19PM -0700, Jeremy Chadwick wrote: > On Sun, Jul 18, 2010 at 01:37:06AM +0300, Reko Turja wrote: > > > > >Can you try reproducing the issue on 8-STABLE? > > > > > >I recently submitted a Heimdal patch against 8.1-STABLE and > > >9.0-CURRENT that resolves some libgssapi-related issues: > > > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454 > > > > > >The patch breaks ABI, so you'll have to rebuild libgssapi-dependent > > >applications. > > > > When linking cyrus-sasl2 against gssapi library from either the > > 1.0.1 official port or the inofficial 1.2.1 patchset cyradm works as > > expected and it logs a message from gssapi/kerberos telling that no > > KDC's are available - which is to be expected on a system that isn't > > using gssapi/kerberos in authenticating. > > > > So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday > > the 5th is clearly some kind of regression as system gsslib doesn't > > seem to recognize the mech used or segfaults. > > > > Benjamin, can you clarify how to apply your patch against the source > > tree - I tried 'patch < the_patchset.diff' in /usr/src but it just > > created a bunch of files in the /usr/src which I think isn't the > > intention. > > Those following this thread will be happy to hear that I'm able to > reproduce the problem on the i386 test box: > > testbox# pkg_info > cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols > cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer) > db41-4.1.25_4 The Berkeley DB package, revision 4.1 > libtool-2.2.6b Generic shared library support script > perl-5.10.1_1 Practical Extraction and Report Language > portaudit-0.5.15 Checks installed ports against a list of security vulnerabi > rsync-3.0.7 A network file distribution/synchronization utility > vim-lite-7.2.411 Vi "workalike", with many additional features (Lite package > > testbox# cyradm localhost > Segmentation fault (core dumped) > > Jul 17 19:35:40 testbox imap[72119]: executed > Jul 17 19:35:40 testbox imap[72119]: accepted connection > Jul 17 19:35:46 testbox kernel: pid 72118 (perl5.10.1), uid 0: exited on signal 11 (core dumped) > > -rw------- 1 root wheel 4448256 Jul 17 19:35 perl5.10.1.core > > (gdb) bt > #0 free (ptr=0x280861c0) at /usr/src/lib/libc/stdlib/malloc.c:3890 > #1 0x287edce2 in gss_release_buffer (minor_status=0xbfbfe698, buffer=0x280861cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 > #2 0x287ed6b2 in _gss_mg_error (m=0x28455bc0, maj=851968, min=2) at /usr/src/lib/libgssapi/gss_display_status.c:240 > #3 0x287ea009 in gss_init_sec_context (minor_status=0xbfbfe7a8, initiator_cred_handle=0x0, context_handle=0x28837354, > target_name=0x285bff60, input_mech_type=0x0, req_flags=58, time_req=0, input_chan_bindings=0x0, input_token=0x0, > actual_mech_type=0x0, output_token=0xbfbfe790, ret_flags=0xbfbfe7a0, time_rec=0x0) > at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 > #4 0x287e1aef in gssapi_client_mech_step (conn_context=0x28837350, params=0x2841e480, serverin=0x0, serverinlen=0, > prompt_need=0xbfbfea70, clientout=0xbfbfea6c, clientoutlen=0xbfbfea68, oparams=0x2846b860) at gssapi.c:1418 > #5 0x283ef591 in sasl_client_step (conn=0x2846b000, serverin=0x0, serverinlen=0, prompt_need=0xbfbfea70, clientout=0xbfbfea6c, > clientoutlen=0xbfbfea68) at client.c:655 > #6 0x283f0215 in sasl_client_start (conn=0x2846b000, mechlist=0x288878c0 "GSSAPI ", prompt_need=0xbfbfea70, clientout=0xbfbfea6c, > clientoutlen=0xbfbfea68, mech=0xbfbfea78) at client.c:603 > #7 0x2832ab1a in imclient_authenticate (imclient=0x288b4000, mechlist=0x28887880 "GSSAPI ", service=0x288877e8 "imap", > user=0x28801754 "", minssf=0, maxssf=10000) at imclient.c:1288 > #8 0x28327131 in XS_Cyrus__IMAP__authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so > #9 0x2811d2e5 in Perl_pp_entersub () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #10 0x2811b7e5 in Perl_runops_standard () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #11 0x280c20d4 in perl_run () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #12 0x08048944 in main () > > I'll poke more at this. Problem solved. Same i386 box: testbox# uname -a FreeBSD testbox.home.lan 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Sat Jul 17 18:46:34 PDT 2010 root@testbox.home.lan:/usr/obj/usr/src/sys/TESTBOX i386 testbox# ls -l /usr/lib/libgssapi.so* lrwxr-xr-x 1 root wheel 15 Jul 17 19:47 /usr/lib/libgssapi.so -> libgssapi.so.10 -r--r--r-- 1 root wheel 1702244 Jul 17 19:47 /usr/lib/libgssapi.so.10 testbox# cyradm localhost Login disabled. cyradm: cannot authenticate to server with as root Jul 17 19:48:51 testbox master[72266]: about to exec /usr/local/cyrus/bin/imapd Jul 17 19:48:51 testbox imap[72266]: executed Jul 17 19:48:51 testbox imap[72266]: accepted connection Jul 17 19:48:51 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 17 19:48:51 testbox kernel: Jul 17 19:48:51 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 17 19:48:51 testbox perl: No worthy mechs found Jul 17 19:48:51 testbox kernel: Jul 17 19:48:51 testbox perl: No worthy mechs found I then tested the same patch on amd64 -- it also works. Again, this has only been tested on RELENG_8. Methodology for patching/fixing is simple: cd /usr/src patch -p0 < /path/to/patch cd lib/libgssapi make make install Then restart any daemons which link to libgssapi or any of the related libgssapi_xxx libraries (you can use ldd to determine this). In the above case, all I had restart was imapd. You *do not* need to rebuild software which is reliant upon libgssapi; the function semantics/API hasn't changed, just the code within one of the functions (gss_release_buffer()). There's no need to bump the library version number either because of this. As far as why it's more prevalent on i386 than amd64: a disassembly would probably help explain that. But to be honest, the last time I worked with x86 assembly was back in the 386/very early 486 days, and that was pure protected mode programming (not under *IX). There's basically little to no chance I'd understand the disassembly here. Someone else would have to delve into it. People who have open PRs on this matter -- please feel free to reference this thread, and/or the below patch, in your PRs. I've also put the patch up on my website for easy fetching: http://jdc.parodius.com/freebsd/gss_release_buffer.c.patch Cheers! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | --- lib/libgssapi/gss_release_buffer.c.orig 2009-08-03 01:13:06.000000000 -0700 +++ lib/libgssapi/gss_release_buffer.c 2010-07-17 19:47:25.000000000 -0700 @@ -37,7 +37,7 @@ { *minor_status = 0; - if (buffer->value) + if (buffer->length && buffer->value) free(buffer->value); _gss_buffer_zero(buffer); From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 08:32:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A151F106566B for ; Sun, 18 Jul 2010 08:32:20 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id 454EE8FC0A for ; Sun, 18 Jul 2010 08:32:20 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 61BC71CC5A; Sun, 18 Jul 2010 11:32:19 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 61BC71CC5A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279441939; bh=ZFXYoUmTOtUEvuXz+tglBproi+EKwdR3KdJ9RRLjL88=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YrzObY+rgnyyy16QV1L999o4umZ7PLeySMhXTGLu16cJi9/Jv1DwOYMz0hr0Ajjhy za2w3xdSeFJrT7uW4SPbXTRUEtd4C+BvziRhDBzq6HS37CWorYJrvyus7kRK3WhQ+5 aOAsGU7rnoIO7I2XPPjZZbmNJaV9BfMUe1RHp1HA= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J-LnyVwGRouO; Sun, 18 Jul 2010 11:32:16 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 106CE1CC59; Sun, 18 Jul 2010 11:32:14 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 106CE1CC59 Message-ID: <2C543F30777B4BB6BC1474ABB4193AEB@rivendell> From: "Reko Turja" To: "Benjamin Lee" References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> In-Reply-To: <4C41F34E.2030309@b1c1l1.com> Date: Sun, 18 Jul 2010 11:32:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , Jeremy Chadwick , freebsd-stable@freebsd.org, Joerg Pulz , Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 08:32:20 -0000 Applying Benjamin's patch to RELENG_8 sources csupped yesterday stops=20 the buildworld in last library stage: In file included from /usr/src/lib/libc/rpc/clnt_dg.c:55: /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:52: error: expected=20 specifier-qualifier-list before 'gss_cred_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:65: error: expected=20 specifier-qualifier-list before 'gss_ctx_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:119: error: expected=20 declaration specifiers or '...' before 'gss_cred_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:120: error: expected=20 declaration specifiers or '...' before 'gss_ctx_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:149: error: expected=20 declaration specifiers or '...' before 'gss_OID' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:150: error: expected=20 ')' before 'oid' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Tried to poke around a bit but I was unable to find declarations for=20 the missing types. How to proceed if I want to test the patch? -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 13:52:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1812A106564A for ; Sun, 18 Jul 2010 13:52:20 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id B016C8FC16 for ; Sun, 18 Jul 2010 13:52:19 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 26FFD1CC5A; Sun, 18 Jul 2010 16:52:18 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 26FFD1CC5A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279461138; bh=88DJ5OyTc+fxspntALiGULg8p28dVvEpt7w0LDVb89o=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mHQfPywKK644Hbii/CM1w2bDc24tO711KAvn2SW8rbpvKTxa9lDFBcd7RhgmeV9fx XVku/UVuH3i3XzTfH69dPLroYAIHLmNLeMmTqrlJYstC8UCD7RjNrWzbNRqnk97UU6 VKQDu8Va543/aqOFktK0XgM7XOJoBBr4tXzzR5F8= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id X4ubqJt0nJcq; Sun, 18 Jul 2010 16:52:15 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id E64A11CC59; Sun, 18 Jul 2010 16:52:14 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net E64A11CC59 Message-ID: From: "Reko Turja" To: "Benjamin Lee" References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> In-Reply-To: <4C41F34E.2030309@b1c1l1.com> Date: Sun, 18 Jul 2010 16:52:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , Jeremy Chadwick , freebsd-stable@freebsd.org, Joerg Pulz , Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 13:52:20 -0000 After manually changing the gssapi header used in=20 /usr/src/include/rpc/rpcsec_gss.h to somewhat klunky "#include=20 "/usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h"" system csupped=20 yesterday built okay and after rebuilding cyrus-sasl, saslauthd and=20 cyrus I get the following failures in log: Jul 18 16:37:35 moria perl: GSSAPI Error: Miscellaneous failure (see=20 text)^B (open(/tmp/krb5cc_0): No such file or directory) -This is expected behaviour as Kerberos was not running at the moment,=20 but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error=20 message After dusting off my old Kerberos setup, doing basic kinit and running=20 cyradm localhost I got: Jul 18 16:39:00 moria perl: GSSAPI Error: Miscellaneous failure (see=20 text) (Server (imap/localhost@XXX.DOMAIN.COM) unknown) -Again expected as there is no imap trust relationship defined. So at least after cursory testing it looks like that with Benjamin's=20 patch there is a working GSSAPI/Kerberos backend available, instead of=20 something that chokes on passed parameters that are ok for every other=20 tested gssapi implementation. Of course, more thorough testing in proper kerberised/LDAP environment=20 needs to be done, which is something I haven't got time at the moment. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 15:15:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929901065677 for ; Sun, 18 Jul 2010 15:15:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B161B8FC0A for ; Sun, 18 Jul 2010 15:15:06 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o6IFF2Qa035145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 18:15:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o6IFF2wq028110; Sun, 18 Jul 2010 18:15:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6IFEveO028107; Sun, 18 Jul 2010 18:14:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Jul 2010 18:14:57 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20100718151457.GP2381@deviant.kiev.zoral.com.ua> References: <20100717152455.GA61987@ravenloft.kiev.ua> <20100717221150.GA18562@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U/fW6JBK3GqE0Htg" Content-Disposition: inline In-Reply-To: <20100717221150.GA18562@stack.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Alex Kozlov Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 15:15:08 -0000 --U/fW6JBK3GqE0Htg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2010 at 12:11:50AM +0200, Jilles Tjoelker wrote: > On Sat, Jul 17, 2010 at 06:24:55PM +0300, Alex Kozlov wrote: > > After updating my buildbox from 26 April 8-STABLE > > to 8.1-RC2 I constantly getting SIGEPIPE >=20 > > portsnap: > > Fetching 4 metadata patches... done. > > Applying metadata patches... done. > > Fetching 0 metadata files... done. > > Fetching 27 patches.....10....20... done. > > Applying patches... done. > > Fetching 3 new ports or files... done. > > sort: write failed: standard output: Broken pipe > > sort: write error > > Removing old files and directories... done. >=20 > > sudo make -C /usr/ports/converters/ascii2binary: > > =3D=3D=3D> Patching for ascii2binary-2.13_2 > > =3D=3D=3D> Applying FreeBSD patches for ascii2binary-2.13_2 > > =3D=3D=3D> ascii2binary-2.13_2 depends on shared library: intlgrep: w= riting output: Broken pipe > > grep: writing output: Broken pipe > [snip repetition] > > - found > > =3D=3D=3D> Configuring for ascii2binary-2.13_2 >=20 > > Does anyone know something about this issue? >=20 > This looks more like the absence of SIGPIPE than an inappropriate > SIGPIPE. I can reproduce both of those error messages by running the > commands with SIGPIPE ignored. grep(1) seems to behave strangely on > write errors, not aborting, for example > yes | { trap '' PIPE; grep -v foo; echo $? >&2; } | : > prints an endless stream of error messages. >=20 > Note that sh(1) silently ignores attempts to change the disposition of > signals that were ignored on entry to the shell, so a > trap - PIPE > is unlikely to help you. >=20 > Similarly, SIGPIPE may be blocked (masked). Few programs expect this. >=20 > The -i and -j options in procstat should be helpful in finding what > exactly is wrong with SIGPIPE. (These options are relatively new, but > should be in 8.1.) Might be, but now I have a feel that something more strange happens there. One of my workstations does not exhibit the behaviour, while another one did. I composed the following grep wrapper to catch the situation you guessed: #!/bin/sh disp=3D$(procstat -i $$ | awk '/PIPE/{print $4}') if expr -- $disp : I >/dev/null ; then echo "grep: SIGPIPE ignored" >/dev/tty kill -STOP $$ fi exec /usr/bin/grep "$@" Amazingly enough, the messages stopped spitting. Even more, I cannot reproduce them on the machine without the wrapper. Side note: despite ports/Mk/bsd.commands.mk defining GREP and EGREP, there are still several instances of the direct grep invocation among Mk/* files. Do port people consider this worth fixing ? --U/fW6JBK3GqE0Htg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxDGnAACgkQC3+MBN1Mb4jfnwCffc/gZM74nn1o9m58HXRajKgJ AFQAnRVadafZt0CBs/GTpIKHuHRz/0Zq =2274 -----END PGP SIGNATURE----- --U/fW6JBK3GqE0Htg-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 16:09:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D58D1065670 for ; Sun, 18 Jul 2010 16:09:42 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from lagoon.isletech.net (lagoon.isletech.net [64.235.98.66]) by mx1.freebsd.org (Postfix) with ESMTP id E77508FC1C for ; Sun, 18 Jul 2010 16:09:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=isletech.net; s=isle; h=Date:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:To:From:Message-Id; bh=ps1al/WGdQkTK6dgyMcpC8t8oS697muISZbNn1NHpz4=; b=HsCk+kY+XQDmXkZiVLhu4qox4mAnkwhd7VJw8uMyMgxXAp+Rx8JV/9cTck6CWlydQVcp5M97x/ipfk/aIQtagA==; Received: from home.isletech.net ([206.248.171.193]:57903 helo=[192.168.34.5]) by lagoon.isletech.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OaVou-0007kU-A2 for freebsd-stable@freebsd.org; Sun, 18 Jul 2010 11:30:24 -0400 Message-Id: <0B1610D9-47F2-42B0-AFC2-456A1EA96B4E@isletech.net> From: Daryl Richards To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Jul 2010 11:29:52 -0400 X-Mailer: Apple Mail (2.936) Subject: em(4) + ALTQ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 16:09:42 -0000 I'm wondering what the status of this problem is.. Will the fixes be in 8.1-RELEASE? I've checked through everything since the initial reports in February, and haven't seen a definitive answer.. Thanks! From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 18:11:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D551C1065674 for ; Sun, 18 Jul 2010 18:11:56 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id B44AB8FC16 for ; Sun, 18 Jul 2010 18:11:56 +0000 (UTC) Received: from nsx.b1c1l1.com (nsx.b1c1l1.com [IPv6:2001:470:83fb:0:250:8dff:fe9a:f666]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id 3CA845C29; Sun, 18 Jul 2010 11:11:56 -0700 (PDT) Message-ID: <4C4343E6.4060307@b1c1l1.com> Date: Sun, 18 Jul 2010 11:11:50 -0700 From: Benjamin Lee User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100628 Thunderbird/3.1 MIME-Version: 1.0 To: Reko Turja References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4719A212C744489AFF15D4BE" Cc: "Mikhail T." , Henrik /KaarPoSoft , freebsd-stable@freebsd.org, Joerg Pulz , Jeremy Chadwick Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 18:11:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4719A212C744489AFF15D4BE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/17/2010 03:37 PM, Reko Turja wrote: >=20 >> Can you try reproducing the issue on 8-STABLE? >> >> I recently submitted a Heimdal patch against 8.1-STABLE and >> 9.0-CURRENT that resolves some libgssapi-related issues: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/147454 >> >> The patch breaks ABI, so you'll have to rebuild libgssapi-dependent >> applications. >=20 > When linking cyrus-sasl2 against gssapi library from either the 1.0.1 > official port or the inofficial 1.2.1 patchset cyradm works as expected= > and it logs a message from gssapi/kerberos telling that no KDC's are > available - which is to be expected on a system that isn't using > gssapi/kerberos in authenticating. >=20 > So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday th= e > 5th is clearly some kind of regression as system gsslib doesn't seem to= > recognize the mech used or segfaults. >=20 > Benjamin, can you clarify how to apply your patch against the source > tree - I tried 'patch < the_patchset.diff' in /usr/src but it just > created a bunch of files in the /usr/src which I think isn't the intent= ion. Hi Reko, It looks like you've already figured it out (based on your responses elsewhere in the thread), but for the record you can apply the patch by running: cd /usr/src patch -p1 -E < foo.diff That patch is over a month old now and no longer applies cleanly. I'll port it forward when I get a chance. --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enig4719A212C744489AFF15D4BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMQ0PrAAoJEHBW16CPoSMCnfUP/imxJGtfUU5A+tZ7M5xwQCUb 4fsq4n9ItZcmeuqqpLw3CLwsj+adCs0ptvQSMKNbjaeEa2cFXxnp33wgbgu81VHv D9yEoDHtXfWVxyX/5BHMN/HRTp9rQUATZdm04B8akj23JeJpm2b0pha7jftTRIyc C5CAiP6NwNFrHOmALDuUDhh+2LWd2BXdNXlOfT7OMQ6BscZlhyx4RAzQxhVf8RKA gp1lG1m8M4jjJAwPLmk30lV95mr452DWicwVLnGK1ZeFU6xXY+rEJb6T1dq1D3UF KmNgu18ae+H3tFbtPgS54tQIz9m4UvN3+J8y+HuWEyJf8v8Nia1Q0kPi66T5E5ve zdrd1RQheTZZEiSs8sgiSmt3TZyYrUaxENE6ms7sFBymlHlTPBMSmiwfvZrTyVgZ T1E7+s0JVlVVOyd/6AbQQsNDErqXrkMH3MxAqs4f8T3LL1mGo0/0zXD9KauzfYKP lo9NRaIDDgZzQI0Er4ywhwp0hQKSWik/9r/Ze/cctWCd6KOIyKYIdfWqao3PX3oV 2p0czHAwvFDoQSQDmYUlJ2o9q29X69/ryZYtG2o6fg5VUVjhUk+J4FJKJkg3W4/V u6KsO2Dw0QSHHHWzXeu5vbXGCZRtLeEotZGOLUrvHD0LHRcYTBiFNRij8AcYLZSn glB57QAXskAl2nW8rBc3 =37q+ -----END PGP SIGNATURE----- --------------enig4719A212C744489AFF15D4BE-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 18:22:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F34D1065670 for ; Sun, 18 Jul 2010 18:22:55 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3288FC16 for ; Sun, 18 Jul 2010 18:22:55 +0000 (UTC) Received: from nsx.b1c1l1.com (nsx.b1c1l1.com [IPv6:2001:470:83fb:0:250:8dff:fe9a:f666]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id CFAC45C29; Sun, 18 Jul 2010 11:22:54 -0700 (PDT) Message-ID: <4C434678.70502@b1c1l1.com> Date: Sun, 18 Jul 2010 11:22:48 -0700 From: Benjamin Lee User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100628 Thunderbird/3.1 MIME-Version: 1.0 To: Reko Turja References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F263705D7AAF47C64C47EBB" Cc: "Mikhail T." , Jeremy Chadwick , freebsd-stable@freebsd.org, Joerg Pulz , Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 18:22:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F263705D7AAF47C64C47EBB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/18/2010 06:52 AM, Reko Turja wrote: > After manually changing the gssapi header used in > /usr/src/include/rpc/rpcsec_gss.h to somewhat klunky "#include > "/usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h"" system csupped > yesterday built okay and after rebuilding cyrus-sasl, saslauthd and > cyrus I get the following failures in log: >=20 > Jul 18 16:37:35 moria perl: GSSAPI Error: Miscellaneous failure (see > text)^B (open(/tmp/krb5cc_0): No such file or directory) >=20 > -This is expected behaviour as Kerberos was not running at the moment, > but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error > message >=20 > After dusting off my old Kerberos setup, doing basic kinit and running > cyradm localhost I got: >=20 > Jul 18 16:39:00 moria perl: GSSAPI Error: Miscellaneous failure (see > text) (Server (imap/localhost@XXX.DOMAIN.COM) unknown) >=20 > -Again expected as there is no imap trust relationship defined. >=20 > So at least after cursory testing it looks like that with Benjamin's > patch there is a working GSSAPI/Kerberos backend available, instead of > something that chokes on passed parameters that are ok for every other > tested gssapi implementation. >=20 > Of course, more thorough testing in proper kerberised/LDAP environment > needs to be done, which is something I haven't got time at the moment. Thanks for your testing! Based on the lack of attention my PR has received it seems that not many people have noticed the regression in libgssapi, even though the breaking commit happened in -CURRENT way back in 2008. When you get a chance, please append your test results to PR kern/147454. That may be helpful in attracting some more attention to this issue. --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enig2F263705D7AAF47C64C47EBB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMQ0Z+AAoJEHBW16CPoSMCmYoQAIx3ODepz1ZyuX94pnxmhZrB 079cN6tp4BWdpSZOwuwc8FzelYUlTdOFd2kLLu6WycZ7w0rQhaVdylrDdKWDUvf/ mjtHDghrMP3b+a8tXrG+twP9UTdboibNzsr9ccZLykB8jSPo7RIYyXy1I5ee5XLk 56ln2yaH9cwMZn7S9RSpmFCGM2j+lx6PhNlDj9xxyUFG9mmwUd2Qz6x16DrMSAwX mnY81K6ywmmqSH03HniYOGBLKzL1yBIWwFmRnoHA5+cysukjMKAiRm64IqKiGMvo MhjKqM8ebFRXI8wWY1KKiltoayKN+/4hGbmuGAxXTVVfy9RsglmiGNV2ATYcX//Q R1LUIKcHqvu7YtSva2bSAzarljnVAH90GgpFtC2S7pjCtuNvQpExm23KOy9PBD+3 L6cE6nIZbWKmxs4Ou6QWLJwfXBPPeJeBDIsWRPqS1h8onfjY9RJ6ug4P7JHY2yxR SGdK/ajZkskOPjIkDsMCGpl+J5frbKJTLFSuHFL1snoSbx3pOP2y56WE46KN3mLh xm7QXAbhpopUsvebhU1vPs4dlvLpqg7pRg892C3LLdu0YJHqpCFRwT5asdavNwTd AWLAFKlFi5bNun7PHfnjsYNlXc6bPY8TfCTVHWv6500lpuewHzFBVPaE+oBawO0h 7Y4I6CrsT/lOfYkM+qZw =5vu0 -----END PGP SIGNATURE----- --------------enig2F263705D7AAF47C64C47EBB-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 19:39:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BFBE106564A for ; Sun, 18 Jul 2010 19:39:14 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id B9BE68FC16 for ; Sun, 18 Jul 2010 19:39:13 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6IJcwY8058047 for ; Sun, 18 Jul 2010 12:38:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:content-type:date:message-id: mime-version:x-mailer:content-transfer-encoding; b=W7XTgzhL2v97cJZ+kJ9rLgPmyjPwW3SKhoCGMtltfdkMGkcxOYjgiB6duWjviMqa From: Sean Bruno To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Sun, 18 Jul 2010 12:38:58 -0700 Message-ID: <1279481938.10126.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: Reporting Functional Server Models X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 18 Jul 2010 19:39:14 -0000 I spent some time last week validating the 7, 8 and -CURRENT on different vendor hardware over here in my lab. Is there a current h/w compatibility list that folks are maintaining that I can update with my findings? Sean From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 21:08:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EA3106564A for ; Sun, 18 Jul 2010 21:08:10 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB478FC08 for ; Sun, 18 Jul 2010 21:08:10 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6IL88eG043887 for ; Sun, 18 Jul 2010 17:08:08 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007182108.o6IL88eG043887@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 18 Jul 2010 17:08:09 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 21:08:11 -0000 On the serial console I see swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 69, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 6, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 69, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 6, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 69, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 6, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 and on a session I had open from before # killall -9 watchdogd just hangs, I guess because its having trouble reading from the disk. If I hit CTRL+t, I see load: 0.00 cmd: csh 73167 [vnread] 22.32r 0.00u 0.00s 0% 3232k load: 0.00 cmd: csh 73167 [vnread] 22.65r 0.00u 0.00s 0% 3232k load: 0.00 cmd: csh 73167 [vnread] 22.96r 0.00u 0.00s 0% 3232k load: 0.00 cmd: csh 73167 [vnread] 23.20r 0.00u 0.00s 0% 3232k load: 0.00 cmd: csh 73167 [vnread] 23.40r 0.00u 0.00s 0% 3232k load: 0.00 cmd: csh 73167 [vnread] 23.61r 0.00u 0.00s 0% 3232k Its RELENG_8 amd64 from July 13th and the swap is on an ARECA drive and I dont see any errors on any of the raidset members. I also have a large zfs spool and a small mount point on a 3ware controller but unfortunately, nothing in the logs post reboot and nothing from smartctl cat /var/run/dmesg.boot Copyright (c) 1992-2010 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 8.1-PRERELEASE #0: Tue Jul 13 09:55:48 EDT 2010 mdtancsa@backup3.sentex.ca:/usr/obj/usr/src/sys/backup amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400.10-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8267673600 (7884 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fed08000, 1000 (3) failed acpi0: reservation of fed1c000, 4000 (3) failed acpi0: reservation of fed20000, 20000 (3) failed acpi0: reservation of fed50000, 40000 (3) failed acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of e0000000, 10000000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0xD1, should be 0xD0 (20100331/tbutils-354) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci3: on pcib2 arcmsr0: mem 0xfc9ff000-0xfc9fffff irq 18 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.16 2009-10-10 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 arcmsr0: [ITHREAD] pcib3: at device 0.2 on pci1 pci2: on pcib3 uhci0: port 0x7800-0x781f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x7880-0x789f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x7c00-0x7c1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xfc8ffc00-0xfc8fffff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib4: irq 17 at device 28.0 on pci0 pci9: on pcib4 em0: port 0xdc00-0xdc1f mem 0xfcfe0000-0xfcffffff,0xfcf00000-0xfcf7ffff,0xfcfdc000-0xfcfdffff irq 16 at device 0.0 on pci9 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1b:21:3f:62:72 pcib5: irq 16 at device 28.1 on pci0 pci8: on pcib5 siis0: port 0xcc00-0xcc7f mem 0xfceffc00-0xfceffc7f,0xfcef8000-0xfcefbfff irq 17 at device 0.0 on pci8 siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [ITHREAD] pcib6: irq 18 at device 28.2 on pci0 pci7: on pcib6 3ware device driver for 9000 series storage controllers, version: 3.80.06.002 twa0: <3ware 9000 series Storage Controller> port 0xb800-0xb8ff mem 0xfa000000-0xfbffffff,0xfcdff000-0xfcdfffff irq 18 at device 0.0 on pci7 twa0: [ITHREAD] twa0: WARNING: (0x04: 0x0008): Unclean shutdown detected: unit=0 twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-2LP, 2 ports, Firmware FE9X 3.08.00.016, BIOS BE9X 3.08.00.004 pcib7: irq 19 at device 28.3 on pci0 pci6: on pcib7 fwohci0: <1394 Open Host Controller Interface> port 0xa800-0xa8ff mem 0xfccff800-0xfccfffff irq 19 at device 0.0 on pci6 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:00:c4:10:80 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x8eacc0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:c4:10:80 fwe0: Ethernet address: 02:1e:8c:c4:10:80 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:00:c4:10:80 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode pcib8: irq 17 at device 28.4 on pci0 pci5: on pcib8 ahci0: mem 0xfcbfa000-0xfcbfbfff irq 16 at device 0.0 on pci5 ahci0: [ITHREAD] ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] atapci0: port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x940f irq 17 at device 0.1 on pci5 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib9: irq 16 at device 28.5 on pci0 pci4: on pcib9 ale0: port 0x8c00-0x8c7f mem 0xfcac0000-0xfcafffff irq 17 at device 0.0 on pci4 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto ale0: Ethernet address: e0:cb:4e:42:4b:37 ale0: [FILTER] uhci3: port 0x7080-0x709f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x7400-0x741f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 uhci5: port 0x7480-0x749f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] usbus6: on uhci5 ehci1: mem 0xfc8ff800-0xfc8ffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib10: at device 30.0 on pci0 pci10: on pcib10 vgapci0: port 0xe000-0xe0ff mem 0xfd000000-0xfdffffff,0xfebff000-0xfebfffff irq 16 at device 0.0 on pci10 isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port 0x6c00-0x6c07,0x6880-0x6883,0x6800-0x6807,0x6480-0x6483,0x6400-0x641f mem 0xfc8fe800-0xfc8fefff irq 19 at device 31.2 on pci0 ahci1: [ITHREAD] ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich2: at channel 0 on ahci1 ahcich2: [ITHREAD] ahcich3: at channel 1 on ahci1 ahcich3: [ITHREAD] ahcich4: at channel 2 on ahci1 ahcich4: [ITHREAD] ahcich5: at channel 3 on ahci1 ahcich5: [ITHREAD] ahcich6: at channel 4 on ahci1 ahcich6: [ITHREAD] ahcich7: at channel 5 on ahci1 ahcich7: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xc0000-0xc97ff,0xc9800-0xca7ff,0xca800-0xcc7ff,0xd4800-0xd77ff,0xd7800-0xd87ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 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 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 (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da0 at arcmsr0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da0: Command Queueing enabled da0: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) da1 at arcmsr0 bus 0 scbus0 target 0 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da1: Command Queueing enabled da1: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) ada0 at ahcich2 bus 0 scbus6 target 0 lun 0da2 at twa0 bus 0 scbus3 target 0 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 100.000MB/s transfers da2: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) ada0: ATA-8 SATA 2.x device 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) ada1 at ahcich3 bus 0 scbus7 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada2 at ahcich4 bus 0 scbus8 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich5 bus 0 scbus9 target 0 lun 0 ada3: ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) pass2 at arcmsr0 bus 0 scbus0 target 16 lun 0 pass2: Fixed Processor SCSI-0 device SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 Trying to mount root from ufs:/dev/da2s1a WARNING: / was not properly dismounted ZFS filesystem version 3 ZFS storage pool version 14 ugen5.2: at usbus5 twa0: INFO: (0x04: 0x000C): Initialize started: unit=0 em0: link state changed to UP ale0: link state changed to UP ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 21:14:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 507BF106566C for ; Sun, 18 Jul 2010 21:14:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id F3A0D8FC1D for ; Sun, 18 Jul 2010 21:14:17 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA11.westchester.pa.mail.comcast.net with comcast id jZ0j1e0021ei1Bg5BZEH3C; Sun, 18 Jul 2010 21:14:17 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta24.westchester.pa.mail.comcast.net with comcast id jZEG1e00J3LrwQ23kZEH87; Sun, 18 Jul 2010 21:14:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 708849B425; Sun, 18 Jul 2010 14:14:15 -0700 (PDT) Date: Sun, 18 Jul 2010 14:14:15 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100718211415.GA84127@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007182108.o6IL88eG043887@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 21:14:18 -0000 On Sun, Jul 18, 2010 at 05:08:09PM -0400, Mike Tancsa wrote: > > > On the serial console I see > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 69, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 6, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 69, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 6, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 69, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 6, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 74, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 128, size: 20480 > [...] > load: 0.00 cmd: csh 73167 [vnread] 22.32r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 22.65r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 22.96r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 23.20r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 23.40r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 23.61r 0.00u 0.00s 0% 3232k Where exactly is your swap partition? I ask because of the below paragraph starting with "Its RELENG_8 amd64 from July 13th ...". > Its RELENG_8 amd64 from July 13th and the swap is on an ARECA drive > and I dont see any errors on any of the raidset members. I also have > a large zfs spool and a small mount point on a 3ware controller but > unfortunately, nothing in the logs post reboot and nothing from > smartctl If you Google for "swap_pager: indefinite wait buffer: bufobj" you'll find this is a pretty well-established problem, but the situation varies per person. A common one is here (read the entire thread): http://www.mail-archive.com/freebsd-questions@freebsd.org/msg192481.html I have no advice as far as how to solve this problem. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 18 21:42:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 821B81065782 for ; Sun, 18 Jul 2010 21:42:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 553718FC13 for ; Sun, 18 Jul 2010 21:42:14 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6ILgDQW044046; Sun, 18 Jul 2010 17:42:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007182142.o6ILgDQW044046@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 18 Jul 2010 17:42:14 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20100718211415.GA84127@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 21:42:14 -0000 At 05:14 PM 7/18/2010, Jeremy Chadwick wrote: >Where exactly is your swap partition? On one of the areca raidsets. # swapctl -l Device: 1024-blocks Used: /dev/da0s1b 10485760 108 >If you Google for "swap_pager: indefinite wait buffer: bufobj" you'll >find this is a pretty well-established problem, but the situation varies >per person. A common one is here (read the entire thread): > >http://www.mail-archive.com/freebsd-questions@freebsd.org/msg192481.html > >I have no advice as far as how to solve this problem. If feels like a disk issue, but SMART values all seem ok eg CLI> disk smart drv=1 S.M.A.R.T Information For Drive[#01] # Attribute Items Flag Value Thres State =============================================================================== 1 Raw Read Error Rate 0x0f 108 6 OK 3 Spin Up Time 0x03 91 0 OK 4 Start/Stop Count 0x32 100 20 OK 5 Reallocated Sector Count 0x33 100 36 OK 7 Seek Error Rate 0x0f 81 30 OK 9 Power-on Hours Count 0x32 79 0 OK 10 Spin Retry Count 0x13 100 97 OK 12 Device Power Cycle Count 0x32 100 20 OK 194 Temperature 0x22 30 0 OK 197 Current Pending Sector Count 0x12 100 0 OK 198 Off-line Scan Uncorrectable Sector Count 0x10 100 0 OK 199 Ultra DMA CRC Error Count 0x3e 200 0 OK smartctl -a -d 3ware,1 /dev/twa0 smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.1-PRERELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Western Digital Raptor family Device Model: WDC WD740ADFD-00NLR1 Serial Number: WD-WMANS1051760 Firmware Version: 20.07P20 User Capacity: 74,355,769,344 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 published, ANSI INCITS 397-2005 Local Time is: Sun Jul 18 17:41:36 2010 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (2391) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 39) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x103f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 170 170 021 Pre-fail Always - 2508 4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 45 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x000a 200 200 051 Old_age Always - 0 9 Power_On_Hours 0x0032 060 060 000 Old_age Always - 29672 10 Spin_Retry_Count 0x0012 100 253 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0012 100 253 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 45 194 Temperature_Celsius 0x0022 107 099 000 Old_age Always - 36 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 02:34:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 149D81065670 for ; Mon, 19 Jul 2010 02:34:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id F02738FC0C for ; Mon, 19 Jul 2010 02:34:20 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta09.emeryville.ca.mail.comcast.net with comcast id jdno1e00117UAYkA9eaLFX; Mon, 19 Jul 2010 02:34:20 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta13.emeryville.ca.mail.comcast.net with comcast id jeaK1e0053LrwQ28ZeaKtc; Mon, 19 Jul 2010 02:34:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 32D5F9B425; Sun, 18 Jul 2010 19:34:19 -0700 (PDT) Date: Sun, 18 Jul 2010 19:34:19 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719023419.GA91006@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007182142.o6ILgDQW044046@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 02:34:21 -0000 On Sun, Jul 18, 2010 at 05:42:14PM -0400, Mike Tancsa wrote: > At 05:14 PM 7/18/2010, Jeremy Chadwick wrote: > > >Where exactly is your swap partition? > > On one of the areca raidsets. > > # swapctl -l > Device: 1024-blocks Used: > /dev/da0s1b 10485760 108 So is da0 actually a RAID volume "behind the scenes" on the Areca controller? How many disks are involved in that set? > >If you Google for "swap_pager: indefinite wait buffer: bufobj" you'll > >find this is a pretty well-established problem, but the situation varies > >per person. A common one is here (read the entire thread): > > > >http://www.mail-archive.com/freebsd-questions@freebsd.org/msg192481.html > > > >I have no advice as far as how to solve this problem. > > If feels like a disk issue, but SMART values all seem ok Well, the thread I linked you stated that the problem has to do with a controller or disk "taking too long". I have no idea what the threshold is. I suppose it could also indicate that your system is (possibly) running low on resources (RAM); I would imagine swap_pager would get called if a processes needed to be offloaded to swap. So maybe this is a system tuning thing more than a hardware thing. You should probably set up a series of monitoring scripts that monitor things like interrupt rate on devices, I/O statistics, and some general memory statistics to determine if processes are being swapped out excessively. vmstat and iostat would help here; see man page for relevant options (for swap stuff, vmstat -s). There's also systat with the -vmstat flag. > CLI> disk smart drv=1 > [...] Unrelated to the problem, but important to note: The SMART output from the Areca CLI is hardly useful (bordering on worthless); it only shows the adjusted/calculated values and not the actual raw values. Even if the CLI lets you print this information, I would still strongly suggest using smartctl. There's no indication the Areca CLI has a quirks database for each drive model/type. I'm also not sure if the Areca CLI can provide the SMART error log, self-test log, or the selective self-test log. > smartctl -a -d 3ware,1 /dev/twa0 Now I'm confused -- this indicates twa(4) is involved, not arcmsr(4). Can you please provide a verbose explanation of the configuration of the disks and controllers in this machine, including device and disk names and what they're associated with, plus if they're RAIDed in any way? Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 02:58:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D871065672 for ; Mon, 19 Jul 2010 02:58:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 539268FC1A for ; Mon, 19 Jul 2010 02:58:40 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id jexW1e0061wpRvQ51eyh3t; Mon, 19 Jul 2010 02:58:41 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.westchester.pa.mail.comcast.net with comcast id jeyg1e0053LrwQ23eeygj5; Mon, 19 Jul 2010 02:58:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4637D9B425; Sun, 18 Jul 2010 19:58:39 -0700 (PDT) Date: Sun, 18 Jul 2010 19:58:39 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719025839.GA91809@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719023419.GA91006@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 02:58:41 -0000 On Sun, Jul 18, 2010 at 07:34:19PM -0700, Jeremy Chadwick wrote: > Now I'm confused -- this indicates twa(4) is involved, not arcmsr(4). > > Can you please provide a verbose explanation of the configuration of the > disks and controllers in this machine, including device and disk names > and what they're associated with, plus if they're RAIDed in any way? > > Thanks. I re-worked this out myself based on the OP's dmesg. It's confusing because there's literally 6 different storage controllers on a single machine: * arcmsr0 <--> irq 18 <--> Areca SATA Host Adapter RAID Controller siis0 <--> irq 17 <--> SiI3132 SATA controller * twa0 <--> irq 18 <--> 3ware 9000 series Storage Controller ahci0 <--> irq 16 <--> JMicron JMB361 AHCI SATA controller atapci0 <--> irq 17 <--> JMicron JMB361 ATA controller * ahci1 <--> irq 19 <--> Intel ICH10 AHCI SATA controller Controllers marked with asterisk (*) are in use/involved. Others don't appear to have anything connected to them. Channels and what above controllers they're connected to. Again, same with the asterisk: ahcich0 <--> ahci0 ahcich1 <--> ahci0 ata2 <--> atapci0 * ahcich2 <--> ahci1 * ahcich3 <--> ahci1 * ahcich4 <--> ahci1 * ahcich5 <--> ahci1 ahcich6 <--> ahci1 ahcich7 <--> ahci1 The dmesg output also shows this. I have no idea what it means: (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step Now we get into the disks. The kernel interspersed output within drivers so I had to work this out myself. da0 <--> arcmsr0 <--> Areca usrvar (RAID volume) da1 <--> arcmsr0 <--> Areca backup1 (RAID volume) da2 <--> twa0 <--> No idea, but looks like a RAID volume ada0 <--> ahcich2 <--> ST31000340AS (disk) ada1 <--> ahcich3 <--> ST31000340AS (disk) ada2 <--> ahcich4 <--> ST31000333AS (disk) ada3 <--> ahcich5 <--> ST31000528AS (disk) So one thing of interest is that the Areca and 3ware controllers are sharing an IRQ. If you do extensive bidirectional I/O between disks on the arcmsr0 and twa0 controllers at the same time (e.g. read from arcmsr0 which writes to twa0, and read from twa0 which writes to arcmsr0), do you see this problem? vmstat -i output would help here, except that it's going to show the rate as a total (for both controllers). I don't know if a way to get more granular output. pciconf -lvc output might also help (to see if the controllers are using MSI or not); only interested in the arcmsr0, twa0, and ahci1 entries. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 03:01:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14481065673 for ; Mon, 19 Jul 2010 03:01:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBA28FC15 for ; Mon, 19 Jul 2010 03:01:18 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6J31Hs1045607; Sun, 18 Jul 2010 23:01:17 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007190301.o6J31Hs1045607@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 18 Jul 2010 23:01:03 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20100719023419.GA91006@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 03:01:20 -0000 At 10:34 PM 7/18/2010, Jeremy Chadwick wrote: >On Sun, Jul 18, 2010 at 05:42:14PM -0400, Mike Tancsa wrote: > > At 05:14 PM 7/18/2010, Jeremy Chadwick wrote: > > > > >Where exactly is your swap partition? > > > > On one of the areca raidsets. > > > > # swapctl -l > > Device: 1024-blocks Used: > > /dev/da0s1b 10485760 108 > >So is da0 actually a RAID volume "behind the scenes" on the Areca >controller? How many disks are involved in that set? yes, da0 is a RAID volume with 4 disks behind the scenes. >Well, the thread I linked you stated that the problem has to do with a >controller or disk "taking too long". I have no idea what the threshold >is. I suppose it could also indicate that your system is (possibly) >running low on resources (RAM); I would imagine swap_pager would get >called if a processes needed to be offloaded to swap. So maybe this is >a system tuning thing more than a hardware thing. Prior to someone rebooting it, it had been stuck in this state for a good 90min. Apart from upgrading to a later RELENG_8 to get the security patches, the machine had been running a few versions of RELENG_8 doing the same workloads every week without issue. /boot/loader.conf has ahci_load="YES" siis_load="YES" sysctl.conf has net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=131072 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=32768 net.inet.udp.recvspace=65536 kern.ipc.somaxconn=1024 kern.ipc.maxsockbuf=4194304 net.inet.ip.redirect=0 net.inet.ip.intr_queue_maxlen=4096 net.route.netisr_maxqlen=1024 kern.ipc.nmbclusters=131072 I do track some basic mem stats via rrd. Looking at the graphs upto that period, nothing unusual was happening CPU: 16.6% user, 0.0% nice, 4.3% system, 0.2% interrupt, 78.8% idle Mem: 443M Active, 5707M Inact, 1462M Wired, 147M Cache, 828M Buf, 166M Free Swap: 10G Total, 124K Used, 10G Free > > smartctl -a -d 3ware,1 /dev/twa0 > >Now I'm confused -- this indicates twa(4) is involved, not arcmsr(4). The other controllers (3ware and onboard ich in ahci mode) provider other storage on the same box. I only noted them in that I checked all their disks for errors of which there were none either. The dmesg from the original post enumerates all the devices on the box. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 03:09:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F13D106566C for ; Mon, 19 Jul 2010 03:09:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4205E8FC0C for ; Mon, 19 Jul 2010 03:09:35 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6J39Y9i045639; Sun, 18 Jul 2010 23:09:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007190309.o6J39Y9i045639@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 18 Jul 2010 23:09:36 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20100719025839.GA91809@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <20100719025839.GA91809@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 03:09:36 -0000 At 10:58 PM 7/18/2010, Jeremy Chadwick wrote: >I re-worked this out myself based on the OP's dmesg. It's confusing >because there's literally 6 different storage controllers on a single >machine: Its a big storage server. Some files dont require fast or frequent access, others do. The disks on the sata controllers are used with zfs for the large files that require infrequent access for example. >(probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step Thats been a normal message for Areca controllers for some time on AMD64 >So one thing of interest is that the Areca and 3ware controllers are >sharing an IRQ. If you do extensive bidirectional I/O between disks on >the arcmsr0 and twa0 controllers at the same time (e.g. read from >arcmsr0 which writes to twa0, and read from twa0 which writes to >arcmsr0), do you see this problem? Its never been an issue in the past 2yrs. The same box was RELENG_7 for some time and then in the past 3 months updated to RELENG_8. > vmstat -i output would help here, >except that it's going to show the rate as a total (for both >controllers). I don't know if a way to get more granular output. > >pciconf -lvc output might also help (to see if the controllers are using >MSI or not); only interested in the arcmsr0, twa0, and ahci1 entries. interrupt total rate irq1: atkbd0 6 0 irq4: uart0 1049 0 irq18: arcmsr0 twa* 5221148 151 irq19: fwohci0+ 151346 4 irq23: uhci3 ehci1 2 0 cpu0: timer 67544881 1962 irq256: em0 57430641 1668 irq257: ale0 3262365 94 irq258: ahci1 10406081 302 cpu1: timer 67539701 1962 cpu2: timer 67168885 1951 cpu3: timer 67169530 1951 Total 345895635 10049 arcmsr0@pci0:3:14:0: class=0x010400 card=0x121017d3 chip=0x121017d3 rev=0x00 hdr=0x00 vendor = 'Areca Technology Corporation' device = 'ARC-1210 4-Port PCIe to SATA RAID Controller' class = mass storage subclass = RAID cap 01[c0] = powerspec 2 supports D0 D1 D3 current D0 cap 05[d0] = MSI supports 2 messages, 64 bit cap 07[e0] = PCI-X 64-bit supports 133MHz, 1024 burst read, 4 split transactions siis0@pci0:8:0:0: class=0x010400 card=0x71321095 chip=0x31321095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI Express (1x) to 2 Port SATA300 (SiI 3132)' class = mass storage subclass = RAID cap 01[54] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(1024) link x1(x1) twa0@pci0:7:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 vendor = '3ware Inc' device = 'PCI-Express SATA2 Raid Controller (9650SE Series)' class = mass storage subclass = RAID cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(512) link x1(x8) ahci0@pci0:5:0:0: class=0x010601 card=0x824f1043 chip=0x2361197b rev=0x02 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'PCI Express to SATA II and PATA Host Controller (JMB363)' class = mass storage subclass = SATA cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 10[50] = PCI-Express 1 legacy endpoint IRQ 2 max data 128(128) link x1(x1) ahci1@pci0:0:31:2: class=0x010601 card=0x82d41043 chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 16 messages enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 09[b0] = vendor (length 6) Intel cap 2 version 0 >-- >| Jeremy Chadwick jdc@parodius.com | >| Parodius Networking http://www.parodius.com/ | >| UNIX Systems Administrator Mountain View, CA, USA | >| Making life hard for others since 1977. PGP: 4BD6C0CB | -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 03:34:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E19E1065675 for ; Mon, 19 Jul 2010 03:34:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 03AE08FC22 for ; Mon, 19 Jul 2010 03:34:25 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta05.emeryville.ca.mail.comcast.net with comcast id jdz41e0040QkzPwA5faRvu; Mon, 19 Jul 2010 03:34:25 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.emeryville.ca.mail.comcast.net with comcast id jfaQ1e00B3LrwQ28NfaQCx; Mon, 19 Jul 2010 03:34:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4E3249B425; Sun, 18 Jul 2010 20:34:24 -0700 (PDT) Date: Sun, 18 Jul 2010 20:34:24 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719033424.GA92607@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007190301.o6J31Hs1045607@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 03:34:26 -0000 On Sun, Jul 18, 2010 at 11:01:03PM -0400, Mike Tancsa wrote: > At 10:34 PM 7/18/2010, Jeremy Chadwick wrote: > >On Sun, Jul 18, 2010 at 05:42:14PM -0400, Mike Tancsa wrote: > >> At 05:14 PM 7/18/2010, Jeremy Chadwick wrote: > >> > >> >Where exactly is your swap partition? > >> > >> On one of the areca raidsets. > >> > >> # swapctl -l > >> Device: 1024-blocks Used: > >> /dev/da0s1b 10485760 108 > > > >So is da0 actually a RAID volume "behind the scenes" on the Areca > >controller? How many disks are involved in that set? > > yes, da0 is a RAID volume with 4 disks behind the scenes. Okay, so can you get full SMART statistics for all 4 of those disks? The adjusted/calculated values for SMART thresholds won't be helpful here, one will need the actual raw SMART data. I hope the Areca CLI can provide that. Also, I'm willing to bet that the da0 "volume" and the da1 "volume" actually share the same physical disks on the Areca controller. Is that correct? If so, think about what would happen if heavy I/O happened on both da0 and da1 at the same time. I talk about this a bit more below. > >Well, the thread I linked you stated that the problem has to do with a > >controller or disk "taking too long". I have no idea what the threshold > >is. I suppose it could also indicate that your system is (possibly) > >running low on resources (RAM); I would imagine swap_pager would get > >called if a processes needed to be offloaded to swap. So maybe this is > >a system tuning thing more than a hardware thing. > > Prior to someone rebooting it, it had been stuck in this state for a > good 90min. Apart from upgrading to a later RELENG_8 to get the > security patches, the machine had been running a few versions of > RELENG_8 doing the same workloads every week without issue. Then I would say you'd need to roll back kernel+world to a previous date and try to figure out when the issue began, if that is indeed the case. > /boot/loader.conf has > ahci_load="YES" > siis_load="YES" > > sysctl.conf has > > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=131072 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendspace=32768 > net.inet.udp.recvspace=65536 > kern.ipc.somaxconn=1024 > kern.ipc.maxsockbuf=4194304 > net.inet.ip.redirect=0 > net.inet.ip.intr_queue_maxlen=4096 > net.route.netisr_maxqlen=1024 > kern.ipc.nmbclusters=131072 None of these, to my knowledge, would affect what you're seeing; they're all network-related. > I do track some basic mem stats via rrd. Looking at the graphs upto > that period, nothing unusual was happening sysctl vm.stats.vm | grep swap Here's another post basically reiterating the same thing: that the controller the swap slice is on (in your case a 4-disk RAID array) is basically taking too long to respond. http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/2e7faeeaca719c52/cdcd4601ce1b90c5 I have no idea where the timeout values are in the kernel. I do see these two entries in sysctl that look to be of interest though. You might try adjusting these (not sure if they're sysctls or loader.conf tunables only): vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 Descriptions: vm.swap_idle_threshold2: Time before a process will be swapped out vm.swap_idle_threshold1: Guaranteed swapped in time for a process I want to point out that the actual amount of data being swapped out is fairly small -- note the "size" fields the swap_pager kernel messages. There doesn't necessarily have to be a shortage of memory to cause a swapout (case in point, see above). It would also help if you could provide timestamps of those messages; are they all happening at once, or gradual over time? If over time, do they all happen around the same time every day, etc.? You see where I'm going with this. Workaround recommendation: put swap directly on a device and not as part of a 4-disk RAID volume (regardless of what type of RAID) and see if the problem goes away. I realise that probably isn't plausible in your situation (since you'd then be dedicating an entire disk to just swap). Others may have other advice. You mention in a later mail that the ada[0-3] disks make up a ZFS pool of some sort. You might try splitting ada0 into two slices, one for swap and the other used as a pool member. Again: I don't think this is necessarily a bad disk problem. The only way you'd be able to determine that would be to monitor on a per-disk basis the I/O response time of each disk member on the Areca. If the CLI tools provide this, awesome. Otherwise you'll probably need to involve Areca Support. Remember: CAM thinks da0 and da1 are actually individual disks, and lacks knowledge of them being associated with a 4-disk RAID volume behind the scenes. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 03:58:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C05D106566C for ; Mon, 19 Jul 2010 03:58:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 17D918FC13 for ; Mon, 19 Jul 2010 03:58:46 +0000 (UTC) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta07.westchester.pa.mail.comcast.net with comcast id jfru1e0011HzFnQ57fymPQ; Mon, 19 Jul 2010 03:58:46 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta14.westchester.pa.mail.comcast.net with comcast id jfyl1e00E3LrwQ23afym5k; Mon, 19 Jul 2010 03:58:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 891859B425; Sun, 18 Jul 2010 20:58:44 -0700 (PDT) Date: Sun, 18 Jul 2010 20:58:44 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719035844.GA93487@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100719033424.GA92607@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 03:58:47 -0000 On Sun, Jul 18, 2010 at 08:34:24PM -0700, Jeremy Chadwick wrote: > On Sun, Jul 18, 2010 at 11:01:03PM -0400, Mike Tancsa wrote: > > I do track some basic mem stats via rrd. Looking at the graphs upto > > that period, nothing unusual was happening > > sysctl vm.stats.vm | grep swap > > Here's another post basically reiterating the same thing: that the > controller the swap slice is on (in your case a 4-disk RAID array) is > basically taking too long to respond. > > http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/2e7faeeaca719c52/cdcd4601ce1b90c5 > > I have no idea where the timeout values are in the kernel. I do see > these two entries in sysctl that look to be of interest though. You > might try adjusting these (not sure if they're sysctls or loader.conf > tunables only): > > vm.swap_idle_threshold2: 10 > vm.swap_idle_threshold1: 2 > > Descriptions: > > vm.swap_idle_threshold2: Time before a process will be swapped out > vm.swap_idle_threshold1: Guaranteed swapped in time for a process > > I want to point out that the actual amount of data being swapped out is > fairly small -- note the "size" fields the swap_pager kernel messages. > There doesn't necessarily have to be a shortage of memory to cause a > swapout (case in point, see above). I took a look at the RELENG_8 code responsible for printing this message: src/sys/vm/swap_pager.c 1067 /* 1068 * SWAP_PAGER_GETPAGES() - bring pages in from swap 1069 * 1070 * Attempt to retrieve (m, count) pages from backing store, but make 1071 * sure we retrieve at least m[reqpage]. We try to load in as large 1072 * a chunk surrounding m[reqpage] as is contiguous in swap and which 1073 * belongs to the same object. 1074 * 1075 * The code is designed for asynchronous operation and 1076 * immediate-notification of 'reqpage' but tends not to be 1077 * used that way. Please do not optimize-out this algorithmic 1078 * feature, I intend to improve on it in the future. 1079 * 1080 * The parent has a single vm_object_pip_add() reference prior to 1081 * calling us and we should return with the same. 1082 * 1083 * The parent has BUSY'd the pages. We should return with 'm' 1084 * left busy, but the others adjusted. 1085 */ 1086 static int 1087 swap_pager_getpages(vm_object_t object, vm_page_t *m, int count, int reqpage) 1088 { .... 1210 /* 1211 * wait for the page we want to complete. VPO_SWAPINPROG is always 1212 * cleared on completion. If an I/O error occurs, SWAPBLK_NONE 1213 * is set in the meta-data. 1214 */ 1215 VM_OBJECT_LOCK(object); 1216 while ((mreq->oflags & VPO_SWAPINPROG) != 0) { 1217 mreq->oflags |= VPO_WANTED; 1218 PCPU_INC(cnt.v_intrans); 1219 if (msleep(mreq, VM_OBJECT_MTX(object), PSWP, "swread", hz*20)) { 1220 printf( 1221 "swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n", 1222 bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); 1223 } 1224 } So I believe this indicates the message only gets printed during swapin, not swapout. Meaning it's happening during an I/O read from da0. Reading msleep(9) provides us some details about what "swread" correlates with (now I know where that column in ps/top comes from), and the timeout value (hz*20): The parameter wmesg is a string describing the sleep condition for tools like ps(1). Due to the limited space of those programs to display arbi†trary strings, this message should not be longer than 6 characters. The parameter timo specifies a timeout for the sleep. If timo is not 0, then the thread will sleep for at most timo / hz seconds. If the timeout expires, then the sleep function will return EWOULDBLOCK. So what's hz? Well, I want to assume it's kern.hz, which defaults to 1000. 1000*20 = 20000, so the timeout would be 20000/1000 = 20 seconds. That's a pretty long time to be waiting for an I/O read to return. So does vm.swap_idle_threshold1 play a role? I doubt it. The code is in src/sys/vm/vm_glue.c, but I don't understand it (especially since it's used in a function called swapout_procs()). I just wish I knew why the description was "Guaranteed swapped in time for a process" when it looks more like it's guaranteed swapped out time? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 04:11:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13D0E106564A for ; Mon, 19 Jul 2010 04:11:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id EB4548FC0C for ; Mon, 19 Jul 2010 04:11:50 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta04.emeryville.ca.mail.comcast.net with comcast id jd6V1e0020S2fkCA4gBqjw; Mon, 19 Jul 2010 04:11:50 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta09.emeryville.ca.mail.comcast.net with comcast id jgBp1e0073LrwQ28VgBpJw; Mon, 19 Jul 2010 04:11:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 300619B425; Sun, 18 Jul 2010 21:11:49 -0700 (PDT) Date: Sun, 18 Jul 2010 21:11:49 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719041149.GA93978@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> <20100719035844.GA93487@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719035844.GA93487@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 04:11:51 -0000 On Sun, Jul 18, 2010 at 08:58:44PM -0700, Jeremy Chadwick wrote: > I took a look at the RELENG_8 code responsible for printing this > message: src/sys/vm/swap_pager.c > > [...] > 1086 static int > 1087 swap_pager_getpages(vm_object_t object, vm_page_t *m, int count, int reqpage) > 1088 { > [...] There was a change to this piece of code on May 13th. See commit 1.312.2.4 below: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/swap_pager.c Before I pull in kib@ or alc@ to help determine if what was introduced could cause what you're seeing, can you clarify this point? > FreeBSD 8.1-PRERELEASE #0: Tue Jul 13 09:55:48 EDT 2010 > mdtancsa at backup3.sentex.ca:/usr/obj/usr/src/sys/backup amd64 > [...] > Its never been an issue in the past 2yrs. The same box was RELENG_7 > for some time and then in the past 3 months updated to RELENG_8. Has this system run a previous version of RELENG_8 within the past 3 months, or are you seeing this issue "as a result of upgrading from RELENG_7 to RELENG_8"? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 07:41:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F761065670 for ; Mon, 19 Jul 2010 07:41:10 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 0962B8FC15 for ; Mon, 19 Jul 2010 07:41:09 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id EDE2DE3F07A; Mon, 19 Jul 2010 09:41:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaaO7bWDJ9bE; Mon, 19 Jul 2010 09:41:05 +0200 (CEST) Received: from pgw.vnode.se (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 2095DE3F079; Mon, 19 Jul 2010 09:41:04 +0200 (CEST) Date: Mon, 19 Jul 2010 09:41:03 +0200 From: Joel Dahl To: sbruno@freebsd.org Message-ID: <20100719074102.GA37877@pgw.vnode.se> References: <1279481938.10126.13.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1279481938.10126.13.camel@localhost.localdomain> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-stable@freebsd.org" Subject: Re: Reporting Functional Server Models X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 07:41:10 -0000 On 18-07-2010 12:38, Sean Bruno wrote: > I spent some time last week validating the 7, 8 and -CURRENT on > different vendor hardware over here in my lab. > > Is there a current h/w compatibility list that folks are maintaining > that I can update with my findings? I don't think there is such a list, but posting your findings to this mailing list would probably be a good start... -- Joel From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 07:40:57 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B047A1065673; Mon, 19 Jul 2010 07:40:57 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC2D8FC15; Mon, 19 Jul 2010 07:40:57 +0000 (UTC) Received: from aldan.narawntapu ([unknown] [173.70.194.135]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5S009F5L7H9XB1@vms173003.mailsrvcs.net>; Mon, 19 Jul 2010 01:40:31 -0500 (CDT) Message-id: <4C43F35D.5020007@aldan.algebra.com> Date: Mon, 19 Jul 2010 02:40:29 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk; rv:1.9.1.10) Gecko/20100716 Thunderbird/3.0.5 MIME-version: 1.0 To: fs@freebsd.org, stable@FreeBSD.org X-Mailman-Approved-At: Mon, 19 Jul 2010 11:11:46 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: panic: handle_written_inodeblock: bad size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 07:40:57 -0000 An 8.1-prerelease machine I have throws the panic in subject quite often. Does anyone care? Is this evidence of some filesystem corruption here, or a known problem that's (almost) solved already? The stacks all look the same: panic: handle_written_inodeblock: bad size ts_to_ct(1279145603.245753580) = [2010-07-14 22:13:23] ... #0 doadump () at pcpu.h:230 #1 0xc05be054 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05be261 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc07501b9 in softdep_disk_write_complete (bp=0xd81bcc30) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4615 #4 0xc062c386 in bufdone_finish (bp=0xd81bcc30) at buf.h:411 #5 0xc062c7bd in bufdone (bp=0xd81bcc30) at /usr/src/sys/kern/vfs_bio.c:3275 #6 0xc0565bb5 in g_vfs_done (bip=0xc497e8c0) at /usr/src/sys/geom/geom_vfs.c:97 #7 0xc0626db9 in biodone (bp=0xc497e8c0) at /usr/src/sys/kern/vfs_bio.c:3110 #8 0xc056301f in g_io_schedule_up (tp=0xc4044000) at /usr/src/sys/geom/geom_io.c:675 #9 0xc05633c8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #10 0xc0595f5f in fork_exit (callout=0xc0563360 , arg=0x0, frame=0xe46a5d38) at /usr/src/sys/kern/kern_fork.c:844 #11 0xc07cf704 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 Please, advise. Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 11:31:49 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A46F1065672 for ; Mon, 19 Jul 2010 11:31:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 22B368FC1C for ; Mon, 19 Jul 2010 11:31:48 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta01.emeryville.ca.mail.comcast.net with comcast id jnQY1e0020lTkoCA1nXobC; Mon, 19 Jul 2010 11:31:48 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.emeryville.ca.mail.comcast.net with comcast id jnXn1e0063LrwQ28QnXn7m; Mon, 19 Jul 2010 11:31:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2AFF39B425; Mon, 19 Jul 2010 04:31:47 -0700 (PDT) Date: Mon, 19 Jul 2010 04:31:47 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100719113147.GA4786@icarus.home.lan> References: <4C43F35D.5020007@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C43F35D.5020007@aldan.algebra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org, fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 11:31:49 -0000 On Mon, Jul 19, 2010 at 02:40:29AM -0400, Mikhail T. wrote: > An 8.1-prerelease machine I have throws the panic in subject quite > often. Does anyone care? Is this evidence of some filesystem > corruption here, or a known problem that's (almost) solved already? > > The stacks all look the same: > > panic: handle_written_inodeblock: bad size > ts_to_ct(1279145603.245753580) = [2010-07-14 22:13:23] > ... > #0 doadump () at pcpu.h:230 > #1 0xc05be054 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xc05be261 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 0xc07501b9 in softdep_disk_write_complete (bp=0xd81bcc30) > at /usr/src/sys/ufs/ffs/ffs_softdep.c:4615 > #4 0xc062c386 in bufdone_finish (bp=0xd81bcc30) at buf.h:411 > #5 0xc062c7bd in bufdone (bp=0xd81bcc30) at > /usr/src/sys/kern/vfs_bio.c:3275 > #6 0xc0565bb5 in g_vfs_done (bip=0xc497e8c0) > at /usr/src/sys/geom/geom_vfs.c:97 > #7 0xc0626db9 in biodone (bp=0xc497e8c0) at > /usr/src/sys/kern/vfs_bio.c:3110 > #8 0xc056301f in g_io_schedule_up (tp=0xc4044000) > at /usr/src/sys/geom/geom_io.c:675 > #9 0xc05633c8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 > #10 0xc0595f5f in fork_exit (callout=0xc0563360 , > arg=0x0, > frame=0xe46a5d38) at /usr/src/sys/kern/kern_fork.c:844 > #11 0xc07cf704 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:273 > > Please, advise. Thanks! If you boot the machine in single-user, and run fsck manually, are there any errors? Only thing I can think of off the top of my head: there's a known situation (also applies to RELENG_7) where a background fsck doesn't correct all errors after a system crash/unclean shutdown. I mention this because I see "softdep" in the above stack trace (usually refers to softupdates). I don't know if this got fixed, but the workaround is to use background_fsck="no" in rc.conf. Yes, after a crash this means you have to wait for the entire fsck to run. I can point you to some (old) discussions about it if need be. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 12:37:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 005BA106564A for ; Mon, 19 Jul 2010 12:37:49 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id ACC898FC1A for ; Mon, 19 Jul 2010 12:37:49 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6JCbmj7049339; Mon, 19 Jul 2010 08:37:48 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007191237.o6JCbmj7049339@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 08:37:50 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20100719033424.GA92607@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 12:37:50 -0000 At 11:34 PM 7/18/2010, Jeremy Chadwick wrote: > > > > yes, da0 is a RAID volume with 4 disks behind the scenes. > >Okay, so can you get full SMART statistics for all 4 of those disks? >The adjusted/calculated values for SMART thresholds won't be helpful >here, one will need the actual raw SMART data. I hope the Areca CLI can >provide that. I thought there was, but I cant seem to get the current smartctl to work with the card. -d TYPE, --device=TYPE Specifies the type of the device. The valid arguments to this option are ata, scsi, sat, marvell, 3ware,N, areca,N, usbcy- press, usbjmicron, usbsunplus, cciss,N, hpt,L/M (or hpt,L/M/N), and test. # smartctl -a -d areca,0 /dev/arcmsr0 smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.1-PRERELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net /dev/arcmsr0: Unknown device type 'areca,0' =======> VALID ARGUMENTS ARE: ata, scsi, sat[,N][+TYPE], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, 3ware,N, hpt,L/M/N, cciss,N, atacam, test <======= Use smartctl -h to get a usage summary The latest CLI tool only gives this info CLI> disk info drv=1 Drive Information =============================================================== IDE Channel : 1 Model Name : ST31000340AS Serial Number : 3QJ07F1N Firmware Rev. : SD15 Disk Capacity : 1000.2GB Device State : NORMAL Timeout Count : 0 Media Error Count : 0 Device Temperature : 29 C SMART Read Error Rate : 108(6) SMART Spinup Time : 91(0) SMART Reallocation Count : 100(36) SMART Seek Error Rate : 81(30) SMART Spinup Retries : 100(97) SMART Calibration Retries : N.A.(N.A.) =============================================================== GuiErrMsg<0x00>: Success. CLI> disk smart drv=1 S.M.A.R.T Information For Drive[#01] # Attribute Items Flag Value Thres State =============================================================================== 1 Raw Read Error Rate 0x0f 108 6 OK 3 Spin Up Time 0x03 91 0 OK 4 Start/Stop Count 0x32 100 20 OK 5 Reallocated Sector Count 0x33 100 36 OK 7 Seek Error Rate 0x0f 81 30 OK 9 Power-on Hours Count 0x32 79 0 OK 10 Spin Retry Count 0x13 100 97 OK 12 Device Power Cycle Count 0x32 100 20 OK 194 Temperature 0x22 29 0 OK 197 Current Pending Sector Count 0x12 100 0 OK 198 Off-line Scan Uncorrectable Sector Count 0x10 100 0 OK 199 Ultra DMA CRC Error Count 0x3e 200 0 OK =============================================================================== GuiErrMsg<0x00>: Success. CLI> The obvious ones (timeout, media error etc) are all zero >Also, I'm willing to bet that the da0 "volume" and the da1 "volume" >actually share the same physical disks on the Areca controller. Is that >correct? Yes >If so, think about what would happen if heavy I/O happened on >both da0 and da1 at the same time. I talk about this a bit more below. No different than any other single disk being heavily worked. Again, this particular hardware configuration has been beaten about for a couple of years. So I am not sure why all of a sudden it would be not possible to do > > > > Prior to someone rebooting it, it had been stuck in this state for a > > good 90min. Apart from upgrading to a later RELENG_8 to get the > > security patches, the machine had been running a few versions of > > RELENG_8 doing the same workloads every week without issue. > >Then I would say you'd need to roll back kernel+world to a previous date >and try to figure out when the issue began, if that is indeed the case. Possibly. The box only gets a heavy workout periodically when it does an rsync to our DR site. >It would also help if you could provide timestamps of those messages; >are they all happening at once, or gradual over time? If over time, do >they all happen around the same time every day, etc.? You see where I'm >going with this. Every couple of seconds I think. If it happens again, I will time it. >situation (since you'd then be dedicating an entire disk to just swap). >Others may have other advice. You mention in a later mail that the >ada[0-3] disks make up a ZFS pool of some sort. You might try splitting >ada0 into two slices, one for swap and the other used as a pool member. That seems like it would just move the problem you are trying to get me to avoid to a different set of disks. If putting swap on a raid array is a bad thing, I am not sure how moving it to a ZFS raid array will help. >Again: I don't think this is necessarily a bad disk problem. The only >way you'd be able to determine that would be to monitor on a per-disk >basis the I/O response time of each disk member on the Areca. If the >CLI tools provide this, awesome. Otherwise you'll probably need to >involve Areca Support. In the past when I have had bad disks on the areca, it did catch and flag device timeouts. There were no such alerts leading up to this situation. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 12:41:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C66C106564A for ; Mon, 19 Jul 2010 12:41:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7CD8FC22 for ; Mon, 19 Jul 2010 12:41:38 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6JCfcq5049355; Mon, 19 Jul 2010 08:41:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007191241.o6JCfcq5049355@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 08:41:40 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20100719035844.GA93487@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> <20100719035844.GA93487@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 12:41:39 -0000 At 11:58 PM 7/18/2010, Jeremy Chadwick wrote: >So I believe this indicates the message only gets printed during swapin, >not swapout. Meaning it's happening during an I/O read from da0. Yes, and from my existing ssh sessions, it would _seem_ no disk IO was completing. ie I tried a killall -9 watchdogd which would need to load killall from the disk, read whatever its linked against. However, after hitting enter it was just blocking on trying to read. So I would describe it as if the entire system was waiting from that "swapper Indefinite wait" to finish, or I could not read anything from drives associated with that controller. >So what's hz? Well, I want to assume it's kern.hz, which defaults to >1000. 1000*20 = 20000, so the timeout would be 20000/1000 = 20 seconds. >That's a pretty long time to be waiting for an I/O read to return. I think the messages were printing to the serial console faster than that, but I could be wrong. If it happens again, I will time it ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 12:48:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF761065678 for ; Mon, 19 Jul 2010 12:48:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id C9B068FC0A for ; Mon, 19 Jul 2010 12:48:26 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6JCmP4N049393; Mon, 19 Jul 2010 08:48:25 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007191248.o6JCmP4N049393@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 08:48:27 -0400 To: Jeremy Chadwick From: Mike Tancsa In-Reply-To: <20100719041149.GA93978@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> <20100719035844.GA93487@icarus.home.lan> <20100719041149.GA93978@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 12:48:27 -0000 At 12:11 AM 7/19/2010, Jeremy Chadwick wrote: >On Sun, Jul 18, 2010 at 08:58:44PM -0700, Jeremy Chadwick wrote: > > I took a look at the RELENG_8 code responsible for printing this > > message: src/sys/vm/swap_pager.c > > > > [...] > > 1086 static int > > 1087 swap_pager_getpages(vm_object_t object, vm_page_t *m, int > count, int reqpage) > > 1088 { > > [...] > >There was a change to this piece of code on May 13th. See commit >1.312.2.4 below: > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/swap_pager.c > >Before I pull in kib@ or alc@ to help determine if what was introduced >could cause what you're seeing, can you clarify this point? > > > FreeBSD 8.1-PRERELEASE #0: Tue Jul 13 09:55:48 EDT 2010 > > mdtancsa at backup3.sentex.ca:/usr/obj/usr/src/sys/backup amd64 > > [...] > > Its never been an issue in the past 2yrs. The same box was RELENG_7 > > for some time and then in the past 3 months updated to RELENG_8. > >Has this system run a previous version of RELENG_8 within the past 3 Here is the recent history of what kernels the box was running Dec 1 07:49:34 backup3 kernel: FreeBSD 7.2-STABLE #0: Mon Nov 30 23:18:16 EST 2009 Dec 1 08:06:17 backup3 kernel: FreeBSD 7.2-STABLE #0: Mon Nov 30 23:18:16 EST 2009 Mar 9 14:50:02 backup3 kernel: FreeBSD 7.3-PRERELEASE #1: Tue Mar 9 12:44:17 EST 2010 Mar 9 14:59:58 backup3 kernel: FreeBSD 7.3-PRERELEASE #1: Tue Mar 9 12:44:17 EST 2010 Apr 21 10:38:05 backup3 kernel: FreeBSD 8.0-STABLE #0: Wed Apr 21 10:19:12 EDT 2010 May 10 10:44:04 backup3 kernel: FreeBSD 8.0-STABLE #2: Mon May 10 09:30:36 EDT 2010 May 26 10:46:05 backup3 kernel: FreeBSD 8.1-PRERELEASE #0: Tue May 25 17:18:59 EDT 2010 Jul 2 13:57:32 backup3 kernel: FreeBSD 8.1-PRERELEASE #2: Fri Jul 2 12:07:22 EDT 2010 Jul 13 13:11:43 backup3 kernel: FreeBSD 8.1-PRERELEASE #0: Tue Jul 13 09:55:48 EDT 2010 Jul 18 13:46:15 backup3 kernel: FreeBSD 8.1-PRERELEASE #0: Tue Jul 13 09:55:48 EDT 2010 >months, or are you seeing this issue "as a result of upgrading from >RELENG_7 to RELENG_8"? The first time I have seen this was going from July 2 to the 13th. However, before drawing any conclusions, this could just be a very odd edge case or hardware, or an actual regression. I think its very hard to say at this point as I cant even reproduce it on demand. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 13:12:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CE72106566B for ; Mon, 19 Jul 2010 13:12:14 +0000 (UTC) (envelope-from sascha=freebsd-stable=freebsd.org=ryjkqjdf@holzleiter.name) Received: from mail.daemonground.de (unknown [IPv6:2a01:4f8:120:84a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 292198FC0C for ; Mon, 19 Jul 2010 13:12:13 +0000 (UTC) Received: from oinetka.gfsrv.net ([79.110.95.2] helo=dreamland.office.local) by mail.daemonground.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim) (envelope-from ) id 1Oaq8j-000Fe8-0p for freebsd-stable@freebsd.org; Mon, 19 Jul 2010 15:12:13 +0200 From: Sascha Holzleiter To: freebsd-stable@freebsd.org Date: Mon, 19 Jul 2010 15:12:08 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.0-STABLE; KDE/4.4.5; amd64; ; ) References: <201007182108.o6IL88eG043887@lava.sentex.ca> In-Reply-To: <201007182108.o6IL88eG043887@lava.sentex.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201007191512.08693.sascha@holzleiter.name> Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 13:12:14 -0000 > > just hangs, I guess because its having trouble reading from the disk. > If I hit CTRL+t, I see > > load: 0.00 cmd: csh 73167 [vnread] 22.32r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 22.65r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 22.96r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 23.20r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 23.40r 0.00u 0.00s 0% 3232k > load: 0.00 cmd: csh 73167 [vnread] 23.61r 0.00u 0.00s 0% 3232k > > Hi, i have similar problems on a i7 system with a 3ware 9650SE controller and a simple 2 disk RAID1 configuration. I can trigger it by just extracting the ports tree onto the raid. It usually stops several times for over a minute doing nothing before continuing. While building KDE it stopped for good when extracting a port. The bsdtar process was hanging there in the wdrain status. Waited over 60 minutes before interrupting the process. I haven't seen any messages in dmesg. I'll try to build with debug support tonight and see if it makes a difference. The version was the one delivered with the PC-BSD 8.1RC discs but also after upgrading to the newest RELENG_8 sources the problem persists. The hardware is fairly new and other OSes show no problems so i'm inclined to say that the hardware isn't faulty ;) I could also try to install a 8.0 system if it helps to determine if a regression in 8.1 is the problem. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:13:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B04B9106564A; Mon, 19 Jul 2010 15:13:19 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6F78A8FC16; Mon, 19 Jul 2010 15:13:19 +0000 (UTC) Received: from [192.168.2.161] (soundwave.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.161]) by relay.admin.pitbpa0.priv.collaborativefusion.com with esmtp; Mon, 19 Jul 2010 11:13:18 -0400 id 0001702A.000000004C446B8E.0000429F From: "Brian A. Seklecki" To: Jack Vogel In-Reply-To: References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> <4C3F49E8.9090201@comcast.net> Organization: Collaborative Fusion, Inc. Date: Mon, 19 Jul 2010 11:13:18 -0400 Message-ID: <1279552398.31311.443.camel@soundwave> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_blackout-17055-1279552398-0001-2" X-Mailer: Evolution 2.30.2 (2.30.2-1.fc13) Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Steve Polyack , Harald Schmalzbauer , Michael Tuexen , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@collaborativefusion.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:13:19 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_blackout-17055-1279552398-0001-2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2010-07-15 at 10:53 -0700, Jack Vogel wrote: > The fact that I WISH it to be MFC'd doesn't mean that I am actually > given permission to do so. It seems 8.1 release was tagged on Saturday so we're proper-fucked (we will have to run local patches on all 1850s and 2850s for the duration of RELENG_8_1) http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D210187 Might want to prepare a patch file and instructions now for when the whining starts on freebsd-questions@. ~BAS --=_blackout-17055-1279552398-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkxEa44ACgkQCne6BNDQ+R9S6QCfYyvzXNLQZLgHRvV8Noc8kPKI AxoAn1pgM+paJjjs6Q9KYVr2JkmU515w =KoXx -----END PGP SIGNATURE----- --=_blackout-17055-1279552398-0001-2-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:21:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E66EC106564A for ; Mon, 19 Jul 2010 15:21:45 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCE138FC15 for ; Mon, 19 Jul 2010 15:21:44 +0000 (UTC) Received: by pvh1 with SMTP id 1so1966676pvh.13 for ; Mon, 19 Jul 2010 08:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Worn6ZrlQfal11mDCuOPuBCMTSk75UvHxM5PgEn/7fQ=; b=iFBAs/mW16CibgMKHg6976c34xjxbI789XY+L/CpSPVysZODZj90G3en8Zgew8Qg2/ mBp8l3B195cq7K6WKCgnO4KmTIuFnbx59kJplkY86BovQTb4b5W3RBh+oj43MarqCDdc kHvSzjyYIo98NHmDFkPEs4Q7Lhn5kkaE/nyEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LKwmTT63EnC5aWrfN29fmHsijNmJHCLB7FWCZw9C2lZUoNCsrOrgyA2SYUOaeiCq0n JMn5+Hdwq8RP3DmAoDKR3YfMwPpmrRTj+wZdY5mLCuDUl/Bsy+XuwwN8wq0Xl2ADVKgG cq4WUFBMxfkpKwCjR+TYjugy8lylYzlNv6P5A= MIME-Version: 1.0 Received: by 10.142.142.15 with SMTP id p15mr6961545wfd.199.1279552898448; Mon, 19 Jul 2010 08:21:38 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 08:21:38 -0700 (PDT) Date: Mon, 19 Jul 2010 11:21:38 -0400 Message-ID: From: Garrett Moore To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:21:46 -0000 I have an 8-drive ZFS array consisting of WD15EADS drives. One of my disks has started to fail, so I got a replacement disk. I have replaced a disk before by: zpool offline tank /dev/da5 shutting down, swapping from old disk to new disk booting zpool replace tank /dev/da5 This worked fine. This time the failing disk was da3, and I tried the same thing: zpool offline tank /dev/da3 zpool status showed da3 offline. shut down, swapped old disk to new disk. When I booted again, I got: Code: NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas raidz1 UNAVAIL 0 0 0 corrupted data da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 I switched back to the old disk and booted again and then I could access my data again, and da3 still showed as offline. I tried 'zpool online tank /dev/da3' and after a few seconds resilvering completed and all 8 drives are back online again, but with the 'dying' disk as da3 still. I tried shutting down WITHOUT first offlining /dev/da3, and swapping the disks, and when I booted I again got 'insufficient replicas'. Why am I getting this error, and how come it worked ok the last time I replaced a disk? And more importantly, how do I switch to my new replacement disk without losing data? Thanks. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:24:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16487106564A for ; Mon, 19 Jul 2010 15:24:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id B893D8FC1F for ; Mon, 19 Jul 2010 15:24:18 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta07.westchester.pa.mail.comcast.net with comcast id jnW41e00517dt5G57rQJd1; Mon, 19 Jul 2010 15:24:18 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta13.westchester.pa.mail.comcast.net with comcast id jrQH1e00P3LrwQ23ZrQJQ8; Mon, 19 Jul 2010 15:24:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 94FD39B425; Mon, 19 Jul 2010 08:24:16 -0700 (PDT) Date: Mon, 19 Jul 2010 08:24:16 -0700 From: Jeremy Chadwick To: Garrett Moore Message-ID: <20100719152416.GA14324@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:24:19 -0000 On Mon, Jul 19, 2010 at 11:21:38AM -0400, Garrett Moore wrote: > I have an 8-drive ZFS array consisting of WD15EADS drives. One of my disks > has started to fail, so I got a replacement disk. I have replaced a disk > before by: > > zpool offline tank /dev/da5 > shutting down, swapping from old disk to new disk > booting > zpool replace tank /dev/da5 > > This worked fine. > > This time the failing disk was da3, and I tried the same thing: > zpool offline tank /dev/da3 > zpool status showed da3 offline. > shut down, swapped old disk to new disk. > > When I booted again, I got: > Code: > > NAME STATE READ WRITE CKSUM > tank UNAVAIL 0 0 0 insufficient replicas > raidz1 UNAVAIL 0 0 0 corrupted data > da0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > > I switched back to the old disk and booted again and then I could access my > data again, and da3 still showed as offline. I tried 'zpool online tank > /dev/da3' and after a few seconds resilvering completed and all 8 drives are > back online again, but with the 'dying' disk as da3 still. > > I tried shutting down WITHOUT first offlining /dev/da3, and swapping the > disks, and when I booted I again got 'insufficient replicas'. > > Why am I getting this error, and how come it worked ok the last time I > replaced a disk? And more importantly, how do I switch to my new replacement > disk without losing data? Can you please provide uname -a output? Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:33:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A50BC1065673 for ; Mon, 19 Jul 2010 15:33:43 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7782D8FC16 for ; Mon, 19 Jul 2010 15:33:43 +0000 (UTC) Received: by pwj9 with SMTP id 9so1981573pwj.13 for ; Mon, 19 Jul 2010 08:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IaTOgZfLLzG9XWViDAHsOLrneGavrcmXGbVH3D6F8aI=; b=L1rPTB35w5+44lkToXS6Ed4zI/UcxYjjYaeMnlu20jKLUrWP3IDhLnqrcarF61Q9Rb yN3qJSfMmJGv5rohyFn4I4wX9vYat9OqqlOAv2fRIfFxVc8jJlJCd1xtJAhwxnJQ2Tsd AsnrJf9ulIxRVejaPfM4idtYD8Ymk2YpJHF/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DFhpf6IKnt5hjA7YJWoHyGMa2eZl+gHsRJtI7r/wcArtr27iRW+YWLyaEaCXce0AxW bItn8V8mEpBKARZ2FEYFnL3AB8yhXlbKrC6VREPJvmJDEuF9e79cilmww5YHauffuwyl 5jL7PHiQQa8Kv5mGq4m5DbA/AL3Ry3O9IsxBE= MIME-Version: 1.0 Received: by 10.114.103.3 with SMTP id a3mr7299406wac.34.1279553621778; Mon, 19 Jul 2010 08:33:41 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 08:33:41 -0700 (PDT) In-Reply-To: <20100719152416.GA14324@icarus.home.lan> References: <20100719152416.GA14324@icarus.home.lan> Date: Mon, 19 Jul 2010 11:33:41 -0400 Message-ID: From: Garrett Moore To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:33:43 -0000 Oops - shouldn't have forgotten that, sorry. FreeBSD leviathan 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 On Mon, Jul 19, 2010 at 11:24 AM, Jeremy Chadwick wrote: > On Mon, Jul 19, 2010 at 11:21:38AM -0400, Garrett Moore wrote: > > I have an 8-drive ZFS array consisting of WD15EADS drives. One of my > disks > > has started to fail, so I got a replacement disk. I have replaced a disk > > before by: > > > > zpool offline tank /dev/da5 > > shutting down, swapping from old disk to new disk > > booting > > zpool replace tank /dev/da5 > > > > This worked fine. > > > > This time the failing disk was da3, and I tried the same thing: > > zpool offline tank /dev/da3 > > zpool status showed da3 offline. > > shut down, swapped old disk to new disk. > > > > When I booted again, I got: > > Code: > > > > NAME STATE READ WRITE CKSUM > > tank UNAVAIL 0 0 0 insufficient replicas > > raidz1 UNAVAIL 0 0 0 corrupted data > > da0 ONLINE 0 0 0 > > da1 ONLINE 0 0 0 > > da2 ONLINE 0 0 0 > > da3 ONLINE 0 0 0 > > da4 ONLINE 0 0 0 > > da5 ONLINE 0 0 0 > > da6 ONLINE 0 0 0 > > da7 ONLINE 0 0 0 > > > > I switched back to the old disk and booted again and then I could access > my > > data again, and da3 still showed as offline. I tried 'zpool online tank > > /dev/da3' and after a few seconds resilvering completed and all 8 drives > are > > back online again, but with the 'dying' disk as da3 still. > > > > I tried shutting down WITHOUT first offlining /dev/da3, and swapping the > > disks, and when I booted I again got 'insufficient replicas'. > > > > Why am I getting this error, and how come it worked ok the last time I > > replaced a disk? And more importantly, how do I switch to my new > replacement > > disk without losing data? > > Can you please provide uname -a output? Thanks. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:45:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D123A106566B for ; Mon, 19 Jul 2010 15:45:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 981DA8FC19 for ; Mon, 19 Jul 2010 15:45:46 +0000 (UTC) Received: by iwn35 with SMTP id 35so5935591iwn.13 for ; Mon, 19 Jul 2010 08:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Dda8gqqlv8RBwJMo1k4EtO51WTUT1e1HHhBzO8kAmFk=; b=ikB2UkVsrmUSFzZZo2QUBR5UYZHLhTN0csDp+xzfuJRqbo4fi/v+FP2/Faya0npfL+ gUDxODny2iNGoMa24OiRfR3bmxfh40cyFHjhBH8d/uLha58Pe+5IXCHexwDvGMrSITmX JKzpteOUtoN3PwiOqJvUSClEbMo1vy7UmV1NE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=l6gKQ0vdjY569WkWwErxC4AWIbjTAMdxxgrlL0VMbo7TPV687Ia0SLEcaMU7bw5J2s MYsFzQ3HSu63fp//tCez8+KhPuJ6gSAepe6LgrFnNyYds0iKUoSH5wPSuFY3aoUEE9HN 1fyreU3jxlyB4yRHl5niixQ9nza48ClvKxx04= MIME-Version: 1.0 Received: by 10.42.1.130 with SMTP id 2mr327907icg.21.1279554345861; Mon, 19 Jul 2010 08:45:45 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Mon, 19 Jul 2010 08:45:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 08:45:45 -0700 Message-ID: From: Freddie Cash To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:45:46 -0000 On Mon, Jul 19, 2010 at 8:21 AM, Garrett Moore wro= te: > I have an 8-drive ZFS array consisting of WD15EADS drives. One of my disk= s > has started to fail, so I got a replacement disk. I have replaced a disk > before by: > > =C2=A0zpool offline tank /dev/da5 > shutting down, swapping from old disk to new disk > booting > =C2=A0zpool replace tank /dev/da5 > > This worked fine. > > This time the failing disk was da3, and I tried the same thing: > =C2=A0zpool offline tank /dev/da3 > zpool status showed da3 offline. > shut down, swapped old disk to new disk. For some reason, ZFS is getting confused by the device names, possibly due to the controller renumbering device nodes? Try the following: zpool offline tank /dev/da3 zpool status tank to make sure it offlined the correct drive zpool export tank might have to do this from single-user mode reboot zpool import tank this forces ZFS to re-taste each drive to read the metadata zpool replace tank /dev/da3 this should force it to use the correct drive Note: if you have / on ZFS, the above may not be doable. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:47:37 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 259B1106564A; Mon, 19 Jul 2010 15:47:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99A5D8FC1A; Mon, 19 Jul 2010 15:47:36 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6JFlJG9095497; Mon, 19 Jul 2010 17:47:34 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6JFlIwv095496; Mon, 19 Jul 2010 17:47:18 +0200 (CEST) (envelope-from olli) Date: Mon, 19 Jul 2010 17:47:18 +0200 (CEST) Message-Id: <201007191547.o6JFlIwv095496@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, jkim@FreeBSD.ORG, AndriyGapon In-Reply-To: <201007152001.o6FK1mGq088944@lurza.secnetix.de> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Mon, 19 Jul 2010 17:47:34 +0200 (CEST) Cc: Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:47:37 -0000 Oliver Fromme wrote: > Jung-uk Kim wrote: > > On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: > > > on 15/07/2010 19:57 Oliver Fromme said the following: > > > > I patched topo_probe() so it calls topo_probe_0x4() after > > > > topo_probe_0xb() if cpu_cores is still 0. I think this > > > > is a better fallback procedure. With this patch, cpu_cores > > > > gets the value 4 which is the correct one, finally: > > > [...] > > > I think that your addition achieves this effect, perhaps just not > > > as explicitly as I would preferred. > > > > > > Jung-uk, what do you think? > > > > Yes, you're right. Please try new patch: > > > > http://people.freebsd.org/~jkim/mp_machdep2.diff > > Thank you! > > I will have access to that particular machine on Monday again, > so testing the new patch will have to wait until Monday. > But from looking at your patch it should have the same result > as my simpler patch, so it should work fine. As expected, the patch works perfectly fine. The cores are detected correctly: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 0, 1, 2, 3 4, 5, 6, 7 Thanks for fixing this! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:56:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2030106567D for ; Mon, 19 Jul 2010 15:56:13 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 591378FC18 for ; Mon, 19 Jul 2010 15:56:13 +0000 (UTC) Received: by gwb19 with SMTP id 19so2056644gwb.13 for ; Mon, 19 Jul 2010 08:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4BgjzAXnuHUhnWcsvN8McYd9RFtl7v9EzG95ZXCAd0o=; b=uIzjC7Y5jxYHgBG63vL08wbv17rA7hnZo8aARIxnzMy34USxqhwReTpj8cwNgzgrDy f8ue+azMwRTOuA2O1DpPhXbnrM4h3RL7UGLCDDabmiLfshhxJKmSXr3vC7rg8Wrl8bUP sHPzk3T5k6/oIkD/46Q6X+s2UPveCGeHCK98w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nJnVaeHmBKncixxB4Tw2eyN59/Cin/3LroMLwB490QyZ+BcWksrcKLI6xqZe8+Oh/K hpSgftSSsetIw2cpa9Zz0MdJcDLgDGT6H+Bob4+7qHsMNMOQv24PnZniJI0OAh2RBDYu imaus052CA/uUsEyjgnEJmPTm3S0SrpLcb85c= MIME-Version: 1.0 Received: by 10.150.69.36 with SMTP id r36mr4791806yba.123.1279554972572; Mon, 19 Jul 2010 08:56:12 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 08:56:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 11:56:12 -0400 Message-ID: From: Garrett Moore To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:56:13 -0000 So you think it's because when I switch from the old disk to the new disk, ZFS doesn't realize the disk has changed, and thinks the data is just corrupt now? Even if that happens, shouldn't the pool still be available, since it's RAIDZ1 and only one disk has gone away? I don't have / on ZFS; I'm only using it as a 'data' partition, so I should be able to try your suggestion. My only concern: is there any risk of trashing my pool if I try your instructions? Everything I've done so far, even when told "insufficient replicas / corrupt data", has not cost me any data as long as I switch back to the original (dying) drive. If I mix in export/import statements which might 'touch' the pool, is there a chance it will choke and trash my data? On Mon, Jul 19, 2010 at 11:45 AM, Freddie Cash wrote: > On Mon, Jul 19, 2010 at 8:21 AM, Garrett Moore > wrote: > > I have an 8-drive ZFS array consisting of WD15EADS drives. One of my > disks > > has started to fail, so I got a replacement disk. I have replaced a disk > > before by: > > > > zpool offline tank /dev/da5 > > shutting down, swapping from old disk to new disk > > booting > > zpool replace tank /dev/da5 > > > > This worked fine. > > > > This time the failing disk was da3, and I tried the same thing: > > zpool offline tank /dev/da3 > > zpool status showed da3 offline. > > shut down, swapped old disk to new disk. > > For some reason, ZFS is getting confused by the device names, possibly > due to the controller renumbering device nodes? > > Try the following: > zpool offline tank /dev/da3 > zpool status tank to make sure it offlined > the correct drive > zpool export tank might have to do this > from single-user mode > reboot > > zpool import tank this forces ZFS to > re-taste each drive to read the metadata > zpool replace tank /dev/da3 this should force it to use > the correct drive > > Note: if you have / on ZFS, the above may not be doable. > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > 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 19 16:00:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 924FE1065670 for ; Mon, 19 Jul 2010 16:00:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from stith.flb.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 522738FC25 for ; Mon, 19 Jul 2010 16:00:44 +0000 (UTC) Received: from titan.flb.omnilan.net (titan.lo4.flb.omnilan.net [172.21.1.150]) (authenticated bits=0) by stith.flb.omnilan.net (8.13.8/8.13.8) with ESMTP id o6JG0NYv031237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 18:00:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.flb.omnilan.net [172.21.1.150] claimed to be titan.flb.omnilan.net Message-ID: <4C447684.7010308@omnilan.de> Date: Mon, 19 Jul 2010 18:00:04 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: bseklecki@collaborativefusion.com References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> <4C3F49E8.9090201@comcast.net> <1279552398.31311.443.camel@soundwave> In-Reply-To: <1279552398.31311.443.camel@soundwave> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6A690C36A07BC733D80DCC7" Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Steve Polyack , Michael Tuexen , Jack Vogel , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:00:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6A690C36A07BC733D80DCC7 Content-Type: multipart/mixed; boundary="------------020608030802000604090208" This is a multi-part message in MIME format. --------------020608030802000604090208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Brian A. Seklecki schrieb am 19.07.2010 17:13 (localtime): > On Thu, 2010-07-15 at 10:53 -0700, Jack Vogel wrote: >> The fact that I WISH it to be MFC'd doesn't mean that I am actually >> given permission to do so. >=20 > It seems 8.1 release was tagged on Saturday so we're proper-fucked > (we will have to run local patches on all 1850s and 2850s for the > duration of RELENG_8_1) >=20 > http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D210187 >=20 >=20 > Might want to prepare a patch file and instructions now for when At least the patchfile is something I have hand, Find attached. > the whining starts on freebsd-questions@. -Harry --------------020608030802000604090208 Content-Type: text/plain; name="e1000-releng8.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="e1000-releng8.patch" LS0tIHN5cy9kZXYvZTEwMDAvaWZfZW0uYwkyMDEwLzA1LzE4IDE3OjA5OjIwCTEuMjEuMi4x MAorKysgc3lzL2Rldi9lMTAwMC9pZl9lbS5jCTIwMTAvMDYvMTggMTc6MjI6MDgJMS4yMS4y LjExCkBAIC0zMCw3ICszMCw3IEBACiAgIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgog CiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKiovCi0vKiRGcmVlQlNEOiBzcmMvc3lzL2Rldi9l MTAwMC9pZl9lbS5jLHYgMS4yMS4yLjEwLjIuMSAyMDEwLzA2LzE0IDAyOjA5OjA2IGtlbnNt aXRoIEV4cCAkKi8KKy8qJEZyZWVCU0Q6IHNyYy9zeXMvZGV2L2UxMDAwL2lmX2VtLmMsdiAx LjIxLjIuMTEgMjAxMC8wNi8xOCAxNzoyMjowOCBqZnYgRXhwICQqLwogCiAjaWZkZWYgSEFW RV9LRVJORUxfT1BUSU9OX0hFQURFUlMKICNpbmNsdWRlICJvcHRfZGV2aWNlX3BvbGxpbmcu aCIKQEAgLTIzMCw4ICsyMzAsOSBAQCBzdGF0aWMgdm9pZAllbV9mcmVlX3JlY2VpdmVfYnVm ZmVycyhzdHJ1CiBzdGF0aWMgdm9pZAllbV9lbmFibGVfaW50cihzdHJ1Y3QgYWRhcHRlciAq KTsKIHN0YXRpYyB2b2lkCWVtX2Rpc2FibGVfaW50cihzdHJ1Y3QgYWRhcHRlciAqKTsKIHN0 YXRpYyB2b2lkCWVtX3VwZGF0ZV9zdGF0c19jb3VudGVycyhzdHJ1Y3QgYWRhcHRlciAqKTsK K3N0YXRpYyB2b2lkCWVtX2FkZF9od19zdGF0cyhzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcik7 CiBzdGF0aWMgYm9vbAllbV90eGVvZihzdHJ1Y3QgdHhfcmluZyAqKTsKLXN0YXRpYyBpbnQJ ZW1fcnhlb2Yoc3RydWN0IHJ4X3JpbmcgKiwgaW50KTsKK3N0YXRpYyBib29sCWVtX3J4ZW9m KHN0cnVjdCByeF9yaW5nICosIGludCwgaW50ICopOwogI2lmbmRlZiBfX05PX1NUUklDVF9B TElHTk1FTlQKIHN0YXRpYyBpbnQJZW1fZml4dXBfcngoc3RydWN0IHJ4X3JpbmcgKik7CiAj ZW5kaWYKQEAgLTI0Miw3ICsyNDMsNiBAQCBzdGF0aWMgYm9vbAllbV90c29fc2V0dXAoc3Ry dWN0IHR4X3JpbmcgCiBzdGF0aWMgdm9pZAllbV9zZXRfcHJvbWlzYyhzdHJ1Y3QgYWRhcHRl ciAqKTsKIHN0YXRpYyB2b2lkCWVtX2Rpc2FibGVfcHJvbWlzYyhzdHJ1Y3QgYWRhcHRlciAq KTsKIHN0YXRpYyB2b2lkCWVtX3NldF9tdWx0aShzdHJ1Y3QgYWRhcHRlciAqKTsKLXN0YXRp YyB2b2lkCWVtX3ByaW50X2h3X3N0YXRzKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIHZv aWQJZW1fdXBkYXRlX2xpbmtfc3RhdHVzKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIHZv aWQJZW1fcmVmcmVzaF9tYnVmcyhzdHJ1Y3QgcnhfcmluZyAqLCBpbnQpOwogc3RhdGljIHZv aWQJZW1fcmVnaXN0ZXJfdmxhbih2b2lkICosIHN0cnVjdCBpZm5ldCAqLCB1MTYpOwpAQCAt MjUyLDExICsyNTIsOSBAQCBzdGF0aWMgaW50CWVtX3htaXQoc3RydWN0IHR4X3JpbmcgKiwg c3RyCiBzdGF0aWMgaW50CWVtX2RtYV9tYWxsb2Moc3RydWN0IGFkYXB0ZXIgKiwgYnVzX3Np emVfdCwKIAkJICAgIHN0cnVjdCBlbV9kbWFfYWxsb2MgKiwgaW50KTsKIHN0YXRpYyB2b2lk CWVtX2RtYV9mcmVlKHN0cnVjdCBhZGFwdGVyICosIHN0cnVjdCBlbV9kbWFfYWxsb2MgKik7 Ci1zdGF0aWMgdm9pZAllbV9wcmludF9kZWJ1Z19pbmZvKHN0cnVjdCBhZGFwdGVyICopOwor c3RhdGljIGludAllbV9zeXNjdGxfbnZtX2luZm8oU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBz dGF0aWMgdm9pZAllbV9wcmludF9udm1faW5mbyhzdHJ1Y3QgYWRhcHRlciAqKTsKIHN0YXRp YyBpbnQgCWVtX2lzX3ZhbGlkX2V0aGVyX2FkZHIodTggKik7Ci1zdGF0aWMgaW50CWVtX3N5 c2N0bF9zdGF0cyhTWVNDVExfSEFORExFUl9BUkdTKTsKLXN0YXRpYyBpbnQJZW1fc3lzY3Rs X2RlYnVnX2luZm8oU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0aWMgaW50CWVtX3N5c2N0 bF9pbnRfZGVsYXkoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0aWMgdm9pZAllbV9hZGRf aW50X2RlbGF5X3N5c2N0bChzdHJ1Y3QgYWRhcHRlciAqLCBjb25zdCBjaGFyICosCiAJCSAg ICBjb25zdCBjaGFyICosIHN0cnVjdCBlbV9pbnRfZGVsYXlfaW5mbyAqLCBpbnQsIGludCk7 CkBAIC0zNDcsOCArMzQ1LDEzIEBAIHN0YXRpYyBpbnQgZW1fZGVidWdfc2JwID0gRkFMU0U7 CiBUVU5BQkxFX0lOVCgiaHcuZW0uc2JwIiwgJmVtX2RlYnVnX3NicCk7CiAKIC8qIExvY2Fs IGNvbnRyb2xzIGZvciBNU0kvTVNJWCAqLworI2lmZGVmIEVNX01VTFRJUVVFVUUKIHN0YXRp YyBpbnQgZW1fZW5hYmxlX21zaXggPSBUUlVFOwogc3RhdGljIGludCBlbV9tc2l4X3F1ZXVl cyA9IDI7IC8qIGZvciA4MjU3NCwgY2FuIGJlIDEgb3IgMiAqLworI2Vsc2UKK3N0YXRpYyBp bnQgZW1fZW5hYmxlX21zaXggPSBGQUxTRTsKK3N0YXRpYyBpbnQgZW1fbXNpeF9xdWV1ZXMg PSAwOyAvKiBkaXNhYmxlICovCisjZW5kaWYKIFRVTkFCTEVfSU5UKCJody5lbS5lbmFibGVf bXNpeCIsICZlbV9lbmFibGVfbXNpeCk7CiBUVU5BQkxFX0lOVCgiaHcuZW0ubXNpeF9xdWV1 ZXMiLCAmZW1fbXNpeF9xdWV1ZXMpOwogCkBAIC00NDcsMTMgKzQ1MCw4IEBAIGVtX2F0dGFj aChkZXZpY2VfdCBkZXYpCiAJLyogU1lTQ1RMIHN0dWZmICovCiAJU1lTQ1RMX0FERF9QUk9D KGRldmljZV9nZXRfc3lzY3RsX2N0eChkZXYpLAogCSAgICBTWVNDVExfQ0hJTERSRU4oZGV2 aWNlX2dldF9zeXNjdGxfdHJlZShkZXYpKSwKLQkgICAgT0lEX0FVVE8sICJkZWJ1ZyIsIENU TFRZUEVfSU5UfENUTEZMQUdfUlcsIGFkYXB0ZXIsIDAsCi0JICAgIGVtX3N5c2N0bF9kZWJ1 Z19pbmZvLCAiSSIsICJEZWJ1ZyBJbmZvcm1hdGlvbiIpOwotCi0JU1lTQ1RMX0FERF9QUk9D KGRldmljZV9nZXRfc3lzY3RsX2N0eChkZXYpLAotCSAgICBTWVNDVExfQ0hJTERSRU4oZGV2 aWNlX2dldF9zeXNjdGxfdHJlZShkZXYpKSwKLQkgICAgT0lEX0FVVE8sICJzdGF0cyIsIENU TFRZUEVfSU5UfENUTEZMQUdfUlcsIGFkYXB0ZXIsIDAsCi0JICAgIGVtX3N5c2N0bF9zdGF0 cywgIkkiLCAiU3RhdGlzdGljcyIpOworCSAgICBPSURfQVVUTywgIm52bSIsIENUTFRZUEVf SU5UfENUTEZMQUdfUlcsIGFkYXB0ZXIsIDAsCisJICAgIGVtX3N5c2N0bF9udm1faW5mbywg IkkiLCAiTlZNIEluZm9ybWF0aW9uIik7CiAKIAljYWxsb3V0X2luaXRfbXR4KCZhZGFwdGVy LT50aW1lciwgJmFkYXB0ZXItPmNvcmVfbXR4LCAwKTsKIApAQCAtNjUxLDYgKzY0OSw4IEBA IGVtX2F0dGFjaChkZXZpY2VfdCBkZXYpCiAJYWRhcHRlci0+dmxhbl9kZXRhY2ggPSBFVkVO VEhBTkRMRVJfUkVHSVNURVIodmxhbl91bmNvbmZpZywKIAkgICAgZW1fdW5yZWdpc3Rlcl92 bGFuLCBhZGFwdGVyLCBFVkVOVEhBTkRMRVJfUFJJX0ZJUlNUKTsgCiAKKwllbV9hZGRfaHdf c3RhdHMoYWRhcHRlcik7CisKIAkvKiBOb24tQU1UIGJhc2VkIGhhcmR3YXJlIGNhbiBub3cg dGFrZSBjb250cm9sIGZyb20gZmlybXdhcmUgKi8KIAlpZiAoYWRhcHRlci0+aGFzX21hbmFn ZSAmJiAhYWRhcHRlci0+aGFzX2FtdCkKIAkJZW1fZ2V0X2h3X2NvbnRyb2woYWRhcHRlcik7 CkBAIC0xMzUxLDEyICsxMzUxLDEzIEBAIGVtX3BvbGwoc3RydWN0IGlmbmV0ICppZnAsIGVu dW0gcG9sbF9jbWQKIAlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7 CiAJc3RydWN0IHR4X3JpbmcJKnR4ciA9IGFkYXB0ZXItPnR4X3JpbmdzOwogCXN0cnVjdCBy eF9yaW5nCSpyeHIgPSBhZGFwdGVyLT5yeF9yaW5nczsKLQl1MzIJCXJlZ19pY3IsIHJ4X2Rv bmUgPSAwOworCXUzMgkJcmVnX2ljcjsKKwlpbnQJCXJ4X2RvbmU7CiAKIAlFTV9DT1JFX0xP Q0soYWRhcHRlcik7CiAJaWYgKChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklO RykgPT0gMCkgewogCQlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKLQkJcmV0dXJuIChyeF9k b25lKTsKKwkJcmV0dXJuICgwKTsKIAl9CiAKIAlpZiAoY21kID09IFBPTExfQU5EX0NIRUNL X1NUQVRVUykgewpAQCAtMTM3MSw5ICsxMzcyLDcgQEAgZW1fcG9sbChzdHJ1Y3QgaWZuZXQg KmlmcCwgZW51bSBwb2xsX2NtZAogCX0KIAlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKIAot CUVNX1JYX0xPQ0socnhyKTsKLQlyeF9kb25lID0gZW1fcnhlb2YocnhyLCBjb3VudCk7Ci0J RU1fUlhfVU5MT0NLKHJ4cik7CisJZW1fcnhlb2YocnhyLCBjb3VudCwgJnJ4X2RvbmUpOwog CiAJRU1fVFhfTE9DSyh0eHIpOwogCWVtX3R4ZW9mKHR4cik7CkBAIC0xNDQ1LDE2ICsxNDQ0 LDE1IEBAIGVtX2hhbmRsZV9xdWUodm9pZCAqY29udGV4dCwgaW50IHBlbmRpbmcKIAlzdHJ1 Y3QgaWZuZXQJKmlmcCA9IGFkYXB0ZXItPmlmcDsKIAlzdHJ1Y3QgdHhfcmluZwkqdHhyID0g YWRhcHRlci0+dHhfcmluZ3M7CiAJc3RydWN0IHJ4X3JpbmcJKnJ4ciA9IGFkYXB0ZXItPnJ4 X3JpbmdzOwotCWJvb2wJCW1vcmVfcng7CisJYm9vbAkJbW9yZTsKIAogCiAJaWYgKGlmcC0+ aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSB7Ci0JCUVNX1JYX0xPQ0socnhyKTsK LQkJbW9yZV9yeCA9IGVtX3J4ZW9mKHJ4ciwgYWRhcHRlci0+cnhfcHJvY2Vzc19saW1pdCk7 Ci0JCUVNX1JYX1VOTE9DSyhyeHIpOworCQltb3JlID0gZW1fcnhlb2YocnhyLCBhZGFwdGVy LT5yeF9wcm9jZXNzX2xpbWl0LCBOVUxMKTsKIAogCQlFTV9UWF9MT0NLKHR4cik7Ci0JCWVt X3R4ZW9mKHR4cik7CisJCWlmIChlbV90eGVvZih0eHIpKQorCQkJbW9yZSA9IFRSVUU7CiAj aWZkZWYgRU1fTVVMVElRVUVVRQogCQlpZiAoIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkK IAkJCWVtX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CkBAIC0xNDYzLDcgKzE0 NjEsNyBAQCBlbV9oYW5kbGVfcXVlKHZvaWQgKmNvbnRleHQsIGludCBwZW5kaW5nCiAJCQll bV9zdGFydF9sb2NrZWQoaWZwLCB0eHIpOwogI2VuZGlmCiAJCUVNX1RYX1VOTE9DSyh0eHIp OwotCQlpZiAobW9yZV9yeCkgeworCQlpZiAobW9yZSkgewogCQkJdGFza3F1ZXVlX2VucXVl dWUoYWRhcHRlci0+dHEsICZhZGFwdGVyLT5xdWVfdGFzayk7CiAJCQlyZXR1cm47CiAJCX0K QEAgLTE1MTEsMTAgKzE1MDksOCBAQCBlbV9tc2l4X3J4KHZvaWQgKmFyZykKIAlzdHJ1Y3Qg YWRhcHRlcgkqYWRhcHRlciA9IHJ4ci0+YWRhcHRlcjsKIAlib29sCQltb3JlOwogCi0JRU1f UlhfTE9DSyhyeHIpOwogCSsrcnhyLT5yeF9pcnE7Ci0JbW9yZSA9IGVtX3J4ZW9mKHJ4ciwg YWRhcHRlci0+cnhfcHJvY2Vzc19saW1pdCk7Ci0JRU1fUlhfVU5MT0NLKHJ4cik7CisJbW9y ZSA9IGVtX3J4ZW9mKHJ4ciwgYWRhcHRlci0+cnhfcHJvY2Vzc19saW1pdCwgTlVMTCk7CiAJ aWYgKG1vcmUpCiAJCXRhc2txdWV1ZV9lbnF1ZXVlKHJ4ci0+dHEsICZyeHItPnJ4X3Rhc2sp OwogCWVsc2UKQEAgLTE1MzksNyArMTUzNSw3IEBAIGVtX21zaXhfbGluayh2b2lkICphcmcp CiAKIAlpZiAocmVnX2ljciAmIChFMTAwMF9JQ1JfUlhTRVEgfCBFMTAwMF9JQ1JfTFNDKSkg ewogCQlhZGFwdGVyLT5ody5tYWMuZ2V0X2xpbmtfc3RhdHVzID0gMTsKLQkJdGFza3F1ZXVl X2VucXVldWUodGFza3F1ZXVlX2Zhc3QsICZhZGFwdGVyLT5saW5rX3Rhc2spOworCQllbV9o YW5kbGVfbGluayhhZGFwdGVyLCAwKTsKIAl9IGVsc2UKIAkJRTEwMDBfV1JJVEVfUkVHKCZh ZGFwdGVyLT5odywgRTEwMDBfSU1TLAogCQkgICAgRU1fTVNJWF9MSU5LIHwgRTEwMDBfSU1T X0xTQyk7CkBAIC0xNTUzLDkgKzE1NDksNyBAQCBlbV9oYW5kbGVfcngodm9pZCAqY29udGV4 dCwgaW50IHBlbmRpbmcpCiAJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIgPSByeHItPmFkYXB0 ZXI7CiAgICAgICAgIGJvb2wgICAgICAgICAgICBtb3JlOwogCi0JRU1fUlhfTE9DSyhyeHIp OwotCW1vcmUgPSBlbV9yeGVvZihyeHIsIGFkYXB0ZXItPnJ4X3Byb2Nlc3NfbGltaXQpOwot CUVNX1JYX1VOTE9DSyhyeHIpOworCW1vcmUgPSBlbV9yeGVvZihyeHIsIGFkYXB0ZXItPnJ4 X3Byb2Nlc3NfbGltaXQsIE5VTEwpOwogCWlmIChtb3JlKQogCQl0YXNrcXVldWVfZW5xdWV1 ZShyeHItPnRxLCAmcnhyLT5yeF90YXNrKTsKIAllbHNlCkBAIC0yMDY5LDkgKzIwNjMsNiBA QCBlbV9sb2NhbF90aW1lcih2b2lkICphcmcpCiAJaWYgKGUxMDAwX2dldF9sYWFfc3RhdGVf ODI1NzEoJmFkYXB0ZXItPmh3KSA9PSBUUlVFKQogCQllMTAwMF9yYXJfc2V0KCZhZGFwdGVy LT5odywgYWRhcHRlci0+aHcubWFjLmFkZHIsIDApOwogCi0JaWYgKGVtX2Rpc3BsYXlfZGVi dWdfc3RhdHMgJiYgaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpCi0JCWVt X3ByaW50X2h3X3N0YXRzKGFkYXB0ZXIpOwotCiAJLyoKIAkqKiBDaGVjayBmb3IgdGltZSBz aW5jZSBhbnkgZGVzY3JpcHRvciB3YXMgY2xlYW5lZAogCSovCkBAIC0yNDMxLDExICsyNDIy LDYgQEAgZW1fYWxsb2NhdGVfbXNpeChzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcgogCWFkYXB0 ZXItPmxpbmt2ZWMgPSB2ZWN0b3I7CiAJYWRhcHRlci0+aXZhcnMgfD0gICg4IHwgdmVjdG9y KSA8PCAxNjsKIAlhZGFwdGVyLT5pdmFycyB8PSAweDgwMDAwMDAwOwotCVRBU0tfSU5JVCgm YWRhcHRlci0+bGlua190YXNrLCAwLCBlbV9oYW5kbGVfbGluaywgYWRhcHRlcik7Ci0JYWRh cHRlci0+dHEgPSB0YXNrcXVldWVfY3JlYXRlX2Zhc3QoImVtX2xpbmsiLCBNX05PV0FJVCwK LQkgICAgdGFza3F1ZXVlX3RocmVhZF9lbnF1ZXVlLCAmYWRhcHRlci0+dHEpOwotCXRhc2tx dWV1ZV9zdGFydF90aHJlYWRzKCZhZGFwdGVyLT50cSwgMSwgUElfTkVULCAiJXMgbGlua3Ei LAotCSAgICBkZXZpY2VfZ2V0X25hbWV1bml0KGFkYXB0ZXItPmRldikpOwogCiAJcmV0dXJu ICgwKTsKIH0KQEAgLTQwOTAsOCArNDA3Niw4IEBAIGVtX2luaXRpYWxpemVfcmVjZWl2ZV91 bml0KHN0cnVjdCBhZGFwdGUKICAqICAKICAqICBGb3IgcG9sbGluZyB3ZSBhbHNvIG5vdyBy ZXR1cm4gdGhlIG51bWJlciBvZiBjbGVhbmVkIHBhY2tldHMKICAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiov Ci1zdGF0aWMgaW50Ci1lbV9yeGVvZihzdHJ1Y3QgcnhfcmluZyAqcnhyLCBpbnQgY291bnQp CitzdGF0aWMgYm9vbAorZW1fcnhlb2Yoc3RydWN0IHJ4X3JpbmcgKnJ4ciwgaW50IGNvdW50 LCBpbnQgKmRvbmUpCiB7CiAJc3RydWN0IGFkYXB0ZXIJCSphZGFwdGVyID0gcnhyLT5hZGFw dGVyOwogCXN0cnVjdCBpZm5ldAkJKmlmcCA9IGFkYXB0ZXItPmlmcDsKQEAgLTQxMDIsNyAr NDA4OCw3IEBAIGVtX3J4ZW9mKHN0cnVjdCByeF9yaW5nICpyeHIsIGludCBjb3VudCkKIAli b29sCQkJZW9wOwogCXN0cnVjdCBlMTAwMF9yeF9kZXNjCSpjdXI7CiAKLQlFTV9SWF9MT0NL X0FTU0VSVChyeHIpOworCUVNX1JYX0xPQ0socnhyKTsKIAogCWZvciAoaSA9IHJ4ci0+bmV4 dF90b19jaGVjaywgcHJvY2Vzc2VkID0gMDsgY291bnQgIT0gMDspIHsKIApAQCAtNDE5Niw4 ICs0MTgyLDEzIEBAIHNraXA6CiAJCQlpID0gMDsKIAogCQkvKiBTZW5kIHRvIHRoZSBzdGFj ayAqLwotCQlpZiAoc2VuZG1wICE9IE5VTEwpCisJCWlmIChzZW5kbXAgIT0gTlVMTCkgewor CQkJcnhyLT5uZXh0X3RvX2NoZWNrID0gaTsKKwkJCUVNX1JYX1VOTE9DSyhyeHIpOwogCQkJ KCppZnAtPmlmX2lucHV0KShpZnAsIHNlbmRtcCk7CisJCQlFTV9SWF9MT0NLKHJ4cik7CisJ CQlpID0gcnhyLT5uZXh0X3RvX2NoZWNrOworCQl9CiAKIAkJLyogT25seSByZWZyZXNoIG1i dWZzIGV2ZXJ5IDggZGVzY3JpcHRvcnMgKi8KIAkJaWYgKHByb2Nlc3NlZCA9PSA4KSB7CkBA IC00MjEzLDEyICs0MjA0LDExIEBAIHNraXA6CiAJfQogCiAJcnhyLT5uZXh0X3RvX2NoZWNr ID0gaTsKKwlpZiAoZG9uZSAhPSBOVUxMKQorCQkqZG9uZSA9IHJ4ZG9uZTsKKwlFTV9SWF9V TkxPQ0socnhyKTsKIAotI2lmZGVmIERFVklDRV9QT0xMSU5HCi0JcmV0dXJuIChyeGRvbmUp OwotI2Vsc2UKIAlyZXR1cm4gKChzdGF0dXMgJiBFMTAwMF9SWERfU1RBVF9ERCkgPyBUUlVF IDogRkFMU0UpOwotI2VuZGlmCiB9CiAKICNpZm5kZWYgX19OT19TVFJJQ1RfQUxJR05NRU5U CkBAIC00ODY5LDExNCArNDg1OSwyODUgQEAgZW1fdXBkYXRlX3N0YXRzX2NvdW50ZXJzKHN0 cnVjdCBhZGFwdGVyIAogfQogCiAKLS8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCi0gKgotICogIFRoaXMg cm91dGluZSBpcyBjYWxsZWQgb25seSB3aGVuIGVtX2Rpc3BsYXlfZGVidWdfc3RhdHMgaXMg ZW5hYmxlZC4KLSAqICBUaGlzIHJvdXRpbmUgcHJvdmlkZXMgYSB3YXkgdG8gdGFrZSBhIGxv b2sgYXQgaW1wb3J0YW50IHN0YXRpc3RpY3MKLSAqICBtYWludGFpbmVkIGJ5IHRoZSBkcml2 ZXIgYW5kIGhhcmR3YXJlLgotICoKLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworLyoKKyAqIEFkZCBz eXNjdGwgdmFyaWFibGVzLCBvbmUgcGVyIHN0YXRpc3RpYywgdG8gdGhlIHN5c3RlbS4KKyAq Lwogc3RhdGljIHZvaWQKLWVtX3ByaW50X2RlYnVnX2luZm8oc3RydWN0IGFkYXB0ZXIgKmFk YXB0ZXIpCitlbV9hZGRfaHdfc3RhdHMoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCiB7CisK IAlkZXZpY2VfdCBkZXYgPSBhZGFwdGVyLT5kZXY7Ci0JdTggKmh3X2FkZHIgPSBhZGFwdGVy LT5ody5od19hZGRyOwotCXN0cnVjdCByeF9yaW5nICpyeHIgPSBhZGFwdGVyLT5yeF9yaW5n czsKLQlzdHJ1Y3QgdHhfcmluZyAqdHhyID0gYWRhcHRlci0+dHhfcmluZ3M7CiAKLQlkZXZp Y2VfcHJpbnRmKGRldiwgIkFkYXB0ZXIgaGFyZHdhcmUgYWRkcmVzcyA9ICVwIFxuIiwgaHdf YWRkcik7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJDVFJMID0gMHgleCBSQ1RMID0gMHgleCBc biIsCi0JICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfQ1RSTCksCi0J ICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUkNUTCkpOwotCWRldmlj ZV9wcmludGYoZGV2LCAiUGFja2V0IGJ1ZmZlciA9IFR4PSVkayBSeD0lZGsgXG4iLAotCSAg ICAoKEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUEJBKSAmIDB4ZmZmZjAw MDApID4+IDE2KSxcCi0JICAgIChFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAw X1BCQSkgJiAweGZmZmYpICk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJGbG93IGNvbnRyb2wg d2F0ZXJtYXJrcyBoaWdoID0gJWQgbG93ID0gJWRcbiIsCi0JICAgIGFkYXB0ZXItPmh3LmZj LmhpZ2hfd2F0ZXIsCi0JICAgIGFkYXB0ZXItPmh3LmZjLmxvd193YXRlcik7Ci0JZGV2aWNl X3ByaW50ZihkZXYsICJ0eF9pbnRfZGVsYXkgPSAlZCwgdHhfYWJzX2ludF9kZWxheSA9ICVk XG4iLAotCSAgICBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1RJRFYpLAot CSAgICBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1RBRFYpKTsKLQlkZXZp Y2VfcHJpbnRmKGRldiwgInJ4X2ludF9kZWxheSA9ICVkLCByeF9hYnNfaW50X2RlbGF5ID0g JWRcbiIsCi0JICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUkRUUiks Ci0JICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUkFEVikpOworCXN0 cnVjdCBzeXNjdGxfY3R4X2xpc3QgKmN0eCA9IGRldmljZV9nZXRfc3lzY3RsX2N0eChkZXYp OworCXN0cnVjdCBzeXNjdGxfb2lkICp0cmVlID0gZGV2aWNlX2dldF9zeXNjdGxfdHJlZShk ZXYpOworCXN0cnVjdCBzeXNjdGxfb2lkX2xpc3QgKmNoaWxkID0gU1lTQ1RMX0NISUxEUkVO KHRyZWUpOworCXN0cnVjdCBlMTAwMF9od19zdGF0cyAqc3RhdHMgPSAmYWRhcHRlci0+c3Rh dHM7CisKKwlzdHJ1Y3Qgc3lzY3RsX29pZCAqc3RhdF9ub2RlLCAqaW50X25vZGUsICpob3N0 X25vZGU7CisJc3RydWN0IHN5c2N0bF9vaWRfbGlzdCAqc3RhdF9saXN0LCAqaW50X2xpc3Qs ICpob3N0X2xpc3Q7CisKKwkvKiBEcml2ZXIgU3RhdGlzdGljcyAqLworCVNZU0NUTF9BRERf VUlOVChjdHgsIGNoaWxkLCBPSURfQVVUTywgImxpbmtfaXJxIiwgCisJCQlDVExGTEFHX1JE LCAmYWRhcHRlci0+bGlua19pcnEsIDAsCisJCQkiTGluayBNU0lYIElSUSBIYW5kbGVkIik7 CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNoaWxkLCBPSURfQVVUTywgIm1idWZfYWxsb2Nf ZmFpbCIsIAorCQkJIENUTEZMQUdfUkQsICZhZGFwdGVyLT5tYnVmX2FsbG9jX2ZhaWxlZCwK KwkJCSAiU3RkIG1idWYgZmFpbGVkIik7CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNoaWxk LCBPSURfQVVUTywgImNsdXN0ZXJfYWxsb2NfZmFpbCIsIAorCQkJIENUTEZMQUdfUkQsICZh ZGFwdGVyLT5tYnVmX2NsdXN0ZXJfZmFpbGVkLAorCQkJICJTdGQgbWJ1ZiBjbHVzdGVyIGZh aWxlZCIpOworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJkcm9w cGVkIiwgCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+ZHJvcHBlZF9wa3RzLAorCQkJIkRy aXZlciBkcm9wcGVkIHBhY2tldHMiKTsKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQs IE9JRF9BVVRPLCAidHhfZG1hX2ZhaWwiLCAKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5u b190eF9kbWFfc2V0dXAsCisJCQkiRHJpdmVyIHR4IGRtYSBmYWlsdXJlIGluIHhtaXQiKTsK KworCVNZU0NUTF9BRERfVUlOVChjdHgsIGNoaWxkLCBPSURfQVVUTywgImZjX2hpZ2hfd2F0 ZXIiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPmh3LmZjLmhpZ2hfd2F0ZXIsIDAsCisJ CQkiRmxvdyBDb250cm9sIEhpZ2ggV2F0ZXJtYXJrIik7CisJU1lTQ1RMX0FERF9VSU5UKGN0 eCwgY2hpbGQsIE9JRF9BVVRPLCAiZmNfbG93X3dhdGVyIiwgCisJCQlDVExGTEFHX1JELCAm YWRhcHRlci0+aHcuZmMubG93X3dhdGVyLCAwLAorCQkJIkZsb3cgQ29udHJvbCBMb3cgV2F0 ZXJtYXJrIik7CisKKwkvKiBNQUMgc3RhdHMgZ2V0IHRoZSBvd24gc3ViIG5vZGUgKi8KKwor CXN0YXRfbm9kZSA9IFNZU0NUTF9BRERfTk9ERShjdHgsIGNoaWxkLCBPSURfQVVUTywgIm1h Y19zdGF0cyIsIAorCQkJCSAgICBDVExGTEFHX1JELCBOVUxMLCAiU3RhdGlzdGljcyIpOwor CXN0YXRfbGlzdCA9IFNZU0NUTF9DSElMRFJFTihzdGF0X25vZGUpOworCisJU1lTQ1RMX0FE RF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgImV4Y2Vzc19jb2xsIiwgCisJCQlD VExGTEFHX1JELCAmc3RhdHMtPmVjb2wsCisJCQkiRXhjZXNzaXZlIGNvbGxpc2lvbnMiKTsK KwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAic3ltYm9sX2Vy cm9ycyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuc3ltZXJycywKKwkJCSJT eW1ib2wgRXJyb3JzIik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURf QVVUTywgInNlcXVlbmNlX2Vycm9ycyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3Rh dHMuc2VjLAorCQkJIlNlcXVlbmNlIEVycm9ycyIpOworCVNZU0NUTF9BRERfUVVBRChjdHgs IHN0YXRfbGlzdCwgT0lEX0FVVE8sICJkZWZlcl9jb3VudCIsCisJCQlDVExGTEFHX1JELCAm YWRhcHRlci0+c3RhdHMuZGMsCisJCQkiRGVmZXIgQ291bnQiKTsKKwlTWVNDVExfQUREX1FV QUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAibWlzc2VkX3BhY2tldHMiLAorCQkJQ1RM RkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLm1wYywKKwkJCSJNaXNzZWQgUGFja2V0cyIpOwor CVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyZWN2X25vX2J1 ZmYiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnJuYmMsCisJCQkiUmVjZWl2 ZSBObyBCdWZmZXJzIik7CisJLyogUkxFQyBpcyBpbmFjY3VyYXRlIG9uIHNvbWUgaGFyZHdh cmUsIGNhbGN1bGF0ZSBvdXIgb3duLiAqLworLyogCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0 YXRfbGlzdCwgT0lEX0FVVE8sICJyZWN2X2xlbl9lcnJzIiwgKi8KKy8qIAkJCUNUTEZMQUdf UkQsIGFkYXB0ZXItPnN0YXRzLnJvYyArIGFkYXB0ZXItPnN0YXRzLnJ1YywgKi8KKy8qIAkJ CSJSZWNlaXZlIExlbmd0aCBFcnJvcnMiKTsgKi8KKworCVNZU0NUTF9BRERfUVVBRChjdHgs IHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyZWN2X2VycnMiLAorCQkJQ1RMRkxBR19SRCwgJmFk YXB0ZXItPnN0YXRzLnJ4ZXJyYywKKwkJCSJSZWNlaXZlIEVycm9ycyIpOworCVNZU0NUTF9B RERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJjcmNfZXJycyIsCisJCQlDVExG TEFHX1JELCAmYWRhcHRlci0+c3RhdHMuY3JjZXJycywKKwkJCSJDUkMgZXJyb3JzIik7CisJ U1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgImFsaWdubWVudF9l cnJzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5hbGduZXJyYywKKwkJCSJB bGlnbm1lbnQgRXJyb3JzIik7CisJLyogT24gODI1NzUgdGhlc2UgYXJlIGNvbGxpc2lvbiBj b3VudHMgKi8KKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAi Y29sbF9leHRfZXJycyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuY2V4dGVy ciwKKwkJCSJDb2xsaXNpb24vQ2FycmllciBleHRlbnNpb24gZXJyb3JzIik7CisJU1lTQ1RM X0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJ4X292ZXJydW5zIiwKKwkJ CUNUTEZMQUdfUkQsICZhZGFwdGVyLT5yeF9vdmVycnVucywKKwkJCSJSWCBvdmVycnVucyIp OworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ3YXRjaGRv Z190aW1lb3V0cyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+d2F0Y2hkb2dfZXZlbnRz LAorCQkJIldhdGNoZG9nIHRpbWVvdXRzIik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3Rh dF9saXN0LCBPSURfQVVUTywgInhvbl9yZWN2ZCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRl ci0+c3RhdHMueG9ucnhjLAorCQkJIlhPTiBSZWNlaXZlZCIpOworCVNZU0NUTF9BRERfUVVB RChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ4b25fdHhkIiwKKwkJCUNUTEZMQUdfUkQs ICZhZGFwdGVyLT5zdGF0cy54b250eGMsCisJCQkiWE9OIFRyYW5zbWl0dGVkIik7CisJU1lT Q1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInhvZmZfcmVjdmQiLAor CQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnhvZmZyeGMsCisJCQkiWE9GRiBSZWNl aXZlZCIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ4 b2ZmX3R4ZCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMueG9mZnR4YywKKwkJ CSJYT0ZGIFRyYW5zbWl0dGVkIik7CisKKwkvKiBQYWNrZXQgUmVjZXB0aW9uIFN0YXRzICov CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInRvdGFsX3Br dHNfcmVjdmQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnRwciwKKwkJCSJU b3RhbCBQYWNrZXRzIFJlY2VpdmVkICIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRf bGlzdCwgT0lEX0FVVE8sICJnb29kX3BrdHNfcmVjdmQiLAorCQkJQ1RMRkxBR19SRCwgJmFk YXB0ZXItPnN0YXRzLmdwcmMsCisJCQkiR29vZCBQYWNrZXRzIFJlY2VpdmVkIik7CisJU1lT Q1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgImJjYXN0X3BrdHNfcmVj dmQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmJwcmMsCisJCQkiQnJvYWRj YXN0IFBhY2tldHMgUmVjZWl2ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xp c3QsIE9JRF9BVVRPLCAibWNhc3RfcGt0c19yZWN2ZCIsCisJCQlDVExGTEFHX1JELCAmYWRh cHRlci0+c3RhdHMubXByYywKKwkJCSJNdWx0aWNhc3QgUGFja2V0cyBSZWNlaXZlZCIpOwor CVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyeF9mcmFtZXNf NjQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnByYzY0LAorCQkJIjY0IGJ5 dGUgZnJhbWVzIHJlY2VpdmVkICIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlz dCwgT0lEX0FVVE8sICJyeF9mcmFtZXNfNjVfMTI3IiwKKwkJCUNUTEZMQUdfUkQsICZhZGFw dGVyLT5zdGF0cy5wcmMxMjcsCisJCQkiNjUtMTI3IGJ5dGUgZnJhbWVzIHJlY2VpdmVkIik7 CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJ4X2ZyYW1l c18xMjhfMjU1IiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5wcmMyNTUsCisJ CQkiMTI4LTI1NSBieXRlIGZyYW1lcyByZWNlaXZlZCIpOworCVNZU0NUTF9BRERfUVVBRChj dHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyeF9mcmFtZXNfMjU2XzUxMSIsCisJCQlDVExG TEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHJjNTExLAorCQkJIjI1Ni01MTEgYnl0ZSBmcmFt ZXMgcmVjZWl2ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9B VVRPLCAicnhfZnJhbWVzXzUxMl8xMDIzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5z dGF0cy5wcmMxMDIzLAorCQkJIjUxMi0xMDIzIGJ5dGUgZnJhbWVzIHJlY2VpdmVkIik7CisJ U1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJ4X2ZyYW1lc18x MDI0XzE1MjIiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnByYzE1MjIsCisJ CQkiMTAyMy0xNTIyIGJ5dGUgZnJhbWVzIHJlY2VpdmVkIik7CisgCVNZU0NUTF9BRERfUVVB RChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJnb29kX29jdGV0c19yZWN2ZCIsIAorIAkJ CUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5nb3JjLCAKKyAJCQkiR29vZCBPY3RldHMg UmVjZWl2ZWQiKTsgCisKKwkvKiBQYWNrZXQgVHJhbnNtaXNzaW9uIFN0YXRzICovCisgCVNZ U0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJnb29kX29jdGVzdF90 eGQiLCAKKyAJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuZ290YywgCisgCQkJIkdv b2QgT2N0ZXN0IFRyYW5zbWl0dGVkIik7IAorCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRf bGlzdCwgT0lEX0FVVE8sICJ0b3RhbF9wa3RzX3R4ZCIsCisJCQlDVExGTEFHX1JELCAmYWRh cHRlci0+c3RhdHMudHB0LAorCQkJIlRvdGFsIFBhY2tldHMgVHJhbnNtaXR0ZWQiKTsKKwlT WVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZ29vZF9wa3RzX3R4 ZCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuZ3B0YywKKwkJCSJHb29kIFBh Y2tldHMgVHJhbnNtaXR0ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3Qs IE9JRF9BVVRPLCAiYmNhc3RfcGt0c190eGQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXIt PnN0YXRzLmJwdGMsCisJCQkiQnJvYWRjYXN0IFBhY2tldHMgVHJhbnNtaXR0ZWQiKTsKKwlT WVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAibWNhc3RfcGt0c190 eGQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLm1wdGMsCisJCQkiTXVsdGlj YXN0IFBhY2tldHMgVHJhbnNtaXR0ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0 X2xpc3QsIE9JRF9BVVRPLCAidHhfZnJhbWVzXzY0IiwKKwkJCUNUTEZMQUdfUkQsICZhZGFw dGVyLT5zdGF0cy5wdGM2NCwKKwkJCSI2NCBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCAiKTsK KwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAidHhfZnJhbWVz XzY1XzEyNyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHRjMTI3LAorCQkJ IjY1LTEyNyBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCIpOworCVNZU0NUTF9BRERfUVVBRChj dHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ0eF9mcmFtZXNfMTI4XzI1NSIsCisJCQlDVExG TEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHRjMjU1LAorCQkJIjEyOC0yNTUgYnl0ZSBmcmFt ZXMgdHJhbnNtaXR0ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9J RF9BVVRPLCAidHhfZnJhbWVzXzI1Nl81MTEiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXIt PnN0YXRzLnB0YzUxMSwKKwkJCSIyNTYtNTExIGJ5dGUgZnJhbWVzIHRyYW5zbWl0dGVkIik7 CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInR4X2ZyYW1l c181MTJfMTAyMyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHRjMTAyMywK KwkJCSI1MTItMTAyMyBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCIpOworCVNZU0NUTF9BRERf UVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ0eF9mcmFtZXNfMTAyNF8xNTIyIiwK KwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5wdGMxNTIyLAorCQkJIjEwMjQtMTUy MiBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0 YXRfbGlzdCwgT0lEX0FVVE8sICJ0c29fdHhkIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVy LT5zdGF0cy50c2N0YywKKwkJCSJUU08gQ29udGV4dHMgVHJhbnNtaXR0ZWQiKTsKKwlTWVND VExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAidHNvX2N0eF9mYWlsIiwK KwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy50c2N0ZmMsCisJCQkiVFNPIENvbnRl eHRzIEZhaWxlZCIpOworCisKKwkvKiBJbnRlcnJ1cHQgU3RhdHMgKi8KKworCWludF9ub2Rl ID0gU1lTQ1RMX0FERF9OT0RFKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAiaW50ZXJydXB0cyIs IAorCQkJCSAgICBDVExGTEFHX1JELCBOVUxMLCAiSW50ZXJydXB0IFN0YXRpc3RpY3MiKTsK KwlpbnRfbGlzdCA9IFNZU0NUTF9DSElMRFJFTihpbnRfbm9kZSk7CisKKwlTWVNDVExfQURE X1FVQUQoY3R4LCBpbnRfbGlzdCwgT0lEX0FVVE8sICJhc3NlcnRzIiwKKwkJCUNUTEZMQUdf UkQsICZhZGFwdGVyLT5zdGF0cy5pYWMsCisJCQkiSW50ZXJydXB0IEFzc2VydGlvbiBDb3Vu dCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgaW50X2xpc3QsIE9JRF9BVVRPLCAicnhf cGt0X3RpbWVyIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5pY3J4cHRjLAor CQkJIkludGVycnVwdCBDYXVzZSBSeCBQa3QgVGltZXIgRXhwaXJlIENvdW50Iik7CisKKwlT WVNDVExfQUREX1FVQUQoY3R4LCBpbnRfbGlzdCwgT0lEX0FVVE8sICJyeF9hYnNfdGltZXIi LAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmljcnhhdGMsCisJCQkiSW50ZXJy dXB0IENhdXNlIFJ4IEFicyBUaW1lciBFeHBpcmUgQ291bnQiKTsKKworCVNZU0NUTF9BRERf UVVBRChjdHgsIGludF9saXN0LCBPSURfQVVUTywgInR4X3BrdF90aW1lciIsCisJCQlDVExG TEFHX1JELCAmYWRhcHRlci0+c3RhdHMuaWN0eHB0YywKKwkJCSJJbnRlcnJ1cHQgQ2F1c2Ug VHggUGt0IFRpbWVyIEV4cGlyZSBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwg aW50X2xpc3QsIE9JRF9BVVRPLCAidHhfYWJzX3RpbWVyIiwKKwkJCUNUTEZMQUdfUkQsICZh ZGFwdGVyLT5zdGF0cy5pY3R4YXRjLAorCQkJIkludGVycnVwdCBDYXVzZSBUeCBBYnMgVGlt ZXIgRXhwaXJlIENvdW50Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBpbnRfbGlzdCwg T0lEX0FVVE8sICJ0eF9xdWV1ZV9lbXB0eSIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+ c3RhdHMuaWN0eHFlYywKKwkJCSJJbnRlcnJ1cHQgQ2F1c2UgVHggUXVldWUgRW1wdHkgQ291 bnQiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGludF9saXN0LCBPSURfQVVUTywgInR4 X3F1ZXVlX21pbl90aHJlc2giLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmlj dHhxbXRjLAorCQkJIkludGVycnVwdCBDYXVzZSBUeCBRdWV1ZSBNaW4gVGhyZXNoIENvdW50 Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBpbnRfbGlzdCwgT0lEX0FVVE8sICJyeF9k ZXNjX21pbl90aHJlc2giLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmljcnhk bXRjLAorCQkJIkludGVycnVwdCBDYXVzZSBSeCBEZXNjIE1pbiBUaHJlc2ggQ291bnQiKTsK KworCVNZU0NUTF9BRERfUVVBRChjdHgsIGludF9saXN0LCBPSURfQVVUTywgInJ4X292ZXJy dW4iLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmljcnhvYywKKwkJCSJJbnRl cnJ1cHQgQ2F1c2UgUmVjZWl2ZXIgT3ZlcnJ1biBDb3VudCIpOworCisJLyogSG9zdCB0byBD YXJkIFN0YXRzICovCisKKwlob3N0X25vZGUgPSBTWVNDVExfQUREX05PREUoY3R4LCBjaGls ZCwgT0lEX0FVVE8sICJob3N0IiwgCisJCQkJICAgIENUTEZMQUdfUkQsIE5VTEwsIAorCQkJ CSAgICAiSG9zdCB0byBDYXJkIFN0YXRpc3RpY3MiKTsKKworCWhvc3RfbGlzdCA9IFNZU0NU TF9DSElMRFJFTihob3N0X25vZGUpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgaG9zdF9s aXN0LCBPSURfQVVUTywgImJyZWFrZXJfdHhfcGt0IiwKKwkJCUNUTEZMQUdfUkQsICZhZGFw dGVyLT5zdGF0cy5jYnRtcGMsCisJCQkiQ2lyY3VpdCBCcmVha2VyIFR4IFBhY2tldCBDb3Vu dCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgaG9zdF9saXN0LCBPSURfQVVUTywgImhv c3RfdHhfcGt0X2Rpc2NhcmQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmh0 ZHBtYywKKwkJCSJIb3N0IFRyYW5zbWl0IERpc2NhcmRlZCBQYWNrZXRzIik7CisKKwlTWVND VExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAicnhfcGt0IiwKKwkJCUNU TEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5ycHRoYywKKwkJCSJSeCBQYWNrZXRzIFRvIEhv c3QiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGhvc3RfbGlzdCwgT0lEX0FVVE8sICJi cmVha2VyX3J4X3BrdHMiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmNicm1w YywKKwkJCSJDaXJjdWl0IEJyZWFrZXIgUnggUGFja2V0IENvdW50Iik7CisKKwlTWVNDVExf QUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAiYnJlYWtlcl9yeF9wa3RfZHJv cCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuY2JyZHBjLAorCQkJIkNpcmN1 aXQgQnJlYWtlciBSeCBEcm9wcGVkIENvdW50Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4 LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAidHhfZ29vZF9wa3QiLAorCQkJQ1RMRkxBR19SRCwg JmFkYXB0ZXItPnN0YXRzLmhncHRjLAorCQkJIkhvc3QgR29vZCBQYWNrZXRzIFR4IENvdW50 Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAiYnJl YWtlcl90eF9wa3RfZHJvcCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuaHRj YmRwYywKKwkJCSJIb3N0IFR4IENpcmN1aXQgQnJlYWtlciBEcm9wcGVkIENvdW50Iik7CisK KwlTWVNDVExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAicnhfZ29vZF9i eXRlcyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuaGdvcmMsCisJCQkiSG9z dCBHb29kIE9jdGV0cyBSZWNlaXZlZCBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0 eCwgaG9zdF9saXN0LCBPSURfQVVUTywgInR4X2dvb2RfYnl0ZXMiLAorCQkJQ1RMRkxBR19S RCwgJmFkYXB0ZXItPnN0YXRzLmhnb3RjLAorCQkJIkhvc3QgR29vZCBPY3RldHMgVHJhbnNt aXQgQ291bnQiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGhvc3RfbGlzdCwgT0lEX0FV VE8sICJsZW5ndGhfZXJyb3JzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5s ZW5lcnJzLAorCQkJIkxlbmd0aCBFcnJvcnMiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgs IGhvc3RfbGlzdCwgT0lEX0FVVE8sICJzZXJkZXNfdmlvbGF0aW9uX3BrdCIsCisJCQlDVExG TEFHX1JELCAmYWRhcHRlci0+c3RhdHMuc2N2cGMsCisJCQkiU2VyRGVzL1NHTUlJIENvZGUg VmlvbGF0aW9uIFBrdCBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgaG9zdF9s aXN0LCBPSURfQVVUTywgImhlYWRlcl9yZWRpcl9taXNzZWQiLAorCQkJQ1RMRkxBR19SRCwg JmFkYXB0ZXItPnN0YXRzLmhybXBjLAorCQkJIkhlYWRlciBSZWRpcmVjdGlvbiBNaXNzZWQg UGFja2V0IENvdW50Iik7CiAKLQlmb3IgKGludCBpID0gMDsgaSA8IGFkYXB0ZXItPm51bV9x dWV1ZXM7IGkrKywgdHhyKyspIHsKLQkJZGV2aWNlX3ByaW50ZihkZXYsICJRdWV1ZSglZCkg dGRoID0gJWQsIHRkdCA9ICVkXG4iLCBpLAotCQkgICAgRTEwMDBfUkVBRF9SRUcoJmFkYXB0 ZXItPmh3LCBFMTAwMF9UREgoaSkpLAotCQkgICAgRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXIt Pmh3LCBFMTAwMF9URFQoaSkpKTsKLQkJZGV2aWNlX3ByaW50ZihkZXYsICJUWCglZCkgbm8g ZGVzY3JpcHRvcnMgYXZhaWwgZXZlbnQgPSAlbGRcbiIsCi0JCSAgICB0eHItPm1lLCB0eHIt Pm5vX2Rlc2NfYXZhaWwpOwotCQlkZXZpY2VfcHJpbnRmKGRldiwgIlRYKCVkKSBNU0lYIElS USBIYW5kbGVkID0gJWxkXG4iLAotCQkgICAgdHhyLT5tZSwgdHhyLT50eF9pcnEpOwotCQlk ZXZpY2VfcHJpbnRmKGRldiwgIk51bSBUeCBkZXNjcmlwdG9ycyBhdmFpbCA9ICVkXG4iLAot CQkgICAgdHhyLT50eF9hdmFpbCk7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiVHggRGVzY3Jp cHRvcnMgbm90IGF2YWlsMSA9ICVsZFxuIiwKLQkJICAgIHR4ci0+bm9fZGVzY19hdmFpbCk7 Ci0JfQotCWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3F1ZXVlczsgaSsrLCBy eHIrKykgewotCQlkZXZpY2VfcHJpbnRmKGRldiwgIlJYKCVkKSBNU0lYIElSUSBIYW5kbGVk ID0gJWxkXG4iLAotCQkgICAgcnhyLT5tZSwgcnhyLT5yeF9pcnEpOwotCQlkZXZpY2VfcHJp bnRmKGRldiwgImh3IHJkaCA9ICVkLCBodyByZHQgPSAlZFxuIiwKLQkJICAgIEUxMDAwX1JF QURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUkRIKGkpKSwKLQkJICAgIEUxMDAwX1JFQURf UkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUkRUKGkpKSk7Ci0JfQotCWRldmljZV9wcmludGYo ZGV2LCAiU3RkIG1idWYgZmFpbGVkID0gJWxkXG4iLAotCSAgICBhZGFwdGVyLT5tYnVmX2Fs bG9jX2ZhaWxlZCk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJTdGQgbWJ1ZiBjbHVzdGVyIGZh aWxlZCA9ICVsZFxuIiwKLQkgICAgYWRhcHRlci0+bWJ1Zl9jbHVzdGVyX2ZhaWxlZCk7Ci0J ZGV2aWNlX3ByaW50ZihkZXYsICJEcml2ZXIgZHJvcHBlZCBwYWNrZXRzID0gJWxkXG4iLAot CSAgICBhZGFwdGVyLT5kcm9wcGVkX3BrdHMpOwotfQogCi1zdGF0aWMgdm9pZAotZW1fcHJp bnRfaHdfc3RhdHMoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCi17Ci0JZGV2aWNlX3QgZGV2 ID0gYWRhcHRlci0+ZGV2OwogCi0JZGV2aWNlX3ByaW50ZihkZXYsICJFeGNlc3NpdmUgY29s bGlzaW9ucyA9ICVsbGRcbiIsCi0JICAgIChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMuZWNv bCk7Ci0jaWYJKERFQlVHX0hXID4gMCkgIC8qIERvbnQgb3V0cHV0IHRoZXNlIGVycm9ycyBu b3JtYWxseSAqLwotCWRldmljZV9wcmludGYoZGV2LCAiU3ltYm9sIGVycm9ycyA9ICVsbGRc biIsCi0JICAgIChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMuc3ltZXJycyk7Ci0jZW5kaWYK LQlkZXZpY2VfcHJpbnRmKGRldiwgIlNlcXVlbmNlIGVycm9ycyA9ICVsbGRcbiIsCi0JICAg IChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMuc2VjKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwg IkRlZmVyIGNvdW50ID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0 cy5kYyk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJNaXNzZWQgUGFja2V0cyA9ICVsbGRcbiIs Ci0JICAgIChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMubXBjKTsKLQlkZXZpY2VfcHJpbnRm KGRldiwgIlJlY2VpdmUgTm8gQnVmZmVycyA9ICVsbGRcbiIsCi0JICAgIChsb25nIGxvbmcp YWRhcHRlci0+c3RhdHMucm5iYyk7Ci0JLyogUkxFQyBpcyBpbmFjY3VyYXRlIG9uIHNvbWUg aGFyZHdhcmUsIGNhbGN1bGF0ZSBvdXIgb3duLiAqLwotCWRldmljZV9wcmludGYoZGV2LCAi UmVjZWl2ZSBMZW5ndGggRXJyb3JzID0gJWxsZFxuIiwKLQkgICAgKChsb25nIGxvbmcpYWRh cHRlci0+c3RhdHMucm9jICsgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5ydWMpKTsKLQlk ZXZpY2VfcHJpbnRmKGRldiwgIlJlY2VpdmUgZXJyb3JzID0gJWxsZFxuIiwKLQkgICAgKGxv bmcgbG9uZylhZGFwdGVyLT5zdGF0cy5yeGVycmMpOwotCWRldmljZV9wcmludGYoZGV2LCAi Q3JjIGVycm9ycyA9ICVsbGRcbiIsCi0JICAgIChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMu Y3JjZXJycyk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJBbGlnbm1lbnQgZXJyb3JzID0gJWxs ZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5hbGduZXJyYyk7Ci0JZGV2 aWNlX3ByaW50ZihkZXYsICJDb2xsaXNpb24vQ2FycmllciBleHRlbnNpb24gZXJyb3JzID0g JWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5jZXh0ZXJyKTsKLQlk ZXZpY2VfcHJpbnRmKGRldiwgIndhdGNoZG9nIHRpbWVvdXRzID0gJWxkXG4iLAotCSAgICBh ZGFwdGVyLT53YXRjaGRvZ19ldmVudHMpOwotCWRldmljZV9wcmludGYoZGV2LCAiWE9OIFJj dmQgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLnhvbnJ4Yyk7 Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJYT04gWG10ZCA9ICVsbGRcbiIsCi0JICAgIChsb25n IGxvbmcpYWRhcHRlci0+c3RhdHMueG9udHhjKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIlhP RkYgUmN2ZCA9ICVsbGRcbiIsCi0JICAgIChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMueG9m ZnJ4Yyk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJYT0ZGIFhtdGQgPSAlbGxkXG4iLAotCSAg ICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLnhvZmZ0eGMpOwotCWRldmljZV9wcmludGYo ZGV2LCAiR29vZCBQYWNrZXRzIFJjdmQgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25nKWFk YXB0ZXItPnN0YXRzLmdwcmMpOwotCWRldmljZV9wcmludGYoZGV2LCAiR29vZCBQYWNrZXRz IFhtdGQgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLmdwdGMp OwotCWRldmljZV9wcmludGYoZGV2LCAiVFNPIENvbnRleHRzIFhtdGQgPSAlbGxkXG4iLAot CSAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLnRzY3RjKTsKLQlkZXZpY2VfcHJpbnRm KGRldiwgIlRTTyBDb250ZXh0cyBGYWlsZWQgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25n KWFkYXB0ZXItPnN0YXRzLnRzY3RmYyk7CiB9CiAKIC8qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCkBAIC00 OTg2LDI4ICs1MTQ3LDkgQEAgZW1fcHJpbnRfaHdfc3RhdHMoc3RydWN0IGFkYXB0ZXIgKmFk YXB0ZQogICogIDMyIHdvcmRzLCBzdHVmZiB0aGF0IG1hdHRlcnMgaXMgaW4gdGhhdCBleHRl bnQuCiAgKgogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKiovCi1zdGF0aWMgdm9pZAotZW1fcHJpbnRfbnZt X2luZm8oc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCi17Ci0JdTE2CWVlcHJvbV9kYXRhOwot CWludAlpLCBqLCByb3cgPSAwOwotCi0JLyogSXRzIGEgYml0IGNydWRlLCBidXQgaXQgZ2V0 cyB0aGUgam9iIGRvbmUgKi8KLQlwcmludGYoIlxuSW50ZXJmYWNlIEVFUFJPTSBEdW1wOlxu Iik7Ci0JcHJpbnRmKCJPZmZzZXRcbjB4MDAwMCAgIik7Ci0JZm9yIChpID0gMCwgaiA9IDA7 IGkgPCAzMjsgaSsrLCBqKyspIHsKLQkJaWYgKGogPT0gOCkgeyAvKiBNYWtlIHRoZSBvZmZz ZXQgYmxvY2sgKi8KLQkJCWogPSAwOyArK3JvdzsKLQkJCXByaW50ZigiXG4weDAwJXgwICAi LHJvdyk7Ci0JCX0KLQkJZTEwMDBfcmVhZF9udm0oJmFkYXB0ZXItPmh3LCBpLCAxLCAmZWVw cm9tX2RhdGEpOwotCQlwcmludGYoIiUwNHggIiwgZWVwcm9tX2RhdGEpOwotCX0KLQlwcmlu dGYoIlxuIik7Ci19CiAKIHN0YXRpYyBpbnQKLWVtX3N5c2N0bF9kZWJ1Z19pbmZvKFNZU0NU TF9IQU5ETEVSX0FSR1MpCitlbV9zeXNjdGxfbnZtX2luZm8oU1lTQ1RMX0hBTkRMRVJfQVJH UykKIHsKIAlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcjsKIAlpbnQgZXJyb3I7CkBAIC01MDE5 LDE2ICs1MTYxLDEyIEBAIGVtX3N5c2N0bF9kZWJ1Z19pbmZvKFNZU0NUTF9IQU5ETEVSX0FS R1MKIAlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3cHRyKQogCQlyZXR1cm4gKGVycm9yKTsKIAot CWlmIChyZXN1bHQgPT0gMSkgewotCQlhZGFwdGVyID0gKHN0cnVjdCBhZGFwdGVyICopYXJn MTsKLQkJZW1fcHJpbnRfZGVidWdfaW5mbyhhZGFwdGVyKTsKLQl9CiAJLyoKIAkgKiBUaGlz IHZhbHVlIHdpbGwgY2F1c2UgYSBoZXggZHVtcCBvZiB0aGUKIAkgKiBmaXJzdCAzMiAxNi1i aXQgd29yZHMgb2YgdGhlIEVFUFJPTSB0bwogCSAqIHRoZSBzY3JlZW4uCiAJICovCi0JaWYg KHJlc3VsdCA9PSAyKSB7CisJaWYgKHJlc3VsdCA9PSAxKSB7CiAJCWFkYXB0ZXIgPSAoc3Ry dWN0IGFkYXB0ZXIgKilhcmcxOwogCQllbV9wcmludF9udm1faW5mbyhhZGFwdGVyKTsKICAg ICAgICAgfQpAQCAtNTAzNiwyNiArNTE3NCwyNCBAQCBlbV9zeXNjdGxfZGVidWdfaW5mbyhT WVNDVExfSEFORExFUl9BUkdTCiAJcmV0dXJuIChlcnJvcik7CiB9CiAKLQotc3RhdGljIGlu dAotZW1fc3lzY3RsX3N0YXRzKFNZU0NUTF9IQU5ETEVSX0FSR1MpCitzdGF0aWMgdm9pZAor ZW1fcHJpbnRfbnZtX2luZm8oc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCiB7Ci0Jc3RydWN0 IGFkYXB0ZXIgKmFkYXB0ZXI7Ci0JaW50IGVycm9yOwotCWludCByZXN1bHQ7Ci0KLQlyZXN1 bHQgPSAtMTsKLQllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZyZXN1bHQsIDAs IHJlcSk7Ci0KLQlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3cHRyKQotCQlyZXR1cm4gKGVycm9y KTsKKwl1MTYJZWVwcm9tX2RhdGE7CisJaW50CWksIGosIHJvdyA9IDA7CiAKLQlpZiAocmVz dWx0ID09IDEpIHsKLQkJYWRhcHRlciA9IChzdHJ1Y3QgYWRhcHRlciAqKWFyZzE7Ci0JCWVt X3ByaW50X2h3X3N0YXRzKGFkYXB0ZXIpOworCS8qIEl0cyBhIGJpdCBjcnVkZSwgYnV0IGl0 IGdldHMgdGhlIGpvYiBkb25lICovCisJcHJpbnRmKCJcbkludGVyZmFjZSBFRVBST00gRHVt cDpcbiIpOworCXByaW50ZigiT2Zmc2V0XG4weDAwMDAgICIpOworCWZvciAoaSA9IDAsIGog PSAwOyBpIDwgMzI7IGkrKywgaisrKSB7CisJCWlmIChqID09IDgpIHsgLyogTWFrZSB0aGUg b2Zmc2V0IGJsb2NrICovCisJCQlqID0gMDsgKytyb3c7CisJCQlwcmludGYoIlxuMHgwMCV4 MCAgIixyb3cpOworCQl9CisJCWUxMDAwX3JlYWRfbnZtKCZhZGFwdGVyLT5odywgaSwgMSwg JmVlcHJvbV9kYXRhKTsKKwkJcHJpbnRmKCIlMDR4ICIsIGVlcHJvbV9kYXRhKTsKIAl9Ci0K LQlyZXR1cm4gKGVycm9yKTsKKwlwcmludGYoIlxuIik7CiB9CiAKIHN0YXRpYyBpbnQKLS0t IHN5cy9kZXYvZTEwMDAvaWZfaWdiLmMJMjAxMC8wNS8xNCAyMjoyMDo1OAkxLjIxLjIuOAor Kysgc3lzL2Rldi9lMTAwMC9pZl9pZ2IuYwkyMDEwLzA2LzE4IDE3OjIyOjA4CTEuMjEuMi45 CkBAIC0zMCw3ICszMCw3IEBACiAgIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgogCiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiovCi0vKiRGcmVlQlNEOiBzcmMvc3lzL2Rldi9lMTAw MC9pZl9pZ2IuYyx2IDEuMjEuMi44LjIuMSAyMDEwLzA2LzE0IDAyOjA5OjA2IGtlbnNtaXRo IEV4cCAkKi8KKy8qJEZyZWVCU0Q6IHNyYy9zeXMvZGV2L2UxMDAwL2lmX2lnYi5jLHYgMS4y MS4yLjkgMjAxMC8wNi8xOCAxNzoyMjowOCBqZnYgRXhwICQqLwogCiAKICNpZmRlZiBIQVZF X0tFUk5FTF9PUFRJT05fSEVBREVSUwpAQCAtOTksNyArOTksNyBAQCBpbnQJaWdiX2Rpc3Bs YXlfZGVidWdfc3RhdHMgPSAwOwogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICogIERyaXZlciB2ZXJz aW9uOgogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKi8KLWNoYXIgaWdiX2RyaXZlcl92ZXJzaW9uW10gPSAi dmVyc2lvbiAtIDEuOS41IjsKK2NoYXIgaWdiX2RyaXZlcl92ZXJzaW9uW10gPSAidmVyc2lv biAtIDEuOS42IjsKIAogCiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCkBAIC0yMDUsMTQgKzIwNSwxMyBA QCBzdGF0aWMgX19pbmxpbmUJdm9pZCBpZ2JfcnhfZGlzY2FyZChzdHJ1CiBzdGF0aWMgX19p bmxpbmUgdm9pZCBpZ2JfcnhfaW5wdXQoc3RydWN0IHJ4X3JpbmcgKiwKIAkJICAgIHN0cnVj dCBpZm5ldCAqLCBzdHJ1Y3QgbWJ1ZiAqLCB1MzIpOwogCi1zdGF0aWMgYm9vbAlpZ2Jfcnhl b2Yoc3RydWN0IGlnYl9xdWV1ZSAqLCBpbnQpOworc3RhdGljIGJvb2wJaWdiX3J4ZW9mKHN0 cnVjdCBpZ2JfcXVldWUgKiwgaW50LCBpbnQgKik7CiBzdGF0aWMgdm9pZAlpZ2JfcnhfY2hl Y2tzdW0odTMyLCBzdHJ1Y3QgbWJ1ZiAqLCB1MzIpOwogc3RhdGljIGludAlpZ2JfdHhfY3R4 X3NldHVwKHN0cnVjdCB0eF9yaW5nICosIHN0cnVjdCBtYnVmICopOwogc3RhdGljIGJvb2wJ aWdiX3Rzb19zZXR1cChzdHJ1Y3QgdHhfcmluZyAqLCBzdHJ1Y3QgbWJ1ZiAqLCB1MzIgKik7 CiBzdGF0aWMgdm9pZAlpZ2Jfc2V0X3Byb21pc2Moc3RydWN0IGFkYXB0ZXIgKik7CiBzdGF0 aWMgdm9pZAlpZ2JfZGlzYWJsZV9wcm9taXNjKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGlj IHZvaWQJaWdiX3NldF9tdWx0aShzdHJ1Y3QgYWRhcHRlciAqKTsKLXN0YXRpYyB2b2lkCWln Yl9wcmludF9od19zdGF0cyhzdHJ1Y3QgYWRhcHRlciAqKTsKIHN0YXRpYyB2b2lkCWlnYl91 cGRhdGVfbGlua19zdGF0dXMoc3RydWN0IGFkYXB0ZXIgKik7CiBzdGF0aWMgdm9pZAlpZ2Jf cmVmcmVzaF9tYnVmcyhzdHJ1Y3QgcnhfcmluZyAqLCBpbnQpOwogCkBAIC0yMjQsMTEgKzIy MywxMCBAQCBzdGF0aWMgaW50CWlnYl94bWl0KHN0cnVjdCB0eF9yaW5nICosIHN0CiBzdGF0 aWMgaW50CWlnYl9kbWFfbWFsbG9jKHN0cnVjdCBhZGFwdGVyICosIGJ1c19zaXplX3QsCiAJ CSAgICBzdHJ1Y3QgaWdiX2RtYV9hbGxvYyAqLCBpbnQpOwogc3RhdGljIHZvaWQJaWdiX2Rt YV9mcmVlKHN0cnVjdCBhZGFwdGVyICosIHN0cnVjdCBpZ2JfZG1hX2FsbG9jICopOwotc3Rh dGljIHZvaWQJaWdiX3ByaW50X2RlYnVnX2luZm8oc3RydWN0IGFkYXB0ZXIgKik7CitzdGF0 aWMgaW50CWlnYl9zeXNjdGxfbnZtX2luZm8oU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0 aWMgdm9pZAlpZ2JfcHJpbnRfbnZtX2luZm8oc3RydWN0IGFkYXB0ZXIgKik7CiBzdGF0aWMg aW50IAlpZ2JfaXNfdmFsaWRfZXRoZXJfYWRkcih1OCAqKTsKLXN0YXRpYyBpbnQJaWdiX3N5 c2N0bF9zdGF0cyhTWVNDVExfSEFORExFUl9BUkdTKTsKLXN0YXRpYyBpbnQJaWdiX3N5c2N0 bF9kZWJ1Z19pbmZvKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworc3RhdGljIHZvaWQgICAgIGln Yl9hZGRfaHdfc3RhdHMoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpOwogLyogTWFuYWdlbWVu dCBhbmQgV09MIFN1cHBvcnQgKi8KIHN0YXRpYyB2b2lkCWlnYl9pbml0X21hbmFnZWFiaWxp dHkoc3RydWN0IGFkYXB0ZXIgKik7CiBzdGF0aWMgdm9pZAlpZ2JfcmVsZWFzZV9tYW5hZ2Vh YmlsaXR5KHN0cnVjdCBhZGFwdGVyICopOwpAQCAtMjQwLDcgKzIzOCw2IEBAIHN0YXRpYyB2 b2lkICAgICBpZ2JfbGVkX2Z1bmModm9pZCAqLCBpbnQKIHN0YXRpYyBpbnQJaWdiX2lycV9m YXN0KHZvaWQgKik7CiBzdGF0aWMgdm9pZAlpZ2JfYWRkX3J4X3Byb2Nlc3NfbGltaXQoc3Ry dWN0IGFkYXB0ZXIgKiwgY29uc3QgY2hhciAqLAogCQkgICAgY29uc3QgY2hhciAqLCBpbnQg KiwgaW50KTsKLXN0YXRpYyB2b2lkCWlnYl9oYW5kbGVfcnh0eCh2b2lkICpjb250ZXh0LCBp bnQgcGVuZGluZyk7CiBzdGF0aWMgdm9pZAlpZ2JfaGFuZGxlX3F1ZSh2b2lkICpjb250ZXh0 LCBpbnQgcGVuZGluZyk7CiBzdGF0aWMgdm9pZAlpZ2JfaGFuZGxlX2xpbmsodm9pZCAqY29u dGV4dCwgaW50IHBlbmRpbmcpOwogCkBAIC00MTIsMTMgKzQwOSw4IEBAIGlnYl9hdHRhY2go ZGV2aWNlX3QgZGV2KQogCS8qIFNZU0NUTCBzdHVmZiAqLwogCVNZU0NUTF9BRERfUFJPQyhk ZXZpY2VfZ2V0X3N5c2N0bF9jdHgoZGV2KSwKIAkgICAgU1lTQ1RMX0NISUxEUkVOKGRldmlj ZV9nZXRfc3lzY3RsX3RyZWUoZGV2KSksCi0JICAgIE9JRF9BVVRPLCAiZGVidWciLCBDVExU WVBFX0lOVHxDVExGTEFHX1JXLCBhZGFwdGVyLCAwLAotCSAgICBpZ2Jfc3lzY3RsX2RlYnVn X2luZm8sICJJIiwgIkRlYnVnIEluZm9ybWF0aW9uIik7Ci0KLQlTWVNDVExfQUREX1BST0Mo ZGV2aWNlX2dldF9zeXNjdGxfY3R4KGRldiksCi0JICAgIFNZU0NUTF9DSElMRFJFTihkZXZp Y2VfZ2V0X3N5c2N0bF90cmVlKGRldikpLAotCSAgICBPSURfQVVUTywgInN0YXRzIiwgQ1RM VFlQRV9JTlR8Q1RMRkxBR19SVywgYWRhcHRlciwgMCwKLQkgICAgaWdiX3N5c2N0bF9zdGF0 cywgIkkiLCAiU3RhdGlzdGljcyIpOworCSAgICBPSURfQVVUTywgIm52bSIsIENUTFRZUEVf SU5UfENUTEZMQUdfUlcsIGFkYXB0ZXIsIDAsCisJICAgIGlnYl9zeXNjdGxfbnZtX2luZm8s ICJJIiwgIk5WTSBJbmZvcm1hdGlvbiIpOwogCiAJU1lTQ1RMX0FERF9JTlQoZGV2aWNlX2dl dF9zeXNjdGxfY3R4KGFkYXB0ZXItPmRldiksCiAJICAgIFNZU0NUTF9DSElMRFJFTihkZXZp Y2VfZ2V0X3N5c2N0bF90cmVlKGFkYXB0ZXItPmRldikpLApAQCAtNTg0LDYgKzU3Niw4IEBA IGlnYl9hdHRhY2goZGV2aWNlX3QgZGV2KQogCWFkYXB0ZXItPnZsYW5fZGV0YWNoID0gRVZF TlRIQU5ETEVSX1JFR0lTVEVSKHZsYW5fdW5jb25maWcsCiAJICAgICBpZ2JfdW5yZWdpc3Rl cl92bGFuLCBhZGFwdGVyLCBFVkVOVEhBTkRMRVJfUFJJX0ZJUlNUKTsKIAorCWlnYl9hZGRf aHdfc3RhdHMoYWRhcHRlcik7CisKIAkvKiBUZWxsIHRoZSBzdGFjayB0aGF0IHRoZSBpbnRl cmZhY2UgaXMgbm90IGFjdGl2ZSAqLwogCWFkYXB0ZXItPmlmcC0+aWZfZHJ2X2ZsYWdzICY9 IH4oSUZGX0RSVl9SVU5OSU5HIHwgSUZGX0RSVl9PQUNUSVZFKTsKIApAQCAtODE4LDIxICs4 MTIsMjUgQEAgaWdiX3N0YXJ0KHN0cnVjdCBpZm5ldCAqaWZwKQogc3RhdGljIGludAogaWdi X21xX3N0YXJ0KHN0cnVjdCBpZm5ldCAqaWZwLCBzdHJ1Y3QgbWJ1ZiAqbSkKIHsKLQlzdHJ1 Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7Ci0Jc3RydWN0IHR4X3JpbmcJ KnR4cjsKLQlpbnQgCQlpID0gMCwgZXJyID0gMDsKKwlzdHJ1Y3QgYWRhcHRlcgkJKmFkYXB0 ZXIgPSBpZnAtPmlmX3NvZnRjOworCXN0cnVjdCBpZ2JfcXVldWUJKnF1ZTsKKwlzdHJ1Y3Qg dHhfcmluZwkJKnR4cjsKKwlpbnQgCQkJaSA9IDAsIGVyciA9IDA7CiAKIAkvKiBXaGljaCBx dWV1ZSB0byB1c2UgKi8KIAlpZiAoKG0tPm1fZmxhZ3MgJiBNX0ZMT1dJRCkgIT0gMCkKIAkJ aSA9IG0tPm1fcGt0aGRyLmZsb3dpZCAlIGFkYXB0ZXItPm51bV9xdWV1ZXM7CiAKIAl0eHIg PSAmYWRhcHRlci0+dHhfcmluZ3NbaV07CisJcXVlID0gJmFkYXB0ZXItPnF1ZXVlc1tpXTsK IAogCWlmIChJR0JfVFhfVFJZTE9DSyh0eHIpKSB7CiAJCWVyciA9IGlnYl9tcV9zdGFydF9s b2NrZWQoaWZwLCB0eHIsIG0pOwogCQlJR0JfVFhfVU5MT0NLKHR4cik7Ci0JfSBlbHNlCisJ fSBlbHNlIHsKIAkJZXJyID0gZHJicl9lbnF1ZXVlKGlmcCwgdHhyLT5iciwgbSk7CisJCXRh c2txdWV1ZV9lbnF1ZXVlKHF1ZS0+dHEsICZxdWUtPnF1ZV90YXNrKTsKKwl9CiAKIAlyZXR1 cm4gKGVycik7CiB9CkBAIC0xMjI1LDUwICsxMjIzLDI0IEBAIGlnYl9pbml0KHZvaWQgKmFy ZykKIAogCiBzdGF0aWMgdm9pZAotaWdiX2hhbmRsZV9yeHR4KHZvaWQgKmNvbnRleHQsIGlu dCBwZW5kaW5nKQotewotCXN0cnVjdCBpZ2JfcXVldWUJKnF1ZSA9IGNvbnRleHQ7Ci0Jc3Ry dWN0IGFkYXB0ZXIJCSphZGFwdGVyID0gcXVlLT5hZGFwdGVyOwotCXN0cnVjdCB0eF9yaW5n CQkqdHhyID0gYWRhcHRlci0+dHhfcmluZ3M7Ci0Jc3RydWN0IGlmbmV0CQkqaWZwOwotCi0J aWZwID0gYWRhcHRlci0+aWZwOwotCi0JaWYgKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RS Vl9SVU5OSU5HKSB7Ci0JCWlmIChpZ2Jfcnhlb2YocXVlLCBhZGFwdGVyLT5yeF9wcm9jZXNz X2xpbWl0KSkKLQkJCXRhc2txdWV1ZV9lbnF1ZXVlKGFkYXB0ZXItPnRxLCAmYWRhcHRlci0+ cnh0eF90YXNrKTsKLQkJSUdCX1RYX0xPQ0sodHhyKTsKLQkJaWdiX3R4ZW9mKHR4cik7Ci0K LSNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSA4MDAwMDAKLQkJaWYgKCFkcmJyX2VtcHR5KGlm cCwgdHhyLT5icikpCi0JCQlpZ2JfbXFfc3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsK LSNlbHNlCi0JCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQotCQkJaWdi X3N0YXJ0X2xvY2tlZCh0eHIsIGlmcCk7Ci0jZW5kaWYKLQkJSUdCX1RYX1VOTE9DSyh0eHIp OwotCX0KLQotCWlnYl9lbmFibGVfaW50cihhZGFwdGVyKTsKLX0KLQotc3RhdGljIHZvaWQK IGlnYl9oYW5kbGVfcXVlKHZvaWQgKmNvbnRleHQsIGludCBwZW5kaW5nKQogewogCXN0cnVj dCBpZ2JfcXVldWUgKnF1ZSA9IGNvbnRleHQ7CiAJc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIg PSBxdWUtPmFkYXB0ZXI7CiAJc3RydWN0IHR4X3JpbmcgKnR4ciA9IHF1ZS0+dHhyOwogCXN0 cnVjdCBpZm5ldAkqaWZwID0gYWRhcHRlci0+aWZwOwotCWJvb2wJCW1vcmU7CiAKIAlpZiAo aWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpIHsKLQkJbW9yZSA9IGlnYl9y eGVvZihxdWUsIC0xKTsKKwkJYm9vbAltb3JlOworCisJCW1vcmUgPSBpZ2Jfcnhlb2YocXVl LCAtMSwgTlVMTCk7CiAKIAkJSUdCX1RYX0xPQ0sodHhyKTsKLQkJaWdiX3R4ZW9mKHR4cik7 CisJCWlmIChpZ2JfdHhlb2YodHhyKSkKKwkJCW1vcmUgPSBUUlVFOwogI2lmIF9fRnJlZUJT RF92ZXJzaW9uID49IDgwMDAwMAotCQlpZ2JfbXFfc3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBO VUxMKTsKKwkJaWYgKCFkcmJyX2VtcHR5KGlmcCwgdHhyLT5icikpCisJCQlpZ2JfbXFfc3Rh cnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKICNlbHNlCiAJCWlmICghSUZRX0RSVl9JU19F TVBUWSgmaWZwLT5pZl9zbmQpKQogCQkJaWdiX3N0YXJ0X2xvY2tlZCh0eHIsIGlmcCk7CkBA IC0xMjgwLDExICsxMjUyLDE1IEBAIGlnYl9oYW5kbGVfcXVlKHZvaWQgKmNvbnRleHQsIGlu dCBwZW5kaW4KIAkJfQogCX0KIAotCS8qIFJlZW5hYmxlIHRoaXMgaW50ZXJydXB0ICovCiAj aWZkZWYgREVWSUNFX1BPTExJTkcKLQlpZiAoIShpZnAtPmlmX2NhcGVuYWJsZSAmIElGQ0FQ X1BPTExJTkcpKQorCWlmIChpZnAtPmlmX2NhcGVuYWJsZSAmIElGQ0FQX1BPTExJTkcpCisJ CXJldHVybjsKICNlbmRpZgotCUUxMDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIEUxMDAw X0VJTVMsIHF1ZS0+ZWltcyk7CisJLyogUmVlbmFibGUgdGhpcyBpbnRlcnJ1cHQgKi8KKwlp ZiAocXVlLT5laW1zKQorCQlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9F SU1TLCBxdWUtPmVpbXMpOworCWVsc2UKKwkJaWdiX2VuYWJsZV9pbnRyKGFkYXB0ZXIpOwog fQogCiAvKiBEZWFsIHdpdGggbGluayBpbiBhIHNsZWVwYWJsZSBjb250ZXh0ICovCkBAIC0x MzA2LDggKzEyODIsOSBAQCBpZ2JfaGFuZGxlX2xpbmsodm9pZCAqY29udGV4dCwgaW50IHBl bmRpCiBzdGF0aWMgaW50CiBpZ2JfaXJxX2Zhc3Qodm9pZCAqYXJnKQogewotCXN0cnVjdCBh ZGFwdGVyCSphZGFwdGVyID0gYXJnOwotCXVpbnQzMl90CXJlZ19pY3I7CisJc3RydWN0IGFk YXB0ZXIJCSphZGFwdGVyID0gYXJnOworCXN0cnVjdCBpZ2JfcXVldWUJKnF1ZSA9IGFkYXB0 ZXItPnF1ZXVlczsKKwl1MzIJCQlyZWdfaWNyOwogCiAKIAlyZWdfaWNyID0gRTEwMDBfUkVB RF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JQ1IpOwpAQCAtMTMyOSwxMSArMTMwNiwxMSBA QCBpZ2JfaXJxX2Zhc3Qodm9pZCAqYXJnKQogCSAqIE1TSSBtZXNzYWdlIHJlb3JkZXJpbmcg ZXJyYXRhIG9uIGNlcnRhaW4gc3lzdGVtcy4KIAkgKi8KIAlpZ2JfZGlzYWJsZV9pbnRyKGFk YXB0ZXIpOwotCXRhc2txdWV1ZV9lbnF1ZXVlKGFkYXB0ZXItPnRxLCAmYWRhcHRlci0+cnh0 eF90YXNrKTsKKwl0YXNrcXVldWVfZW5xdWV1ZShxdWUtPnRxLCAmcXVlLT5xdWVfdGFzayk7 CiAKIAkvKiBMaW5rIHN0YXR1cyBjaGFuZ2UgKi8KIAlpZiAocmVnX2ljciAmIChFMTAwMF9J Q1JfUlhTRVEgfCBFMTAwMF9JQ1JfTFNDKSkKLQkJdGFza3F1ZXVlX2VucXVldWUoYWRhcHRl ci0+dHEsICZhZGFwdGVyLT5saW5rX3Rhc2spOworCQl0YXNrcXVldWVfZW5xdWV1ZShxdWUt PnRxLCAmYWRhcHRlci0+bGlua190YXNrKTsKIAogCWlmIChyZWdfaWNyICYgRTEwMDBfSUNS X1JYTykKIAkJYWRhcHRlci0+cnhfb3ZlcnJ1bnMrKzsKQEAgLTEzNzMsMTUgKzEzNTAsMTQg QEAgaWdiX3BvbGwoc3RydWN0IGlmbmV0ICppZnAsIGVudW0gcG9sbF9jbQogCQlyZWdfaWNy ID0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JQ1IpOwogCQkvKiBMaW5r IHN0YXR1cyBjaGFuZ2UgKi8KIAkJaWYgKHJlZ19pY3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwg RTEwMDBfSUNSX0xTQykpCi0JCQl0YXNrcXVldWVfZW5xdWV1ZShhZGFwdGVyLT50cSwgJmFk YXB0ZXItPmxpbmtfdGFzayk7CisJCQlpZ2JfaGFuZGxlX2xpbmsoYWRhcHRlciwgMCk7CiAK IAkJaWYgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfUlhPKQogCQkJYWRhcHRlci0+cnhfb3ZlcnJ1 bnMrKzsKIAl9CiAJSUdCX0NPUkVfVU5MT0NLKGFkYXB0ZXIpOwogCi0JLyogVE9ETzogcnhf Y291bnQgKi8KLQlyeF9kb25lID0gaWdiX3J4ZW9mKHF1ZSwgY291bnQpID8gMSA6IDA7CisJ aWdiX3J4ZW9mKHF1ZSwgY291bnQsICZyeF9kb25lKTsKIAogCUlHQl9UWF9MT0NLKHR4cik7 CiAJZG8gewpAQCAtMTQyMSw3ICsxMzk3LDcgQEAgaWdiX21zaXhfcXVlKHZvaWQgKmFyZykK IAltb3JlX3R4ID0gaWdiX3R4ZW9mKHR4cik7CiAJSUdCX1RYX1VOTE9DSyh0eHIpOwogCi0J bW9yZV9yeCA9IGlnYl9yeGVvZihxdWUsIGFkYXB0ZXItPnJ4X3Byb2Nlc3NfbGltaXQpOwor CW1vcmVfcnggPSBpZ2Jfcnhlb2YocXVlLCBhZGFwdGVyLT5yeF9wcm9jZXNzX2xpbWl0LCBO VUxMKTsKIAogCWlmIChpZ2JfZW5hYmxlX2FpbSA9PSBGQUxTRSkKIAkJZ290byBub19jYWxj OwpAQCAtMTUwMSw3ICsxNDc3LDcgQEAgaWdiX21zaXhfbGluayh2b2lkICphcmcpCiAJaWNy ID0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JQ1IpOwogCWlmICghKGlj ciAmIEUxMDAwX0lDUl9MU0MpKQogCQlnb3RvIHNwdXJpb3VzOwotCXRhc2txdWV1ZV9lbnF1 ZXVlKGFkYXB0ZXItPnRxLCAmYWRhcHRlci0+bGlua190YXNrKTsKKwlpZ2JfaGFuZGxlX2xp bmsoYWRhcHRlciwgMCk7CiAKIHNwdXJpb3VzOgogCS8qIFJlYXJtICovCkBAIC0xOTAwLDcg KzE4NzYsNiBAQCBzdGF0aWMgdm9pZAogaWdiX2xvY2FsX3RpbWVyKHZvaWQgKmFyZykKIHsK IAlzdHJ1Y3QgYWRhcHRlcgkJKmFkYXB0ZXIgPSBhcmc7Ci0Jc3RydWN0IGlmbmV0CQkqaWZw ID0gYWRhcHRlci0+aWZwOwogCWRldmljZV90CQlkZXYgPSBhZGFwdGVyLT5kZXY7CiAJc3Ry dWN0IHR4X3JpbmcJCSp0eHIgPSBhZGFwdGVyLT50eF9yaW5nczsKIApAQCAtMTkxMCw5ICsx ODg1LDYgQEAgaWdiX2xvY2FsX3RpbWVyKHZvaWQgKmFyZykKIAlpZ2JfdXBkYXRlX2xpbmtf c3RhdHVzKGFkYXB0ZXIpOwogCWlnYl91cGRhdGVfc3RhdHNfY291bnRlcnMoYWRhcHRlcik7 CiAKLQlpZiAoaWdiX2Rpc3BsYXlfZGVidWdfc3RhdHMgJiYgaWZwLT5pZl9kcnZfZmxhZ3Mg JiBJRkZfRFJWX1JVTk5JTkcpCi0JCWlnYl9wcmludF9od19zdGF0cyhhZGFwdGVyKTsKLQog ICAgICAgICAvKgogICAgICAgICAqKiBXYXRjaGRvZzogY2hlY2sgZm9yIHRpbWUgc2luY2Ug YW55IGRlc2NyaXB0b3Igd2FzIGNsZWFuZWQKICAgICAgICAgKi8KQEAgLTE5MjMsMTEgKzE4 OTUsNiBAQCBpZ2JfbG9jYWxfdGltZXIodm9pZCAqYXJnKQogCQkJZ290byB0aW1lb3V0Owog CX0KIAotCS8qIFRyaWdnZXIgYW4gUlggaW50ZXJydXB0IG9uIGFsbCBxdWV1ZXMgKi8KLSNp ZmRlZiBERVZJQ0VfUE9MTElORwotCWlmICghKGlmcC0+aWZfY2FwZW5hYmxlICYgSUZDQVBf UE9MTElORykpCi0jZW5kaWYKLQlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAw MF9FSUNTLCBhZGFwdGVyLT5yeF9tYXNrKTsKIAljYWxsb3V0X3Jlc2V0KCZhZGFwdGVyLT50 aW1lciwgaHosIGlnYl9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAJcmV0dXJuOwogCkBAIC0y MTQyLDIwICsyMTA5LDIwIEBAIGlnYl9hbGxvY2F0ZV9sZWdhY3koc3RydWN0IGFkYXB0ZXIg KmFkYXAKIAkgKiBUcnkgYWxsb2NhdGluZyBhIGZhc3QgaW50ZXJydXB0IGFuZCB0aGUgYXNz b2NpYXRlZCBkZWZlcnJlZAogCSAqIHByb2Nlc3NpbmcgY29udGV4dHMuCiAJICovCi0JVEFT S19JTklUKCZhZGFwdGVyLT5yeHR4X3Rhc2ssIDAsIGlnYl9oYW5kbGVfcnh0eCwgcXVlKTsK KwlUQVNLX0lOSVQoJnF1ZS0+cXVlX3Rhc2ssIDAsIGlnYl9oYW5kbGVfcXVlLCBxdWUpOwog CS8qIE1ha2UgdGFza2xldCBmb3IgZGVmZXJyZWQgbGluayBoYW5kbGluZyAqLwogCVRBU0tf SU5JVCgmYWRhcHRlci0+bGlua190YXNrLCAwLCBpZ2JfaGFuZGxlX2xpbmssIGFkYXB0ZXIp OwotCWFkYXB0ZXItPnRxID0gdGFza3F1ZXVlX2NyZWF0ZV9mYXN0KCJpZ2JfdGFza3EiLCBN X05PV0FJVCwKLQkgICAgdGFza3F1ZXVlX3RocmVhZF9lbnF1ZXVlLCAmYWRhcHRlci0+dHEp OwotCXRhc2txdWV1ZV9zdGFydF90aHJlYWRzKCZhZGFwdGVyLT50cSwgMSwgUElfTkVULCAi JXMgdGFza3EiLAorCXF1ZS0+dHEgPSB0YXNrcXVldWVfY3JlYXRlX2Zhc3QoImlnYl90YXNr cSIsIE1fTk9XQUlULAorCSAgICB0YXNrcXVldWVfdGhyZWFkX2VucXVldWUsICZxdWUtPnRx KTsKKwl0YXNrcXVldWVfc3RhcnRfdGhyZWFkcygmcXVlLT50cSwgMSwgUElfTkVULCAiJXMg dGFza3EiLAogCSAgICBkZXZpY2VfZ2V0X25hbWV1bml0KGFkYXB0ZXItPmRldikpOwogCWlm ICgoZXJyb3IgPSBidXNfc2V0dXBfaW50cihkZXYsIGFkYXB0ZXItPnJlcywKIAkgICAgSU5U Ul9UWVBFX05FVCB8IElOVFJfTVBTQUZFLCBpZ2JfaXJxX2Zhc3QsIE5VTEwsCiAJICAgIGFk YXB0ZXIsICZhZGFwdGVyLT50YWcpKSAhPSAwKSB7CiAJCWRldmljZV9wcmludGYoZGV2LCAi RmFpbGVkIHRvIHJlZ2lzdGVyIGZhc3QgaW50ZXJydXB0ICIKIAkJCSAgICAiaGFuZGxlcjog JWRcbiIsIGVycm9yKTsKLQkJdGFza3F1ZXVlX2ZyZWUoYWRhcHRlci0+dHEpOwotCQlhZGFw dGVyLT50cSA9IE5VTEw7CisJCXRhc2txdWV1ZV9mcmVlKHF1ZS0+dHEpOworCQlxdWUtPnRx ID0gTlVMTDsKIAkJcmV0dXJuIChlcnJvcik7CiAJfQogCkBAIC0yMTk0LDYgKzIxNjEsOSBA QCBpZ2JfYWxsb2NhdGVfbXNpeChzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlCiAJCQlkZXZpY2Vf cHJpbnRmKGRldiwgIkZhaWxlZCB0byByZWdpc3RlciBRdWV1ZSBoYW5kbGVyIik7CiAJCQly ZXR1cm4gKGVycm9yKTsKIAkJfQorI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDgwMDUwNAor CQlidXNfZGVzY3JpYmVfaW50cihkZXYsIHF1ZS0+cmVzLCBxdWUtPnRhZywgInF1ZSAlZCIs IGkpOworI2VuZGlmCiAJCXF1ZS0+bXNpeCA9IHZlY3RvcjsKIAkJaWYgKGFkYXB0ZXItPmh3 Lm1hYy50eXBlID09IGUxMDAwXzgyNTc1KQogCQkJcXVlLT5laW1zID0gRTEwMDBfRUlDUl9U WF9RVUVVRTAgPDwgaTsKQEAgLTIyMjksMTUgKzIxOTksMTEgQEAgaWdiX2FsbG9jYXRlX21z aXgoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZQogCQlkZXZpY2VfcHJpbnRmKGRldiwgIkZhaWxl ZCB0byByZWdpc3RlciBMaW5rIGhhbmRsZXIiKTsKIAkJcmV0dXJuIChlcnJvcik7CiAJfQor I2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDgwMDUwNAorCWJ1c19kZXNjcmliZV9pbnRyKGRl diwgYWRhcHRlci0+cmVzLCBhZGFwdGVyLT50YWcsICJsaW5rIik7CisjZW5kaWYKIAlhZGFw dGVyLT5saW5rdmVjID0gdmVjdG9yOwogCi0JLyogTWFrZSB0YXNrbGV0IGZvciBkZWZlcnJl ZCBoYW5kbGluZyAqLwotCVRBU0tfSU5JVCgmYWRhcHRlci0+bGlua190YXNrLCAwLCBpZ2Jf aGFuZGxlX2xpbmssIGFkYXB0ZXIpOwotCWFkYXB0ZXItPnRxID0gdGFza3F1ZXVlX2NyZWF0 ZV9mYXN0KCJpZ2JfbGluayIsIE1fTk9XQUlULAotCSAgICB0YXNrcXVldWVfdGhyZWFkX2Vu cXVldWUsICZhZGFwdGVyLT50cSk7Ci0JdGFza3F1ZXVlX3N0YXJ0X3RocmVhZHMoJmFkYXB0 ZXItPnRxLCAxLCBQSV9ORVQsICIlcyBsaW5rIiwKLQkgICAgZGV2aWNlX2dldF9uYW1ldW5p dChhZGFwdGVyLT5kZXYpKTsKLQogCXJldHVybiAoMCk7CiB9CiAKQEAgLTM1NzAsNyArMzUz Niw3IEBAIGlnYl9yZWZyZXNoX21idWZzKHN0cnVjdCByeF9yaW5nICpyeHIsIGkKIAljbGVh bmVkID0gLTE7IC8qIFNpZ25pZnkgbm8gY29tcGxldGlvbnMgKi8KIAl3aGlsZSAoaSAhPSBs aW1pdCkgewogCQlyeGJ1ZiA9ICZyeHItPnJ4X2J1ZmZlcnNbaV07Ci0JCWlmIChyeGJ1Zi0+ bV9oZWFkID09IE5VTEwpIHsKKwkJaWYgKChyeGJ1Zi0+bV9oZWFkID09IE5VTEwpICYmIChy eHItPmhkcl9zcGxpdCkpIHsKIAkJCW1oID0gbV9nZXRoZHIoTV9ET05UV0FJVCwgTVRfREFU QSk7CiAJCQlpZiAobWggPT0gTlVMTCkKIAkJCQlnb3RvIHVwZGF0ZTsKQEAgLTM3NzYsMTYg KzM3NDIsMjQgQEAgaWdiX3NldHVwX3JlY2VpdmVfcmluZyhzdHJ1Y3QgcnhfcmluZyAqcgog CSovCiAJaWdiX2ZyZWVfcmVjZWl2ZV9yaW5nKHJ4cik7CiAKKwkvKiBDb25maWd1cmUgZm9y IGhlYWRlciBzcGxpdD8gKi8KKwlpZiAoaWdiX2hlYWRlcl9zcGxpdCkKKwkJcnhyLT5oZHJf c3BsaXQgPSBUUlVFOworCiAgICAgICAgIC8qIE5vdyByZXBsZW5pc2ggdGhlIHJpbmcgbWJ1 ZnMgKi8KIAlmb3IgKGludCBqID0gMDsgaiAhPSBhZGFwdGVyLT5udW1fcnhfZGVzYzsgKytq KSB7CiAJCXN0cnVjdCBtYnVmCSptaCwgKm1wOwogCiAJCXJ4YnVmID0gJnJ4ci0+cnhfYnVm ZmVyc1tqXTsKKwkJaWYgKHJ4ci0+aGRyX3NwbGl0ID09IEZBTFNFKQorCQkJZ290byBza2lw X2hlYWQ7CiAKIAkJLyogRmlyc3QgdGhlIGhlYWRlciAqLwogCQlyeGJ1Zi0+bV9oZWFkID0g bV9nZXRoZHIoTV9ET05UV0FJVCwgTVRfREFUQSk7Ci0JCWlmIChyeGJ1Zi0+bV9oZWFkID09 IE5VTEwpCisJCWlmIChyeGJ1Zi0+bV9oZWFkID09IE5VTEwpIHsKKwkJCWVycm9yID0gRU5P QlVGUzsKICAgICAgICAgICAgICAgICAgICAgICAgIGdvdG8gZmFpbDsKKwkJfQogCQltX2Fk aihyeGJ1Zi0+bV9oZWFkLCBFVEhFUl9BTElHTik7CiAJCW1oID0gcnhidWYtPm1faGVhZDsK IAkJbWgtPm1fbGVuID0gbWgtPm1fcGt0aGRyLmxlbiA9IE1ITEVOOwpAQCAtMzgwMSwxMSAr Mzc3NSwxNCBAQCBpZ2Jfc2V0dXBfcmVjZWl2ZV9yaW5nKHN0cnVjdCByeF9yaW5nICpyCiAJ CS8qIFVwZGF0ZSBkZXNjcmlwdG9yICovCiAJCXJ4ci0+cnhfYmFzZVtqXS5yZWFkLmhkcl9h ZGRyID0gaHRvbGU2NChoc2VnWzBdLmRzX2FkZHIpOwogCitza2lwX2hlYWQ6CiAJCS8qIE5v dyB0aGUgcGF5bG9hZCBjbHVzdGVyICovCiAJCXJ4YnVmLT5tX3BhY2sgPSBtX2dldGpjbChN X0RPTlRXQUlULCBNVF9EQVRBLAogCQkgICAgTV9QS1RIRFIsIGFkYXB0ZXItPnJ4X21idWZf c3opOwotCQlpZiAocnhidWYtPm1fcGFjayA9PSBOVUxMKQorCQlpZiAocnhidWYtPm1fcGFj ayA9PSBOVUxMKSB7CisJCQllcnJvciA9IEVOT0JVRlM7CiAgICAgICAgICAgICAgICAgICAg ICAgICBnb3RvIGZhaWw7CisJCX0KIAkJbXAgPSByeGJ1Zi0+bV9wYWNrOwogCQltcC0+bV9w a3RoZHIubGVuID0gbXAtPm1fbGVuID0gYWRhcHRlci0+cnhfbWJ1Zl9zejsKIAkJLyogR2V0 IHRoZSBtZW1vcnkgbWFwcGluZyAqLwpAQCAtMzgyNCwxMSArMzgwMSw4IEBAIGlnYl9zZXR1 cF9yZWNlaXZlX3Jpbmcoc3RydWN0IHJ4X3JpbmcgKnIKIAlyeHItPm5leHRfdG9fY2hlY2sg PSAwOwogCXJ4ci0+bmV4dF90b19yZWZyZXNoID0gMDsKIAlyeHItPmxyb19lbmFibGVkID0g RkFMU0U7Ci0KLQlpZiAoaWdiX2hlYWRlcl9zcGxpdCkKLQkJcnhyLT5oZHJfc3BsaXQgPSBU UlVFOwotCWVsc2UKLQkJaWZwLT5pZl9jYXBhYmlsaXRpZXMgJj0gfklGQ0FQX0xSTzsKKwly eHItPnJ4X3NwbGl0X3BhY2tldHMgPSAwOworCXJ4ci0+cnhfYnl0ZXMgPSAwOwogCiAJcnhy LT5mbXAgPSBOVUxMOwogCXJ4ci0+bG1wID0gTlVMTDsKQEAgLTM4NzIsNyArMzg0Niw3IEBA IHN0YXRpYyBpbnQKIGlnYl9zZXR1cF9yZWNlaXZlX3N0cnVjdHVyZXMoc3RydWN0IGFkYXB0 ZXIgKmFkYXB0ZXIpCiB7CiAJc3RydWN0IHJ4X3JpbmcgKnJ4ciA9IGFkYXB0ZXItPnJ4X3Jp bmdzOwotCWludCBpLCBqOworCWludCBpOwogCiAJZm9yIChpID0gMDsgaSA8IGFkYXB0ZXIt Pm51bV9xdWV1ZXM7IGkrKywgcnhyKyspCiAJCWlmIChpZ2Jfc2V0dXBfcmVjZWl2ZV9yaW5n KHJ4cikpCkBAIC0zODgzLDEzICszODU3LDExIEBAIGZhaWw6CiAJLyoKIAkgKiBGcmVlIFJY IGJ1ZmZlcnMgYWxsb2NhdGVkIHNvIGZhciwgd2Ugd2lsbCBvbmx5IGhhbmRsZQogCSAqIHRo ZSByaW5ncyB0aGF0IGNvbXBsZXRlZCwgdGhlIGZhaWxpbmcgY2FzZSB3aWxsIGhhdmUKLQkg KiBjbGVhbmVkIHVwIGZvciBpdHNlbGYuIFRoZSB2YWx1ZSBvZiAnaScgd2lsbCBiZSB0aGUK LQkgKiBmYWlsZWQgcmluZyBzbyB3ZSBtdXN0IHByZS1kZWNyZW1lbnQgaXQuCisJICogY2xl YW5lZCB1cCBmb3IgaXRzZWxmLiAnaScgaXMgdGhlIGVuZHBvaW50LgogCSAqLwotCXJ4ciA9 IGFkYXB0ZXItPnJ4X3JpbmdzOwotCWZvciAoLS1pOyBpID4gMDsgaS0tLCByeHIrKykgewot CQlmb3IgKGogPSAwOyBqIDwgYWRhcHRlci0+bnVtX3J4X2Rlc2M7IGorKykKLQkJCWlnYl9m cmVlX3JlY2VpdmVfcmluZyhyeHIpOworCWZvciAoaW50IGogPSAwOyBqID4gaTsgKytqKSB7 CisJCXJ4ciA9ICZhZGFwdGVyLT5yeF9yaW5nc1tpXTsKKwkJaWdiX2ZyZWVfcmVjZWl2ZV9y aW5nKHJ4cik7CiAJfQogCiAJcmV0dXJuIChFTk9CVUZTKTsKQEAgLTQxOTUsNyArNDE2Nyw5 IEBAIGlnYl9yeF9pbnB1dChzdHJ1Y3QgcnhfcmluZyAqcnhyLCBzdHJ1Y3QKIAkJCWlmICh0 Y3BfbHJvX3J4KCZyeHItPmxybywgbSwgMCkgPT0gMCkKIAkJCQlyZXR1cm47CiAJfQorCUlH Ql9SWF9VTkxPQ0socnhyKTsKIAkoKmlmcC0+aWZfaW5wdXQpKGlmcCwgbSk7CisJSUdCX1JY X0xPQ0socnhyKTsKIH0KIAogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpAQCAtNDIxMCwxNCArNDE4NCwx NCBAQCBpZ2JfcnhfaW5wdXQoc3RydWN0IHJ4X3JpbmcgKnJ4ciwgc3RydWN0CiAgKiAgUmV0 dXJuIFRSVUUgaWYgbW9yZSB0byBjbGVhbiwgRkFMU0Ugb3RoZXJ3aXNlCiAgKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqLwogc3RhdGljIGJvb2wKLWlnYl9yeGVvZihzdHJ1Y3QgaWdiX3F1ZXVlICpxdWUs IGludCBjb3VudCkKK2lnYl9yeGVvZihzdHJ1Y3QgaWdiX3F1ZXVlICpxdWUsIGludCBjb3Vu dCwgaW50ICpkb25lKQogewogCXN0cnVjdCBhZGFwdGVyCQkqYWRhcHRlciA9IHF1ZS0+YWRh cHRlcjsKIAlzdHJ1Y3QgcnhfcmluZwkJKnJ4ciA9IHF1ZS0+cnhyOwogCXN0cnVjdCBpZm5l dAkJKmlmcCA9IGFkYXB0ZXItPmlmcDsKIAlzdHJ1Y3QgbHJvX2N0cmwJCSpscm8gPSAmcnhy LT5scm87CiAJc3RydWN0IGxyb19lbnRyeQkqcXVldWVkOwotCWludAkJCWksIHByb2Nlc3Nl ZCA9IDA7CisJaW50CQkJaSwgcHJvY2Vzc2VkID0gMCwgcnhkb25lID0gMDsKIAl1MzIJCQlw dHlwZSwgc3RhdGVyciA9IDA7CiAJdW5pb24gZTEwMDBfYWR2X3J4X2Rlc2MJKmN1cjsKIApA QCAtNDM2Niw4ICs0MzQwLDEyIEBAIG5leHRfZGVzYzoKIAkJLyoKIAkJKiogU2VuZCB0byB0 aGUgc3RhY2sgb3IgTFJPCiAJCSovCi0JCWlmIChzZW5kbXAgIT0gTlVMTCkKKwkJaWYgKHNl bmRtcCAhPSBOVUxMKSB7CisJCQlyeHItPm5leHRfdG9fY2hlY2sgPSBpOwogCQkJaWdiX3J4 X2lucHV0KHJ4ciwgaWZwLCBzZW5kbXAsIHB0eXBlKTsKKwkJCWkgPSByeHItPm5leHRfdG9f Y2hlY2s7CisJCQlyeGRvbmUrKzsKKwkJfQogCiAJCS8qIEV2ZXJ5IDggZGVzY3JpcHRvcnMg d2UgZ28gdG8gcmVmcmVzaCBtYnVmcyAqLwogCQlpZiAocHJvY2Vzc2VkID09IDgpIHsKQEAg LTQzOTQsNiArNDM3Miw5IEBAIG5leHRfZGVzYzoKIAogCUlHQl9SWF9VTkxPQ0socnhyKTsK IAorCWlmIChkb25lICE9IE5VTEwpCisJCSpkb25lID0gcnhkb25lOworCiAJLyoKIAkqKiBX ZSBzdGlsbCBoYXZlIGNsZWFuaW5nIHRvIGRvPwogCSoqIFNjaGVkdWxlIGFub3RoZXIgaW50 ZXJydXB0IGlmIHNvLgpAQCAtNDc1MSw4ICs0NzMyLDEwIEBAIGlnYl91cGRhdGVfc3RhdHNf Y291bnRlcnMoc3RydWN0IGFkYXB0ZXIKIAkvKiBGb3IgdGhlIDY0LWJpdCBieXRlIGNvdW50 ZXJzIHRoZSBsb3cgZHdvcmQgbXVzdCBiZSByZWFkIGZpcnN0LiAqLwogCS8qIEJvdGggcmVn aXN0ZXJzIGNsZWFyIG9uIHRoZSByZWFkIG9mIHRoZSBoaWdoIGR3b3JkICovCiAKLQlhZGFw dGVyLT5zdGF0cy5nb3JjICs9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBf R09SQ0gpOwotCWFkYXB0ZXItPnN0YXRzLmdvdGMgKz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0 ZXItPmh3LCBFMTAwMF9HT1RDSCk7CisJYWRhcHRlci0+c3RhdHMuZ29yYyArPSBFMTAwMF9S RUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0dPUkNMKSArCisJICAoKHU2NClFMTAwMF9S RUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0dPUkNIKSA8PCAzMik7CisJYWRhcHRlci0+ c3RhdHMuZ290YyArPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0dPVENM KSArCisJICAoKHU2NClFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0dPVENI KSA8PCAzMikgOwogCiAJYWRhcHRlci0+c3RhdHMucm5iYyArPSBFMTAwMF9SRUFEX1JFRygm YWRhcHRlci0+aHcsIEUxMDAwX1JOQkMpOwogCWFkYXB0ZXItPnN0YXRzLnJ1YyArPSBFMTAw MF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1JVQyk7CkBAIC00Nzc0LDYgKzQ3NTcs MzggQEAgaWdiX3VwZGF0ZV9zdGF0c19jb3VudGVycyhzdHJ1Y3QgYWRhcHRlcgogCWFkYXB0 ZXItPnN0YXRzLm1wdGMgKz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9N UFRDKTsKIAlhZGFwdGVyLT5zdGF0cy5icHRjICs9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVy LT5odywgRTEwMDBfQlBUQyk7CiAKKwkvKiBJbnRlcnJ1cHQgQ291bnRzICovCisKKwlhZGFw dGVyLT5zdGF0cy5pYWMgKz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9J QUMpOworCWFkYXB0ZXItPnN0YXRzLmljcnhwdGMgKz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0 ZXItPmh3LCBFMTAwMF9JQ1JYUFRDKTsKKwlhZGFwdGVyLT5zdGF0cy5pY3J4YXRjICs9IEUx MDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfSUNSWEFUQyk7CisJYWRhcHRlci0+ c3RhdHMuaWN0eHB0YyArPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0lD VFhQVEMpOworCWFkYXB0ZXItPnN0YXRzLmljdHhhdGMgKz0gRTEwMDBfUkVBRF9SRUcoJmFk YXB0ZXItPmh3LCBFMTAwMF9JQ1RYQVRDKTsKKwlhZGFwdGVyLT5zdGF0cy5pY3R4cWVjICs9 IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfSUNUWFFFQyk7CisJYWRhcHRl ci0+c3RhdHMuaWN0eHFtdGMgKz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAw MF9JQ1RYUU1UQyk7CisJYWRhcHRlci0+c3RhdHMuaWNyeGRtdGMgKz0gRTEwMDBfUkVBRF9S RUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JQ1JYRE1UQyk7CisJYWRhcHRlci0+c3RhdHMuaWNy eG9jICs9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfSUNSWE9DKTsKKwor CS8qIEhvc3QgdG8gQ2FyZCBTdGF0aXN0aWNzICovCisKKwlhZGFwdGVyLT5zdGF0cy5jYnRt cGMgKz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9DQlRNUEMpOworCWFk YXB0ZXItPnN0YXRzLmh0ZHBtYyArPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUx MDAwX0hURFBNQyk7CisJYWRhcHRlci0+c3RhdHMuY2JyZHBjICs9IEUxMDAwX1JFQURfUkVH KCZhZGFwdGVyLT5odywgRTEwMDBfQ0JSRFBDKTsKKwlhZGFwdGVyLT5zdGF0cy5jYnJtcGMg Kz0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9DQlJNUEMpOworCWFkYXB0 ZXItPnN0YXRzLnJwdGhjICs9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBf UlBUSEMpOworCWFkYXB0ZXItPnN0YXRzLmhncHRjICs9IEUxMDAwX1JFQURfUkVHKCZhZGFw dGVyLT5odywgRTEwMDBfSEdQVEMpOworCWFkYXB0ZXItPnN0YXRzLmh0Y2JkcGMgKz0gRTEw MDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9IVENCRFBDKTsKKwlhZGFwdGVyLT5z dGF0cy5oZ29yYyArPSAoRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9IR09S Q0wpICsKKwkJCQkgKCh1NjQpRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCAKKwkJCQkJ CSAgICAgIEUxMDAwX0hHT1JDSCkgPDwgMzIpKTsKKworCWFkYXB0ZXItPnN0YXRzLmhnb3Rj ICs9IChFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0hHT1RDTCkgKworCQkJ CSAoKHU2NClFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIAorCQkJCQkJICAgICAgRTEw MDBfSEdPVENIKSA8PCAzMikpOworCWFkYXB0ZXItPnN0YXRzLmxlbmVycnMgKz0gRTEwMDBf UkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9MRU5FUlJTKTsKKwlhZGFwdGVyLT5zdGF0 cy5zY3ZwYyArPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1NDVlBDKTsK KwlhZGFwdGVyLT5zdGF0cy5ocm1wYyArPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcs IEUxMDAwX0hSTVBDKTsKKwogCWFkYXB0ZXItPnN0YXRzLmFsZ25lcnJjICs9IAogCQlFMTAw MF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0FMR05FUlJDKTsKIAlhZGFwdGVyLT5z dGF0cy5yeGVycmMgKz0gCkBAIC00ODAyLDE0MCArNDgxNywzNzUgQEAgaWdiX3VwZGF0ZV9z dGF0c19jb3VudGVycyhzdHJ1Y3QgYWRhcHRlcgogfQogCiAKLS8qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Ci0gKgotICogIFRoaXMgcm91dGluZSBpcyBjYWxsZWQgb25seSB3aGVuIGlnYl9kaXNwbGF5 X2RlYnVnX3N0YXRzIGlzIGVuYWJsZWQuCi0gKiAgVGhpcyByb3V0aW5lIHByb3ZpZGVzIGEg d2F5IHRvIHRha2UgYSBsb29rIGF0IGltcG9ydGFudCBzdGF0aXN0aWNzCi0gKiAgbWFpbnRh aW5lZCBieSB0aGUgZHJpdmVyIGFuZCBoYXJkd2FyZS4KLSAqCi0gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Ki8KKy8qCisgKiBBZGQgc3lzY3RsIHZhcmlhYmxlcywgb25lIHBlciBzdGF0aXN0aWMsIHRv IHRoZSBzeXN0ZW0uCisgKi8KIHN0YXRpYyB2b2lkCi1pZ2JfcHJpbnRfZGVidWdfaW5mbyhz dHJ1Y3QgYWRhcHRlciAqYWRhcHRlcikKK2lnYl9hZGRfaHdfc3RhdHMoc3RydWN0IGFkYXB0 ZXIgKmFkYXB0ZXIpCiB7CisKIAlkZXZpY2VfdCBkZXYgPSBhZGFwdGVyLT5kZXY7Ci0Jc3Ry dWN0IGlnYl9xdWV1ZSAqcXVlID0gYWRhcHRlci0+cXVldWVzOwotCXN0cnVjdCByeF9yaW5n ICpyeHIgPSBhZGFwdGVyLT5yeF9yaW5nczsKKwogCXN0cnVjdCB0eF9yaW5nICp0eHIgPSBh ZGFwdGVyLT50eF9yaW5nczsKLQl1aW50OF90ICpod19hZGRyID0gYWRhcHRlci0+aHcuaHdf YWRkcjsKKwlzdHJ1Y3QgcnhfcmluZyAqcnhyID0gYWRhcHRlci0+cnhfcmluZ3M7CiAKLQlk ZXZpY2VfcHJpbnRmKGRldiwgIkFkYXB0ZXIgaGFyZHdhcmUgYWRkcmVzcyA9ICVwIFxuIiwg aHdfYWRkcik7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJDVFJMID0gMHgleCBSQ1RMID0gMHgl eCBcbiIsCi0JICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfQ1RSTCks Ci0JICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUkNUTCkpOwotCi0j aWYJKERFQlVHX0hXID4gMCkgIC8qIERvbnQgb3V0cHV0IHRoZXNlIGVycm9ycyBub3JtYWxs eSAqLwotCWRldmljZV9wcmludGYoZGV2LCAiSU1TID0gMHgleCBFSU1TID0gMHgleCBcbiIs Ci0JICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfSU1TKSwKLQkgICAg RTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9FSU1TKSk7Ci0jZW5kaWYKKwlz dHJ1Y3Qgc3lzY3RsX2N0eF9saXN0ICpjdHggPSBkZXZpY2VfZ2V0X3N5c2N0bF9jdHgoZGV2 KTsKKwlzdHJ1Y3Qgc3lzY3RsX29pZCAqdHJlZSA9IGRldmljZV9nZXRfc3lzY3RsX3RyZWUo ZGV2KTsKKwlzdHJ1Y3Qgc3lzY3RsX29pZF9saXN0ICpjaGlsZCA9IFNZU0NUTF9DSElMRFJF Tih0cmVlKTsKKwlzdHJ1Y3QgZTEwMDBfaHdfc3RhdHMgKnN0YXRzID0gJmFkYXB0ZXItPnN0 YXRzOworCisJc3RydWN0IHN5c2N0bF9vaWQgKnN0YXRfbm9kZSwgKnF1ZXVlX25vZGUsICpp bnRfbm9kZSwgKmhvc3Rfbm9kZTsKKwlzdHJ1Y3Qgc3lzY3RsX29pZF9saXN0ICpzdGF0X2xp c3QsICpxdWV1ZV9saXN0LCAqaW50X2xpc3QsICpob3N0X2xpc3Q7CisKKyNkZWZpbmUgUVVF VUVfTkFNRV9MRU4gMzIKKwljaGFyIG5hbWVidWZbUVVFVUVfTkFNRV9MRU5dOworCisJLyog RHJpdmVyIFN0YXRpc3RpY3MgKi8KKwlTWVNDVExfQUREX1VJTlQoY3R4LCBjaGlsZCwgT0lE X0FVVE8sICJsaW5rX2lycSIsIAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPmxpbmtfaXJx LCAwLAorCQkJIkxpbmsgTVNJWCBJUlEgSGFuZGxlZCIpOworCVNZU0NUTF9BRERfVUxPTkco Y3R4LCBjaGlsZCwgT0lEX0FVVE8sICJkcm9wcGVkIiwgCisJCQlDVExGTEFHX1JELCAmYWRh cHRlci0+ZHJvcHBlZF9wa3RzLAorCQkJIkRyaXZlciBkcm9wcGVkIHBhY2tldHMiKTsKKwlT WVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAidHhfZG1hX2ZhaWwiLCAK KwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5ub190eF9kbWFfc2V0dXAsCisJCQkiRHJpdmVy IHR4IGRtYSBmYWlsdXJlIGluIHhtaXQiKTsKKworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBj aGlsZCwgT0lEX0FVVE8sICJkZXZpY2VfY29udHJvbCIsIAorCQkJQ1RMRkxBR19SRCwgJmFk YXB0ZXItPmRldmljZV9jb250cm9sLAorCQkJIkRldmljZSBDb250cm9sIFJlZ2lzdGVyIik7 CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNoaWxkLCBPSURfQVVUTywgInJ4X2NvbnRyb2wi LCAKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5yeF9jb250cm9sLAorCQkJIlJlY2VpdmVy IENvbnRyb2wgUmVnaXN0ZXIiKTsKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9J RF9BVVRPLCAiaW50ZXJydXB0X21hc2siLCAKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5p bnRfbWFzaywKKwkJCSJJbnRlcnJ1cHQgTWFzayIpOworCVNZU0NUTF9BRERfVUxPTkcoY3R4 LCBjaGlsZCwgT0lEX0FVVE8sICJleHRlbmRlZF9pbnRfbWFzayIsIAorCQkJQ1RMRkxBR19S RCwgJmFkYXB0ZXItPmVpbnRfbWFzaywKKwkJCSJFeHRlbmRlZCBJbnRlcnJ1cHQgTWFzayIp OworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJ0eF9idWZfYWxs b2MiLCAKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5wYWNrZXRfYnVmX2FsbG9jX3R4LAor CQkJIlRyYW5zbWl0IEJ1ZmZlciBQYWNrZXQgQWxsb2NhdGlvbiIpOworCVNZU0NUTF9BRERf VUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJyeF9idWZfYWxsb2MiLCAKKwkJCUNUTEZM QUdfUkQsICZhZGFwdGVyLT5wYWNrZXRfYnVmX2FsbG9jX3J4LAorCQkJIlJlY2VpdmUgQnVm ZmVyIFBhY2tldCBBbGxvY2F0aW9uIik7CisJU1lTQ1RMX0FERF9VSU5UKGN0eCwgY2hpbGQs IE9JRF9BVVRPLCAiZmNfaGlnaF93YXRlciIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+ aHcuZmMuaGlnaF93YXRlciwgMCwKKwkJCSJGbG93IENvbnRyb2wgSGlnaCBXYXRlcm1hcmsi KTsKKwlTWVNDVExfQUREX1VJTlQoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJmY19sb3dfd2F0 ZXIiLCAKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5ody5mYy5sb3dfd2F0ZXIsIDAsCisJ CQkiRmxvdyBDb250cm9sIExvdyBXYXRlcm1hcmsiKTsKIAotCWRldmljZV9wcmludGYoZGV2 LCAiUGFja2V0IGJ1ZmZlciA9IFR4PSVkayBSeD0lZGsgXG4iLAotCSAgICAoKEUxMDAwX1JF QURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfUEJBKSAmIDB4ZmZmZjAwMDApID4+IDE2KSxc Ci0JICAgIChFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1BCQSkgJiAweGZm ZmYpICk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJGbG93IGNvbnRyb2wgd2F0ZXJtYXJrcyBo aWdoID0gJWQgbG93ID0gJWRcbiIsCi0JICAgIGFkYXB0ZXItPmh3LmZjLmhpZ2hfd2F0ZXIs Ci0JICAgIGFkYXB0ZXItPmh3LmZjLmxvd193YXRlcik7Ci0KLQlmb3IgKGludCBpID0gMDsg aSA8IGFkYXB0ZXItPm51bV9xdWV1ZXM7IGkrKywgcnhyKyssIHR4cisrKSB7Ci0JCWRldmlj ZV9wcmludGYoZGV2LCAiUXVldWUoJWQpIHRkaCA9ICVkLCB0ZHQgPSAlZCAgIiwgaSwKLQkJ ICAgIEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfVERIKGkpKSwKLQkJICAg IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfVERUKGkpKSk7Ci0JCWRldmlj ZV9wcmludGYoZGV2LCAicmRoID0gJWQsIHJkdCA9ICVkXG4iLAotCQkgICAgRTEwMDBfUkVB RF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9SREgoaSkpLAotCQkgICAgRTEwMDBfUkVBRF9S RUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9SRFQoaSkpKTsKLQkJZGV2aWNlX3ByaW50ZihkZXYs ICJUWCglZCkgbm8gZGVzY3JpcHRvcnMgYXZhaWwgZXZlbnQgPSAlbGxkXG4iLAotCQkgICAg dHhyLT5tZSwgKGxvbmcgbG9uZyl0eHItPm5vX2Rlc2NfYXZhaWwpOwotCQlkZXZpY2VfcHJp bnRmKGRldiwgIlRYKCVkKSBQYWNrZXRzIHNlbnQgPSAlbGxkXG4iLAotCQkgICAgdHhyLT5t ZSwgKGxvbmcgbG9uZyl0eHItPnR4X3BhY2tldHMpOwotCQlkZXZpY2VfcHJpbnRmKGRldiwg IlJYKCVkKSBQYWNrZXRzIHJlY2VpdmVkID0gJWxsZCAgIiwKLQkJICAgIHJ4ci0+bWUsIChs b25nIGxvbmcpcnhyLT5yeF9wYWNrZXRzKTsKKwlmb3IgKGludCBpID0gMDsgaSA8IGFkYXB0 ZXItPm51bV9xdWV1ZXM7IGkrKywgdHhyKyspIHsKKwkJc25wcmludGYobmFtZWJ1ZiwgUVVF VUVfTkFNRV9MRU4sICJxdWV1ZSVkIiwgaSk7CisJCXF1ZXVlX25vZGUgPSBTWVNDVExfQURE X05PREUoY3R4LCBjaGlsZCwgT0lEX0FVVE8sIG5hbWVidWYsCisJCQkJCSAgICBDVExGTEFH X1JELCBOVUxMLCAiUXVldWUgTmFtZSIpOworCQlxdWV1ZV9saXN0ID0gU1lTQ1RMX0NISUxE UkVOKHF1ZXVlX25vZGUpOworCisJCVNZU0NUTF9BRERfVUlOVChjdHgsIHF1ZXVlX2xpc3Qs IE9JRF9BVVRPLCAidHhkX2hlYWQiLAorCQkJCUNUTEZMQUdfUkQsICZ0eHItPnRkaCwgMCwK KwkJCQkiVHJhbnNtaXQgRGVzY3JpcHRvciBIZWFkIik7CisJCVNZU0NUTF9BRERfVUlOVChj dHgsIHF1ZXVlX2xpc3QsIE9JRF9BVVRPLCAidHhkX3RhaWwiLAorCQkJCUNUTEZMQUdfUkQs ICZ0eHItPnRkdCwgMCwKKwkJCQkiVHJhbnNtaXQgRGVzY3JpcHRvciBUYWlsIik7CisJCVNZ U0NUTF9BRERfUVVBRChjdHgsIHF1ZXVlX2xpc3QsIE9JRF9BVVRPLCAibm9fZGVzY19hdmFp bCIsIAorCQkJCUNUTEZMQUdfUkQsICZ0eHItPm5vX2Rlc2NfYXZhaWwsCisJCQkJIlF1ZXVl IE5vIERlc2NyaXB0b3IgQXZhaWxhYmxlIik7CisJCVNZU0NUTF9BRERfUVVBRChjdHgsIHF1 ZXVlX2xpc3QsIE9JRF9BVVRPLCAidHhfcGFja2V0cyIsCisJCQkJQ1RMRkxBR19SRCwgJnR4 ci0+dHhfcGFja2V0cywKKwkJCQkiUXVldWUgUGFja2V0cyBUcmFuc21pdHRlZCIpOwogCX0K IAogCWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3F1ZXVlczsgaSsrLCByeHIr KykgewogCQlzdHJ1Y3QgbHJvX2N0cmwgKmxybyA9ICZyeHItPmxybzsKLQkJZGV2aWNlX3By aW50ZihkZXYsICJRdWV1ZSglZCkgcmRoID0gJWQsIHJkdCA9ICVkXG4iLCBpLAotCQkgICAg RTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9SREgoaSkpLAotCQkgICAgRTEw MDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9SRFQoaSkpKTsKLQkJZGV2aWNlX3By aW50ZihkZXYsICJSWCglZCkgUGFja2V0cyByZWNlaXZlZCA9ICVsbGRcbiIsIHJ4ci0+bWUs Ci0JCSAgICAobG9uZyBsb25nKXJ4ci0+cnhfcGFja2V0cyk7Ci0JCWRldmljZV9wcmludGYo ZGV2LCAiIFNwbGl0IFBhY2tldHMgPSAlbGxkICIsCi0JCSAgICAobG9uZyBsb25nKXJ4ci0+ cnhfc3BsaXRfcGFja2V0cyk7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiIEJ5dGUgY291bnQg PSAlbGxkXG4iLAotCQkgICAgKGxvbmcgbG9uZylyeHItPnJ4X2J5dGVzKTsKLQkJZGV2aWNl X3ByaW50ZihkZXYsIlJYKCVkKSBMUk8gUXVldWVkPSAlZCAgIiwKLQkJICAgIGksIGxyby0+ bHJvX3F1ZXVlZCk7Ci0JCWRldmljZV9wcmludGYoZGV2LCJMUk8gRmx1c2hlZD0gJWRcbiIs bHJvLT5scm9fZmx1c2hlZCk7Ci0JfQotCi0JZm9yIChpbnQgaSA9IDA7IGkgPCBhZGFwdGVy LT5udW1fcXVldWVzOyBpKyssIHF1ZSsrKQotCQlkZXZpY2VfcHJpbnRmKGRldiwiUVVFKCVk KSBJUlFzID0gJWxseFxuIiwKLQkJICAgIGksIChsb25nIGxvbmcpcXVlLT5pcnFzKTsKLQot CWRldmljZV9wcmludGYoZGV2LCAiTElOSyBNU0lYIElSUSBIYW5kbGVkID0gJXVcbiIsIGFk YXB0ZXItPmxpbmtfaXJxKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIk1idWYgZGVmcmFnIGZh aWxlZCA9ICVsZFxuIiwKLQkgICAgYWRhcHRlci0+bWJ1Zl9kZWZyYWdfZmFpbGVkKTsKLQlk ZXZpY2VfcHJpbnRmKGRldiwgIlN0ZCBtYnVmIGhlYWRlciBmYWlsZWQgPSAlbGRcbiIsCi0J ICAgIGFkYXB0ZXItPm1idWZfaGVhZGVyX2ZhaWxlZCk7Ci0JZGV2aWNlX3ByaW50ZihkZXYs ICJTdGQgbWJ1ZiBwYWNrZXQgZmFpbGVkID0gJWxkXG4iLAotCSAgICBhZGFwdGVyLT5tYnVm X3BhY2tldF9mYWlsZWQpOwotCWRldmljZV9wcmludGYoZGV2LCAiRHJpdmVyIGRyb3BwZWQg cGFja2V0cyA9ICVsZFxuIiwKLQkgICAgYWRhcHRlci0+ZHJvcHBlZF9wa3RzKTsKLQlkZXZp Y2VfcHJpbnRmKGRldiwgIkRyaXZlciB0eCBkbWEgZmFpbHVyZSBpbiB4bWl0ID0gJWxkXG4i LAotCQlhZGFwdGVyLT5ub190eF9kbWFfc2V0dXApOwotfQogCi1zdGF0aWMgdm9pZAotaWdi X3ByaW50X2h3X3N0YXRzKHN0cnVjdCBhZGFwdGVyICphZGFwdGVyKQotewotCWRldmljZV90 IGRldiA9IGFkYXB0ZXItPmRldjsKKwkJc25wcmludGYobmFtZWJ1ZiwgUVVFVUVfTkFNRV9M RU4sICJxdWV1ZSVkIiwgaSk7CisJCXF1ZXVlX25vZGUgPSBTWVNDVExfQUREX05PREUoY3R4 LCBjaGlsZCwgT0lEX0FVVE8sIG5hbWVidWYsIAorCQkJCQkgICAgQ1RMRkxBR19SRCwgTlVM TCwgIlF1ZXVlIE5hbWUiKTsKKwkJcXVldWVfbGlzdCA9IFNZU0NUTF9DSElMRFJFTihxdWV1 ZV9ub2RlKTsKKworCQlTWVNDVExfQUREX1VJTlQoY3R4LCBxdWV1ZV9saXN0LCBPSURfQVVU TywgInJ4ZF9oZWFkIiwKKwkJCQlDVExGTEFHX1JELCAmcnhyLT5yZGgsIDAsCisJCQkJIlJl Y2VpdmUgRGVzY3JpcHRvciBIZWFkIik7CisJCVNZU0NUTF9BRERfVUlOVChjdHgsIHF1ZXVl X2xpc3QsIE9JRF9BVVRPLCAicnhkX3RhaWwiLAorCQkJCUNUTEZMQUdfUkQsICZyeHItPnJk dCwgMCwKKwkJCQkiUmVjZWl2ZSBEZXNjcmlwdG9yIFRhaWwiKTsKKwkJU1lTQ1RMX0FERF9R VUFEKGN0eCwgcXVldWVfbGlzdCwgT0lEX0FVVE8sICJyeF9wYWNrZXRzIiwKKwkJCQlDVExG TEFHX1JELCAmcnhyLT5yeF9wYWNrZXRzLAorCQkJCSJRdWV1ZSBQYWNrZXRzIFJlY2VpdmVk Iik7CisJCVNZU0NUTF9BRERfUVVBRChjdHgsIHF1ZXVlX2xpc3QsIE9JRF9BVVRPLCAicnhf Ynl0ZXMiLAorCQkJCUNUTEZMQUdfUkQsICZyeHItPnJ4X2J5dGVzLAorCQkJCSJRdWV1ZSBC eXRlcyBSZWNlaXZlZCIpOworCQlTWVNDVExfQUREX1VJTlQoY3R4LCBxdWV1ZV9saXN0LCBP SURfQVVUTywgImxyb19xdWV1ZWQiLAorCQkJCUNUTEZMQUdfUkQsICZscm8tPmxyb19xdWV1 ZWQsIDAsCisJCQkJIkxSTyBRdWV1ZWQiKTsKKwkJU1lTQ1RMX0FERF9VSU5UKGN0eCwgcXVl dWVfbGlzdCwgT0lEX0FVVE8sICJscm9fZmx1c2hlZCIsCisJCQkJQ1RMRkxBR19SRCwgJmxy by0+bHJvX2ZsdXNoZWQsIDAsCisJCQkJIkxSTyBGbHVzaGVkIik7CisJfQorCisJLyogTUFD IHN0YXRzIGdldCB0aGUgb3duIHN1YiBub2RlICovCisKKwlzdGF0X25vZGUgPSBTWVNDVExf QUREX05PREUoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJtYWNfc3RhdHMiLCAKKwkJCQkgICAg Q1RMRkxBR19SRCwgTlVMTCwgIk1BQyBTdGF0aXN0aWNzIik7CisJc3RhdF9saXN0ID0gU1lT Q1RMX0NISUxEUkVOKHN0YXRfbm9kZSk7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0 X2xpc3QsIE9JRF9BVVRPLCAiZXhjZXNzX2NvbGwiLCAKKwkJCUNUTEZMQUdfUkQsICZzdGF0 cy0+ZWNvbCwKKwkJCSJFeGNlc3NpdmUgY29sbGlzaW9ucyIpOworCVNZU0NUTF9BRERfUVVB RChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJzaW5nbGVfY29sbCIsIAorCQkJQ1RMRkxB R19SRCwgJnN0YXRzLT5zY2MsCisJCQkiU2luZ2xlIGNvbGxpc2lvbnMiKTsKKwlTWVNDVExf QUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAibXVsdGlwbGVfY29sbCIsIAor CQkJQ1RMRkxBR19SRCwgJnN0YXRzLT5tY2MsCisJCQkiTXVsdGlwbGUgY29sbGlzaW9ucyIp OworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJsYXRlX2Nv bGwiLCAKKwkJCUNUTEZMQUdfUkQsICZzdGF0cy0+bGF0ZWNvbCwKKwkJCSJMYXRlIGNvbGxp c2lvbnMiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAi Y29sbGlzaW9uX2NvdW50IiwgCisJCQlDVExGTEFHX1JELCAmc3RhdHMtPmNvbGMsCisJCQki Q29sbGlzaW9uIENvdW50Iik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBP SURfQVVUTywgInN5bWJvbF9lcnJvcnMiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0 YXRzLnN5bWVycnMsCisJCQkiU3ltYm9sIEVycm9ycyIpOworCVNZU0NUTF9BRERfUVVBRChj dHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJzZXF1ZW5jZV9lcnJvcnMiLAorCQkJQ1RMRkxB R19SRCwgJmFkYXB0ZXItPnN0YXRzLnNlYywKKwkJCSJTZXF1ZW5jZSBFcnJvcnMiKTsKKwlT WVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZGVmZXJfY291bnQi LAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmRjLAorCQkJIkRlZmVyIENvdW50 Iik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgIm1pc3Nl ZF9wYWNrZXRzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5tcGMsCisJCQki TWlzc2VkIFBhY2tldHMiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9J RF9BVVRPLCAicmVjdl9ub19idWZmIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0 cy5ybmJjLAorCQkJIlJlY2VpdmUgTm8gQnVmZmVycyIpOworCVNZU0NUTF9BRERfUVVBRChj dHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyZWN2X3VuZGVyc2l6ZSIsCisJCQlDVExGTEFH X1JELCAmYWRhcHRlci0+c3RhdHMucnVjLAorCQkJIlJlY2VpdmUgVW5kZXJzaXplIik7CisJ U1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJlY3ZfZnJhZ21l bnRlZCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucmZjLAorCQkJIkZyYWdt ZW50ZWQgUGFja2V0cyBSZWNlaXZlZCAiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0 X2xpc3QsIE9JRF9BVVRPLCAicmVjdl9vdmVyc2l6ZSIsCisJCQlDVExGTEFHX1JELCAmYWRh cHRlci0+c3RhdHMucm9jLAorCQkJIk92ZXJzaXplZCBQYWNrZXRzIFJlY2VpdmVkIik7CisJ U1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJlY3ZfamFiYmVy IiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5yamMsCisJCQkiUmVjZXZpZWQg SmFiYmVyIik7CiAKLQlkZXZpY2VfcHJpbnRmKGRldiwgIkV4Y2Vzc2l2ZSBjb2xsaXNpb25z ID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5lY29sKTsKLSNp ZgkoREVCVUdfSFcgPiAwKSAgLyogRG9udCBvdXRwdXQgdGhlc2UgZXJyb3JzIG5vcm1hbGx5 ICovCi0JZGV2aWNlX3ByaW50ZihkZXYsICJTeW1ib2wgZXJyb3JzID0gJWxsZFxuIiwKLQkg ICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5zeW1lcnJzKTsKLSNlbmRpZgotCWRldmlj ZV9wcmludGYoZGV2LCAiU2VxdWVuY2UgZXJyb3JzID0gJWxsZFxuIiwKLQkgICAgKGxvbmcg bG9uZylhZGFwdGVyLT5zdGF0cy5zZWMpOwotCWRldmljZV9wcmludGYoZGV2LCAiRGVmZXIg Y291bnQgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLmRjKTsK LQlkZXZpY2VfcHJpbnRmKGRldiwgIk1pc3NlZCBQYWNrZXRzID0gJWxsZFxuIiwKLQkgICAg KGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5tcGMpOwotCWRldmljZV9wcmludGYoZGV2LCAi UmVjZWl2ZSBObyBCdWZmZXJzID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVy LT5zdGF0cy5ybmJjKTsKIAkvKiBSTEVDIGlzIGluYWNjdXJhdGUgb24gc29tZSBoYXJkd2Fy ZSwgY2FsY3VsYXRlIG91ciBvd24uICovCi0JZGV2aWNlX3ByaW50ZihkZXYsICJSZWNlaXZl IExlbmd0aCBFcnJvcnMgPSAlbGxkXG4iLAotCSAgICAoKGxvbmcgbG9uZylhZGFwdGVyLT5z dGF0cy5yb2MgKyAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLnJ1YykpOwotCWRldmljZV9w cmludGYoZGV2LCAiUmVjZWl2ZSBlcnJvcnMgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25n KWFkYXB0ZXItPnN0YXRzLnJ4ZXJyYyk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJDcmMgZXJy b3JzID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5jcmNlcnJz KTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIkFsaWdubWVudCBlcnJvcnMgPSAlbGxkXG4iLAot CSAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLmFsZ25lcnJjKTsKKy8qIAlTWVNDVExf QUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAicmVjdl9sZW5fZXJycyIsICov CisvKiAJCQlDVExGTEFHX1JELCBhZGFwdGVyLT5zdGF0cy5yb2MgKyBhZGFwdGVyLT5zdGF0 cy5ydWMsICovCisvKiAJCQkiUmVjZWl2ZSBMZW5ndGggRXJyb3JzIik7ICovCisKKwlTWVND VExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAicmVjdl9lcnJzIiwKKwkJ CUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5yeGVycmMsCisJCQkiUmVjZWl2ZSBFcnJv cnMiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiY3Jj X2VycnMiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmNyY2VycnMsCisJCQki Q1JDIGVycm9ycyIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FV VE8sICJhbGlnbm1lbnRfZXJycyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMu YWxnbmVycmMsCisJCQkiQWxpZ25tZW50IEVycm9ycyIpOwogCS8qIE9uIDgyNTc1IHRoZXNl IGFyZSBjb2xsaXNpb24gY291bnRzICovCi0JZGV2aWNlX3ByaW50ZihkZXYsICJDb2xsaXNp b24vQ2FycmllciBleHRlbnNpb24gZXJyb3JzID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9u ZylhZGFwdGVyLT5zdGF0cy5jZXh0ZXJyKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIlJYIG92 ZXJydW5zID0gJWxkXG4iLCBhZGFwdGVyLT5yeF9vdmVycnVucyk7Ci0JZGV2aWNlX3ByaW50 ZihkZXYsICJ3YXRjaGRvZyB0aW1lb3V0cyA9ICVsZFxuIiwKLQkgICAgYWRhcHRlci0+d2F0 Y2hkb2dfZXZlbnRzKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIlhPTiBSY3ZkID0gJWxsZFxu IiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy54b25yeGMpOwotCWRldmljZV9w cmludGYoZGV2LCAiWE9OIFhtdGQgPSAlbGxkXG4iLAotCSAgICAobG9uZyBsb25nKWFkYXB0 ZXItPnN0YXRzLnhvbnR4Yyk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJYT0ZGIFJjdmQgPSAl bGxkXG4iLAotCSAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLnhvZmZyeGMpOwotCWRl dmljZV9wcmludGYoZGV2LCAiWE9GRiBYbXRkID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9u ZylhZGFwdGVyLT5zdGF0cy54b2ZmdHhjKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIkdvb2Qg UGFja2V0cyBSY3ZkID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0 cy5ncHJjKTsKLQlkZXZpY2VfcHJpbnRmKGRldiwgIkdvb2QgUGFja2V0cyBYbXRkID0gJWxs ZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy5ncHRjKTsKLQlkZXZpY2Vf cHJpbnRmKGRldiwgIlRTTyBDb250ZXh0cyBYbXRkID0gJWxsZFxuIiwKLQkgICAgKGxvbmcg bG9uZylhZGFwdGVyLT5zdGF0cy50c2N0Yyk7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJUU08g Q29udGV4dHMgRmFpbGVkID0gJWxsZFxuIiwKLQkgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5z dGF0cy50c2N0ZmMpOwotfQorCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lE X0FVVE8sICJjb2xsX2V4dF9lcnJzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0 cy5jZXh0ZXJyLAorCQkJIkNvbGxpc2lvbi9DYXJyaWVyIGV4dGVuc2lvbiBlcnJvcnMiKTsK KwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAicnhfb3ZlcnJ1 bnMiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnJ4X292ZXJydW5zLAorCQkJIlJYIG92 ZXJydW5zIik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywg IndhdGNoZG9nX3RpbWVvdXRzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT53YXRjaGRv Z19ldmVudHMsCisJCQkiV2F0Y2hkb2cgdGltZW91dHMiKTsKKwlTWVNDVExfQUREX1FVQUQo Y3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAieG9uX3JlY3ZkIiwKKwkJCUNUTEZMQUdfUkQs ICZhZGFwdGVyLT5zdGF0cy54b25yeGMsCisJCQkiWE9OIFJlY2VpdmVkIik7CisJU1lTQ1RM X0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInhvbl90eGQiLAorCQkJQ1RM RkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnhvbnR4YywKKwkJCSJYT04gVHJhbnNtaXR0ZWQi KTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAieG9mZl9y ZWN2ZCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMueG9mZnJ4YywKKwkJCSJY T0ZGIFJlY2VpdmVkIik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURf QVVUTywgInhvZmZfdHhkIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy54b2Zm dHhjLAorCQkJIlhPRkYgVHJhbnNtaXR0ZWQiKTsKKwkvKiBQYWNrZXQgUmVjZXB0aW9uIFN0 YXRzICovCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInRv dGFsX3BrdHNfcmVjdmQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnRwciwK KwkJCSJUb3RhbCBQYWNrZXRzIFJlY2VpdmVkICIpOworCVNZU0NUTF9BRERfUVVBRChjdHgs IHN0YXRfbGlzdCwgT0lEX0FVVE8sICJnb29kX3BrdHNfcmVjdmQiLAorCQkJQ1RMRkxBR19S RCwgJmFkYXB0ZXItPnN0YXRzLmdwcmMsCisJCQkiR29vZCBQYWNrZXRzIFJlY2VpdmVkIik7 CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgImJjYXN0X3Br dHNfcmVjdmQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmJwcmMsCisJCQki QnJvYWRjYXN0IFBhY2tldHMgUmVjZWl2ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBz dGF0X2xpc3QsIE9JRF9BVVRPLCAibWNhc3RfcGt0c19yZWN2ZCIsCisJCQlDVExGTEFHX1JE LCAmYWRhcHRlci0+c3RhdHMubXByYywKKwkJCSJNdWx0aWNhc3QgUGFja2V0cyBSZWNlaXZl ZCIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyeF9m cmFtZXNfNjQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnByYzY0LAorCQkJ IjY0IGJ5dGUgZnJhbWVzIHJlY2VpdmVkICIpOworCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0 YXRfbGlzdCwgT0lEX0FVVE8sICJyeF9mcmFtZXNfNjVfMTI3IiwKKwkJCUNUTEZMQUdfUkQs ICZhZGFwdGVyLT5zdGF0cy5wcmMxMjcsCisJCQkiNjUtMTI3IGJ5dGUgZnJhbWVzIHJlY2Vp dmVkIik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJ4 X2ZyYW1lc18xMjhfMjU1IiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5wcmMy NTUsCisJCQkiMTI4LTI1NSBieXRlIGZyYW1lcyByZWNlaXZlZCIpOworCVNZU0NUTF9BRERf UVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJyeF9mcmFtZXNfMjU2XzUxMSIsCisJ CQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHJjNTExLAorCQkJIjI1Ni01MTEgYnl0 ZSBmcmFtZXMgcmVjZWl2ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3Qs IE9JRF9BVVRPLCAicnhfZnJhbWVzXzUxMl8xMDIzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFw dGVyLT5zdGF0cy5wcmMxMDIzLAorCQkJIjUxMi0xMDIzIGJ5dGUgZnJhbWVzIHJlY2VpdmVk Iik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInJ4X2Zy YW1lc18xMDI0XzE1MjIiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLnByYzE1 MjIsCisJCQkiMTAyMy0xNTIyIGJ5dGUgZnJhbWVzIHJlY2VpdmVkIik7CisgCVNZU0NUTF9B RERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJnb29kX29jdGV0c19yZWN2ZCIs IAorIAkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5nb3JjLCAKKyAJCQkiR29vZCBP Y3RldHMgUmVjZWl2ZWQiKTsgCisKKwkvKiBQYWNrZXQgVHJhbnNtaXNzaW9uIFN0YXRzICov CisgCVNZU0NUTF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJnb29kX29j dGVzdF90eGQiLCAKKyAJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuZ290YywgCisg CQkJIkdvb2QgT2N0ZXN0IFRyYW5zbWl0dGVkIik7IAorCVNZU0NUTF9BRERfUVVBRChjdHgs IHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ0b3RhbF9wa3RzX3R4ZCIsCisJCQlDVExGTEFHX1JE LCAmYWRhcHRlci0+c3RhdHMudHB0LAorCQkJIlRvdGFsIFBhY2tldHMgVHJhbnNtaXR0ZWQi KTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZ29vZF9w a3RzX3R4ZCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuZ3B0YywKKwkJCSJH b29kIFBhY2tldHMgVHJhbnNtaXR0ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0 X2xpc3QsIE9JRF9BVVRPLCAiYmNhc3RfcGt0c190eGQiLAorCQkJQ1RMRkxBR19SRCwgJmFk YXB0ZXItPnN0YXRzLmJwdGMsCisJCQkiQnJvYWRjYXN0IFBhY2tldHMgVHJhbnNtaXR0ZWQi KTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAibWNhc3Rf cGt0c190eGQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLm1wdGMsCisJCQki TXVsdGljYXN0IFBhY2tldHMgVHJhbnNtaXR0ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4 LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAidHhfZnJhbWVzXzY0IiwKKwkJCUNUTEZMQUdfUkQs ICZhZGFwdGVyLT5zdGF0cy5wdGM2NCwKKwkJCSI2NCBieXRlIGZyYW1lcyB0cmFuc21pdHRl ZCAiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAidHhf ZnJhbWVzXzY1XzEyNyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHRjMTI3 LAorCQkJIjY1LTEyNyBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCIpOworCVNZU0NUTF9BRERf UVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ0eF9mcmFtZXNfMTI4XzI1NSIsCisJ CQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHRjMjU1LAorCQkJIjEyOC0yNTUgYnl0 ZSBmcmFtZXMgdHJhbnNtaXR0ZWQiKTsKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xp c3QsIE9JRF9BVVRPLCAidHhfZnJhbWVzXzI1Nl81MTEiLAorCQkJQ1RMRkxBR19SRCwgJmFk YXB0ZXItPnN0YXRzLnB0YzUxMSwKKwkJCSIyNTYtNTExIGJ5dGUgZnJhbWVzIHRyYW5zbWl0 dGVkIik7CisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgInR4 X2ZyYW1lc181MTJfMTAyMyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMucHRj MTAyMywKKwkJCSI1MTItMTAyMyBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCIpOworCVNZU0NU TF9BRERfUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ0eF9mcmFtZXNfMTAyNF8x NTIyIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5wdGMxNTIyLAorCQkJIjEw MjQtMTUyMiBieXRlIGZyYW1lcyB0cmFuc21pdHRlZCIpOworCVNZU0NUTF9BRERfUVVBRChj dHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJ0c29fdHhkIiwKKwkJCUNUTEZMQUdfUkQsICZh ZGFwdGVyLT5zdGF0cy50c2N0YywKKwkJCSJUU08gQ29udGV4dHMgVHJhbnNtaXR0ZWQiKTsK KwlTWVNDVExfQUREX1FVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAidHNvX2N0eF9m YWlsIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy50c2N0ZmMsCisJCQkiVFNP IENvbnRleHRzIEZhaWxlZCIpOworCisKKwkvKiBJbnRlcnJ1cHQgU3RhdHMgKi8KKworCWlu dF9ub2RlID0gU1lTQ1RMX0FERF9OT0RFKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAiaW50ZXJy dXB0cyIsIAorCQkJCSAgICBDVExGTEFHX1JELCBOVUxMLCAiSW50ZXJydXB0IFN0YXRpc3Rp Y3MiKTsKKwlpbnRfbGlzdCA9IFNZU0NUTF9DSElMRFJFTihpbnRfbm9kZSk7CisKKwlTWVND VExfQUREX1FVQUQoY3R4LCBpbnRfbGlzdCwgT0lEX0FVVE8sICJhc3NlcnRzIiwKKwkJCUNU TEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5pYWMsCisJCQkiSW50ZXJydXB0IEFzc2VydGlv biBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgaW50X2xpc3QsIE9JRF9BVVRP LCAicnhfcGt0X3RpbWVyIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5pY3J4 cHRjLAorCQkJIkludGVycnVwdCBDYXVzZSBSeCBQa3QgVGltZXIgRXhwaXJlIENvdW50Iik7 CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBpbnRfbGlzdCwgT0lEX0FVVE8sICJyeF9hYnNf dGltZXIiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmljcnhhdGMsCisJCQki SW50ZXJydXB0IENhdXNlIFJ4IEFicyBUaW1lciBFeHBpcmUgQ291bnQiKTsKKworCVNZU0NU TF9BRERfUVVBRChjdHgsIGludF9saXN0LCBPSURfQVVUTywgInR4X3BrdF90aW1lciIsCisJ CQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuaWN0eHB0YywKKwkJCSJJbnRlcnJ1cHQg Q2F1c2UgVHggUGt0IFRpbWVyIEV4cGlyZSBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFE KGN0eCwgaW50X2xpc3QsIE9JRF9BVVRPLCAidHhfYWJzX3RpbWVyIiwKKwkJCUNUTEZMQUdf UkQsICZhZGFwdGVyLT5zdGF0cy5pY3R4YXRjLAorCQkJIkludGVycnVwdCBDYXVzZSBUeCBB YnMgVGltZXIgRXhwaXJlIENvdW50Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBpbnRf bGlzdCwgT0lEX0FVVE8sICJ0eF9xdWV1ZV9lbXB0eSIsCisJCQlDVExGTEFHX1JELCAmYWRh cHRlci0+c3RhdHMuaWN0eHFlYywKKwkJCSJJbnRlcnJ1cHQgQ2F1c2UgVHggUXVldWUgRW1w dHkgQ291bnQiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGludF9saXN0LCBPSURfQVVU TywgInR4X3F1ZXVlX21pbl90aHJlc2giLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0 YXRzLmljdHhxbXRjLAorCQkJIkludGVycnVwdCBDYXVzZSBUeCBRdWV1ZSBNaW4gVGhyZXNo IENvdW50Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBpbnRfbGlzdCwgT0lEX0FVVE8s ICJyeF9kZXNjX21pbl90aHJlc2giLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRz LmljcnhkbXRjLAorCQkJIkludGVycnVwdCBDYXVzZSBSeCBEZXNjIE1pbiBUaHJlc2ggQ291 bnQiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGludF9saXN0LCBPSURfQVVUTywgInJ4 X292ZXJydW4iLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmljcnhvYywKKwkJ CSJJbnRlcnJ1cHQgQ2F1c2UgUmVjZWl2ZXIgT3ZlcnJ1biBDb3VudCIpOworCisJLyogSG9z dCB0byBDYXJkIFN0YXRzICovCisKKwlob3N0X25vZGUgPSBTWVNDVExfQUREX05PREUoY3R4 LCBjaGlsZCwgT0lEX0FVVE8sICJob3N0IiwgCisJCQkJICAgIENUTEZMQUdfUkQsIE5VTEws IAorCQkJCSAgICAiSG9zdCB0byBDYXJkIFN0YXRpc3RpY3MiKTsKKworCWhvc3RfbGlzdCA9 IFNZU0NUTF9DSElMRFJFTihob3N0X25vZGUpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwg aG9zdF9saXN0LCBPSURfQVVUTywgImJyZWFrZXJfdHhfcGt0IiwKKwkJCUNUTEZMQUdfUkQs ICZhZGFwdGVyLT5zdGF0cy5jYnRtcGMsCisJCQkiQ2lyY3VpdCBCcmVha2VyIFR4IFBhY2tl dCBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwgaG9zdF9saXN0LCBPSURfQVVU TywgImhvc3RfdHhfcGt0X2Rpc2NhcmQiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0 YXRzLmh0ZHBtYywKKwkJCSJIb3N0IFRyYW5zbWl0IERpc2NhcmRlZCBQYWNrZXRzIik7CisK KwlTWVNDVExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAicnhfcGt0IiwK KwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5zdGF0cy5ycHRoYywKKwkJCSJSeCBQYWNrZXRz IFRvIEhvc3QiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGhvc3RfbGlzdCwgT0lEX0FV VE8sICJicmVha2VyX3J4X3BrdHMiLAorCQkJQ1RMRkxBR19SRCwgJmFkYXB0ZXItPnN0YXRz LmNicm1wYywKKwkJCSJDaXJjdWl0IEJyZWFrZXIgUnggUGFja2V0IENvdW50Iik7CisKKwlT WVNDVExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAiYnJlYWtlcl9yeF9w a3RfZHJvcCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuY2JyZHBjLAorCQkJ IkNpcmN1aXQgQnJlYWtlciBSeCBEcm9wcGVkIENvdW50Iik7CisKKwlTWVNDVExfQUREX1FV QUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAidHhfZ29vZF9wa3QiLAorCQkJQ1RMRkxB R19SRCwgJmFkYXB0ZXItPnN0YXRzLmhncHRjLAorCQkJIkhvc3QgR29vZCBQYWNrZXRzIFR4 IENvdW50Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRP LCAiYnJlYWtlcl90eF9wa3RfZHJvcCIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3Rh dHMuaHRjYmRwYywKKwkJCSJIb3N0IFR4IENpcmN1aXQgQnJlYWtlciBEcm9wcGVkIENvdW50 Iik7CisKKwlTWVNDVExfQUREX1FVQUQoY3R4LCBob3N0X2xpc3QsIE9JRF9BVVRPLCAicnhf Z29vZF9ieXRlcyIsCisJCQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuaGdvcmMsCisJ CQkiSG9zdCBHb29kIE9jdGV0cyBSZWNlaXZlZCBDb3VudCIpOworCisJU1lTQ1RMX0FERF9R VUFEKGN0eCwgaG9zdF9saXN0LCBPSURfQVVUTywgInR4X2dvb2RfYnl0ZXMiLAorCQkJQ1RM RkxBR19SRCwgJmFkYXB0ZXItPnN0YXRzLmhnb3RjLAorCQkJIkhvc3QgR29vZCBPY3RldHMg VHJhbnNtaXQgQ291bnQiKTsKKworCVNZU0NUTF9BRERfUVVBRChjdHgsIGhvc3RfbGlzdCwg T0lEX0FVVE8sICJsZW5ndGhfZXJyb3JzIiwKKwkJCUNUTEZMQUdfUkQsICZhZGFwdGVyLT5z dGF0cy5sZW5lcnJzLAorCQkJIkxlbmd0aCBFcnJvcnMiKTsKKworCVNZU0NUTF9BRERfUVVB RChjdHgsIGhvc3RfbGlzdCwgT0lEX0FVVE8sICJzZXJkZXNfdmlvbGF0aW9uX3BrdCIsCisJ CQlDVExGTEFHX1JELCAmYWRhcHRlci0+c3RhdHMuc2N2cGMsCisJCQkiU2VyRGVzL1NHTUlJ IENvZGUgVmlvbGF0aW9uIFBrdCBDb3VudCIpOworCisJU1lTQ1RMX0FERF9RVUFEKGN0eCwg aG9zdF9saXN0LCBPSURfQVVUTywgImhlYWRlcl9yZWRpcl9taXNzZWQiLAorCQkJQ1RMRkxB R19SRCwgJmFkYXB0ZXItPnN0YXRzLmhybXBjLAorCQkJIkhlYWRlciBSZWRpcmVjdGlvbiBN aXNzZWQgUGFja2V0IENvdW50Iik7CiAKKworfQogLyoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAqCiAg KiAgVGhpcyByb3V0aW5lIHByb3ZpZGVzIGEgd2F5IHRvIGR1bXAgb3V0IHRoZSBhZGFwdGVy IGVlcHJvbSwKQEAgLTQ5NDMsMjggKzUxOTMsOCBAQCBpZ2JfcHJpbnRfaHdfc3RhdHMoc3Ry dWN0IGFkYXB0ZXIgKmFkYXB0CiAgKiAgMzIgd29yZHMsIHN0dWZmIHRoYXQgbWF0dGVycyBp cyBpbiB0aGF0IGV4dGVudC4KICAqCiAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KLXN0YXRpYyB2b2lk Ci1pZ2JfcHJpbnRfbnZtX2luZm8oc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCi17Ci0JdTE2 CWVlcHJvbV9kYXRhOwotCWludAlpLCBqLCByb3cgPSAwOwotCi0JLyogSXRzIGEgYml0IGNy dWRlLCBidXQgaXQgZ2V0cyB0aGUgam9iIGRvbmUgKi8KLQlwcmludGYoIlxuSW50ZXJmYWNl IEVFUFJPTSBEdW1wOlxuIik7Ci0JcHJpbnRmKCJPZmZzZXRcbjB4MDAwMCAgIik7Ci0JZm9y IChpID0gMCwgaiA9IDA7IGkgPCAzMjsgaSsrLCBqKyspIHsKLQkJaWYgKGogPT0gOCkgeyAv KiBNYWtlIHRoZSBvZmZzZXQgYmxvY2sgKi8KLQkJCWogPSAwOyArK3JvdzsKLQkJCXByaW50 ZigiXG4weDAwJXgwICAiLHJvdyk7Ci0JCX0KLQkJZTEwMDBfcmVhZF9udm0oJmFkYXB0ZXIt Pmh3LCBpLCAxLCAmZWVwcm9tX2RhdGEpOwotCQlwcmludGYoIiUwNHggIiwgZWVwcm9tX2Rh dGEpOwotCX0KLQlwcmludGYoIlxuIik7Ci19Ci0KIHN0YXRpYyBpbnQKLWlnYl9zeXNjdGxf ZGVidWdfaW5mbyhTWVNDVExfSEFORExFUl9BUkdTKQoraWdiX3N5c2N0bF9udm1faW5mbyhT WVNDVExfSEFORExFUl9BUkdTKQogewogCXN0cnVjdCBhZGFwdGVyICphZGFwdGVyOwogCWlu dCBlcnJvcjsKQEAgLTQ5NzYsMTYgKzUyMDYsMTIgQEAgaWdiX3N5c2N0bF9kZWJ1Z19pbmZv KFNZU0NUTF9IQU5ETEVSX0FSRwogCWlmIChlcnJvciB8fCAhcmVxLT5uZXdwdHIpCiAJCXJl dHVybiAoZXJyb3IpOwogCi0JaWYgKHJlc3VsdCA9PSAxKSB7Ci0JCWFkYXB0ZXIgPSAoc3Ry dWN0IGFkYXB0ZXIgKilhcmcxOwotCQlpZ2JfcHJpbnRfZGVidWdfaW5mbyhhZGFwdGVyKTsK LQl9CiAJLyoKIAkgKiBUaGlzIHZhbHVlIHdpbGwgY2F1c2UgYSBoZXggZHVtcCBvZiB0aGUK IAkgKiBmaXJzdCAzMiAxNi1iaXQgd29yZHMgb2YgdGhlIEVFUFJPTSB0bwogCSAqIHRoZSBz Y3JlZW4uCiAJICovCi0JaWYgKHJlc3VsdCA9PSAyKSB7CisJaWYgKHJlc3VsdCA9PSAxKSB7 CiAJCWFkYXB0ZXIgPSAoc3RydWN0IGFkYXB0ZXIgKilhcmcxOwogCQlpZ2JfcHJpbnRfbnZt X2luZm8oYWRhcHRlcik7CiAgICAgICAgIH0KQEAgLTQ5OTMsMjYgKzUyMTksMjQgQEAgaWdi X3N5c2N0bF9kZWJ1Z19pbmZvKFNZU0NUTF9IQU5ETEVSX0FSRwogCXJldHVybiAoZXJyb3Ip OwogfQogCi0KLXN0YXRpYyBpbnQKLWlnYl9zeXNjdGxfc3RhdHMoU1lTQ1RMX0hBTkRMRVJf QVJHUykKK3N0YXRpYyB2b2lkCitpZ2JfcHJpbnRfbnZtX2luZm8oc3RydWN0IGFkYXB0ZXIg KmFkYXB0ZXIpCiB7Ci0Jc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXI7Ci0JaW50IGVycm9yOwot CWludCByZXN1bHQ7Ci0KLQlyZXN1bHQgPSAtMTsKLQllcnJvciA9IHN5c2N0bF9oYW5kbGVf aW50KG9pZHAsICZyZXN1bHQsIDAsIHJlcSk7Ci0KLQlpZiAoZXJyb3IgfHwgIXJlcS0+bmV3 cHRyKQotCQlyZXR1cm4gKGVycm9yKTsKKwl1MTYJZWVwcm9tX2RhdGE7CisJaW50CWksIGos IHJvdyA9IDA7CiAKLQlpZiAocmVzdWx0ID09IDEpIHsKLQkJYWRhcHRlciA9IChzdHJ1Y3Qg YWRhcHRlciAqKWFyZzE7Ci0JCWlnYl9wcmludF9od19zdGF0cyhhZGFwdGVyKTsKKwkvKiBJ dHMgYSBiaXQgY3J1ZGUsIGJ1dCBpdCBnZXRzIHRoZSBqb2IgZG9uZSAqLworCXByaW50Zigi XG5JbnRlcmZhY2UgRUVQUk9NIER1bXA6XG4iKTsKKwlwcmludGYoIk9mZnNldFxuMHgwMDAw ICAiKTsKKwlmb3IgKGkgPSAwLCBqID0gMDsgaSA8IDMyOyBpKyssIGorKykgeworCQlpZiAo aiA9PSA4KSB7IC8qIE1ha2UgdGhlIG9mZnNldCBibG9jayAqLworCQkJaiA9IDA7ICsrcm93 OworCQkJcHJpbnRmKCJcbjB4MDAleDAgICIscm93KTsKKwkJfQorCQllMTAwMF9yZWFkX252 bSgmYWRhcHRlci0+aHcsIGksIDEsICZlZXByb21fZGF0YSk7CisJCXByaW50ZigiJTA0eCAi LCBlZXByb21fZGF0YSk7CiAJfQotCi0JcmV0dXJuIChlcnJvcik7CisJcHJpbnRmKCJcbiIp OwogfQogCiBzdGF0aWMgdm9pZAotLS0gc3lzL2Rldi9lMTAwMC9pZl9pZ2IuaAkyMDEwLzA0 LzA1IDIwOjM5OjQ0CTEuNC4yLjIKKysrIHN5cy9kZXYvZTEwMDAvaWZfaWdiLmgJMjAxMC8w Ni8xOCAxNzoyMjowOAkxLjQuMi4zCkBAIC0zMCw3ICszMCw3IEBACiAgIFBPU1NJQklMSVRZ IE9GIFNVQ0ggREFNQUdFLgogCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCi0vKiRGcmVl QlNEOiBzcmMvc3lzL2Rldi9lMTAwMC9pZl9pZ2IuaCx2IDEuNC4yLjIuMi4xIDIwMTAvMDYv MTQgMDI6MDk6MDYga2Vuc21pdGggRXhwICQqLworLyokRnJlZUJTRDogc3JjL3N5cy9kZXYv ZTEwMDAvaWZfaWdiLmgsdiAxLjQuMi4zIDIwMTAvMDYvMTggMTc6MjI6MDggamZ2IEV4cCAk Ki8KIAogI2lmbmRlZiBfSUdCX0hfREVGSU5FRF8KICNkZWZpbmUgX0lHQl9IX0RFRklORURf CkBAIC0zMTcsNiArMzE3LDkgQEAgc3RydWN0IHR4X3JpbmcgewogCWludAkJCXdhdGNoZG9n X3RpbWU7CiAJdTY0CQkJbm9fZGVzY19hdmFpbDsKIAl1NjQJCQl0eF9wYWNrZXRzOworCS8q IFN0YXRpc3RpY3MgZm9yIHJlcG9ydGluZywgT05MWS4gKi8KKwl1MzIJCQl0ZGg7IC8qIFRy YW5zbWl0IERlc2NyaXB0b3IgSGVhZCAqLworCXUzMgkJCXRkdDsgLyogVHJhbnNtaXQgRGVz Y3JpcHRvciBUYWlsICovCiB9OwogCiAvKgpAQCAtMzUzLDYgKzM1Niw5IEBAIHN0cnVjdCBy eF9yaW5nIHsKIAl1NjQJCQlyeF9kaXNjYXJkZWQ7CiAJdTY0CQkJcnhfcGFja2V0czsKIAl1 NjQJCQlyeF9ieXRlczsKKwkvKiBTdGF0aXN0aWNzIGZvciByZXBvcnRpbmcsIE9OTFkuICov CisJdTMyCQkJcmRoOyAvKiBUcmFuc21pdCBEZXNjcmlwdG9yIEhlYWQgKi8KKwl1MzIJCQly ZHQ7IC8qIFRyYW5zbWl0IERlc2NyaXB0b3IgVGFpbCAqLwogfTsKIAogc3RydWN0IGFkYXB0 ZXIgewpAQCAtMzgyLDggKzM4OCw2IEBAIHN0cnVjdCBhZGFwdGVyIHsKIAlpbnQJCW1pbl9m cmFtZV9zaXplOwogCXN0cnVjdCBtdHgJY29yZV9tdHg7CiAJaW50CQlpZ2JfaW5zZXJ0X3Zs YW5faGVhZGVyOwotCXN0cnVjdCB0YXNrICAgICByeHR4X3Rhc2s7Ci0Jc3RydWN0IHRhc2tx dWV1ZSAqdHE7CS8qIGFkYXB0ZXIgdGFzayBxdWV1ZSAqLwogICAgICAgICB1MTYJCW51bV9x dWV1ZXM7CiAKIAlldmVudGhhbmRsZXJfdGFnIHZsYW5fYXR0YWNoOwpAQCAtNDI4LDYgKzQz MiwxMiBAQCBzdHJ1Y3QgYWRhcHRlciB7CiAgICAgICAgIHVuc2lnbmVkIGxvbmcJbm9fdHhf ZG1hX3NldHVwOwogCXVuc2lnbmVkIGxvbmcJd2F0Y2hkb2dfZXZlbnRzOwogCXVuc2lnbmVk IGxvbmcJcnhfb3ZlcnJ1bnM7CisJdW5zaWduZWQgbG9uZwlkZXZpY2VfY29udHJvbDsKKwl1 bnNpZ25lZCBsb25nCXJ4X2NvbnRyb2w7CisJdW5zaWduZWQgbG9uZwlpbnRfbWFzazsKKwl1 bnNpZ25lZCBsb25nCWVpbnRfbWFzazsKKwl1bnNpZ25lZCBsb25nCXBhY2tldF9idWZfYWxs b2Nfcng7CisJdW5zaWduZWQgbG9uZwlwYWNrZXRfYnVmX2FsbG9jX3R4OwogCiAJYm9vbGVh bl90ICAgICAgIGluX2RldGFjaDsKIAotLS0gc3lzL2Rldi9lMTAwMC9pZl9sZW0uYwkyMDEw LzA1LzE0IDIyOjIwOjU4CTEuMy4yLjQKKysrIHN5cy9kZXYvZTEwMDAvaWZfbGVtLmMJMjAx MC8wNi8xOCAxNzoyMjowOAkxLjMuMi41CkBAIC0zMCw3ICszMCw3IEBACiAgIFBPU1NJQklM SVRZIE9GIFNVQ0ggREFNQUdFLgogCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCi0vKiRG cmVlQlNEOiBzcmMvc3lzL2Rldi9lMTAwMC9pZl9sZW0uYyx2IDEuMy4yLjQuMi4xIDIwMTAv MDYvMTQgMDI6MDk6MDYga2Vuc21pdGggRXhwICQqLworLyokRnJlZUJTRDogc3JjL3N5cy9k ZXYvZTEwMDAvaWZfbGVtLmMsdiAxLjMuMi41IDIwMTAvMDYvMTggMTc6MjI6MDggamZ2IEV4 cCAkKi8KIAogI2lmZGVmIEhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJTCiAjaW5jbHVkZSAi b3B0X2RldmljZV9wb2xsaW5nLmgiCkBAIC0yMDAsNyArMjAwLDcgQEAgc3RhdGljIHZvaWQJ bGVtX3R4ZW9mKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIHZvaWQJbGVtX3R4X3B1cmdl KHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIGludAlsZW1fYWxsb2NhdGVfcmVjZWl2ZV9z dHJ1Y3R1cmVzKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIGludAlsZW1fYWxsb2NhdGVf dHJhbnNtaXRfc3RydWN0dXJlcyhzdHJ1Y3QgYWRhcHRlciAqKTsKLXN0YXRpYyBpbnQJbGVt X3J4ZW9mKHN0cnVjdCBhZGFwdGVyICosIGludCk7CitzdGF0aWMgYm9vbAlsZW1fcnhlb2Yo c3RydWN0IGFkYXB0ZXIgKiwgaW50LCBpbnQgKik7CiAjaWZuZGVmIF9fTk9fU1RSSUNUX0FM SUdOTUVOVAogc3RhdGljIGludAlsZW1fZml4dXBfcngoc3RydWN0IGFkYXB0ZXIgKik7CiAj ZW5kaWYKQEAgLTEyNTUsNyArMTI1NSw3IEBAIGxlbV9wb2xsKHN0cnVjdCBpZm5ldCAqaWZw LCBlbnVtIHBvbGxfY20KIAl9CiAJRU1fQ09SRV9VTkxPQ0soYWRhcHRlcik7CiAKLQlyeF9k b25lID0gbGVtX3J4ZW9mKGFkYXB0ZXIsIGNvdW50KTsKKwlsZW1fcnhlb2YoYWRhcHRlciwg Y291bnQsICZyeF9kb25lKTsKIAogCUVNX1RYX0xPQ0soYWRhcHRlcik7CiAJbGVtX3R4ZW9m KGFkYXB0ZXIpOwpAQCAtMTMwOCw3ICsxMzA4LDcgQEAgbGVtX2ludHIodm9pZCAqYXJnKQog CiAJRU1fVFhfTE9DSyhhZGFwdGVyKTsKIAlsZW1fdHhlb2YoYWRhcHRlcik7Ci0JbGVtX3J4 ZW9mKGFkYXB0ZXIsIC0xKTsKKwlsZW1fcnhlb2YoYWRhcHRlciwgLTEsIE5VTEwpOwogCWxl bV90eGVvZihhZGFwdGVyKTsKIAlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JV Tk5JTkcgJiYKIAkgICAgIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKQEAgLTEz NTAsNyArMTM1MCw3IEBAIGxlbV9oYW5kbGVfcnh0eCh2b2lkICpjb250ZXh0LCBpbnQgcGVu ZGkKIAogCiAJaWYgKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSB7Ci0J CWlmIChsZW1fcnhlb2YoYWRhcHRlciwgYWRhcHRlci0+cnhfcHJvY2Vzc19saW1pdCkgIT0g MCkKKwkJaWYgKGxlbV9yeGVvZihhZGFwdGVyLCBhZGFwdGVyLT5yeF9wcm9jZXNzX2xpbWl0 LCBOVUxMKSAhPSAwKQogCQkJdGFza3F1ZXVlX2VucXVldWUoYWRhcHRlci0+dHEsICZhZGFw dGVyLT5yeHR4X3Rhc2spOwogCQlFTV9UWF9MT0NLKGFkYXB0ZXIpOwogCQlsZW1fdHhlb2Yo YWRhcHRlcik7CkBAIC0zNDQ5LDggKzM0NDksOCBAQCBsZW1fZnJlZV9yZWNlaXZlX3N0cnVj dHVyZXMoc3RydWN0IGFkYXB0CiAgKiAgCiAgKiAgRm9yIHBvbGxpbmcgd2UgYWxzbyBub3cg cmV0dXJuIHRoZSBudW1iZXIgb2YgY2xlYW5lZCBwYWNrZXRzCiAgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Lwotc3RhdGljIGludAotbGVtX3J4ZW9mKHN0cnVjdCBhZGFwdGVyICphZGFwdGVyLCBpbnQg Y291bnQpCitzdGF0aWMgYm9vbAorbGVtX3J4ZW9mKHN0cnVjdCBhZGFwdGVyICphZGFwdGVy LCBpbnQgY291bnQsIGludCAqZG9uZSkKIHsKIAlzdHJ1Y3QgaWZuZXQJKmlmcCA9IGFkYXB0 ZXItPmlmcDs7CiAJc3RydWN0IG1idWYJKm1wOwpAQCAtMzQ2Niw4ICszNDY2LDEwIEBAIGxl bV9yeGVvZihzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciwgaW50IGMKIAkgICAgQlVTX0RNQVNZ TkNfUE9TVFJFQUQpOwogCiAJaWYgKCEoKGN1cnJlbnRfZGVzYy0+c3RhdHVzKSAmIEUxMDAw X1JYRF9TVEFUX0REKSkgeworCQlpZiAoZG9uZSAhPSBOVUxMKQorCQkJKmRvbmUgPSByeF9z ZW50OwogCQlFTV9SWF9VTkxPQ0soYWRhcHRlcik7Ci0JCXJldHVybiAocnhfc2VudCk7CisJ CXJldHVybiAoRkFMU0UpOwogCX0KIAogCXdoaWxlICgoY3VycmVudF9kZXNjLT5zdGF0dXMg JiBFMTAwMF9SWERfU1RBVF9ERCkgJiYKQEAgLTM2MjYsOCArMzYyOCwxMCBAQCBkaXNjYXJk OgogCWlmICgtLWkgPCAwKQogCQlpID0gYWRhcHRlci0+bnVtX3J4X2Rlc2MgLSAxOwogCUUx MDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1JEVCgwKSwgaSk7CisJaWYgKGRv bmUgIT0gTlVMTCkKKwkJKmRvbmUgPSByeF9zZW50OwogCUVNX1JYX1VOTE9DSyhhZGFwdGVy KTsKLQlyZXR1cm4gKHJ4X3NlbnQpOworCXJldHVybiAoY3VycmVudF9kZXNjLT5zdGF0dXMg JiBFMTAwMF9SWERfU1RBVF9ERCk7CiB9CiAKICNpZm5kZWYgX19OT19TVFJJQ1RfQUxJR05N RU5UCg== --------------020608030802000604090208-- --------------enigF6A690C36A07BC733D80DCC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkxEdpcACgkQLDqVQ9VXb8jz9ACfaLxQ+Y+z2ullaBPna0/0KrDT bAYAoKW/S/STf/Y8EzULUKEd8l6bxGNJ =zpqG -----END PGP SIGNATURE----- --------------enigF6A690C36A07BC733D80DCC7-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:15:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 638851065674 for ; Mon, 19 Jul 2010 16:15:23 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 290BF8FC0A for ; Mon, 19 Jul 2010 16:15:22 +0000 (UTC) Received: by iwn35 with SMTP id 35so5970339iwn.13 for ; Mon, 19 Jul 2010 09:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=yOtogE4122l2OxVnolaUJ8h5ql8ONfEXwx7/qo3920Q=; b=S39FJK/sDOuX6GscMEtip/luh6B3WPIkh+Sbp2L2yyJG1Q95cZRNG8az0lF8rzMQgX 8sZDVu/EQkrOr+ZfRxm6Rk8Ds9PtBGWGh4bdti7XAyev6HlUGiTy+31guyL0XoXzum8K 28KBcYjtu1oapi9AOMUtSt0sCJEffY0O6OOsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ak4wMBUPFHl9n5WQFg745CErZQrG03YKh/KtVpRy1A51Q5MFradUqwsALNj9RqcMI9 KPJF0C9xDs55UKw1smAB9s1U8+adqrvr3LRYvyNK9JDCOBnWEsOzS+UQEz8DmWw02KdX vgp51dEQr8NOZ/8YRkJ+RVqVOGNBaQKsrxi7o= MIME-Version: 1.0 Received: by 10.231.144.15 with SMTP id x15mr5356517ibu.73.1279556122433; Mon, 19 Jul 2010 09:15:22 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Mon, 19 Jul 2010 09:15:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 09:15:21 -0700 Message-ID: From: Freddie Cash To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:15:23 -0000 On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore wrote: > So you think it's because when I switch from the old disk to the new disk, > ZFS doesn't realize the disk has changed, and thinks the data is just > corrupt now? Even if that happens, shouldn't the pool still be available, > since it's RAIDZ1 and only one disk has gone away? I think it's because you pull the old drive, boot with the new drive, the controller re-numbers all the devices (ie da3 is now da2, da2 is now da1, da1 is now da0, da0 is now da6, etc), and ZFS thinks that all the drives have changed, thus corrupting the pool. I've had this happen on our storage servers a couple of times before I started using glabel(8) on all our drives (dead drive on RAID controller, remove drive, reboot for whatever reason, all device nodes are renumbered, everything goes kablooey). Doing the export and import will force ZFS to re-read the metadata on the drives (ZFS does it's own "labelling" to say which drives belong to which vdevs), and to pick things up correctly using the new device nodes. > I don't have / on ZFS; I'm only using it as a 'data' partition, so I should > be able to try your suggestion. My only concern: is there any risk of > trashing my pool if I try your instructions? Everything I've done so far, > even when told "insufficient replicas / corrupt data", has not cost me any > data as long as I switch back to the original (dying) drive. If I mix in > export/import statements which might 'touch' the pool, is there a chance it > will choke and trash my data? Well, there's always a chance things explode. :) But an export/import is safe so long as all drives are connected at the time. I've recovered "corrupted" pools by doing the above. (I've now switched to labelling all my drives to prevent this from happening.) Of course, always have good backups. ;) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:18:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1052F106567A for ; Mon, 19 Jul 2010 16:18:27 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BBA498FC17 for ; Mon, 19 Jul 2010 16:18:26 +0000 (UTC) Received: by gxk24 with SMTP id 24so2769067gxk.13 for ; Mon, 19 Jul 2010 09:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WPjcoXShfHDD7+sPyTF7G+nbJRrjiyuVAepjZBsZq1w=; b=TEsMaI8OvcsO6Mg7s3/esB5D7YnE/P/FEmXy7xBkuuhHExcFrj0mAsisFW3Y1+oGsL 9q0IcYveAKM6wziPkgHLBW+vSYVnRf7f3a2jI8kfyIkZBhSBg83CMxaRKVJJBg9GHqZ8 Bdb0P2tFnwuLTkirKYkDqE8KpkFsRl91W1n10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yua32NCAyETjQF8QSwIpHeaXBW11bN8N/gLiG/9f9kfZ8ZRNWtc7Gnm+4oLhKfYifv qTPR7kGM3Px6+xa1pwqoJoZgfcbZM/aes8N8Zc6XNYxr+1iyejof9nBaGsWR6FAcMJTs Zw+6hAJZ2jYbJrWY2suiba/S2vzRio4IABLr8= MIME-Version: 1.0 Received: by 10.224.80.69 with SMTP id s5mr4423730qak.5.1279556305670; Mon, 19 Jul 2010 09:18:25 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Mon, 19 Jul 2010 09:18:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 11:18:25 -0500 Message-ID: From: Adam Vande More To: Garrett Moore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:18:27 -0000 On Mon, Jul 19, 2010 at 10:56 AM, Garrett Moore wrote: > So you think it's because when I switch from the old disk to the new disk, > ZFS doesn't realize the disk has changed, and thinks the data is just > corrupt now? Even if that happens, shouldn't the pool still be available, > since it's RAIDZ1 and only one disk has gone away? > > I don't have / on ZFS; I'm only using it as a 'data' partition, so I should > be able to try your suggestion. My only concern: is there any risk of > trashing my pool if I try your instructions? Everything I've done so far, > even when told "insufficient replicas / corrupt data", has not cost me any > data as long as I switch back to the original (dying) drive. If I mix in > export/import statements which might 'touch' the pool, is there a chance it > will choke and trash my data? > I'm not sure what's going on in your case, but I have cron'd a zpool scrub for my pool on weekly basis to avoid this. I run a / zfs mirror and one day I could no longer boot and saw the dread 'insufficient replicas'. I eventually got it when disk started to work again briefly then did a snapshot/send offsite, redid system with new install & disk then restored data. The export/import shouldn't hurt, I used that when booting off an MFSBSD cd and imported the zpool to send from there. Perhaps you might want to consider RAIDZ2 with all those disks. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:32:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E59CA106564A for ; Mon, 19 Jul 2010 16:32:39 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4AE8FC0C for ; Mon, 19 Jul 2010 16:32:39 +0000 (UTC) Received: by gwb19 with SMTP id 19so2081993gwb.13 for ; Mon, 19 Jul 2010 09:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=81Gxybw6gMchH2i18yVtkt7qx1QwB+522zWlt15HcM0=; b=JhLeR9CcngFjKCiLmMCIqa7BCTXvqWRq4qaSy/oO3PFm4AX/rv6IoLxPWqsFNOuvdW cGE05lHVQWSeMbzZ5kZQtw7CXV6JgGAQASoxCBAV3CyCruX5PbajewMCvRX9j2fqj5N9 eRTjZ6yG/9Es58nV0sv+g5uG0sxk1bq4IuyAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=skJEGvbL2M2VbeJyXAd4lZZ8AxaIaDprIc+PKlTZyo2qWqTzjV1UIBrtbxVUsrnsaE 5Bd0tKlITZxEkH3DXAgZ9zNDyW1m21h0vX1HHIw8ksHet/e5vyxIL3EirwLOysJNELWO 0IiheWzjmO3g5De4r1BTI8rySGbwypYRz762g= MIME-Version: 1.0 Received: by 10.100.212.7 with SMTP id k7mr5060739ang.45.1279557158522; Mon, 19 Jul 2010 09:32:38 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 09:32:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 12:32:38 -0400 Message-ID: From: Garrett Moore To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:32:40 -0000 The data on the disks is not irreplaceable so if I lose the array it isn't the end of the world but I would prefer not to lose it as it would be a pain to get all of the data again. Freddie's explanation is reasonable, but any ideas why it didn't happen when I replaced my first dead drive (da5)? That replacement was completely painless. The system is in a Supermicro case with a hotswap backplane: http://www.supermicro.com/products/chassis/4U/743/SC743TQ-865.cfm The backplane ports are connected to a Supermicro AOC-USASLP-L8I LSI 1068E 8-PORT RAID 0/1/10 Uio SATA/SAS Controller. By the way, Freddie, in your instructions in the 'reboot' step I assume that is when I will be switching the physical drives, correct? On Mon, Jul 19, 2010 at 12:18 PM, Adam Vande More wrote: > On Mon, Jul 19, 2010 at 10:56 AM, Garrett Moore wrote: > >> So you think it's because when I switch from the old disk to the new disk, >> ZFS doesn't realize the disk has changed, and thinks the data is just >> corrupt now? Even if that happens, shouldn't the pool still be available, >> since it's RAIDZ1 and only one disk has gone away? >> >> I don't have / on ZFS; I'm only using it as a 'data' partition, so I >> should >> be able to try your suggestion. My only concern: is there any risk of >> trashing my pool if I try your instructions? Everything I've done so far, >> even when told "insufficient replicas / corrupt data", has not cost me any >> data as long as I switch back to the original (dying) drive. If I mix in >> export/import statements which might 'touch' the pool, is there a chance >> it >> will choke and trash my data? >> > > I'm not sure what's going on in your case, but I have cron'd a zpool scrub > for my pool on weekly basis to avoid this. I run a / zfs mirror and one day > I could no longer boot and saw the dread 'insufficient replicas'. I > eventually got it when disk started to work again briefly then did a > snapshot/send offsite, redid system with new install & disk then restored > data. The export/import shouldn't hurt, I used that when booting off an > MFSBSD cd and imported the zpool to send from there. Perhaps you might want > to consider RAIDZ2 with all those disks. > > -- > Adam Vande More > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:32:53 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48AAE1065693 for ; Mon, 19 Jul 2010 16:32:53 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by mx1.freebsd.org (Postfix) with ESMTP id B14168FC16 for ; Mon, 19 Jul 2010 16:32:52 +0000 (UTC) Received: from kloboucek (kloboucek.ics.muni.cz [147.251.3.38]) (authenticated user=hopet@META bits=0) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id o6JGWo1o023710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Jul 2010 18:32:50 +0200 From: "Petr Holub" To: "'Petr Holub'" , References: In-Reply-To: Date: Mon, 19 Jul 2010 18:32:43 +0200 Message-ID: <00ae01cb2760$062b5d40$128217c0$@muni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskYPrZUR8uVTaZRQOL1c4GFwIpTAC/oBdw Content-Language: cs X-Muni-Spam-TestIP: 147.251.3.38 X-Muni-Envelope-From: hopet@ics.muni.cz X-Muni-Virus-Test: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Mon, 19 Jul 2010 18:32:51 +0200 (CEST) Cc: Subject: RE: update on kern/145064? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:32:53 -0000 Dear stable list, > is there any update on bug hunting of the issue described here? > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 > I've attempted to install PC BSD 8.1-RC1 on my desktop and I'm facing > the same problem with the Marvell SATA driver. Therefore, PC BSD is > not installable on my machine as it deterministically panics on > boot. The same machine runs FreeBSD 7.3 just fine. FYI, Alexander Motin provided me with a patch on ata-pci.c that makes 8.1-PRERELEASE boot OK on my machine. The patch is available on the PR page: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 Would it be possible to include this patch into the 8.1-RELEASE and PCBSD 8.1-RELEASE? Petr From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:33:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337991065677 for ; Mon, 19 Jul 2010 16:33:30 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2F928FC26 for ; Mon, 19 Jul 2010 16:33:29 +0000 (UTC) Received: by gyd8 with SMTP id 8so2765054gyd.13 for ; Mon, 19 Jul 2010 09:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=o9qIYwliuFENc2I6rMUbX53w/4pIQ6pWmnAkpk9SP3Y=; b=cvGlNWa1OfGGjJiuUxYiJv2PbORrlkx9QyYmIk9uv4DaY9v24Z/fzuKfXS6G1ZWseG 9EnX43fmmzSLaJEUsvHwNfppu/B7vRHiKCNSzAbusPTkmdgSWqnI4CM3lDWP/lxz5H5J F5flUFWg5n1WUdTdS1tkZlGbaPsiaH+lRTUvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qWvJfSV+Ozo8fwFVlqLH65EUICr3ZF0Bqp2tw+FtS63Q/umHZ7MN8o/ImgHNjlsVFq ClOOym0yEqbrAndeZ/ZqoumyjdZ25vf1UXidKwRuXgWxjAOwg2/a4Hpf0UABYlYTb/2F Qwi9f6pxjr93JvMky9UCwshcqci+PEs5/MnAM= MIME-Version: 1.0 Received: by 10.151.116.1 with SMTP id t1mr4834815ybm.329.1279557208896; Mon, 19 Jul 2010 09:33:28 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 09:33:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 12:33:28 -0400 Message-ID: From: Garrett Moore To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:33:30 -0000 I forgot to ask in the last email, is there a way to convert from Z1 to Z2 without losing data? I actually have far more storage than I need so I'd consider going to Z2. On Mon, Jul 19, 2010 at 12:18 PM, Adam Vande More wrote: > On Mon, Jul 19, 2010 at 10:56 AM, Garrett Moore wrote: > >> So you think it's because when I switch from the old disk to the new disk, >> ZFS doesn't realize the disk has changed, and thinks the data is just >> corrupt now? Even if that happens, shouldn't the pool still be available, >> since it's RAIDZ1 and only one disk has gone away? >> >> I don't have / on ZFS; I'm only using it as a 'data' partition, so I >> should >> be able to try your suggestion. My only concern: is there any risk of >> trashing my pool if I try your instructions? Everything I've done so far, >> even when told "insufficient replicas / corrupt data", has not cost me any >> data as long as I switch back to the original (dying) drive. If I mix in >> export/import statements which might 'touch' the pool, is there a chance >> it >> will choke and trash my data? >> > > I'm not sure what's going on in your case, but I have cron'd a zpool scrub > for my pool on weekly basis to avoid this. I run a / zfs mirror and one day > I could no longer boot and saw the dread 'insufficient replicas'. I > eventually got it when disk started to work again briefly then did a > snapshot/send offsite, redid system with new install & disk then restored > data. The export/import shouldn't hurt, I used that when booting off an > MFSBSD cd and imported the zpool to send from there. Perhaps you might want > to consider RAIDZ2 with all those disks. > > -- > Adam Vande More > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:36:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A12AC10656A9 for ; Mon, 19 Jul 2010 16:36:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 517CB8FC14 for ; Mon, 19 Jul 2010 16:36:54 +0000 (UTC) Received: by gyd8 with SMTP id 8so2767530gyd.13 for ; Mon, 19 Jul 2010 09:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=4ffF25yJuhcNUCpKHYku5QF3rlsDH5oXL2yA5b/8e8o=; b=hC01Y3uvDrjF3b3tnJ+CLc1ZDdwztY2wiZngh+19/pfz38lh7jlmk9C510iF/UZ1Gx 8qbXbihC/QniBB+tLIzSW7holoPETTWzlKtcvF4M1wcUyVanrNXzRNe0HtU42n0c22Sl ZHmaNrrrdxvj+IKHeQ/hF0Bi1yQ6XP7RAmC/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Oo/uaAWf+3fnnDevjThk7UXFrlEQXIWVCDNzlgGVpc+TwtoxWmwS0UGzuLSsABdTid 8VUCleSgFtF9LtJvvmoKlPQjVdabWl5meHJIKHK+doi5TbIiTQxrawRhgnwobalJ8K1T MiqVFos41vTtdQVUxq7Lqp7baNLkvw/GTFA6k= MIME-Version: 1.0 Received: by 10.90.98.19 with SMTP id v19mr3092448agb.20.1279557397488; Mon, 19 Jul 2010 09:36:37 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Mon, 19 Jul 2010 09:36:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 09:36:37 -0700 Message-ID: From: Freddie Cash To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:36:55 -0000 On Mon, Jul 19, 2010 at 9:32 AM, Garrett Moore wrote: > The data on the disks is not irreplaceable so if I lose the array it isn't > the end of the world but I would prefer not to lose it as it would be a pain > to get all of the data again. > > Freddie's explanation is reasonable, but any ideas why it didn't happen when > I replaced my first dead drive (da5)? That replacement was completely > painless. > > The system is in a Supermicro case with a hotswap backplane: > http://www.supermicro.com/products/chassis/4U/743/SC743TQ-865.cfm > The backplane ports are connected to a Supermicro AOC-USASLP-L8I LSI 1068E > 8-PORT RAID 0/1/10 Uio SATA/SAS Controller. > > By the way, Freddie, in your instructions in the 'reboot' step I assume that > is when I will be switching the physical drives, correct? Correct. export, power off, swap drives, power on, import. If it's a hot-swap backplane, though, have you tried doing it without the reboot? zpool offline tank da3 camcontrol da3 camcontrol rescan (or something like that) zpool replace tank da3 Read the camcontrol man page to see what the commands are to "turn off" the drive, and to rescan the controller for the new drive. It's possible the device number may change. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:40:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4A1106567A for ; Mon, 19 Jul 2010 16:40:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA238FC27 for ; Mon, 19 Jul 2010 16:40:22 +0000 (UTC) Received: by pxi8 with SMTP id 8so2170584pxi.13 for ; Mon, 19 Jul 2010 09:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=rEmw1fn3DMzIUOM4BZeUZXhKOs/3gsWsGEIMdHpVOaA=; b=MzcZCl7JOx2YXn7XUCSPvz3Z0NINwY3ZdJ2XW0q2D5qZyZuYTZEs41C+pq9pb0XfeQ zWzBXCwKMb9UDxee6DGD6Bq/xPmaq1AwIvmk8p52xoWEgopnc7vu69judlnDdST6YQ7T ySUbs4iZrDWMlDgtfnzcNHN7zra+xohhbbjcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BIbhKuB/K41ewSdIiDDX9IcwwcJb5Lt2F/bO6xLki9QTZ68X90nwiJEYKvyOLz8XUF vJtSyHXn9/Z5DHHkVVAhx2LAc67gheTDIYThnaVy3q6mhvHk7Hc+3zLTQ2umzPOtKkmm TnsZKShOhblJfsf6Qacpmk2TDjZugXxvf2AlA= MIME-Version: 1.0 Received: by 10.114.75.14 with SMTP id x14mr7354546waa.189.1279557621879; Mon, 19 Jul 2010 09:40:21 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Mon, 19 Jul 2010 09:40:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 09:40:21 -0700 Message-ID: From: Freddie Cash To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:40:22 -0000 On Mon, Jul 19, 2010 at 9:33 AM, Garrett Moore wrote: > I forgot to ask in the last email, is there a way to convert from Z1 to Z2 > without losing data? I actually have far more storage than I need so I'd > consider going to Z2. No, unfortunately it's not currently possible to change vdev types in ZFS. This is waiting on the long-time-in-coming "block-pointer rewrite" feature which has not yet been added to ZFS in OpenSolaris (and there's very little information on it's progress). The standard process is: - configure new server - configure pool using new vdev layout - zfs send/recv data to new server - decommission old server Or: - take backups of server - destroy pool - configure new pool using new vdev layout - restore from backups -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 16:52:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E641065672 for ; Mon, 19 Jul 2010 16:52:24 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 525AB8FC0C for ; Mon, 19 Jul 2010 16:52:24 +0000 (UTC) Received: by iwn35 with SMTP id 35so6014252iwn.13 for ; Mon, 19 Jul 2010 09:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=v1P7x7IeqpFZwGAjblihb7y+uQzbchTwgMRo9i2Jzlo=; b=QTuwI8npkIcltRae4iiZd2z7BkpVYwQTdATgZYwv9Jf+THkW5nXwqGR7GwJMWJvElx BY705y0Ph2rgwEzgaHzNbAQuZhwuf0BvWCb5soihE21DsYe3OB5NwQ0gkgc2CleyQSkW oGCN7/WB2TOJ8riE0T7h6HHwbV/Kn4gd2DxLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M6mWK0uSKT/gPzXs0rBFilPeGt0LRMMRIHQFuH3Al+1RtkKyJ1ZsBt5KRhUS5E4RWj 5AR6cS4evhi6y0H7vXR2q24ywCLv0zCSSOrfJlkQj0l2nDUdqyeesW78PjkHWd0+o1L/ G0Sy+AJraOaKUM1LHQNwqatZB59/O/djR34xM= MIME-Version: 1.0 Received: by 10.231.152.146 with SMTP id g18mr4590313ibw.48.1279558343333; Mon, 19 Jul 2010 09:52:23 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 09:52:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 12:52:23 -0400 Message-ID: From: Garrett Moore To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:52:24 -0000 I'm nervous to trust the hotswap features and camcontrol to set things up properly, but I guess I could try it. When I first set the system up before I put data on the array I tried the hotswap functionality and drives wouldn't always re-attach when reinserted, even if I fiddled with camcontrol, but I can't remember exactly what I did then. On Mon, Jul 19, 2010 at 12:36 PM, Freddie Cash wrote: > On Mon, Jul 19, 2010 at 9:32 AM, Garrett Moore > wrote: > > The data on the disks is not irreplaceable so if I lose the array it > isn't > > the end of the world but I would prefer not to lose it as it would be a > pain > > to get all of the data again. > > > > Freddie's explanation is reasonable, but any ideas why it didn't happen > when > > I replaced my first dead drive (da5)? That replacement was completely > > painless. > > > > The system is in a Supermicro case with a hotswap backplane: > > http://www.supermicro.com/products/chassis/4U/743/SC743TQ-865.cfm > > The backplane ports are connected to a Supermicro AOC-USASLP-L8I LSI > 1068E > > 8-PORT RAID 0/1/10 Uio SATA/SAS Controller. > > > > By the way, Freddie, in your instructions in the 'reboot' step I assume > that > > is when I will be switching the physical drives, correct? > > Correct. export, power off, swap drives, power on, import. > > If it's a hot-swap backplane, though, have you tried doing it without > the reboot? > > zpool offline tank da3 > camcontrol da3 > > camcontrol rescan (or something like that) > zpool replace tank da3 > > Read the camcontrol man page to see what the commands are to "turn > off" the drive, and to rescan the controller for the new drive. It's > possible the device number may change. > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > 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 19 19:03:51 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A354B106566C; Mon, 19 Jul 2010 19:03:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Mon, 19 Jul 2010 15:03:28 -0400 User-Agent: KMail/1.6.2 References: <877004.53626.qm@web59106.mail.re1.yahoo.com> <201007161522.54572.jkim@FreeBSD.org> <201007161918.32195.jkim@FreeBSD.org> In-Reply-To: <201007161918.32195.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201007191503.37511.jkim@FreeBSD.org> Cc: David DEMELIER Subject: Re: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 19:03:51 -0000 On Friday 16 July 2010 07:18 pm, Jung-uk Kim wrote: > On Friday 16 July 2010 03:22 pm, Jung-uk Kim wrote: > > On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: > > > 2010/6/19 paradox : > > > >>On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: > > > >>> Hi there, > > > >>> > > > >>> I was so happy to see that VESA is available for amd64, but > > > >>> unfortunately it does not work really well for me. Take a > > > >>> look at this picture : > > > >>> > > > >>> http://img717.imageshack.us/img717/7311/dsc00399h.jpg > > > >>> > > > >>> My laptop is a 15,6" so the best resolution is 1366x768, I > > > >>> tried this > > > >>> > > > >>> : vidcontrol MODE_496. As you can see on the picture all > > > >>> : the lines are > > > >>> > > > >>> completely everywhere, if I mouse the cursor they move away > > > >>> (I'm not drunk!). > > > >>> > > > >>> I have SC_PIXEL_MODE in my kernel config. > > > >>> > > > >>> The console terminal is okay until I don't excess > > > >>> 1280x960x32 video mode. > > > >>> > > > >>> Do you have any idea to fix this ? > > > >> > > > >>It is kinda known problem. ���������If the mode has larger > > > >> bytes per scan line than the minimum, few characters per > > > >> line are lost when the screen is scrolled up or down, i.e., > > > >> framebuffer copies of whole screen. ���������When you move > > > >> the mouse onto the line, entire line is redrawn and > > > >> restored. ���������That's what you are seeing. ���������Ed > > > >> might have a better idea how to fix it (CC'ed). > > > >> > > > >>Jung-uk Kim > > > > > > > > this is incorrent calculate the scan lines in the vesa driver > > > > Jung-uk Kim should to fix it > > > > > > But Jung-uk Kim said Ed' should fix it so we are in an infinite > > > loop :- > > > > No, I didn't say that. What I meant was "Ed may be a better > > qualified person to fix syscons vs. terminal emulator interaction > > issues." :-( > > Can you please try the attached patch? FYI, I just went ahead and committed a (slightly better) patch on head as r210248. It will be MFC'ed soon. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 20:17:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4816E106566B for ; Mon, 19 Jul 2010 20:17:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFBB8FC19 for ; Mon, 19 Jul 2010 20:17:00 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta05.emeryville.ca.mail.comcast.net with comcast id jok11e0010mlR8UA5wH0dL; Mon, 19 Jul 2010 20:17:00 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta11.emeryville.ca.mail.comcast.net with comcast id jwGz1e0053LrwQ28XwH0vS; Mon, 19 Jul 2010 20:17:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 825AB9B425; Mon, 19 Jul 2010 13:16:59 -0700 (PDT) Date: Mon, 19 Jul 2010 13:16:59 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719201659.GA21088@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> <20100719035844.GA93487@icarus.home.lan> <201007191241.o6JCfcq5049355@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007191241.o6JCfcq5049355@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:17:01 -0000 On Mon, Jul 19, 2010 at 08:41:40AM -0400, Mike Tancsa wrote: > At 11:58 PM 7/18/2010, Jeremy Chadwick wrote: > > >So I believe this indicates the message only gets printed during swapin, > >not swapout. Meaning it's happening during an I/O read from da0. > > Yes, and from my existing ssh sessions, it would _seem_ no disk IO > was completing. ie I tried a killall -9 watchdogd which would need > to load killall from the disk, read whatever its linked against. > However, after hitting enter it was just blocking on trying to read. > So I would describe it as if the entire system was waiting from that > "swapper Indefinite wait" to finish, or I could not read anything > from drives associated with that controller. Hmm, okay, so it sounds like the controller wedged or arcmsr(4) started acting oddly. I would open up a case with Areca on the problem, *especially* if it happens again. > >So what's hz? Well, I want to assume it's kern.hz, which defaults to > >1000. 1000*20 = 20000, so the timeout would be 20000/1000 = 20 seconds. > >That's a pretty long time to be waiting for an I/O read to return. > > I think the messages were printing to the serial console faster than > that, but I could be wrong. If it happens again, I will time it Come to think of it, I'm betting you'd get large batches of these messages if/when it happens. That VM code isn't something I'm familiar with (nor msleep(9)), I just happen to dig around and find what I can. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 20:33:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC3DA106564A for ; Mon, 19 Jul 2010 20:33:18 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by mx1.freebsd.org (Postfix) with ESMTP id 545658FC1D for ; Mon, 19 Jul 2010 20:33:17 +0000 (UTC) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com ([77.103.165.1] helo=propellor.libeljournal.com country=GB ident=hirez) by v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4c44b10e.5557.1e for freebsd-stable@freebsd.org; Mon, 19 Jul 2010 21:09:50 +0100 (envelope-sender ) Received: from localhost (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id EA0A81709E for ; Mon, 19 Jul 2010 21:09:49 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by localhost (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c88V6Z+DXeqK for ; Mon, 19 Jul 2010 21:09:46 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id BF3301707B for ; Mon, 19 Jul 2010 21:09:46 +0100 (BST) Message-ID: <4C44B104.2050000@libeljournal.com> Date: Mon, 19 Jul 2010 21:09:40 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-stable References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:33:19 -0000 On 19/07/2010 17:52, Garrett Moore wrote: > I'm nervous to trust the hotswap features and camcontrol to set things up > properly, but I guess I could try it. When I first set the system up before > I put data on the array I tried the hotswap functionality and drives > wouldn't always re-attach when reinserted, even if I fiddled with > camcontrol, but I can't remember exactly what I did then. We've a pair of medium-sized ZFS boxes with Supermicro boards (X8DTi, IIRC) in hotswap chassis. They've both got one hot-spare drive. Well, I say 'hot spare'. I mean 'Ought to be a hot-spare if my shoddy Perl works when triggered by devd'. What we've found to work is this: Drive fails (thus far simulated by pulling the drive from the backplane) ZFS error reported. Pool in degraded state. 'zpool replace pool da9 da23' (Where da23 is the hot spare and where this *should* happen automagically.) Wait for resilvering. Go on and swap the failed drive (da9 in this case) 'camcontrol rescan all' (new drive shows up in /var/log/messages) 'zpool replace da9' Wait while resilvering happens. Hot-swap drive returns to 'avail' status. [ ... ] -- JH-R From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 20:33:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D16F106564A for ; Mon, 19 Jul 2010 20:33:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD428FC12 for ; Mon, 19 Jul 2010 20:33:21 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id joZ41e00416AWCUAFwZMsA; Mon, 19 Jul 2010 20:33:21 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta06.emeryville.ca.mail.comcast.net with comcast id jwZL1e0023LrwQ28SwZLHh; Mon, 19 Jul 2010 20:33:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0F7B29B425; Mon, 19 Jul 2010 13:33:20 -0700 (PDT) Date: Mon, 19 Jul 2010 13:33:20 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20100719203320.GB21088@icarus.home.lan> References: <201007182108.o6IL88eG043887@lava.sentex.ca> <20100718211415.GA84127@icarus.home.lan> <201007182142.o6ILgDQW044046@lava.sentex.ca> <20100719023419.GA91006@icarus.home.lan> <201007190301.o6J31Hs1045607@lava.sentex.ca> <20100719033424.GA92607@icarus.home.lan> <201007191237.o6JCbmj7049339@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007191237.o6JCbmj7049339@lava.sentex.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: deadlock or bad disk ? RELENG_8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:33:22 -0000 On Mon, Jul 19, 2010 at 08:37:50AM -0400, Mike Tancsa wrote: > At 11:34 PM 7/18/2010, Jeremy Chadwick wrote: > >> > >> yes, da0 is a RAID volume with 4 disks behind the scenes. > > > >Okay, so can you get full SMART statistics for all 4 of those disks? > >The adjusted/calculated values for SMART thresholds won't be helpful > >here, one will need the actual raw SMART data. I hope the Areca CLI can > >provide that. > > I thought there was, but I cant seem to get the current smartctl to > work with the card. > > -d TYPE, --device=TYPE > Specifies the type of the device. The valid arguments to this > option are ata, scsi, sat, marvell, 3ware,N, areca,N, usbcy- > press, usbjmicron, usbsunplus, cciss,N, hpt,L/M (or hpt,L/M/N), > and test. > > # smartctl -a -d areca,0 /dev/arcmsr0 > smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.1-PRERELEASE amd64] (local build) > Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net > > /dev/arcmsr0: Unknown device type 'areca,0' > =======> VALID ARGUMENTS ARE: ata, scsi, sat[,N][+TYPE], > usbcypress[,X], usbjmicron[,x][,N], usbsunplus, 3ware,N, hpt,L/M/N, > cciss,N, atacam, test <======= > > Use smartctl -h to get a usage summary According to the official smartctl documentation and man page, the "areca,N" argument is only supported on Linux. Bummer. Areca SATA RAID controllers are currently supported under Linux only. To look at SATA disks behind Areca RAID controllers, use syntax such as: smartctl -a -d areca,2 /dev/sg2 smartctl -a -d areca,3 /dev/sg3 > The latest CLI tool only gives this info > > CLI> disk info drv=1 > Drive Information > =============================================================== > IDE Channel : 1 > Model Name : ST31000340AS > Serial Number : 3QJ07F1N > Firmware Rev. : SD15 > Disk Capacity : 1000.2GB > Device State : NORMAL > Timeout Count : 0 > Media Error Count : 0 > Device Temperature : 29 C > SMART Read Error Rate : 108(6) > SMART Spinup Time : 91(0) > SMART Reallocation Count : 100(36) > SMART Seek Error Rate : 81(30) > SMART Spinup Retries : 100(97) > SMART Calibration Retries : N.A.(N.A.) > =============================================================== > GuiErrMsg<0x00>: Success. > > CLI> disk smart drv=1 > S.M.A.R.T Information For Drive[#01] > # Attribute Items Flag Value Thres State > =============================================================================== > 1 Raw Read Error Rate 0x0f 108 6 OK > 3 Spin Up Time 0x03 91 0 OK > 4 Start/Stop Count 0x32 100 20 OK > 5 Reallocated Sector Count 0x33 100 36 OK > 7 Seek Error Rate 0x0f 81 30 OK > 9 Power-on Hours Count 0x32 79 0 OK > 10 Spin Retry Count 0x13 100 97 OK > 12 Device Power Cycle Count 0x32 100 20 OK > 194 Temperature 0x22 29 0 OK > 197 Current Pending Sector Count 0x12 100 0 OK > 198 Off-line Scan Uncorrectable Sector Count 0x10 100 0 OK > 199 Ultra DMA CRC Error Count 0x3e 200 0 OK > =============================================================================== > GuiErrMsg<0x00>: Success. Yeah, this isn't going to help much. The raw SMART data isn't being shown. I downloaded the Areca CLI manual dated 2010/07 which doesn't state anything other than what you've already shown. Bummer. > >If so, think about what would happen if heavy I/O happened on > >both da0 and da1 at the same time. I talk about this a bit more below. > > No different than any other single disk being heavily worked. > Again, this particular hardware configuration has been beaten about > for a couple of years. So I am not sure why all of a sudden it would > be not possible to do That's a very good question, and I don't have an answer to it. I also would have a hard time believing that suddenly out of no where heavy I/O would exhibit this problem. I'm just going over possibilities. For example, I see that the da1 RAID volume is labelled "backup1", so if you were storing backups there possibly the I/O degrades over time as a result of there being more data/files, etc... Wouldn't have seen it a year ago, but might see it now. Just thinking out loud. > >situation (since you'd then be dedicating an entire disk to just swap). > >Others may have other advice. You mention in a later mail that the > >ada[0-3] disks make up a ZFS pool of some sort. You might try splitting > >ada0 into two slices, one for swap and the other used as a pool member. > > That seems like it would just move the problem you are trying to get > me to avoid to a different set of disks. If putting swap on a raid > array is a bad thing, I am not sure how moving it to a ZFS raid > array will help. The idea wasn't to move swap to ZFS (that's a bad idea from what I remember, something about crash dumps not working in that situation). My idea was to move swap to a dedicated partition on a disk that happens to also be used for ZFS. E.g.: ada0 ada0s1a = 20GB = swap ada0s1b = 980GB = ZFS pool ada1 = 1000GB = ZFS pool ada2 = 1000GB = ZFS pool ada3 = 1000GB = ZFS pool Again, this isn't a solution for the problem. I'm in no way trying to dissuade anyone from figuring out the root cause. But quite often on the list if someone can't get an answer to "why" they want to know what they can do as a workaround. There just happens to be reports of this problem going all the way back to RELENG_6, and all the posts I've read so far have been when people have had swap backed by some sort of RAID. > >Again: I don't think this is necessarily a bad disk problem. The only > >way you'd be able to determine that would be to monitor on a per-disk > >basis the I/O response time of each disk member on the Areca. If the > >CLI tools provide this, awesome. Otherwise you'll probably need to > >involve Areca Support. > > In the past when I have had bad disks on the areca, it did catch and > flag device timeouts. There were no such alerts leading up to this > situation. Yeah, which makes it sound more like a driver issue or something. I really don't know what to say. Areca does officially support FreeBSD so they might have some ideas. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 20:36:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C75A91065680 for ; Mon, 19 Jul 2010 20:36:40 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 40A598FC14 for ; Mon, 19 Jul 2010 20:36:40 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 14CB239824; Mon, 19 Jul 2010 22:25:42 +0200 (SAST) Date: Mon, 19 Jul 2010 22:25:42 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20100719202541.GA42777@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: packet loss on ixgbe using vlans and ipv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:36:40 -0000 Hi, I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel 82599 cards). It is running FreeBSD RELENG_8 last updated on July 13. What I see is packet loss (0 - 40%) on IPv6 packets in vlans, when the machine is not the originator of the packets. Let me try to describe a little more. If a neigbouring machine ping6 it, there will be packet loss. If it act as a router for ipv6, there will be packet loss. This happen even when the network is pretty idle and with different switches (Nortel and Cisco equipment). The packet loss is very fluctuating. Pinging 1000 packets might loose 1% one time and the next time 30%. Looking with tcpdump, I can see the packets arriving and going out, but the packet never arrive at the next machine. (My feeling is that they get lost inside the card.) The error counters on the switch does not increment. I do not see packet loss if the machine originate the packets, for example ping6 from the machine. Also ipv4 packets do not have any packets loss. If I do not use vlans, I don't see packet loss with ipv6 either. pciconf -l of the ethernet cards: ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 dmesg of the first ethernet card. The others look the same, except for the memory and irq values: ix0: port 0xdcc 0-0xdcdf mem 0xd4100000-0xd417ffff,0xd40f8000-0xd40fbfff irq 64 at device 0.0 on pci129 ix0: Using MSIX interrupts with 17 vectors ix0: [ITHREAD] ... ix0: Ethernet address: 00:1b:21:57:b4:20 ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 If anybody need more info, please ask. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 20:41:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8647106566B for ; Mon, 19 Jul 2010 20:41:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id CF3B38FC08 for ; Mon, 19 Jul 2010 20:41:25 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta05.emeryville.ca.mail.comcast.net with comcast id jtTK1e0050EPchoA5whRcj; Mon, 19 Jul 2010 20:41:25 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.emeryville.ca.mail.comcast.net with comcast id jwhQ1e0053LrwQ28MwhQkv; Mon, 19 Jul 2010 20:41:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0D5649B425; Mon, 19 Jul 2010 13:41:24 -0700 (PDT) Date: Mon, 19 Jul 2010 13:41:24 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100719204124.GA21573@icarus.home.lan> References: <4C43F35D.5020007@aldan.algebra.com> <20100719113147.GA4786@icarus.home.lan> <4C44758F.7080209@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C44758F.7080209@aldan.algebra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:41:26 -0000 On Mon, Jul 19, 2010 at 11:55:59AM -0400, Mikhail T. wrote: > 19.07.2010 07:31, Jeremy Chadwick напиÑав(ла): > >If you boot the machine in single-user, and run fsck manually, are there > >any errors? > Thanks, Jeremy... I wish, there was a way to learn, /which/ > file-system is giving trouble... However, after sending the question > out last night, I tried to pkg_delete a package on the machine, and > was very lucky to see a file-system error (inode something or other) > before the panic struck. That, at least, told me, which file-system > was in trouble (/var). I dump-ed it out, re-created, and then > restored it... Although dumping went smooth, there were two errors > at which restore offered to abort. I told it not to and got (most of > the) file-system restored. (The dump is available to anyone wishing > to investigate -- contact me privately. I'm not posting it publicly > because of the passwd-file backup under /var). I see where you're going with this -- the only way you knew it was /var was based on the inode error you saw before the system crashed. > So far seems quiet -- no panics for two more hours before I went to bed. > >Only thing I can think of off the top of my head: there's a known > >situation (also applies to RELENG_7) where a background fsck doesn't > >correct all errors after a system crash/unclean shutdown. I mention > >this because I see "softdep" in the above stack trace (usually refers to > >softupdates). I don't know if this got fixed, but the workaround is to > >use background_fsck="no" in rc.conf. Yes, after a crash this means you > >have to wait for the entire fsck to run. > When setting up my main machine 4 years ago, I turned off background > fsck... But I thought, things have improved sufficiently enough > since then :-( Maybe, background fsck should still be disabled by > default? > > And, IMO, at the very least, *any panic related to a file-system > must clearly identify the file-system in question*... What do you > think? I think that's a reasonable request and would be ideal for situations like this. If it's possible or not is a completely different question. I might be able to code something like this up (would be my first time messing around in the kernel in this regard -- warning, alert, hazard, danger Will Robinson!), but it'd probably make more sense for someone already familiar with that section of code to do it. I'm much more familiar with userland stuff, the kernel is "black magic". ;-) Assuming work tonight isn't that busy for me, I'll see if I can dedicate some cycles to printing this information in the error string you saw. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 20:46:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECE991065672 for ; Mon, 19 Jul 2010 20:46:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7A68FC14 for ; Mon, 19 Jul 2010 20:46:20 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id jnnY1e0050cZkys54wmLxE; Mon, 19 Jul 2010 20:46:20 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta10.westchester.pa.mail.comcast.net with comcast id jwmK1e00D3LrwQ23WwmLRz; Mon, 19 Jul 2010 20:46:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5A2A69B425; Mon, 19 Jul 2010 13:46:18 -0700 (PDT) Date: Mon, 19 Jul 2010 13:46:18 -0700 From: Jeremy Chadwick To: John Hay Message-ID: <20100719204618.GA21752@icarus.home.lan> References: <20100719202541.GA42777@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719202541.GA42777@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: packet loss on ixgbe using vlans and ipv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:46:21 -0000 On Mon, Jul 19, 2010 at 10:25:42PM +0200, John Hay wrote: > I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel > 82599 cards). It is running FreeBSD RELENG_8 last updated on July 13. > > What I see is packet loss (0 - 40%) on IPv6 packets in vlans, when the > machine is not the originator of the packets. > > Let me try to describe a little more. If a neigbouring machine ping6 it, > there will be packet loss. If it act as a router for ipv6, there will be > packet loss. This happen even when the network is pretty idle and with > different switches (Nortel and Cisco equipment). The packet loss is > very fluctuating. Pinging 1000 packets might loose 1% one time and the > next time 30%. Looking with tcpdump, I can see the packets arriving and > going out, but the packet never arrive at the next machine. (My feeling is > that they get lost inside the card.) The error counters on the switch > does not increment. > > I do not see packet loss if the machine originate the packets, for example > ping6 from the machine. Also ipv4 packets do not have any packets loss. If > I do not use vlans, I don't see packet loss with ipv6 either. > > pciconf -l of the ethernet cards: > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 Can you provide pciconf -lvc output for the ix[0-3] cards instead? I believe Jack Vogel will need this. vmstat -i might also be helpful (full output). Thanks! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 15:56:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B17221065679 for ; Mon, 19 Jul 2010 15:56:01 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 73F5F8FC13 for ; Mon, 19 Jul 2010 15:56:00 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o6JFtxKR030635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 11:55:59 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o6JFtxsT021007; Mon, 19 Jul 2010 11:55:59 -0400 Message-ID: <4C44758F.7080209@aldan.algebra.com> Date: Mon, 19 Jul 2010 11:55:59 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C43F35D.5020007@aldan.algebra.com> <20100719113147.GA4786@icarus.home.lan> In-Reply-To: <20100719113147.GA4786@icarus.home.lan> X-Mailman-Approved-At: Mon, 19 Jul 2010 21:15:38 +0000 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:56:01 -0000 19.07.2010 07:31, Jeremy Chadwick ÎÁÐÉÓÁ×(ÌÁ): > If you boot the machine in single-user, and run fsck manually, are there > any errors? > Thanks, Jeremy... I wish, there was a way to learn, /which/ file-system is giving trouble... However, after sending the question out last night, I tried to pkg_delete a package on the machine, and was very lucky to see a file-system error (inode something or other) before the panic struck. That, at least, told me, which file-system was in trouble (/var). I dump-ed it out, re-created, and then restored it... Although dumping went smooth, there were two errors at which restore offered to abort. I told it not to and got (most of the) file-system restored. (The dump is available to anyone wishing to investigate -- contact me privately. I'm not posting it publicly because of the passwd-file backup under /var). So far seems quiet -- no panics for two more hours before I went to bed. > Only thing I can think of off the top of my head: there's a known > situation (also applies to RELENG_7) where a background fsck doesn't > correct all errors after a system crash/unclean shutdown. I mention > this because I see "softdep" in the above stack trace (usually refers to > softupdates). I don't know if this got fixed, but the workaround is to > use background_fsck="no" in rc.conf. Yes, after a crash this means you > have to wait for the entire fsck to run. > When setting up my main machine 4 years ago, I turned off background fsck... But I thought, things have improved sufficiently enough since then :-( Maybe, background fsck should still be disabled by default? And, IMO, at the very least, *any panic related to a file-system must clearly identify the file-system in question*... What do you think? Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 21:25:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDF31065670 for ; Mon, 19 Jul 2010 21:25:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B61C48FC12 for ; Mon, 19 Jul 2010 21:25:06 +0000 (UTC) Received: (qmail 3482 invoked by uid 399); 19 Jul 2010 21:25:05 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jul 2010 21:25:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Mon, 19 Jul 2010 14:25:02 -0700 (PDT) From: Doug Barton To: "Brian A. Seklecki" In-Reply-To: <1279552398.31311.443.camel@soundwave> Message-ID: References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> <4C3F49E8.9090201@comcast.net> <1279552398.31311.443.camel@soundwave> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Steve Polyack , Harald Schmalzbauer , Michael Tuexen , Jack Vogel , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 21:25:07 -0000 On Mon, 19 Jul 2010, Brian A. Seklecki wrote: > On Thu, 2010-07-15 at 10:53 -0700, Jack Vogel wrote: >> The fact that I WISH it to be MFC'd doesn't mean that I am actually >> given permission to do so. > > It seems 8.1 release was tagged on Saturday so we're proper-f***** I can appreciate your frustration, but we don't use that kind of language on the freebsd lists. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 22:04:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698311065674 for ; Mon, 19 Jul 2010 22:04:13 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6728FC16 for ; Mon, 19 Jul 2010 22:04:12 +0000 (UTC) Received: by iwn35 with SMTP id 35so6366766iwn.13 for ; Mon, 19 Jul 2010 15:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jspWGSe7JkncMATLGmJDHbvMOalqNU5VowGR9PmVObE=; b=HiDE+f+hNQP6lO22J6XJXCV2PaLmvnw1LWV5CVYiozkuAFqhT9RD3ijK9inEOx7Hgs ze05kTL8vSM4S9VUzYyzAzbxvOtIZWs1BPVR9cq+HqjeZZtgH3EIQ04VpyQ8WQSg4cPq ql15eKrAasy8h0vLKA9f9rVPUS5uJj3c18EuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c6Q7pWVWDM3ll7b0TSXwrFVlVdBc2MQB/Etl2KsojciDy9YiwdC2bKUnVjmPcuwfyc NSccCZCSBvnpwJXVJdrC9PYnFH47VS9qxJyBddngsXdBjtdGyW+NGd2poapXFECTq0DF vDQTXGcf6JLXKeHOh44Mgf2pqmtoPskCrsllk= MIME-Version: 1.0 Received: by 10.231.14.194 with SMTP id h2mr6124764iba.67.1279577052316; Mon, 19 Jul 2010 15:04:12 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 15:04:12 -0700 (PDT) In-Reply-To: <4C44B104.2050000@libeljournal.com> References: <4C44B104.2050000@libeljournal.com> Date: Mon, 19 Jul 2010 18:04:12 -0400 Message-ID: From: Garrett Moore To: John Hawkes-Reed Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 22:04:13 -0000 Well, hotswapping worked, but now I have a totally different problem. Just for reference: # zpool offline tank da3 # camcontrol stop da3 # camcontrol rescan all <'da3 lost device, removing device entry'> # camcontrol rescan all <'da3 at mpt0 ...', so new drive was found! yay> # zpool replace tank da3 *cannot replace da3 with da3: device is too small* So I looked at the smartctl output for the old and new drive. Old: Device Model: WDC WD15EADS-00P8B0 Serial Number: WD-WMAVU0087717 Firmware Version: 01.00A01 User Capacity: 1,500,301,910,016 bytes New: Device Model: WDC WD15EADS-00R6B0 Serial Number: WD-WCAVY4770428 Firmware Version: 01.00A01 User Capacity: 1,500,300,828,160 bytes God damnit, Western Digital. What can I do now? It's such a small difference, is there a way I can work around this? My other replacement drive is the "00R6B0" drive model as well, with the slightly smaller capacity. On Mon, Jul 19, 2010 at 4:09 PM, John Hawkes-Reed wrote: > On 19/07/2010 17:52, Garrett Moore wrote: > >> I'm nervous to trust the hotswap features and camcontrol to set things up >> properly, but I guess I could try it. When I first set the system up >> before >> I put data on the array I tried the hotswap functionality and drives >> wouldn't always re-attach when reinserted, even if I fiddled with >> camcontrol, but I can't remember exactly what I did then. >> > > We've a pair of medium-sized ZFS boxes with Supermicro boards (X8DTi, IIRC) > in hotswap chassis. They've both got one hot-spare drive. Well, I say 'hot > spare'. I mean 'Ought to be a hot-spare if my shoddy Perl works when > triggered by devd'. What we've found to work is this: > > Drive fails (thus far simulated by pulling the drive from the backplane) > ZFS error reported. Pool in degraded state. > 'zpool replace pool da9 da23' (Where da23 is the hot spare and where this > *should* happen automagically.) > Wait for resilvering. > Go on and swap the failed drive (da9 in this case) > 'camcontrol rescan all' (new drive shows up in /var/log/messages) > 'zpool replace da9' > Wait while resilvering happens. > Hot-swap drive returns to 'avail' status. > > [ ... ] > > > -- > JH-R > > _______________________________________________ > 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 19 22:18:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D35A6106564A for ; Mon, 19 Jul 2010 22:18:43 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9652C8FC22 for ; Mon, 19 Jul 2010 22:18:43 +0000 (UTC) Received: by iwn35 with SMTP id 35so6385258iwn.13 for ; Mon, 19 Jul 2010 15:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=za+8W5S0V5fx/tSPQHcrBY9n1wKnxDglwWfBb/MPGu8=; b=YVTH0/WT8vv0B5AQ3EUiGaZ2Wadh0zZouUOQ9oB6UCjKgPrZ9ix6vlTW7kStUOL4OV X7+ZprHNeT0FvRCUIwShH4Dlnkz+Vhf0xIR8LuAy8BYjy/iFYpFYF5bVY/1Bp8MuHj4m kAJllqelwxrmaGvpVRnYwx5gBEX6ohlV/3/4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=u/qaofwGaEpj351RemjrUHzaSy3OxG2OiRkyTmQuBh3UCfy0jm1JFKOpWf7XIHKkjq 3no9jLDXEixwCHHFuXMyJe3N3pvr4YzdRBroiGHse0r7JC4Lt4IkvplJHED0asm9TDFs jMIK5wggshCZaSfcMeJ9r/YjT/jUkxOc3mEd0= MIME-Version: 1.0 Received: by 10.231.60.7 with SMTP id n7mr6396892ibh.60.1279577921685; Mon, 19 Jul 2010 15:18:41 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Mon, 19 Jul 2010 15:18:41 -0700 (PDT) In-Reply-To: References: <4C44B104.2050000@libeljournal.com> Date: Mon, 19 Jul 2010 15:18:41 -0700 Message-ID: From: Freddie Cash To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 22:18:43 -0000 On Mon, Jul 19, 2010 at 3:04 PM, Garrett Moore wro= te: > Well, hotswapping worked, but now I have a totally different problem. Jus= t Yay. :) > for reference: > # zpool offline tank da3 > # camcontrol stop da3 > > # camcontrol rescan all > <'da3 lost device, removing device entry'> > # camcontrol rescan all > <'da3 at mpt0 ...', so new drive was found! yay> > # zpool replace tank da3 > *cannot replace da3 with da3: device is too small* > > So I looked at the smartctl output for the old and new drive. Old: > Device Model: =C2=A0 =C2=A0 WDC WD15EADS-00P8B0 > Serial Number: =C2=A0 =C2=A0WD-WMAVU0087717 > Firmware Version: 01.00A01 > User Capacity: =C2=A0 =C2=A01,500,301,910,016 bytes > > New: > Device Model: =C2=A0 =C2=A0 WDC WD15EADS-00R6B0 > Serial Number: =C2=A0 =C2=A0WD-WCAVY4770428 > Firmware Version: 01.00A01 > User Capacity: =C2=A0 =C2=A01,500,300,828,160 bytes > > God damnit, Western Digital. What can I do now? It's such a small > difference, is there a way I can work around this? My other replacement > drive is the "00R6B0" drive model as well, with the slightly smaller > capacity. Crap! There's a version of ZFS that works around this (or maybe a version of OSol?), although I don't recall the version off-hand, and I can't find it in the list of versions on the OSol website. You may be stuck until you get a drive with more sectors. :( --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 22:22:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB6E4106566C for ; Mon, 19 Jul 2010 22:22:11 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 897718FC0A for ; Mon, 19 Jul 2010 22:22:11 +0000 (UTC) Received: by vws19 with SMTP id 19so6481762vws.13 for ; Mon, 19 Jul 2010 15:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4oMN3/q4hPJGuPrI8nzuL0m39MluhQ4GnKtnlex4WRo=; b=KZ2lPg8UnFkE9MXwEc6MlemKm4dJLEQEOSH5GZu4nOaQQRd04EO1W7GLTVcOzpCgJs ZfBWuybj9SyDShtlUn+Lv+nTdFYjcAwoi9kCjyWMLEINnhGghyb/9qxirFMJBhZum1mF sEo8ahjsK93zieRjDYh3Q8JuOav54hEYqnY9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fRRlmm3Ybhom1caI9fyVjioiddr6wIqP/PrAn7Ve1guUSB7wC7PgcvTEajKiTLbGU6 NaaCtz2rxU85OKL6DOA/D7+XkN72v0ocUe49RmOF6FJyNOKV7fCFcy/eFVopXuYsz2ff d5TiOfUT2pXcfoZNPL38/orklPQ7Gb3Gj0Rjw= MIME-Version: 1.0 Received: by 10.224.97.14 with SMTP id j14mr4488026qan.374.1279578130607; Mon, 19 Jul 2010 15:22:10 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Mon, 19 Jul 2010 15:22:10 -0700 (PDT) In-Reply-To: References: <4C44B104.2050000@libeljournal.com> Date: Mon, 19 Jul 2010 17:22:10 -0500 Message-ID: From: Adam Vande More To: Garrett Moore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , John Hawkes-Reed Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 22:22:11 -0000 On Mon, Jul 19, 2010 at 5:04 PM, Garrett Moore wrote: > Well, hotswapping worked, but now I have a totally different problem. Just > for reference: > # zpool offline tank da3 > # camcontrol stop da3 > > # camcontrol rescan all > <'da3 lost device, removing device entry'> > # camcontrol rescan all > <'da3 at mpt0 ...', so new drive was found! yay> > # zpool replace tank da3 > *cannot replace da3 with da3: device is too small* > > So I looked at the smartctl output for the old and new drive. Old: > Device Model: WDC WD15EADS-00P8B0 > Serial Number: WD-WMAVU0087717 > Firmware Version: 01.00A01 > User Capacity: 1,500,301,910,016 bytes > > New: > Device Model: WDC WD15EADS-00R6B0 > Serial Number: WD-WCAVY4770428 > Firmware Version: 01.00A01 > User Capacity: 1,500,300,828,160 bytes > > God damnit, Western Digital. What can I do now? It's such a small > difference, is there a way I can work around this? Uff da, I'm pretty sure the answer is no, you would have had to use the smallest device first when creating the pool I think. > My other replacement > drive is the "00R6B0" drive model as well, with the slightly smaller > capacity. > -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Jul 19 22:28:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6422106564A for ; Mon, 19 Jul 2010 22:28:58 +0000 (UTC) (envelope-from garrettmoore@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 83FFC8FC16 for ; Mon, 19 Jul 2010 22:28:58 +0000 (UTC) Received: by iwn35 with SMTP id 35so6398659iwn.13 for ; Mon, 19 Jul 2010 15:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Ba57ewnje8TzsReIDYa5YDqk+zdBhudGl9w61u7dUwg=; b=OnQKnXed9t5ydwtZauzwDxqJqFCvGd5F2HqWNzBfx+ZPUOnbQgynEOJD9WzIaNqmDo Pin82N/SLLOJ0b6k32KtVHN7QA10TqEauDx4TtioQ8JDA9Lf3LSoceGcOSndGE1DlQyg rSQ8o1FM8/9Fov5848dk8PBcZ0W/XL4Mxz5fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d0N2yELpPGvOd8Avlt5q0TEDv2LZOq8lyLpHSU68sJdF5fg6OTQ4fuQRzg4prHhNsh xe3qC+LwSMycR04unM+G76/D2ztLcGUV7/E/PlQ+HoT4n1rHlNS+PC9qMFfTsjYqpius rSiHdOmuH2eP4BG9C360q8xH3mY2K1qIQm3s0= MIME-Version: 1.0 Received: by 10.231.14.194 with SMTP id h2mr6153503iba.67.1279578496593; Mon, 19 Jul 2010 15:28:16 -0700 (PDT) Received: by 10.231.117.72 with HTTP; Mon, 19 Jul 2010 15:28:16 -0700 (PDT) In-Reply-To: References: <4C44B104.2050000@libeljournal.com> Date: Mon, 19 Jul 2010 18:28:16 -0400 Message-ID: From: Garrett Moore To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , John Hawkes-Reed Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 22:28:58 -0000 Well thank you very much Western Digital for your absolutely pathetic RMA service sending me an inferior drive. I'll call tomorrow and see what can be done; I'm going to insist on these 00R6B0 drives being sent back, and being given a drive of >= 1,500,301,910,016 bytes capacity. At least now I learned how to hotswap :/ On Mon, Jul 19, 2010 at 6:22 PM, Adam Vande More wrote: > > > On Mon, Jul 19, 2010 at 5:04 PM, Garrett Moore wrote: > >> Well, hotswapping worked, but now I have a totally different problem. Just >> for reference: >> # zpool offline tank da3 >> # camcontrol stop da3 >> >> # camcontrol rescan all >> <'da3 lost device, removing device entry'> >> # camcontrol rescan all >> <'da3 at mpt0 ...', so new drive was found! yay> >> # zpool replace tank da3 >> *cannot replace da3 with da3: device is too small* >> >> So I looked at the smartctl output for the old and new drive. Old: >> Device Model: WDC WD15EADS-00P8B0 >> Serial Number: WD-WMAVU0087717 >> Firmware Version: 01.00A01 >> User Capacity: 1,500,301,910,016 bytes >> >> New: >> Device Model: WDC WD15EADS-00R6B0 >> Serial Number: WD-WCAVY4770428 >> Firmware Version: 01.00A01 >> User Capacity: 1,500,300,828,160 bytes >> >> God damnit, Western Digital. What can I do now? It's such a small >> difference, is there a way I can work around this? > > > Uff da, I'm pretty sure the answer is no, you would have had to use the > smallest device first when creating the pool I think. > > >> My other replacement >> drive is the "00R6B0" drive model as well, with the slightly smaller >> capacity. >> > > > > -- > Adam Vande More > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 01:25:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB3E71065675 for ; Tue, 20 Jul 2010 01:25:44 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing03.lava.net (outgoing03.lava.net [IPv6:2001:1888:0:1:202:b3ff:fe1d:6b98]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3428FC1A for ; Tue, 20 Jul 2010 01:25:44 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTP id A20091019C; Mon, 19 Jul 2010 15:25:43 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 44FD4196E48; Mon, 19 Jul 2010 15:25:43 -1000 (HST) Date: Mon, 19 Jul 2010 15:25:43 -1000 From: Clifton Royston To: Garrett Moore Message-ID: <20100720012542.GA25848@lava.net> Mail-Followup-To: Garrett Moore , freebsd-stable References: <4C44B104.2050000@libeljournal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 01:25:44 -0000 On Mon, Jul 19, 2010 at 06:28:16PM -0400, Garrett Moore wrote: > Well thank you very much Western Digital for your absolutely pathetic RMA > service sending me an inferior drive. I'll call tomorrow and see what can be > done; I'm going to insist on these 00R6B0 drives being sent back, and being > given a drive of >= 1,500,301,910,016 bytes capacity. > > At least now I learned how to hotswap :/ This is the wrong time to find it out, I know, but: For geom mirror purposes I have taken to carving out HD partitions which are exactly a round number of GiB, and at least 100 MiB less than the claimed capacity. I then label the partitions using geom label, and use the partition label specification in setting up the mirror. The first means that when an unannounced change in drive capacity like this happens, I can still add the smaller drive into a RAID set of larger drives painlessly, because the partition sizes will still match exactly. (It also means that if I can only find a larger drive, e.g. if 1TB drives later drop off the market or are more expensive than larger drives, I can easily add a larger drive into the set by making its partition size match the rest.) The second means that if the BIOS/probing sequence does its little dance and the drives end up getting renumbered, it does not affect which drive is which part of what mirror in the slightest. The space sacrificed is trivial compared to the convenience and safety net. I think I got both those suggestions on this list, and I would hope (assume?) that they have equivalents under ZFS. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 02:03:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7960B1065675 for ; Tue, 20 Jul 2010 02:03:43 +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 E70278FC0C for ; Tue, 20 Jul 2010 02:03:42 +0000 (UTC) Received: from [10.0.2.77] (ppp121-45-157-223.lns6.adl6.internode.on.net [121.45.157.223]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6K23XQn010181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Jul 2010 11:33:39 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20100720012542.GA25848@lava.net> Date: Tue, 20 Jul 2010 11:33:31 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <007ECC64-0B03-4B4E-BBA4-80ED5297B2E4@gsoft.com.au> References: <4C44B104.2050000@libeljournal.com> <20100720012542.GA25848@lava.net> To: Clifton Royston X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable , Garrett Moore Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 02:03:43 -0000 On 20/07/2010, at 10:55, Clifton Royston wrote: > The space sacrificed is trivial compared to the convenience and safety > net. >=20 > I think I got both those suggestions on this list, and I would hope > (assume?) that they have equivalents under ZFS.=20 I partitioned my ZFS disks using GPT so I could reference them using GPT = UUIDs. I also put 4Gb partitions on each one which I glued together using = gmirror and used it for swap. I learnt this from many tales of woe :) -- 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 20 02:07:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92A73106564A for ; Tue, 20 Jul 2010 02:07:32 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 640E38FC18 for ; Tue, 20 Jul 2010 02:07:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C0B6450B99; Tue, 20 Jul 2010 03:07:31 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PV8QalXR6U6; Tue, 20 Jul 2010 03:07:31 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id EE3D550B97 ; Tue, 20 Jul 2010 03:07:30 +0100 (BST) Message-ID: <4C4504DF.30602@langille.org> Date: Mon, 19 Jul 2010 22:07:27 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Freddie Cash References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 02:07:32 -0000 On 7/19/2010 12:15 PM, Freddie Cash wrote: > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore wrote: >> So you think it's because when I switch from the old disk to the new disk, >> ZFS doesn't realize the disk has changed, and thinks the data is just >> corrupt now? Even if that happens, shouldn't the pool still be available, >> since it's RAIDZ1 and only one disk has gone away? > > I think it's because you pull the old drive, boot with the new drive, > the controller re-numbers all the devices (ie da3 is now da2, da2 is > now da1, da1 is now da0, da0 is now da6, etc), and ZFS thinks that all > the drives have changed, thus corrupting the pool. I've had this > happen on our storage servers a couple of times before I started using > glabel(8) on all our drives (dead drive on RAID controller, remove > drive, reboot for whatever reason, all device nodes are renumbered, > everything goes kablooey). Can you explain a bit about how you use glabel(8) in conjunction with ZFS? If I can retrofit this into an exist ZFS array to make things easier in the future... 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 ]# zpool status pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad16 ONLINE 0 0 0 > Of course, always have good backups. ;) In my case, this ZFS array is the backup. ;) But I'm setting up a tape library, real soon now.... -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 02:50:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9214106564A for ; Tue, 20 Jul 2010 02:50:06 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4E28FC0C for ; Tue, 20 Jul 2010 02:50:06 +0000 (UTC) Received: by qwg5 with SMTP id 5so2447829qwg.13 for ; Mon, 19 Jul 2010 19:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=e0HaW7DFuQheM1CG4BaqQ7Cwb55W8CtVlj6EEwaeA64=; b=F+WU4DEuZSZ8fuqUv/KlI/eJ/6foQcQB4vjmV68dtsOHRB7Yh1Xyww2axcVblPP/pc I3JzGmy6rvoWF75tx39F5kDAbLMo4p2belKLYy8Iq6OjE9/5gPu/aVZqk3U4HDJ/3dtS XhAqLA6OC+aG16G1G9e29aK9EiEjImjT33LwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fIBu7e+Kmm5klMOqQQe/nkYeR4J95FZIrfGhd4QiWJrB5ZfH39WKlesUKRWgpPrVdY unqQtzWfvdj1SoeteUmgPKLZ4ublEq4ZW/mcFJAuG/Q5ECGqTRE/YPU6oaefrdfOudCJ B6SIuRZ6fXVYp3N4VM6hXY3Za2KHSE2TCGc+0= MIME-Version: 1.0 Received: by 10.224.3.10 with SMTP id 10mr5265540qal.145.1279594203822; Mon, 19 Jul 2010 19:50:03 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Mon, 19 Jul 2010 19:50:03 -0700 (PDT) In-Reply-To: <4C4504DF.30602@langille.org> References: <4C4504DF.30602@langille.org> Date: Mon, 19 Jul 2010 21:50:03 -0500 Message-ID: From: Adam Vande More To: Dan Langille Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 02:50:06 -0000 On Mon, Jul 19, 2010 at 9:07 PM, Dan Langille wrote: > I think it's because you pull the old drive, boot with the new drive, >> the controller re-numbers all the devices (ie da3 is now da2, da2 is >> now da1, da1 is now da0, da0 is now da6, etc), and ZFS thinks that all >> the drives have changed, thus corrupting the pool. I've had this >> happen on our storage servers a couple of times before I started using >> glabel(8) on all our drives (dead drive on RAID controller, remove >> drive, reboot for whatever reason, all device nodes are renumbered, >> everything goes kablooey). >> > > > Can you explain a bit about how you use glabel(8) in conjunction with ZFS? > If I can retrofit this into an exist ZFS array to make things easier in the > future... > If you've used whole disks in ZFS, you can't retrofit it if by retrofit you mean an almost painless method of resolving this. GEOM setup stuff generally should happen BEFORE the file system is on it. You would create your partition(s) slightly smaller than the disk, label it, then use the resulting device as your zfs device when creating the pool. If you have an existing full disk install, that means restoring the data after you've done those steps. It works just as well with MBR style partitioning, there's nothing saying you have to use GPT. GPT is just better though in terms of ease of use IMO among other things. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 04:21:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E283F106564A for ; Tue, 20 Jul 2010 04:21:14 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id B4DEB8FC15 for ; Tue, 20 Jul 2010 04:21:12 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 083D939824; Tue, 20 Jul 2010 06:20:40 +0200 (SAST) Date: Tue, 20 Jul 2010 06:20:39 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20100720042039.GA79254@zibbi.meraka.csir.co.za> References: <20100719202541.GA42777@zibbi.meraka.csir.co.za> <20100719204618.GA21752@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719204618.GA21752@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Subject: Re: packet loss on ixgbe using vlans and ipv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 04:21:15 -0000 On Mon, Jul 19, 2010 at 01:46:18PM -0700, Jeremy Chadwick wrote: > On Mon, Jul 19, 2010 at 10:25:42PM +0200, John Hay wrote: > > I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel > > 82599 cards). It is running FreeBSD RELENG_8 last updated on July 13. > > > > What I see is packet loss (0 - 40%) on IPv6 packets in vlans, when the > > machine is not the originator of the packets. > > > > Let me try to describe a little more. If a neigbouring machine ping6 it, > > there will be packet loss. If it act as a router for ipv6, there will be > > packet loss. This happen even when the network is pretty idle and with > > different switches (Nortel and Cisco equipment). The packet loss is > > very fluctuating. Pinging 1000 packets might loose 1% one time and the > > next time 30%. Looking with tcpdump, I can see the packets arriving and > > going out, but the packet never arrive at the next machine. (My feeling is > > that they get lost inside the card.) The error counters on the switch > > does not increment. > > > > I do not see packet loss if the machine originate the packets, for example > > ping6 from the machine. Also ipv4 packets do not have any packets loss. If > > I do not use vlans, I don't see packet loss with ipv6 either. > > > > pciconf -l of the ethernet cards: > > > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > Can you provide pciconf -lvc output for the ix[0-3] cards instead? I > believe Jack Vogel will need this. vmstat -i might also be helpful > (full output). Ok, here is it and also a netstat -m thrown in. The numbers are pretty low because I rebooted after compiling a kernel with IPFIREWALL, ROUTETABLES, MROUTING and FLOWTABLE removed. I'll add my kernel config file with empty and commented out lines removed. After rebooting, I first tested with vlans (that is in my rc.conf) and then tested with the vlans unconfigured on ix2. ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) output of vmstat -i interrupt total rate irq19: ehci0 28371 0 irq21: uhci2 uhci4+ 48 0 irq23: atapci0 46 0 irq34: mpt0 146954 2 cpu0: timer 112205297 1999 irq256: bce0 52063 0 irq257: bce1 1 0 irq258: bce2 1 0 irq259: bce3 1 0 irq260: ix0:que 0 142258 2 irq261: ix0:que 1 56464 1 irq262: ix0:que 2 56199 1 irq263: ix0:que 3 56198 1 irq264: ix0:que 4 66569 1 irq265: ix0:que 5 56148 1 irq266: ix0:que 6 56217 1 irq267: ix0:que 7 56311 1 irq268: ix0:que 8 56169 1 irq269: ix0:que 9 69485 1 irq270: ix0:que 10 56176 1 irq271: ix0:que 11 56205 1 irq272: ix0:que 12 56281 1 irq273: ix0:que 13 56359 1 irq274: ix0:que 14 56292 1 irq275: ix0:que 15 56197 1 irq276: ix0:link 2 0 irq277: ix1:que 0 107873 1 irq278: ix1:que 1 56094 0 irq279: ix1:que 2 56097 0 irq280: ix1:que 3 56096 0 irq281: ix1:que 4 65439 1 irq282: ix1:que 5 56091 0 irq283: ix1:que 6 56092 0 irq284: ix1:que 7 56098 0 irq285: ix1:que 8 56091 0 irq286: ix1:que 9 56096 0 irq287: ix1:que 10 56093 0 irq288: ix1:que 11 56091 0 irq289: ix1:que 12 56096 0 irq290: ix1:que 13 56095 0 irq291: ix1:que 14 57125 1 irq292: ix1:que 15 56093 0 irq293: ix1:link 1 0 irq294: ix2:que 0 231250 4 irq295: ix2:que 1 57784 1 irq296: ix2:que 2 69956 1 irq297: ix2:que 3 59498 1 irq298: ix2:que 4 58201 1 irq299: ix2:que 5 58599 1 irq300: ix2:que 6 57813 1 irq301: ix2:que 7 60075 1 irq302: ix2:que 8 68639 1 irq303: ix2:que 9 58194 1 irq304: ix2:que 10 60752 1 irq305: ix2:que 11 57628 1 irq306: ix2:que 12 66796 1 irq307: ix2:que 13 63307 1 irq308: ix2:que 14 60788 1 irq309: ix2:que 15 59102 1 irq310: ix2:link 5 0 irq311: ix3:que 0 56090 0 irq312: ix3:que 1 56090 0 irq313: ix3:que 2 56090 0 irq314: ix3:que 3 56090 0 irq315: ix3:que 4 56090 0 irq316: ix3:que 5 56090 0 irq317: ix3:que 6 56090 0 irq318: ix3:que 7 56090 0 irq319: ix3:que 8 56090 0 irq320: ix3:que 9 56090 0 irq321: ix3:que 10 56090 0 irq322: ix3:que 11 56090 0 irq323: ix3:que 12 56090 0 irq324: ix3:que 13 56090 0 irq325: ix3:que 14 56090 0 irq326: ix3:que 15 56090 0 cpu1: timer 112196134 1999 cpu10: timer 112196179 1999 cpu3: timer 112196135 1999 cpu8: timer 112196108 1999 cpu4: timer 112196161 1999 cpu11: timer 112196179 1999 cpu5: timer 112196161 1999 cpu13: timer 112196179 1999 cpu6: timer 112196161 1999 cpu14: timer 112196179 1999 cpu2: timer 112196106 1999 cpu12: timer 112196179 1999 cpu7: timer 112196161 1999 cpu9: timer 112196155 1999 cpu15: timer 112196179 1999 Total 1799390156 32072 netstat -m 133178/4042/137220 mbufs in use (current/cache/total) 133112/2062/135174/262144 mbuf clusters in use (current/cache/total/max) 133112/2056 mbuf+clusters out of packet secondary zone in use (current/cache) 0/20/20/131072 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) 299518K/5214K/304733K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines kernel config file, basically started with 64 bit and removed the stuff I do not need. cpu HAMMER ident SEEKAT device ipmi makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options INCLUDE_CONFIG_FILE # Include this file in kernel options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device ata device atapicd # ATAPI CDROM drives device mpt # LSI-Logic MPT-Fusion device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct SCSI access) device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device uart # Generic UART driver device loop # Network loopback device random # Entropy device device ether # Ethernet support device pty # BSD-style compatibility pseudo ttys device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse kldstat Id Refs Address Size Name 1 55 0xffffffff80100000 6ea290 kernel 2 1 0xffffffff807eb000 19e088 zfs.ko 3 2 0xffffffff8098a000 3860 opensolaris.ko 4 2 0xffffffff8098e000 20448 krpc.ko 5 1 0xffffffff809af000 21100 geom_mirror.ko 6 1 0xffffffff809d1000 66c0 if_vlan.ko 7 1 0xffffffff809d8000 506c8 if_bce.ko 8 2 0xffffffff80a29000 3ec20 miibus.ko 9 1 0xffffffff80a68000 243e0 if_ixgbe.ko 10 1 0xffffffff80a8d000 1e08 coretemp.ko John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 07:19:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 134861065676 for ; Tue, 20 Jul 2010 07:19:48 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id A2C9D8FC22 for ; Tue, 20 Jul 2010 07:19:47 +0000 (UTC) Received: from [IPv6:2001:7b8:204:3:226:bbff:fe1a:76b5] ([IPv6:2001:7b8:204:3:226:bbff:fe1a:76b5]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.4) with ESMTP id o6K7Jeut095097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Jul 2010 07:19:45 GMT (envelope-from ruben@verweg.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ruben van Staveren In-Reply-To: <4C4264F1.4010708@gothic.net.au> Date: Tue, 20 Jul 2010 09:19:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <337E2BDC-1A76-40E4-868D-8B403742151C@verweg.com> References: <20100717152455.GA61987@ravenloft.kiev.ua> <4C4264F1.4010708@gothic.net.au> To: Sean X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]); Tue, 20 Jul 2010 07:19:45 +0000 (UTC) Cc: freebsd-stable@freebsd.org Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 07:19:48 -0000 Hi, On 18 Jul 2010, at 4:20, Sean wrote: > On 18/07/2010 1:24 AM, Alex Kozlov wrote: >> Hi, stable >>=20 >> After updating my buildbox from 26 April 8-STABLE >> to 8.1-RC2 I constantly getting SIGEPIPE >>=20 >=20 >=20 > [snip] >=20 > I'm getting the same thing; what shell are you using? I changed my = shell on one machine from /bin/tcsh to /usr/local/bin/bash and problem = disappeared. Another occasion where this problem acts up: is marked as broken: does not build** Makefile possibly broken: = mail/moztraybiff: grep: write error: Broken pipe moztraybiff-1.2.4_1 ---> Session ended at: Tue, 20 Jul 2010 09:04:41 +0200 (consumed = 00:03:01)/usr/local/sbin/portupgrade:1473:in `get_pkgname': Makefile = broken (MakefileBrok enError) from /usr/local/sbin/portupgrade:623 from /usr/local/sbin/portupgrade:614:in `each' from /usr/local/sbin/portupgrade:614 from /usr/local/sbin/portupgrade:588:in `catch' from /usr/local/sbin/portupgrade:588 from /usr/local/lib/ruby/1.8/optparse.rb:1310:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1310:in = `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1306:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1306:in = `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1254:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1254:in = `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1248:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order' from /usr/local/sbin/portupgrade:565:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:791:in `initialize' from /usr/local/sbin/portupgrade:229:in `new' from /usr/local/sbin/portupgrade:229:in `main' from /usr/local/sbin/portupgrade:2213 This happens during a "sudo portupgrade -va --batch" my shell is /bin/tcsh too. When I run "exec bash" after sudo -s and then = do the portupgrade the problem doesn't show up.=20 To me, this is a clear breakage and should be considered a show stopper = issue for 8.1-RELEASE. All shells should be equally supported, = especially when they reside in /bin. Is there already an open pr on this = ? Thanks, Ruben =20 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 08:03:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A631106567F for ; Tue, 20 Jul 2010 08:03:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 422ED8FC1F for ; Tue, 20 Jul 2010 08:03:02 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta12.emeryville.ca.mail.comcast.net with comcast id k8061e0010lTkoCAC832Fk; Tue, 20 Jul 2010 08:03:02 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.emeryville.ca.mail.comcast.net with comcast id k8311e00C3LrwQ28Q8329B; Tue, 20 Jul 2010 08:03:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 659049B425; Tue, 20 Jul 2010 01:03:01 -0700 (PDT) Date: Tue, 20 Jul 2010 01:03:01 -0700 From: Jeremy Chadwick To: Ruben van Staveren Message-ID: <20100720080301.GA39019@icarus.home.lan> References: <20100717152455.GA61987@ravenloft.kiev.ua> <4C4264F1.4010708@gothic.net.au> <337E2BDC-1A76-40E4-868D-8B403742151C@verweg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <337E2BDC-1A76-40E4-868D-8B403742151C@verweg.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:03:04 -0000 On Tue, Jul 20, 2010 at 09:19:39AM +0200, Ruben van Staveren wrote: > To me, this is a clear breakage and should be considered a show > stopper issue for 8.1-RELEASE. Too late for that now... ftp://ftp4.freebsd.org/pub/FreeBSD/releases/amd64/ ftp://ftp4.freebsd.org/pub/FreeBSD/releases/i386/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 08:16:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBBE6106566C for ; Tue, 20 Jul 2010 08:16:08 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 68F3F8FC0A for ; Tue, 20 Jul 2010 08:16:08 +0000 (UTC) Received: by yxe42 with SMTP id 42so1501638yxe.13 for ; Tue, 20 Jul 2010 01:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=/RJuHTsPzZk/1OZDFF4KpA4KA94IA9qpphp7BwL8LZQ=; b=VUV/JVfjitkSOChWeVkiWgw5atA7rzo5tJN6gi6nXnvBMafIB5sjM6Jd8ylfi1xXeK OWjhQzZsh+4Q2BNg82VPmfNHDPX5/g0PzqolXaNaqEGvhq3w07qUm8Tnluem9WE728AB z4QQ0Y2zpA8Z0QBh5q9eLYcuxLfCCY2qy9kd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=i5w33/whh4k1nM+gHdcWX2786rh0H8HcUzYPvT42pzPbsTJ1Ir7PCN67XaSXs35d05 bPfZQlUnh8patRps4Nqq5la83gQdkjgzajN4z+MYAqvrELh5AmEE78YQ47ViVWWOpHUj Rtrafp5ksbJUi6zZ5SNmF7vhMcku4OsjAoAT4= Received: by 10.100.112.10 with SMTP id k10mr2413491anc.14.1279613767495; Tue, 20 Jul 2010 01:16:07 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id q7sm39238889anf.26.2010.07.20.01.16.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 01:16:06 -0700 (PDT) Sender: "J. Hellenthal" Date: Tue, 20 Jul 2010 04:15:59 -0400 From: jhell To: Markus Gebert In-Reply-To: Message-ID: References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:16:08 -0000 On Sat, 17 Jul 2010 14:35, Markus Gebert wrote: In Message-Id: > > On 13.07.2010, at 16:02, Markus Gebert wrote: > >> Unfortunately, I have not been able to get anything useful out the svn >> commit logs, which could explain this. Maybe someone else has an idea >> what could have changed between 7 and 8 to break it, and again between >> 8 and CURRENT to magically fix it again. > > I tracked this down further. I couldn't easily downgrade my 8.1 > installation to see when the problem was introduced because the zpool > version used is 14. So I tried to figure out, when the problem was > solved in CURRENT. > > I started with the first possible revision that can boot off my v14 pool > (r201143, Dec 28, zfs v14 commit). With this revision, I was able to > trigger the MCE. > > Then I took some later revision (rev206010, Apr 1, chosen randomly), and > I couldn't reproduce the problem. I started narrowing the revisions down > until I found out, that while on r202386 I'm still able to trigger the > MCE, r202387 seems to solve the problem on CURRENT: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=202387 > > Since John Baldwin mentioned this problem could be timing related, it > seems reasonable, that a clock-related change could be fix it. But this > commit seems to have been MFC'd to 8-STABLE and 8.1 (at least as far as > I can tell) along with some other changes to amd64 specific code. I > thought that maybe these other changes that have been MFC'd could have > reintroduced the problem later on, but so far I could not reproduce the > problem with newer CURRENT revisions. So, I actually nailed this one > done to a single commit on CURRENT, but still cannot tell what the > actual difference is compared to 8-STABLE/8.1. > > Any ideas how to proceed? > Adding to this I remembered some specific commits that caught my attention when they happened. Specifically they were to mca.c (locate mca) on my machine provided the file paths and svn log provided the commit log. When you said April and I seen the log it rang a bell. These may be of interest to you: ------------------------------------------------------------------------ r210079 | jhb | 2010-07-14 17:10:14 -0400 (Wed, 14 Jul 2010) | 13 lines MFC 208507,208556,208621: Add support for corrected machine check interrupts. CMCI is a new local APIC interrupt that fires when a threshold of corrected machine check events is reached. CMCI also includes a count of events when reporting corrected errors in the bank's status register. Note that individual banks may or may not support CMCI. If they do, each bank includes its own threshold register that determines when the interrupt fires. Currently the code uses a very simple strategy where it doubles the threshold on each interrupt until it succeeds in throttling the interrupt to occur only once a minute (this interval can be tuned via sysctl). The threshold is also adjusted on each hourly poll which will lower the threshold once events stop occurring. ------------------------------------------------------------------------ r206183 | alc | 2010-04-05 12:11:42 -0400 (Mon, 05 Apr 2010) | 6 lines MFC r204907, r204913, r205402, r205573, r205573 Implement AMD's recommended workaround for Erratum 383 on Family 10h processors. Enable machine check exceptions by default. ------------------------------------------------------------------------ And a list of mca.c's within the stable/8 src tree: /usr/src/sbin/mca/mca.c /usr/src/sys/amd64/amd64/mca.c /usr/src/sys/dev/aha/aha_mca.c /usr/src/sys/dev/buslogic/bt_mca.c /usr/src/sys/dev/ep/if_ep_mca.c /usr/src/sys/i386/i386/mca.c /usr/src/sys/ia64/ia64/mca.c Regards & Good luck, -- jhell From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 08:38:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F5FC106564A for ; Tue, 20 Jul 2010 08:38:18 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id 28A598FC1F for ; Tue, 20 Jul 2010 08:38:17 +0000 (UTC) Received: from visi.gothic.net.au (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id AD2813DA4A for ; Tue, 20 Jul 2010 18:38:16 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by visi.gothic.net.au (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id C-Kmr6469esh for ; Tue, 20 Jul 2010 18:38:11 +1000 (EST) Received: from sean-macbook.gothic.net.au (sean-macbook.gothic.net.au [10.168.1.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id 76FC33DA3A; Tue, 20 Jul 2010 18:38:11 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Sean In-Reply-To: <337E2BDC-1A76-40E4-868D-8B403742151C@verweg.com> Date: Tue, 20 Jul 2010 18:38:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100717152455.GA61987@ravenloft.kiev.ua> <4C4264F1.4010708@gothic.net.au> <337E2BDC-1A76-40E4-868D-8B403742151C@verweg.com> To: Ruben van Staveren X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:38:18 -0000 On 20/07/2010, at 5:19 PM, Ruben van Staveren wrote: > Hi, >=20 > This happens during a "sudo portupgrade -va --batch" > my shell is /bin/tcsh too. When I run "exec bash" after sudo -s and = then do the portupgrade the problem doesn't show up.=20 >=20 > To me, this is a clear breakage and should be considered a show = stopper issue for 8.1-RELEASE. All shells should be equally supported, = especially when they reside in /bin. Is there already an open pr on this = ? >=20 No PR from me, and not a chance of a fix to 8.1 at this point, unless it = really does cause breakage (not just a message, but actually stops = things); the tag has been laid down and would need to be slid forward. It's likely to be either of two things... a bug in sh, that using tcsh = highlights because of differing signal setup; or a bug in tcsh that a = bug fix in sh highlights. It's a bug that comes and goes in the history = of FreeBSD, at least since early 2006 (based on 10 seconds with Google - = http://www.linuxquestions.org/questions/*bsd-17/broken-pipe-432167/) > Thanks, > Ruben =20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 08:41:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 815DC1065673 for ; Tue, 20 Jul 2010 08:41:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C54138FC12 for ; Tue, 20 Jul 2010 08:41:18 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA27184; Tue, 20 Jul 2010 11:41:15 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C45612A.2060502@icyb.net.ua> Date: Tue, 20 Jul 2010 11:41:14 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Garrett Moore References: <4C44B104.2050000@libeljournal.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:41:19 -0000 on 20/07/2010 01:04 Garrett Moore said the following: > Well, hotswapping worked, but now I have a totally different problem. Just > for reference: > # zpool offline tank da3 > # camcontrol stop da3 > > # camcontrol rescan all > <'da3 lost device, removing device entry'> > # camcontrol rescan all > <'da3 at mpt0 ...', so new drive was found! yay> > # zpool replace tank da3 > *cannot replace da3 with da3: device is too small* > > So I looked at the smartctl output for the old and new drive. Old: > Device Model: WDC WD15EADS-00P8B0 > Serial Number: WD-WMAVU0087717 > Firmware Version: 01.00A01 > User Capacity: 1,500,301,910,016 bytes > > New: > Device Model: WDC WD15EADS-00R6B0 > Serial Number: WD-WCAVY4770428 > Firmware Version: 01.00A01 > User Capacity: 1,500,300,828,160 bytes > > God damnit, Western Digital. What can I do now? It's such a small > difference, is there a way I can work around this? My other replacement > drive is the "00R6B0" drive model as well, with the slightly smaller > capacity. I second what others have said - crap. But there could be some hope, not sure. Can you check what is the actual size used by the pool on the disk? It should be somewhere in zdb -C output ("asize"?). If I remember correctly, that actual size should be a multiple of some rather large power of two, so it could be that it is smaller than 'User Capacity' of both old and new drives. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 08:51:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00B81065672 for ; Tue, 20 Jul 2010 08:51:51 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id 89AC48FC15 for ; Tue, 20 Jul 2010 08:51:51 +0000 (UTC) Received: from [IPv6:2001:7b8:204:3:226:bbff:fe1a:76b5] ([IPv6:2001:7b8:204:3:226:bbff:fe1a:76b5]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.4) with ESMTP id o6K8pjvk099950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Jul 2010 08:51:50 GMT (envelope-from ruben@verweg.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Ruben van Staveren In-Reply-To: <20100720080301.GA39019@icarus.home.lan> Date: Tue, 20 Jul 2010 10:51:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C400765-B856-47BD-A088-D20A8AF9EED0@verweg.com> References: <20100717152455.GA61987@ravenloft.kiev.ua> <4C4264F1.4010708@gothic.net.au> <337E2BDC-1A76-40E4-868D-8B403742151C@verweg.com> <20100720080301.GA39019@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]); Tue, 20 Jul 2010 08:51:50 +0000 (UTC) Cc: freebsd-stable@freebsd.org Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:51:52 -0000 On 20 Jul 2010, at 10:03, Jeremy Chadwick wrote: > On Tue, Jul 20, 2010 at 09:19:39AM +0200, Ruben van Staveren wrote: >> To me, this is a clear breakage and should be considered a show >> stopper issue for 8.1-RELEASE. >=20 > Too late for that now=85 Oh well, errata when the culprit is found=85 I've filed this as misc/148781 >=20 > ftp://ftp4.freebsd.org/pub/FreeBSD/releases/amd64/ > ftp://ftp4.freebsd.org/pub/FreeBSD/releases/i386/ Thanks! >=20 > --=20 > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | Regards, Ruben= From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 10:04:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD621065676 for ; Tue, 20 Jul 2010 10:04:22 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (pop3.nitronet.pl [195.90.106.28]) by mx1.freebsd.org (Postfix) with ESMTP id C49938FC19 for ; Tue, 20 Jul 2010 10:04:21 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ob9Qg-000IaW-7H for freebsd-stable@freebsd.org; Tue, 20 Jul 2010 11:48:02 +0200 Date: Tue, 20 Jul 2010 11:47:54 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <426290558.20100720114754@nitronet.pl> To: Andriy Gapon In-Reply-To: <4C45612A.2060502@icyb.net.ua> References: <4C44B104.2050000@libeljournal.com> <4C45612A.2060502@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-stable , Garrett Moore Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 10:04:22 -0000 Hi guys, > I second what others have said - crap. > But there could be some hope, not sure. > Can you check what is the actual size used by the pool on the disk? > It should be somewhere in zdb -C output ("asize"?). > If I remember correctly, that actual size should be a multiple of some ra= ther > large power of two, so it could be that it is smaller than 'User Capacity= ' of both > old and new drives. Well, I see some possibilities for creative solution here, using some ssd (or usb stick or mdconfig as act of desperation) and gconcat, but it's asking for trouble and should probably be considered a temporary hack. What I personally would do is get a 2TB drive and use it instead, with gpt and -l for label, and replace it as gpt/something. Using 100 or so MB less than whole disk is also a good idea, as you can see ;) Cheers and good luck. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 04:40:25 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA851065678 for ; Tue, 20 Jul 2010 04:40:25 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id EF4668FC17 for ; Tue, 20 Jul 2010 04:40:24 +0000 (UTC) Received: from aldan.narawntapu ([unknown] [173.70.194.135]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L5U00BEXAAW3BK2@vms173019.mailsrvcs.net> for stable@FreeBSD.org; Mon, 19 Jul 2010 23:40:13 -0500 (CDT) Message-id: <4C4528A8.5040605@aldan.algebra.com> Date: Tue, 20 Jul 2010 00:40:08 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk; rv:1.9.1.10) Gecko/20100716 Thunderbird/3.0.5 MIME-version: 1.0 To: stable@FreeBSD.org X-Mailman-Approved-At: Tue, 20 Jul 2010 11:05:14 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: today's 8.1/i386: panic: bad pte X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 04:40:25 -0000 Some part of KDE4's kdm crashed at start-up and seems to have taken the entire machine with it: kgdb /boot/kernel/kernel /var/crash/vmcore.22 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <6>pid 18398 (drkonqi), uid 0: exited on signal 11 (core dumped) TPTE at 0xbfca9488 IS ZERO @ VA 2a522000 panic: bad pte Uptime: 2h28m24s Physical memory: 1263 MB Dumping 195 MB: 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/splash_pcx.ko...Reading symbols from /boot/kernel/splash_pcx.ko.symbols...done. done. Loaded symbols for /boot/kernel/splash_pcx.ko Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko #0 doadump () at pcpu.h:231 231 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt full #0 doadump () at pcpu.h:231 No locals. #1 0xc05d10a4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 _giantcnt = Variable "_giantcnt" is not available. (kgdb) where #0 doadump () at pcpu.h:231 #1 0xc05d10a4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05d12b1 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc07f0406 in pmap_remove_pages (pmap=0xc85bbc78) at /usr/src/sys/i386/i386/pmap.c:4198 #4 0xc079516b in vmspace_exit (td=0xc51f3a00) at /usr/src/sys/vm/vm_map.c:409 #5 0xc05a7253 in exit1 (td=0xc51f3a00, rv=139) at /usr/src/sys/kern/kern_exit.c:303 #6 0xc05d3296 in sigexit (td=0xc51f3a00, sig=139) at /usr/src/sys/kern/kern_sig.c:2872 #7 0xc05d47a8 in postsig (sig=11) at /usr/src/sys/kern/kern_sig.c:2759 #8 0xc06082f8 in ast (framep=0xe5fafd38) at /usr/src/sys/kern/subr_trap.c:234 #9 0xc07e2c44 in doreti_ast () at /usr/src/sys/i386/i386/exception.s:368 Does this look familiar to anyone? Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 13:49:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9549D1065675 for ; Tue, 20 Jul 2010 13:49:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1038FC1D for ; Tue, 20 Jul 2010 13:49:33 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta14.emeryville.ca.mail.comcast.net with comcast id kDWt1e0030b6N64AEDpYLe; Tue, 20 Jul 2010 13:49:32 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta03.emeryville.ca.mail.comcast.net with comcast id kDpX1e00A3LrwQ28PDpYX8; Tue, 20 Jul 2010 13:49:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 86DDF9B425; Tue, 20 Jul 2010 06:49:31 -0700 (PDT) Date: Tue, 20 Jul 2010 06:49:31 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100720134931.GA41352@icarus.home.lan> References: <4C43F35D.5020007@aldan.algebra.com> <20100719113147.GA4786@icarus.home.lan> <4C44758F.7080209@aldan.algebra.com> <20100719204124.GA21573@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100719204124.GA21573@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 13:49:33 -0000 On Mon, Jul 19, 2010 at 01:41:24PM -0700, Jeremy Chadwick wrote: > On Mon, Jul 19, 2010 at 11:55:59AM -0400, Mikhail T. wrote: > > 19.07.2010 07:31, Jeremy Chadwick напиÑав(ла): > > >If you boot the machine in single-user, and run fsck manually, are there > > >any errors? > > Thanks, Jeremy... I wish, there was a way to learn, /which/ > > file-system is giving trouble... However, after sending the question > > out last night, I tried to pkg_delete a package on the machine, and > > was very lucky to see a file-system error (inode something or other) > > before the panic struck. That, at least, told me, which file-system > > was in trouble (/var). > > [...] > > And, IMO, at the very least, *any panic related to a file-system > > must clearly identify the file-system in question*... What do you > > think? > > [...] > Assuming work tonight isn't that busy for me, I'll see if I can dedicate > some cycles to printing this information in the error string you saw. I spent some time on this tonight. It's not as simple as it sounds, for me anyway. Relevant source bits: src/sys/ufs/ffs/ffs_softdep.c src/sys/ufs/ffs/fs.h src/sys/ufs/ffs/softdep.h ffs_softdep.c, which is almost 6500 lines, contains a large number of inode-related functions which can call panic(). Functions which have easy access to the related inodedep struct are the ones which would be able to print this information easily. Sort of. struct inodedep (see softdep.h) contains a member called id_fs, which is struct fs (see fs.h). struct fs contains a member called fs_fsmnt (a char buffer), which is the name of the mounted filesystem. fs_fsmnt[0] should be NULL ('\0') if the filesystem isn't mounted. So in the case of your panic within handle_written_inodeblock(), it would be as simple as something like: u_char *mntpt = NULL; if (inodedep->id_fs->fs_fsmnt[0] != '\0') mntpt = &inodedep->id_fs->fs_fsmnt; else /* XXX do what here? */ Then, the panic() statements later have to do something like this (taken from real code): if (dp1->di_db[adp->ad_lbn]!=adp->ad_oldblkno) panic("%s: %s: %s #%jd mismatch %d != %jd", "handle_written_inodeblock", (mntpt ? mntpt) : "", "direct pointer", (intmax_t)adp->ad_lbn, dp1->di_db[adp->ad_lbn], (intmax_t)adp->ad_oldblkno); The panic message would look like one of the following: panic: handle_written_inodeblock: /mnt: direct pointer #nnn mismatch nnn != nnn panic: handle_written_inodeblock: : direct pointer #nnn mismatch nnn != nnn The "" string there is a Bad Idea(tm); see below. Secondly, this brings up the question: what happens if someone is doing something like "fsck /var", where /var uses soft updates? /var isn't mounted when this happens. Can these inode-related functions get called during that time? If so, fs_fsmnt would (in theory -- I haven't tested in practise) be null. So in that case, what should get printed as the filesystem? Well, this is where the "" string comes into play. My first answer was: "the name of the device/slice/etc. which the inode is associated with". The problem is that I couldn't find a way to get this information, as it's not stored in struct fs anywhere. One would have to change the kernel ABI to pass this down the stack, which changes the ABI and is not something I'm willing to do (plus there's performance implications as you're passing something else on the stack per every call). Of course there may be a way to get this easily, but I don't see it or know of it. Thirdly, and this is equally as important: given the repetitive nature of this code (it would have to be repeated in numerous functions), making a common function that populates a (global) variable with the fsname its working on would be ideal. But I don't know the implication of this, nor do I see many (I think two?) global variables used within softdep_ffs.c. Extending one of the structs to get access to the necessary information is not as simple as "just do it" -- there are implications when it comes to memory usage and so on. This is not a piece of code to bang on lightly. This should probably be discussed on freebsd-hackers, but cross-posting across 3 separate mailing lists is rude. If you want to drive this, cool, but please start a new thread about the matter (wanting the filesystem or device printed in panic() when things like filesystem panics happen) on freebsd-hackers. I'm not subscribed to that list, so please CC me if you go this route. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 17:18:40 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEDBB1065670 for ; Tue, 20 Jul 2010 17:18:40 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 638798FC12 for ; Tue, 20 Jul 2010 17:18:39 +0000 (UTC) Received: by gwb19 with SMTP id 19so3022820gwb.13 for ; Tue, 20 Jul 2010 10:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=/tWuNaDaqCu58ZHEuEF+9iSpzEgIqSNYAxapHMyGzMQ=; b=mEmYI9PsP9w481YgIjuLpDGzvyHkK9vVR+MPInlf7LPlmOQHgrcTmMwnIcz66eiuHG 7bMB+LWdYcAR0itvMMB2s0zBTrcDGVtnsvwBAqhcv9B9h9aYnZxQGz4DjKlLFWN+aWNI KzvgddBvTesP1BZquZhLxgJcgKA4hZTAf3cIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=lmWs0iLxZ20HC1lyZKTM/TenTkSvyoMCObbtbbC8Ea0HqthppWNmX1zY0e2HWS2JL0 m2Wmbqg9UwYMELzZ6ZcZ6/YfG86QtB4hae+OkIWdwTG9F/XfAiFgk6OPjG6QQTKmqbW7 NPV52ahoTn4gYS6pbzsypsw6LLoCWhUllbFdo= MIME-Version: 1.0 Received: by 10.224.106.160 with SMTP id x32mr5747296qao.130.1279644475047; Tue, 20 Jul 2010 09:47:55 -0700 (PDT) Received: by 10.229.239.5 with HTTP; Tue, 20 Jul 2010 09:47:54 -0700 (PDT) In-Reply-To: <4C4528A8.5040605@aldan.algebra.com> References: <4C4528A8.5040605@aldan.algebra.com> Date: Tue, 20 Jul 2010 11:47:54 -0500 Message-ID: From: Alan Cox To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: today's 8.1/i386: panic: bad pte X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:18:40 -0000 On Mon, Jul 19, 2010 at 11:40 PM, Mikhail T. > wrote: > Some part of KDE4's kdm crashed at start-up and seems to have taken the > entire machine with it: > > kgdb /boot/kernel/kernel /var/crash/vmcore.22 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > <6>pid 18398 (drkonqi), uid 0: exited on signal 11 (core dumped) > TPTE at 0xbfca9488 IS ZERO @ VA 2a522000 > panic: bad pte > Uptime: 2h28m24s > Physical memory: 1263 MB > Dumping 195 MB: 180 164 148 132 116 100 84 68 52 36 20 4 > > Reading symbols from /boot/kernel/splash_pcx.ko...Reading symbols > from /boot/kernel/splash_pcx.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/splash_pcx.ko > Reading symbols from /boot/kernel/vesa.ko...Reading symbols from > /boot/kernel/vesa.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/vesa.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols > from /boot/kernel/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > #0 doadump () at pcpu.h:231 > 231 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt full > #0 doadump () at pcpu.h:231 > No locals. > #1 0xc05d10a4 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:416 > _giantcnt = Variable "_giantcnt" is not available. > (kgdb) where > #0 doadump () at pcpu.h:231 > #1 0xc05d10a4 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xc05d12b1 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 0xc07f0406 in pmap_remove_pages (pmap=0xc85bbc78) at > /usr/src/sys/i386/i386/pmap.c:4198 > #4 0xc079516b in vmspace_exit (td=0xc51f3a00) at > /usr/src/sys/vm/vm_map.c:409 > #5 0xc05a7253 in exit1 (td=0xc51f3a00, rv=139) at > /usr/src/sys/kern/kern_exit.c:303 > #6 0xc05d3296 in sigexit (td=0xc51f3a00, sig=139) at > /usr/src/sys/kern/kern_sig.c:2872 > #7 0xc05d47a8 in postsig (sig=11) at /usr/src/sys/kern/kern_sig.c:2759 > #8 0xc06082f8 in ast (framep=0xe5fafd38) at > /usr/src/sys/kern/subr_trap.c:234 > #9 0xc07e2c44 in doreti_ast () at > /usr/src/sys/i386/i386/exception.s:368 > > Does this look familiar to anyone? Thanks! > > Historically, this panic has indicated flakey memory. This panic occurs because a memory location within a page table has unexpectedly changed to zero. Alan From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 17:40:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20092106566C for ; Tue, 20 Jul 2010 17:40:17 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id ED7FE8FC14 for ; Tue, 20 Jul 2010 17:40:16 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 88C4C2C2A91; Tue, 20 Jul 2010 12:09:09 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q10-aYBbzbKN; Tue, 20 Jul 2010 12:09:01 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 9EC912C2AEB; Tue, 20 Jul 2010 12:09:01 -0500 (CDT) Message-ID: <4C45D82B.8000600@cs.rice.edu> Date: Tue, 20 Jul 2010 12:08:59 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "Mikhail T." References: <4C4528A8.5040605@aldan.algebra.com> <4C45D3EA.6010208@aldan.algebra.com> In-Reply-To: <4C45D3EA.6010208@aldan.algebra.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: alc@freebsd.org, stable@freebsd.org Subject: Re: today's 8.1/i386: panic: bad pte X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:40:17 -0000 Mikhail T. wrote: > 20.07.2010 12:47, Alan Cox ÎÁÐÉÓÁ×(ÌÁ): >> Historically, this panic has indicated flakey memory. This panic >> occurs because a memory location within a page table has unexpectedly >> changed to zero. > Ouch... Thanks for the hint (maybe, the panic should say something > like that?) > > In any case, is there a way to identify the the flakey DIMM? I did run > memtest on this box and haven't received any errors... Thanks! Yours, No, not from the panic message. If a thorough memtest didn't turn up a problem, then I would start looking for another cause. Alan From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 16:50:51 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8033A106564A; Tue, 20 Jul 2010 16:50:51 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5EB8FC12; Tue, 20 Jul 2010 16:50:51 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o6KGooQE021995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 12:50:50 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o6KGoofY031277; Tue, 20 Jul 2010 12:50:50 -0400 Message-ID: <4C45D3EA.6010208@aldan.algebra.com> Date: Tue, 20 Jul 2010 12:50:50 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: alc@freebsd.org References: <4C4528A8.5040605@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 20 Jul 2010 17:45:17 +0000 Cc: stable@freebsd.org, Alan Cox Subject: Re: today's 8.1/i386: panic: bad pte X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:50:51 -0000 20.07.2010 12:47, Alan Cox ÎÁÐÉÓÁ×(ÌÁ): > Historically, this panic has indicated flakey memory. This panic > occurs because a memory location within a page table has unexpectedly > changed to zero. Ouch... Thanks for the hint (maybe, the panic should say something like that?) In any case, is there a way to identify the the flakey DIMM? I did run memtest on this box and haven't received any errors... Thanks! Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 21:46:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFBAC106564A for ; Tue, 20 Jul 2010 21:46:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8D67F8FC18 for ; Tue, 20 Jul 2010 21:46:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3880446B91; Tue, 20 Jul 2010 17:46:00 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4BC2E8A04E; Tue, 20 Jul 2010 17:45:59 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 20 Jul 2010 15:59:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201559.45081.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Jul 2010 17:45:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Markus Gebert Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:46:00 -0000 On Saturday, July 17, 2010 2:35:21 pm Markus Gebert wrote: > > On 13.07.2010, at 16:02, Markus Gebert wrote: > > > Unfortunately, I have not been able to get anything useful out the svn commit logs, which could explain this. Maybe someone else has an idea what could have changed between 7 and 8 to break it, and again between 8 and CURRENT to magically fix it again. > > I tracked this down further. I couldn't easily downgrade my 8.1 installation to see when the problem was introduced because the zpool version used is 14. So I tried to figure out, when the problem was solved in CURRENT. > > I started with the first possible revision that can boot off my v14 pool (r201143, Dec 28, zfs v14 commit). With this revision, I was able to trigger the MCE. > > Then I took some later revision (rev206010, Apr 1, chosen randomly), and I couldn't reproduce the problem. I started narrowing the revisions down until I found out, that while on r202386 I'm still able to trigger the MCE, r202387 seems to solve the problem on CURRENT: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=202387 Although this change was MFC'd, it was later disabled by default because it causes issues on other machines. I think there is a tunable you need to set in loader.conf to enable it for 8.1. Attilio (the author of that commit) should know which tunable to set. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 22:57:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABF061065674 for ; Tue, 20 Jul 2010 22:57:26 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5418FC14 for ; Tue, 20 Jul 2010 22:57:26 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:39678 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ObLkZ-000I2W-KW; Wed, 21 Jul 2010 00:57:23 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: Date: Wed, 21 Jul 2010 00:57:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> To: freebsd-stable X-Mailer: Apple Mail (2.1081) Cc: jhell Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 22:57:26 -0000 On 20.07.2010, at 10:15, jhell wrote: >> Any ideas how to proceed? >>=20 >=20 > Adding to this I remembered some specific commits that caught my = attention when they happened. Specifically they were to mca.c (locate = mca) on my machine provided the file paths and svn log provided the = commit log. >=20 > When you said April and I seen the log it rang a bell. Thank you for the hint. We've already tried to reproduce with MCA = disabled, and didn't succeed. The thing is, without altering the bios = default settings, the OS doesn't even get an MCE before the system = reboots itself showing those "hypertransport sync flood" and "pci = express fatal error" stuff during POST. So I guess it's safe to say, = that the problem happens before MCA can kick in. Markus= From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 00:57:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6766A106566B; Wed, 21 Jul 2010 00:57:09 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 100638FC1E; Wed, 21 Jul 2010 00:57:08 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:39496 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ObNcR-000LTk-Mi; Wed, 21 Jul 2010 02:57:07 +0200 Mime-Version: 1.0 (Apple Message framework v1081) From: Markus Gebert In-Reply-To: <201007201559.45081.jhb@freebsd.org> Date: Wed, 21 Jul 2010 02:57:07 +0200 Message-Id: <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 00:57:09 -0000 On 20.07.2010, at 21:59, John Baldwin wrote: >> I started narrowing the revisions down until I=20 >> found out, that while on r202386 I'm still able to trigger the MCE, = r202387=20 >> seems to solve the problem on CURRENT: >>=20 >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D202387 >=20 > Although this change was MFC'd, it was later disabled by default = because it=20 > causes issues on other machines. I think there is a tunable you need = to set=20 > in loader.conf to enable it for 8.1. Attilio (the author of that = commit)=20 > should know which tunable to set. Might be this one in sys/amd64/amd64/clock.c: ---- static int lapic_allclocks =3D 1; TUNABLE_INT("machdep.lapic_allclocks", &lapic_allclocks); ---- The r202387 changes put this into local_apic.c, guess it was moved later = on (or after MFC), and that's why I couldn't find it on 8-stable. And, = indeed, this tunable seems to be gone again in current. Testing with = machdep.lapic_allclocks=3D0 right now. So far it looks very promising. = I'll let it run overnight. Another thing though: Today I compared verbose boot output from 8-stable = and the current box. I saw that the ioapic sets up IRQ routing = differently on these two systems although the hardware is the same. This = seemed not so interesting at first, but then I noticed that 8-stable = sets up two routes (to lapic0 and lapic2, or sometimes lapic3) for IRQ58 = (mpt0), while current only uses one route (to lapic0). I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box = behave like the one running current. Indeed, this seems to have changed = IRQ58 to be routed to lapic0 only. And the box was running for hours = without showing the symptoms. I just checked boot verbose outpout of my 8-stable box again (booted = with machdep.lapic_allclocks=3D0 as mentioned above). And now it seems = to have set up IRQ routes just like the current box (one route for IRQ58 = to lapic0). So I don't get which issue came first... If either one is ruled out, the = problem seems to be gone. Was it the clock issue causing wrong IRQ = routing setup which in turn causes mpt or the CPU go nuts? Or is mpt = having two interrupt routes actually a normal thing (then why doesn't = current behave this way?), but the mpt driver causes strange thins when = operating with clock issues? Or have I misinterpreted something? Here's the boot verbose output of ioapic related to interrupts 56 (em0), = 57 (em1) and 58 (mpt0): ---- 1st X4100M2 - running 8-stable (machdep.lapic_allclocks=3D1, MCEs = can be reproduced easily) ---- # egrep '^ioapic' boot.normal | egrep 'IRQ 5[678]' | sort ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 0 vector 55 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 1 vector 50 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 0 vector 56 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 2 vector 50 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 0 vector 57 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 3 vector 50 ---- ---- 1st X4100M2 - running 8-stable (machdep.lapic_allclocks=3D0, test = currently running, no MCEs so far) ---- # egrep '^ioapic' boot.lapic_allclocks0 | egrep 'IRQ 5[678]' | sort ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 0 vector 55 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 2 vector 50 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 0 vector 56 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 3 vector 50 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 0 vector 57 ---- ---- 2nd X4100M2 - running current (MCEs cannot be reproduced) ---- # dmesg | egrep '^ioapic' | egrep 'IRQ 5[678]' | sort ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 0 vector 55 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 2 vector 50 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 0 vector 56 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 3 vector 50 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 0 vector 57 ---- Markus From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 05:57:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAFD61065679 for ; Wed, 21 Jul 2010 05:57:26 +0000 (UTC) (envelope-from alanbryan1234@yahoo.com) Received: from web50502.mail.re2.yahoo.com (web50502.mail.re2.yahoo.com [206.190.38.78]) by mx1.freebsd.org (Postfix) with SMTP id 6AA9D8FC08 for ; Wed, 21 Jul 2010 05:57:26 +0000 (UTC) Received: (qmail 39212 invoked by uid 60001); 21 Jul 2010 05:57:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279691845; bh=25RV+40Ps1uhG/YJwfF127pEps2rJbxy5yLwM5rN/wY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pxqTu9tYP/BtjCMVdstgM4MK7YjGEqCLWORmxdQDWoSjOhOekFhTJaDDvG1gAz1wgIg3VcdRt34tb+TgCOzGkKsyJeW1sstbkb8fHhvuTtxf4768ocTKzV1MaaUzYP0S/qo2ULaqU1GK4mFaOEHiNjbgtfta5rVj9oETyb/Ad9A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sfzt3+5v3LH7nyleIAPaj4f1zyh6ufhghvFaLqnr96QS+aipUN5nMuwvenuDU86iu0ZEHjc+lTP7X1otZramKCwzYUEifIlmQfb5BKSvcHKFqenB/BiJ70bvNmQa94m6HJIATb8mJlm37YzFZMyiHA9JbMunfL67RHAyHqbJ+0I=; Message-ID: <578438.38753.qm@web50502.mail.re2.yahoo.com> X-YMail-OSG: 0pcScCwVM1mJiPPrGvyI.yobcmF49wUYGMeB7nK9thAu5cj seoOIfrCIW6QfCZ3kwoH95za37_5.rj558NdptwIIRY0Ec.XJoFvwNLvHs6B qF4XA7k0itZJagcub9M.RqhE6cmBDU8f66XU6XTFec1kpmnV9jLIC4ZYMV4Y cpOYThaVZi9m6s9PMlrEEX1qXbgt.zlCRvsfoYfydfMjE7H1vj_UX.f8utwF MoW5BJ4azBu5QSWY4ZubsNHA3kToWoblEg9yruDIqGuBVU9_ACZRnTFH8fSj ICACTOlV80MarFmH1ohgbbMLfOSHrIfIC.VGQPROTVh.n3EjnQui0.ecDk5w 7oDbM_b5GcAxBCIImqUnTo62V1aamkAGC Received: from [68.4.245.43] by web50502.mail.re2.yahoo.com via HTTP; Tue, 20 Jul 2010 22:57:25 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.104.276605 Date: Tue, 20 Jul 2010 22:57:25 -0700 (PDT) From: alan bryan To: Freddie Cash , Dan Langille In-Reply-To: <4C4504DF.30602@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 05:57:27 -0000 =0A=0A--- On Mon, 7/19/10, Dan Langille wrote:=0A=0A> Fr= om: Dan Langille =0A> Subject: Re: Problems replacing fai= ling drive in ZFS pool=0A> To: "Freddie Cash" =0A> Cc: "= freebsd-stable" =0A> Date: Monday, July 19, 201= 0, 7:07 PM=0A> On 7/19/2010 12:15 PM, Freddie Cash=0A> wrote:=0A> > On Mon,= Jul 19, 2010 at 8:56 AM, Garrett Moore=A0=0A> wrot= e:=0A> >> So you think it's because when I switch from the=0A> old disk to = the new disk,=0A> >> ZFS doesn't realize the disk has changed, and=0A> thin= ks the data is just=0A> >> corrupt now? Even if that happens, shouldn't the= =0A> pool still be available,=0A> >> since it's RAIDZ1 and only one disk ha= s gone=0A> away?=0A> > =0A> > I think it's because you pull the old drive, = boot with=0A> the new drive,=0A> > the controller re-numbers all the device= s (ie da3 is=0A> now da2, da2 is=0A> > now da1, da1 is now da0, da0 is now = da6, etc), and ZFS=0A> thinks that all=0A> > the drives have changed, thus = corrupting the=0A> pool.=A0 I've had this=0A> > happen on our storage serve= rs a couple of times before=0A> I started using=0A> > glabel(8) on all our = drives (dead drive on RAID=0A> controller, remove=0A> > drive, reboot for w= hatever reason, all device nodes=0A> are renumbered,=0A> > everything goes = kablooey).=0A> =0A> Can you explain a bit about how you use glabel(8) in=0A= > conjunction with ZFS?=A0 If I can retrofit this into an=0A> exist ZFS arr= ay to make things easier in the future...=0A> =0A> 8.0-STABLE #0: Fri Mar= =A0 5 00:46:11 EST 2010=0A> =0A> ]# zpool status=0A> =A0 pool: storage=0A> = state: ONLINE=0A> scrub: none requested=0A> config:=0A> =0A> =A0 =A0 =A0 = =A0 NAME=A0 =A0 =A0 =A0=0A> STATE=A0 =A0=A0=A0READ WRITE CKSUM=0A> =A0 =A0 = =A0 =A0 storage=A0=0A> =A0=A0=A0ONLINE=A0 =A0=0A> =A0=A0=A00=A0 =A0=A0=A00= =A0=0A> =A0=A0=A00=0A> =A0 =A0 =A0 =A0 =A0 raidz1=A0 =A0=0A> ONLINE=A0 =A0 = =A0=A0=A00=A0=0A> =A0=A0=A00=A0 =A0=A0=A00=0A> =A0 =A0 =A0 =A0 =A0 =A0 ad8= =A0=0A> =A0=A0=A0ONLINE=A0 =A0=0A> =A0=A0=A00=A0 =A0=A0=A00=A0=0A> =A0=A0= =A00=0A> =A0 =A0 =A0 =A0 =A0 =A0 ad10=A0 =A0=0A> ONLINE=A0 =A0 =A0=A0=A00= =A0=0A> =A0=A0=A00=A0 =A0=A0=A00=0A> =A0 =A0 =A0 =A0 =A0 =A0 ad12=A0 =A0=0A= > ONLINE=A0 =A0 =A0=A0=A00=A0=0A> =A0=A0=A00=A0 =A0=A0=A00=0A> =A0 =A0 =A0 = =A0 =A0 =A0 ad14=A0 =A0=0A> ONLINE=A0 =A0 =A0=A0=A00=A0=0A> =A0=A0=A00=A0 = =A0=A0=A00=0A> =A0 =A0 =A0 =A0 =A0 =A0 ad16=A0 =A0=0A> ONLINE=A0 =A0 =A0=A0= =A00=A0=0A> =A0=A0=A00=A0 =A0=A0=A00=0A> =0A> > Of course, always have good= backups.=A0 ;)=0A> =0A> In my case, this ZFS array is the backup.=A0 ;)=0A= > =0A> But I'm setting up a tape library, real soon now....=0A> =0A> -- Dan= Langille - http://langille.org/=0A> ______________________________________= _________=0A> freebsd-stable@freebsd.org=0A> mailing list=0A> http://lists.= freebsd.org/mailman/listinfo/freebsd-stable=0A> To unsubscribe, send any ma= il to "freebsd-stable-unsubscribe@freebsd.org"=0A> =0A=0ADan,=0A=0AHere's h= ow to do it after the fact:=0A=0Ahttp://unix.derkeiler.com/Mailing-Lists/Fr= eeBSD/current/2009-07/msg00623.html=0A=0A--Alan Bryan=0A=0A=0A=0A=0A=0A = From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 06:09:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B5331065672 for ; Wed, 21 Jul 2010 06:09:48 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE908FC14 for ; Wed, 21 Jul 2010 06:09:48 +0000 (UTC) Received: by iwn35 with SMTP id 35so8237467iwn.13 for ; Tue, 20 Jul 2010 23:09:47 -0700 (PDT) Received: by 10.231.32.198 with SMTP id e6mr8818269ibd.86.1279692579280; Tue, 20 Jul 2010 23:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.207.19 with HTTP; Tue, 20 Jul 2010 23:09:18 -0700 (PDT) In-Reply-To: <578438.38753.qm@web50502.mail.re2.yahoo.com> References: <4C4504DF.30602@langille.org> <578438.38753.qm@web50502.mail.re2.yahoo.com> From: Joshua Boyd Date: Wed, 21 Jul 2010 02:09:18 -0400 Message-ID: To: alan bryan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , Dan Langille Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:09:48 -0000 On Wed, Jul 21, 2010 at 1:57 AM, alan bryan wrote: > > > --- On Mon, 7/19/10, Dan Langille wrote: > > > From: Dan Langille > > Subject: Re: Problems replacing failing drive in ZFS pool > > To: "Freddie Cash" > > Cc: "freebsd-stable" > > Date: Monday, July 19, 2010, 7:07 PM > > On 7/19/2010 12:15 PM, Freddie Cash > > wrote: > > > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore > > > wrote: > > >> So you think it's because when I switch from the > > old disk to the new disk, > > >> ZFS doesn't realize the disk has changed, and > > thinks the data is just > > >> corrupt now? Even if that happens, shouldn't the > > pool still be available, > > >> since it's RAIDZ1 and only one disk has gone > > away? > > > > > > I think it's because you pull the old drive, boot with > > the new drive, > > > the controller re-numbers all the devices (ie da3 is > > now da2, da2 is > > > now da1, da1 is now da0, da0 is now da6, etc), and ZFS > > thinks that all > > > the drives have changed, thus corrupting the > > pool. I've had this > > > happen on our storage servers a couple of times before > > I started using > > > glabel(8) on all our drives (dead drive on RAID > > controller, remove > > > drive, reboot for whatever reason, all device nodes > > are renumbered, > > > everything goes kablooey). > > > > Can you explain a bit about how you use glabel(8) in > > conjunction with ZFS? If I can retrofit this into an > > exist ZFS array to make things easier in the future... > > > > 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 > > > > ]# zpool status > > pool: storage > > state: ONLINE > > scrub: none requested > > config: > > > > NAME > > STATE READ WRITE CKSUM > > storage > > ONLINE > > 0 0 > > 0 > > raidz1 > > ONLINE 0 > > 0 0 > > ad8 > > ONLINE > > 0 0 > > 0 > > ad10 > > ONLINE 0 > > 0 0 > > ad12 > > ONLINE 0 > > 0 0 > > ad14 > > ONLINE 0 > > 0 0 > > ad16 > > ONLINE 0 > > 0 0 > > > > > Of course, always have good backups. ;) > > > > In my case, this ZFS array is the backup. ;) > > > > But I'm setting up a tape library, real soon now.... > > > > -- Dan Langille - http://langille.org/ > > _______________________________________________ > > 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 > " > > > > Dan, > > Here's how to do it after the fact: > > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html > > --Alan Bryan > [root@foghornleghorn ~]# glabel label disk01 /dev/da0 glabel: Can't store metadata on /dev/da0: Operation not permitted. Hrmph. > > > > > > > _______________________________________________ > 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" > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 06:15:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C54D8106564A for ; Wed, 21 Jul 2010 06:15:13 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 93A608FC08 for ; Wed, 21 Jul 2010 06:15:13 +0000 (UTC) Received: by iwn35 with SMTP id 35so8242091iwn.13 for ; Tue, 20 Jul 2010 23:15:12 -0700 (PDT) Received: by 10.231.32.198 with SMTP id e6mr8825627ibd.86.1279692911181; Tue, 20 Jul 2010 23:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.207.19 with HTTP; Tue, 20 Jul 2010 23:14:51 -0700 (PDT) In-Reply-To: References: <4C4504DF.30602@langille.org> <578438.38753.qm@web50502.mail.re2.yahoo.com> From: Joshua Boyd Date: Wed, 21 Jul 2010 02:14:51 -0400 Message-ID: To: alan bryan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , Dan Langille Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:15:13 -0000 On Wed, Jul 21, 2010 at 2:09 AM, Joshua Boyd wrote: > On Wed, Jul 21, 2010 at 1:57 AM, alan bryan wrote: > >> >> >> --- On Mon, 7/19/10, Dan Langille wrote: >> >> > From: Dan Langille >> > Subject: Re: Problems replacing failing drive in ZFS pool >> > To: "Freddie Cash" >> > Cc: "freebsd-stable" >> > Date: Monday, July 19, 2010, 7:07 PM >> > On 7/19/2010 12:15 PM, Freddie Cash >> > wrote: >> > > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore> > >> > wrote: >> > >> So you think it's because when I switch from the >> > old disk to the new disk, >> > >> ZFS doesn't realize the disk has changed, and >> > thinks the data is just >> > >> corrupt now? Even if that happens, shouldn't the >> > pool still be available, >> > >> since it's RAIDZ1 and only one disk has gone >> > away? >> > > >> > > I think it's because you pull the old drive, boot with >> > the new drive, >> > > the controller re-numbers all the devices (ie da3 is >> > now da2, da2 is >> > > now da1, da1 is now da0, da0 is now da6, etc), and ZFS >> > thinks that all >> > > the drives have changed, thus corrupting the >> > pool. I've had this >> > > happen on our storage servers a couple of times before >> > I started using >> > > glabel(8) on all our drives (dead drive on RAID >> > controller, remove >> > > drive, reboot for whatever reason, all device nodes >> > are renumbered, >> > > everything goes kablooey). >> > >> > Can you explain a bit about how you use glabel(8) in >> > conjunction with ZFS? If I can retrofit this into an >> > exist ZFS array to make things easier in the future... >> > >> > 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 >> > >> > ]# zpool status >> > pool: storage >> > state: ONLINE >> > scrub: none requested >> > config: >> > >> > NAME >> > STATE READ WRITE CKSUM >> > storage >> > ONLINE >> > 0 0 >> > 0 >> > raidz1 >> > ONLINE 0 >> > 0 0 >> > ad8 >> > ONLINE >> > 0 0 >> > 0 >> > ad10 >> > ONLINE 0 >> > 0 0 >> > ad12 >> > ONLINE 0 >> > 0 0 >> > ad14 >> > ONLINE 0 >> > 0 0 >> > ad16 >> > ONLINE 0 >> > 0 0 >> > >> > > Of course, always have good backups. ;) >> > >> > In my case, this ZFS array is the backup. ;) >> > >> > But I'm setting up a tape library, real soon now.... >> > >> > -- Dan Langille - http://langille.org/ >> > _______________________________________________ >> > 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" >> > >> >> Dan, >> >> Here's how to do it after the fact: >> >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html >> >> --Alan Bryan >> > > [root@foghornleghorn ~]# glabel label disk01 /dev/da0 > glabel: Can't store metadata on /dev/da0: Operation not permitted. > > Hrmph. > Nevermind, sysctl kern.geom.debugflags=16 solves that problem, but then you get this: [root@foghornleghorn ~]# zpool replace tank da0 label/disk01 cannot open 'label/disk01': no such GEOM provider must be a full path or shorthand device name > > >> >> >> >> >> >> >> _______________________________________________ >> 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" >> > > > > -- > Joshua Boyd > JBipNet > > E-mail: boydjd@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 06:32:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B104106564A for ; Wed, 21 Jul 2010 06:32:57 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 266028FC0C for ; Wed, 21 Jul 2010 06:32:56 +0000 (UTC) Received: by iwn35 with SMTP id 35so8257291iwn.13 for ; Tue, 20 Jul 2010 23:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=imWfdLtjgyXhIIhrbGD+5K1yxTJw9UjRApHjY5Pd3cI=; b=VKjy7Z5kmI4V6iOCGCRJcx88WvMO4khHEA11cIKkrqgN2/AorEysTjXMyxRQBEdN1/ u5HYBrzK2zCaMj/3uS0kT6hWtQItY6l4gfRJ7vOXFOUyEIrEEHo5/5vScZJs+88WioTm REvi2nK5dicTCLHFwaL5tPAwFeqlraxWH28cU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; b=EjRr2wi096JxMU5Ruy4dwY9IQvoF4t4hTjnwzJq2owl9b58GPocTK9sbWwmqnCRX+y VvT5CK8hZe7dnOdzUZrbPbaujv3SaUJ0XCOqvs9V20adMaaBITUHlWTUwvJ5SjW67BT8 GPKQPTcBAQhIA60AYh/GZ7DMsLMWbhbl+S81w= Received: by 10.231.29.33 with SMTP id o33mr6485476ibc.164.1279693976401; Tue, 20 Jul 2010 23:32:56 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-133-55.dsl.klmzmi.sbcglobal.net [99.181.133.55]) by mx.google.com with ESMTPS id e8sm28411890ibb.14.2010.07.20.23.32.54 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 23:32:55 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C469495.50506@dataix.net> Date: Wed, 21 Jul 2010 02:32:53 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100718 Thunderbird MIME-Version: 1.0 To: Joshua Boyd References: <4C4504DF.30602@langille.org> <578438.38753.qm@web50502.mail.re2.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alan bryan , freebsd-stable , Dan Langille Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhell@opensolaris.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:32:57 -0000 On 07/21/2010 02:14, Joshua Boyd wrote: > [root@foghornleghorn ~]# zpool replace tank da0 label/disk01 > cannot open 'label/disk01': no such GEOM provider > must be a full path or shorthand device name Of course you cant. You have labeled a disk that is already in use so in turn the label should never appear in dev/label/*. If you tried to re-silver the same disk that was already in use I would think if it could be done that the result would be of inconsistent data and write errors all over the place. Regards, -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 06:43:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D351065673 for ; Wed, 21 Jul 2010 06:43:13 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9A08FC17 for ; Wed, 21 Jul 2010 06:43:13 +0000 (UTC) Received: (qmail 31403 invoked by uid 0); 21 Jul 2010 06:43:12 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jul 2010 06:43:12 -0000 Date: Wed, 21 Jul 2010 02:43:11 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: alan bryan In-Reply-To: <578438.38753.qm@web50502.mail.re2.yahoo.com> Message-ID: References: <578438.38753.qm@web50502.mail.re2.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1730636414-1279694592=:33454" Cc: freebsd-stable , Dan Langille Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:43:13 -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. --0-1730636414-1279694592=:33454 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 20 Jul 2010, alan bryan wrote: > > > --- On Mon, 7/19/10, Dan Langille wrote: > >> From: Dan Langille >> Subject: Re: Problems replacing failing drive in ZFS pool >> To: "Freddie Cash" >> Cc: "freebsd-stable" >> Date: Monday, July 19, 2010, 7:07 PM >> On 7/19/2010 12:15 PM, Freddie Cash >> wrote: >> > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore >> wrote: >> >> So you think it's because when I switch from the >> old disk to the new disk, >> >> ZFS doesn't realize the disk has changed, and >> thinks the data is just >> >> corrupt now? Even if that happens, shouldn't the >> pool still be available, >> >> since it's RAIDZ1 and only one disk has gone >> away? >> > >> > I think it's because you pull the old drive, boot with >> the new drive, >> > the controller re-numbers all the devices (ie da3 is >> now da2, da2 is >> > now da1, da1 is now da0, da0 is now da6, etc), and ZFS >> thinks that all >> > the drives have changed, thus corrupting the >> pool.  I've had this >> > happen on our storage servers a couple of times before >> I started using >> > glabel(8) on all our drives (dead drive on RAID >> controller, remove >> > drive, reboot for whatever reason, all device nodes >> are renumbered, >> > everything goes kablooey). >> >> Can you explain a bit about how you use glabel(8) in >> conjunction with ZFS?  If I can retrofit this into an >> exist ZFS array to make things easier in the future... >> >> 8.0-STABLE #0: Fri Mar  5 00:46:11 EST 2010 >> >> ]# zpool status >>   pool: storage >> state: ONLINE >> scrub: none requested >> config: >> >>         NAME >> STATE     READ WRITE CKSUM >>         storage >>    ONLINE >>    0     0 >>    0 >>           raidz1 >> ONLINE       0 >>    0     0 >>             ad8 >>    ONLINE >>    0     0 >>    0 >>             ad10 >> ONLINE       0 >>    0     0 >>             ad12 >> ONLINE       0 >>    0     0 >>             ad14 >> ONLINE       0 >>    0     0 >>             ad16 >> ONLINE       0 >>    0     0 >> >> > Of course, always have good backups.  ;) >> >> In my case, this ZFS array is the backup.  ;) >> >> But I'm setting up a tape library, real soon now.... >> >> -- Dan Langille - http://langille.org/ >> _______________________________________________ >> 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" >> > > Dan, > > Here's how to do it after the fact: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html Two things: -What's the preferred labelling method for disks that will be used with zfs these days? geom_label or gpt labels? I've been using the latter and I find them a little simpler. -I think that if you already are using gpt partitioning, you can add a gpt label after the fact (ie: gpart -i index# -l your_label adaX). "gpart list" will give you a list of index numbers. Charles > --Alan Bryan > _______________________________________________ > 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" > --0-1730636414-1279694592=:33454-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 06:54:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B6A1065670 for ; Wed, 21 Jul 2010 06:54:49 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id F02F08FC08 for ; Wed, 21 Jul 2010 06:54:48 +0000 (UTC) Received: (qmail 43362 invoked by uid 0); 21 Jul 2010 06:54:48 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jul 2010 06:54:48 -0000 Date: Wed, 21 Jul 2010 02:54:47 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: alan bryan In-Reply-To: Message-ID: References: <578438.38753.qm@web50502.mail.re2.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-296719080-1279695288=:33454" Cc: freebsd-stable , Dan Langille Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:54: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. --0-296719080-1279695288=:33454 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 21 Jul 2010, Charles Sprickman wrote: > On Tue, 20 Jul 2010, alan bryan wrote: > >> >> >> --- On Mon, 7/19/10, Dan Langille wrote: >> >>> From: Dan Langille >>> Subject: Re: Problems replacing failing drive in ZFS pool >>> To: "Freddie Cash" >>> Cc: "freebsd-stable" >>> Date: Monday, July 19, 2010, 7:07 PM >>> On 7/19/2010 12:15 PM, Freddie Cash >>> wrote: >>> > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore >>> wrote: >>> >> So you think it's because when I switch from the >>> old disk to the new disk, >>> >> ZFS doesn't realize the disk has changed, and >>> thinks the data is just >>> >> corrupt now? Even if that happens, shouldn't the >>> pool still be available, >>> >> since it's RAIDZ1 and only one disk has gone >>> away? >>> > > I think it's because you pull the old drive, boot with >>> the new drive, >>> > the controller re-numbers all the devices (ie da3 is >>> now da2, da2 is >>> > now da1, da1 is now da0, da0 is now da6, etc), and ZFS >>> thinks that all >>> > the drives have changed, thus corrupting the >>> pool.  I've had this >>> > happen on our storage servers a couple of times before >>> I started using >>> > glabel(8) on all our drives (dead drive on RAID >>> controller, remove >>> > drive, reboot for whatever reason, all device nodes >>> are renumbered, >>> > everything goes kablooey). >>> >>> Can you explain a bit about how you use glabel(8) in >>> conjunction with ZFS?  If I can retrofit this into an >>> exist ZFS array to make things easier in the future... >>> >>> 8.0-STABLE #0: Fri Mar  5 00:46:11 EST 2010 >>> >>> ]# zpool status >>>   pool: storage >>> state: ONLINE >>> scrub: none requested >>> config: >>> >>>         NAME STATE     READ WRITE CKSUM >>>         storage >>>    ONLINE >>>    0     0 >>>    0 >>>           raidz1 ONLINE       0 >>>    0     0 >>>             ad8 >>>    ONLINE >>>    0     0 >>>    0 >>>             ad10 ONLINE       0 >>>    0     0 >>>             ad12 ONLINE       0 >>>    0     0 >>>             ad14 ONLINE       0 >>>    0     0 >>>             ad16 ONLINE       0 >>>    0     0 >>> >>> > Of course, always have good backups.  ;) >>> >>> In my case, this ZFS array is the backup.  ;) >>> >>> But I'm setting up a tape library, real soon now.... >>> >>> -- Dan Langille - http://langille.org/ >>> _______________________________________________ >>> 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" >>> >> >> Dan, >> >> Here's how to do it after the fact: >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html > > Two things: > > -What's the preferred labelling method for disks that will be used with zfs > these days? geom_label or gpt labels? I've been using the latter and I find > them a little simpler. > > -I think that if you already are using gpt partitioning, you can add a gpt > label after the fact (ie: gpart -i index# -l your_label adaX). "gpart list" > will give you a list of index numbers. Oops. That should be "gpart modify -i index# -l your_label adax". > Charles > >> --Alan Bryan >> _______________________________________________ >> 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" > --0-296719080-1279695288=:33454-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 08:33:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 539ED106566B; Wed, 21 Jul 2010 08:33:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6773C8FC16; Wed, 21 Jul 2010 08:33:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA22198; Wed, 21 Jul 2010 11:33:11 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ObUjn-000Ndu-De; Wed, 21 Jul 2010 11:33:11 +0300 Message-ID: <4C46B0C6.4020400@icyb.net.ua> Date: Wed, 21 Jul 2010 11:33:10 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Markus Gebert References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> In-Reply-To: <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 08:33:19 -0000 on 21/07/2010 03:57 Markus Gebert said the following: > Another thing though: Today I compared verbose boot output from 8-stable and > the current box. I saw that the ioapic sets up IRQ routing differently on > these two systems although the hardware is the same. This seemed not so > interesting at first, but then I noticed that 8-stable sets up two routes (to > lapic0 and lapic2, or sometimes lapic3) for IRQ58 (mpt0), while current only > uses one route (to lapic0). My understanding that it's not "two routes", but re-routing. During early boot all interrupts are bound to BSP; later, when APs become online, the interrupts are re-distributed among available CPUs. > I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box behave > like the one running current. Indeed, this seems to have changed IRQ58 to be > routed to lapic0 only. And the box was running for hours without showing the > symptoms. > > I just checked boot verbose outpout of my 8-stable box again (booted with > machdep.lapic_allclocks=0 as mentioned above). And now it seems to have set > up IRQ routes just like the current box (one route for IRQ58 to lapic0). Not sure how to interpret this properly. One possibility is a hardware problem where interrupt message route between ioapic2 and CPU to which lapic3 belongs is flaky. Perhaps, this might be a FreeBSD problem: it could be that the system somehow tells to not set up such routes, but we don't listen. But this is far fetched. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 09:17:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A18BD1065675; Wed, 21 Jul 2010 09:17:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AF3F28FC2E; Wed, 21 Jul 2010 09:17:16 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA23801; Wed, 21 Jul 2010 12:17:07 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ObVQJ-000Ngi-2u; Wed, 21 Jul 2010 12:17:07 +0300 Message-ID: <4C46BB12.6090903@icyb.net.ua> Date: Wed, 21 Jul 2010 12:17:06 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Markus Gebert References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> In-Reply-To: <4C46B0C6.4020400@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 09:17:17 -0000 on 21/07/2010 11:33 Andriy Gapon said the following: > Not sure how to interpret this properly. > One possibility is a hardware problem where interrupt message route between > ioapic2 and CPU to which lapic3 belongs is flaky. Or, I/O path between that CPU and the PCI slot where the device resides. Or the CPU. Or... I think that lapic2 and lapic3 reside in a different physical package/socket, given that you have 2x2 CPU/core configuration. BTW, John, could there be any problem because of this: ioapic1: WARNING: intbase 48 != expected base 24 ioapic2: WARNING: intbase 56 != expected base 55 ioapic3: WARNING: intbase 24 != expected base 63 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 09:40:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 637161065677 for ; Wed, 21 Jul 2010 09:40:31 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C816A8FC08 for ; Wed, 21 Jul 2010 09:40:30 +0000 (UTC) Received: by wwe15 with SMTP id 15so1644621wwe.31 for ; Wed, 21 Jul 2010 02:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=Z5lVmtyA96nepvHyB7xBHxFq7wVMVUnQxmKcOtxavPU=; b=cLBksue4L4XXxggxzWNFYwccnxZ48O0r07JmbIRYY0tCwHMi1adkijQMmLMZ0+Cvl+ yhFpcV1FnyUeIDd07+kSCmuajT++zVkxojn0UILvFGe1fsPNXz3hEsb+XuTS2LESzH4S Khm6IY8GDUhcBp5eiXeeFf8wP7UZ7IdiGbImA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=pm7UgCBoe1DR2EwIykgyFRd9M1OfZ98NEm6M0kCizD1wq2EKO0CmEmo442MeccIMmT Dt3i29MBOUyYrdj7vzd8nadbXNE6TkEndeJG1ilZTaS5faNtz75YgXOsSrIKvsPnDYeK xmS6vAtEY/4hWI1Ow6qvV5Ej76U9jGn5/LAvg= MIME-Version: 1.0 Received: by 10.216.178.135 with SMTP id f7mr6402586wem.63.1279705229518; Wed, 21 Jul 2010 02:40:29 -0700 (PDT) Received: by 10.216.138.66 with HTTP; Wed, 21 Jul 2010 02:40:29 -0700 (PDT) Date: Wed, 21 Jul 2010 11:40:29 +0200 Message-ID: From: Spil Oss To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Changes to ipfw in 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 09:40:31 -0000 Hi, Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last night?) - 8.1 booted fine - connections from the system itself were fine - connections from my jails to the internet were not working - connections from my LAN/WLAN to the internet were not working Reverting back to 8.0-p2 with the same configuration works fine. In UPDATING I see that rc.firewall and rc.firewall6 were unified. Setup is - xl0 connected to internet/public IP via dhcp - bge0/wlan0(ath0) connected to LAN - jails have ip's on bge0 in the same subnet as the LAN - allow all from any to any via bge0|wlan0|lo0 - NAT using natd My guess is that something's changed to ipfw that is affecting my network settings. Any clues where I went wrong? Help appreciated/ Kind regards, Spil. rc.conf: firewall_enable="YES" firewall_script="/etc/ipfw.rules" natd.conf interface xl0 dynamic yes same_ports yes # http/https to http jail redirect_port tcp 192.168.2.3:80 80 redirect_port tcp 192.168.2.3:443 443 Part of /etc/ipfw.rules #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=xl0 pif6=gif0 ext6="2001:dead:beef:1::1" ks="keep-state" ipfw -q -f flush # Allow internal traffic $cmd 002 allow all from any to any via bge0 # exclude LAN traffic $cmd 003 allow all from any to any via lo0 # exclude loopback traffic $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic # Allow all encapulated IPv6 to/from tunnel PoP $cmd 010 allow ip4 from to me via $pif $cmd 010 allow ip4 from me to via $pif # Black-hole some stuff using tables $cmd 050 drop ip from "table(17)" to any in via $pif $cmd 050 drop ip from any to "table(17)" out via $pif # Separate IPv6 rules (no NAT!) $cmd 060 skipto 1000 ip6 from any to any $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound packets from external $cmd 101 check-state # Authorized outbound packets $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 150 $skip tcp from any to any out via $pif $ks $cmd 151 $skip udp from any to any out via $pif $ks $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks # Deny all inbound traffic from non-routable reserved address spaces $cmd 300 unreach host all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 301 unreach host all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 302 unreach host all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP $cmd 303 unreach host all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 unreach host all from 0.0.0.0/8 to any in via $pif #loopback $cmd 305 unreach host all from 169.254.0.0/16 to any in via $pif #DHCP auto-config $cmd 306 unreach host all from 192.0.2.0/24 to any in via $pif #reserved for docs $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 unreach host all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Deny packets that did not match the dynamic rule table #$cmd 330 deny all from any to any frag in via $pif # All late fragments #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK # Authorized inbound packets $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-exceeded $cmd 420 allow tcp from any to me ssh in via $pif setup $ks $cmd 421 allow tcp from any to me smtp in via $pif $cmd 422 allow tcp from any to me http in via $pif $cmd 423 allow tcp from any to me https in via $pif $cmd 424 allow tcp from any to me imaps in via $pif #$cmd 449 unreach host ip from any to any in via $pif $cmd 448 reject log all from any to any in via $pif $cmd 449 reject log all from any to any out via $pif $cmd 450 reject log ip from any to any # This is skipto location for outbound stateful rules $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 11:59:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167181065677 for ; Wed, 21 Jul 2010 11:59:06 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3B328FC29 for ; Wed, 21 Jul 2010 11:59:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 6638B50B7B; Wed, 21 Jul 2010 12:59:05 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwvZj7pzY4zr; Wed, 21 Jul 2010 12:59:04 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 57CF950B7A ; Wed, 21 Jul 2010 12:59:04 +0100 (BST) Message-ID: <4C46E105.8080604@langille.org> Date: Wed, 21 Jul 2010 07:59:01 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Charles Sprickman References: <578438.38753.qm@web50502.mail.re2.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alan bryan , freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 11:59:06 -0000 On 7/21/2010 2:54 AM, Charles Sprickman wrote: > On Wed, 21 Jul 2010, Charles Sprickman wrote: > >> On Tue, 20 Jul 2010, alan bryan wrote: >> >>> >>> >>> --- On Mon, 7/19/10, Dan Langille wrote: >>> >>>> From: Dan Langille >>>> Subject: Re: Problems replacing failing drive in ZFS pool >>>> To: "Freddie Cash" >>>> Cc: "freebsd-stable" >>>> Date: Monday, July 19, 2010, 7:07 PM >>>> On 7/19/2010 12:15 PM, Freddie Cash >>>> wrote: >>>> > On Mon, Jul 19, 2010 at 8:56 AM, Garrett >>>> Moore wrote: >>>> >> So you think it's because when I switch from the >>>> old disk to the new disk, >>>> >> ZFS doesn't realize the disk has changed, and >>>> thinks the data is just >>>> >> corrupt now? Even if that happens, shouldn't the >>>> pool still be available, >>>> >> since it's RAIDZ1 and only one disk has gone >>>> away? >>>> > > I think it's because you pull the old drive, boot with >>>> the new drive, >>>> > the controller re-numbers all the devices (ie da3 is >>>> now da2, da2 is >>>> > now da1, da1 is now da0, da0 is now da6, etc), and ZFS >>>> thinks that all >>>> > the drives have changed, thus corrupting the >>>> pool. I've had this >>>> > happen on our storage servers a couple of times before >>>> I started using >>>> > glabel(8) on all our drives (dead drive on RAID >>>> controller, remove >>>> > drive, reboot for whatever reason, all device nodes >>>> are renumbered, >>>> > everything goes kablooey). >>>> >>>> Can you explain a bit about how you use glabel(8) in >>>> conjunction with ZFS? If I can retrofit this into an >>>> exist ZFS array to make things easier in the future... >>>> >>>> 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 >>>> >>>> ]# zpool status >>>> pool: storage >>>> state: ONLINE >>>> scrub: none requested >>>> config: >>>> >>>> NAME STATE READ WRITE CKSUM >>>> storage >>>> ONLINE >>>> 0 0 >>>> 0 >>>> raidz1 ONLINE 0 >>>> 0 0 >>>> ad8 >>>> ONLINE >>>> 0 0 >>>> 0 >>>> ad10 ONLINE 0 >>>> 0 0 >>>> ad12 ONLINE 0 >>>> 0 0 >>>> ad14 ONLINE 0 >>>> 0 0 >>>> ad16 ONLINE 0 >>>> 0 0 >>>> >>>> > Of course, always have good backups. ;) >>>> >>>> In my case, this ZFS array is the backup. ;) >>>> >>>> But I'm setting up a tape library, real soon now.... >>>> >>>> -- Dan Langille - http://langille.org/ >>>> _______________________________________________ >>>> 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" >>>> >>> >>> Dan, >>> >>> Here's how to do it after the fact: >>> >>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html >>> >> >> Two things: >> >> -What's the preferred labelling method for disks that will be used >> with zfs these days? geom_label or gpt labels? I've been using the >> latter and I find them a little simpler. >> >> -I think that if you already are using gpt partitioning, you can add a >> gpt label after the fact (ie: gpart -i index# -l your_label adaX). >> "gpart list" will give you a list of index numbers. > > Oops. > > That should be "gpart modify -i index# -l your_label adax". I'm not using gpt partitioning. I think I'd like to try that. To do just that, I've ordered two more HDD. They'll be arriving today. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 12:15:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40AF5106568E for ; Wed, 21 Jul 2010 12:15:49 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 36A188FC15 for ; Wed, 21 Jul 2010 12:15:47 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B47BF39825; Wed, 21 Jul 2010 14:15:14 +0200 (SAST) Date: Wed, 21 Jul 2010 14:15:14 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20100721121514.GA39474@zibbi.meraka.csir.co.za> References: <20100719202541.GA42777@zibbi.meraka.csir.co.za> <20100719204618.GA21752@icarus.home.lan> <20100720042039.GA79254@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100720042039.GA79254@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.3i Cc: jfvogel@gmail.com Subject: packet loss on ixgbe using vlans and routing. Was: packet loss on ixgbe using vlans and ipv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 12:15:49 -0000 Ok, after some more testing, I found that it was not only with ipv6 that I had packet loss. Routing either ipv4 or ipv6 had some loss. My test setup is the Dell T710 with its ix2 connected to a 10G port of a Nortel 4526GTX. On that port I have 2 vlans configured with half of the 1G ports in the one vlan and the other half in the other vlan. If I test with iperf from one of the machines on a 1G port to the T710, I get 920Mbit/s. If I do it simultaneously from a few machines connected to the 1G ports, all of them basically saturate their 1G links. If I now try to route from the one vlan to the other, ie. doing an iperf from a 1G connected machine, through the T710, to another 1G connected machine, I see packet loss, sometimes 100kbits/s. So it seems that as long as the T710 with the 10G card is the start or end point of the connection, I get no packet loss, but as soon as it has to route, something go wrong. John On Tue, Jul 20, 2010 at 06:20:39AM +0200, John Hay wrote: > On Mon, Jul 19, 2010 at 01:46:18PM -0700, Jeremy Chadwick wrote: > > On Mon, Jul 19, 2010 at 10:25:42PM +0200, John Hay wrote: > > > I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel > > > 82599 cards). It is running FreeBSD RELENG_8 last updated on July 13. > > > > > > What I see is packet loss (0 - 40%) on IPv6 packets in vlans, when the > > > machine is not the originator of the packets. > > > > > > Let me try to describe a little more. If a neigbouring machine ping6 it, > > > there will be packet loss. If it act as a router for ipv6, there will be > > > packet loss. This happen even when the network is pretty idle and with > > > different switches (Nortel and Cisco equipment). The packet loss is > > > very fluctuating. Pinging 1000 packets might loose 1% one time and the > > > next time 30%. Looking with tcpdump, I can see the packets arriving and > > > going out, but the packet never arrive at the next machine. (My feeling is > > > that they get lost inside the card.) The error counters on the switch > > > does not increment. > > > > > > I do not see packet loss if the machine originate the packets, for example > > > ping6 from the machine. Also ipv4 packets do not have any packets loss. If > > > I do not use vlans, I don't see packet loss with ipv6 either. > > > > > > pciconf -l of the ethernet cards: > > > > > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > > Can you provide pciconf -lvc output for the ix[0-3] cards instead? I > > believe Jack Vogel will need this. vmstat -i might also be helpful > > (full output). > > Ok, here is it and also a netstat -m thrown in. The numbers are pretty low > because I rebooted after compiling a kernel with IPFIREWALL, ROUTETABLES, > MROUTING and FLOWTABLE removed. I'll add my kernel config file with empty > and commented out lines removed. > > After rebooting, I first tested with vlans (that is in my rc.conf) and then > tested with the vlans unconfigured on ix2. > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > output of vmstat -i > > interrupt total rate > irq19: ehci0 28371 0 > irq21: uhci2 uhci4+ 48 0 > irq23: atapci0 46 0 > irq34: mpt0 146954 2 > cpu0: timer 112205297 1999 > irq256: bce0 52063 0 > irq257: bce1 1 0 > irq258: bce2 1 0 > irq259: bce3 1 0 > irq260: ix0:que 0 142258 2 > irq261: ix0:que 1 56464 1 > irq262: ix0:que 2 56199 1 > irq263: ix0:que 3 56198 1 > irq264: ix0:que 4 66569 1 > irq265: ix0:que 5 56148 1 > irq266: ix0:que 6 56217 1 > irq267: ix0:que 7 56311 1 > irq268: ix0:que 8 56169 1 > irq269: ix0:que 9 69485 1 > irq270: ix0:que 10 56176 1 > irq271: ix0:que 11 56205 1 > irq272: ix0:que 12 56281 1 > irq273: ix0:que 13 56359 1 > irq274: ix0:que 14 56292 1 > irq275: ix0:que 15 56197 1 > irq276: ix0:link 2 0 > irq277: ix1:que 0 107873 1 > irq278: ix1:que 1 56094 0 > irq279: ix1:que 2 56097 0 > irq280: ix1:que 3 56096 0 > irq281: ix1:que 4 65439 1 > irq282: ix1:que 5 56091 0 > irq283: ix1:que 6 56092 0 > irq284: ix1:que 7 56098 0 > irq285: ix1:que 8 56091 0 > irq286: ix1:que 9 56096 0 > irq287: ix1:que 10 56093 0 > irq288: ix1:que 11 56091 0 > irq289: ix1:que 12 56096 0 > irq290: ix1:que 13 56095 0 > irq291: ix1:que 14 57125 1 > irq292: ix1:que 15 56093 0 > irq293: ix1:link 1 0 > irq294: ix2:que 0 231250 4 > irq295: ix2:que 1 57784 1 > irq296: ix2:que 2 69956 1 > irq297: ix2:que 3 59498 1 > irq298: ix2:que 4 58201 1 > irq299: ix2:que 5 58599 1 > irq300: ix2:que 6 57813 1 > irq301: ix2:que 7 60075 1 > irq302: ix2:que 8 68639 1 > irq303: ix2:que 9 58194 1 > irq304: ix2:que 10 60752 1 > irq305: ix2:que 11 57628 1 > irq306: ix2:que 12 66796 1 > irq307: ix2:que 13 63307 1 > irq308: ix2:que 14 60788 1 > irq309: ix2:que 15 59102 1 > irq310: ix2:link 5 0 > irq311: ix3:que 0 56090 0 > irq312: ix3:que 1 56090 0 > irq313: ix3:que 2 56090 0 > irq314: ix3:que 3 56090 0 > irq315: ix3:que 4 56090 0 > irq316: ix3:que 5 56090 0 > irq317: ix3:que 6 56090 0 > irq318: ix3:que 7 56090 0 > irq319: ix3:que 8 56090 0 > irq320: ix3:que 9 56090 0 > irq321: ix3:que 10 56090 0 > irq322: ix3:que 11 56090 0 > irq323: ix3:que 12 56090 0 > irq324: ix3:que 13 56090 0 > irq325: ix3:que 14 56090 0 > irq326: ix3:que 15 56090 0 > cpu1: timer 112196134 1999 > cpu10: timer 112196179 1999 > cpu3: timer 112196135 1999 > cpu8: timer 112196108 1999 > cpu4: timer 112196161 1999 > cpu11: timer 112196179 1999 > cpu5: timer 112196161 1999 > cpu13: timer 112196179 1999 > cpu6: timer 112196161 1999 > cpu14: timer 112196179 1999 > cpu2: timer 112196106 1999 > cpu12: timer 112196179 1999 > cpu7: timer 112196161 1999 > cpu9: timer 112196155 1999 > cpu15: timer 112196179 1999 > Total 1799390156 32072 > > netstat -m > > 133178/4042/137220 mbufs in use (current/cache/total) > 133112/2062/135174/262144 mbuf clusters in use (current/cache/total/max) > 133112/2056 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/20/20/131072 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) > 299518K/5214K/304733K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > kernel config file, basically started with 64 bit and removed the stuff > I do not need. > > cpu HAMMER > ident SEEKAT > device ipmi > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > options SCHED_ULE # ULE scheduler > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission Protocol > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_DIRHASH # Improve performance on big directories > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options P1003_1B_SEMAPHORES # POSIX-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > options INCLUDE_CONFIG_FILE # Include this file in kernel > options SMP # Symmetric MultiProcessor Kernel > device cpufreq > device acpi > device pci > device ata > device atapicd # ATAPI CDROM drives > device mpt # LSI-Logic MPT-Fusion > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > device pass # Passthrough device (direct SCSI access) > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > device kbdmux # keyboard multiplexer > device vga # VGA video card driver > device splash # Splash screen and screen saver support > device sc > device agp # support several AGP chipsets > device uart # Generic UART driver > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device pty # BSD-style compatibility pseudo ttys > device bpf # Berkeley packet filter > device uhci # UHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device umass # Disks/Mass storage - Requires scbus and da > device ums # Mouse > > kldstat > Id Refs Address Size Name > 1 55 0xffffffff80100000 6ea290 kernel > 2 1 0xffffffff807eb000 19e088 zfs.ko > 3 2 0xffffffff8098a000 3860 opensolaris.ko > 4 2 0xffffffff8098e000 20448 krpc.ko > 5 1 0xffffffff809af000 21100 geom_mirror.ko > 6 1 0xffffffff809d1000 66c0 if_vlan.ko > 7 1 0xffffffff809d8000 506c8 if_bce.ko > 8 2 0xffffffff80a29000 3ec20 miibus.ko > 9 1 0xffffffff80a68000 243e0 if_ixgbe.ko > 10 1 0xffffffff80a8d000 1e08 coretemp.ko > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > _______________________________________________ > 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" -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 12:25:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B941065672; Wed, 21 Jul 2010 12:25:59 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 088A48FC17; Wed, 21 Jul 2010 12:25:58 +0000 (UTC) Received: from [77.109.131.203] (port=62076 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ObYN3-000BgB-KX; Wed, 21 Jul 2010 14:25:57 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <4C46B0C6.4020400@icyb.net.ua> Date: Wed, 21 Jul 2010 14:25:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CABE3EC-1EE7-4B6B-85EA-70AA2A107948@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 12:25:59 -0000 On 21.07.2010, at 10:33, Andriy Gapon wrote: > on 21/07/2010 03:57 Markus Gebert said the following: >> Another thing though: Today I compared verbose boot output from = 8-stable and >> the current box. I saw that the ioapic sets up IRQ routing = differently on >> these two systems although the hardware is the same. This seemed not = so >> interesting at first, but then I noticed that 8-stable sets up two = routes (to >> lapic0 and lapic2, or sometimes lapic3) for IRQ58 (mpt0), while = current only >> uses one route (to lapic0). >=20 > My understanding that it's not "two routes", but re-routing. > During early boot all interrupts are bound to BSP; later, when APs = become > online, the interrupts are re-distributed among available CPUs. I guess you're right, misinterpretation on my side. Thanks for = clarifying this. Now being aware of this, it seems to me that in the = machdep.lapic_allclocks=3D0 case, there might just be more interrupts to = be assigned/routed due to "more clocks being used". If that's true, = maybe it's just "luck" that in this case the mpt interrupt gets assigned = to lapic0/cpu0 and the box runs fine. I'm just guessing though, since I = have no clue how interrupts are assigned to lapics exactly (round-robin? = some logic?). >> I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box = behave >> like the one running current. Indeed, this seems to have changed = IRQ58 to be >> routed to lapic0 only. And the box was running for hours without = showing the >> symptoms. >>=20 >> I just checked boot verbose outpout of my 8-stable box again (booted = with >> machdep.lapic_allclocks=3D0 as mentioned above). And now it seems to = have set >> up IRQ routes just like the current box (one route for IRQ58 to = lapic0). >=20 > Not sure how to interpret this properly. > One possibility is a hardware problem where interrupt message route = between > ioapic2 and CPU to which lapic3 belongs is flaky. > Perhaps, this might be a FreeBSD problem: it could be that the system = somehow > tells to not set up such routes, but we don't listen. But this is far = fetched. I'm not sure either. If my "theory" above proved to be true, it would = have been just luck, that 6.x and 7.x (and current) run just fine on the = X4100M2. A (short) test on Ubuntu didn't trigger the problem, so the = Linux kernel is either lucky too by selecting an interrupt route that is = "not flaky", or there's indeed some way to figure out not to use some = lapics for some interrupts. Or we didn't test Linux thoroughly enough. Markus From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 12:37:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA931065674; Wed, 21 Jul 2010 12:37:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED8E8FC0A; Wed, 21 Jul 2010 12:37:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27663; Wed, 21 Jul 2010 15:36:53 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C46E9E5.8000204@icyb.net.ua> Date: Wed, 21 Jul 2010 15:36:53 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Markus Gebert References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> <5CABE3EC-1EE7-4B6B-85EA-70AA2A107948@hostpoint.ch> In-Reply-To: <5CABE3EC-1EE7-4B6B-85EA-70AA2A107948@hostpoint.ch> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 12:37:01 -0000 on 21/07/2010 15:25 Markus Gebert said the following: > On 21.07.2010, at 10:33, Andriy Gapon wrote: > >> on 21/07/2010 03:57 Markus Gebert said the following: >>> Another thing though: Today I compared verbose boot output from 8-stable >>> and the current box. I saw that the ioapic sets up IRQ routing differently >>> on these two systems although the hardware is the same. This seemed not so >>> interesting at first, but then I noticed that 8-stable sets up two routes >>> (to lapic0 and lapic2, or sometimes lapic3) for IRQ58 (mpt0), while current >>> only uses one route (to lapic0). >> My understanding that it's not "two routes", but re-routing. During early >> boot all interrupts are bound to BSP; later, when APs become online, the >> interrupts are re-distributed among available CPUs. > > I guess you're right, misinterpretation on my side. Thanks for clarifying this. > > > Now being aware of this, it seems to me that in the machdep.lapic_allclocks=0 > case, there might just be more interrupts to be assigned/routed due to "more > clocks being used". If that's true, maybe it's just "luck" that in this case > the mpt interrupt gets assigned to lapic0/cpu0 and the box runs fine. I'm just > guessing though, since I have no clue how interrupts are assigned to lapics > exactly (round-robin? some logic?). Yes, round-robin, for interrupts that not explicitly bound to specific CPUs. The process is deterministic, but hard to predict indeed. >>> I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box behave >>> like the one running current. Indeed, this seems to have changed IRQ58 to >>> be routed to lapic0 only. And the box was running for hours without showing >>> the symptoms. >>> >>> I just checked boot verbose outpout of my 8-stable box again (booted with >>> machdep.lapic_allclocks=0 as mentioned above). And now it seems to have set >>> up IRQ routes just like the current box (one route for IRQ58 to lapic0). >> Not sure how to interpret this properly. One possibility is a hardware >> problem where interrupt message route between ioapic2 and CPU to which lapic3 >> belongs is flaky. Perhaps, this might be a FreeBSD problem: it could be that >> the system somehow tells to not set up such routes, but we don't listen. But >> this is far fetched. > > > I'm not sure either. If my "theory" above proved to be true, it would have been > just luck, that 6.x and 7.x (and current) run just fine on the X4100M2. A > (short) test on Ubuntu didn't trigger the problem, so the Linux kernel is > either lucky too by selecting an interrupt route that is "not flaky", or > there's indeed some way to figure out not to use some lapics for some > interrupts. Or we didn't test Linux thoroughly enough. Yep, it would be interesting to see how interrupts were distributed among CPUs on that Linux. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 13:21:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4171065674 for ; Wed, 21 Jul 2010 13:21:37 +0000 (UTC) (envelope-from SNasonov@BCC.RU) Received: from extmx.bcc.ru (extmx.bcc.ru [217.170.85.214]) by mx1.freebsd.org (Postfix) with ESMTP id D39EE8FC1B for ; Wed, 21 Jul 2010 13:21:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by extmx.bcc.ru (Postfix) with ESMTP id D4ADE1176F; Wed, 21 Jul 2010 16:55:02 +0400 (MSD) Received: from extmx.bcc.ru ([127.0.0.1]) by localhost (extmx.bcc.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30781-03; Wed, 21 Jul 2010 16:55:02 +0400 (MSD) Received: from mail.bcc (unknown [172.16.250.23]) by extmx.bcc.ru (Postfix) with ESMTP id 309D1F812; Wed, 21 Jul 2010 16:55:02 +0400 (MSD) Received: from snasonovnbwxp.bcc ([192.168.201.205]) by mail.bcc over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jul 2010 16:57:29 +0400 From: Sergey G Nasonov Organization: BCC To: spil.oss@gmail.com Date: Wed, 21 Jul 2010 16:57:29 +0400 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201007211657.29818.snasonov@bcc.ru> X-OriginalArrivalTime: 21 Jul 2010 12:57:29.0516 (UTC) FILETIME=[46BCFEC0:01CB28D4] X-Virus-Scanned: amavisd-new at bcc.ru Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Changes to ipfw in 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 13:21:37 -0000 Hello Spill, I have get the same trouble after updating my 8.0 Stable. I thing you need modify some firewall rules. Please change $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound to $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound and $cmd 500 divert natd ip from any to any out via $pif to $cmd 500 divert natd ip4 from any to any out via $pif accordingly. -- Best Regards, Nasonov Sergey From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 15:22:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2BD11065672 for ; Wed, 21 Jul 2010 15:22:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B909C8FC19 for ; Wed, 21 Jul 2010 15:22:41 +0000 (UTC) Received: by iwn35 with SMTP id 35so8713132iwn.13 for ; Wed, 21 Jul 2010 08:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uCO7m4GrhLMQifG8fHuZtTne4nXBWsAWZpZ0erTF4nI=; b=Wbv8Wwg/PH360+Z40/de7HajbowGk+SQjlJPuyctwI8Xvk9ESbDGsFF9qVDI2GHOk8 hg9AuDGKB6rJCbube8P3zX6hWv/UW2/KlMq91/+PTWzhdxp9A/UhIfQ+cXkK+cG0AWZI u3+lp05Rak6mDsJtEyGc73+4MKpeADTa6+Lqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=LY9N18+1VWoYfAqW7GVVdKh/BSHUn43Acl+IpByd0frYHYnakG0vQEcrdy+MF2QmmF N0uCp2ayYH0Yk6M5dfh6balRCvM+c/GinoA4RBxZnz6X6QWxKo/35yiClAWE+bPuNUya rC74qFRFnjHh9QqR/lzzGFUbroJ9iZ9rJcJuo= MIME-Version: 1.0 Received: by 10.231.182.201 with SMTP id cd9mr318671ibb.21.1279725760793; Wed, 21 Jul 2010 08:22:40 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Wed, 21 Jul 2010 08:22:40 -0700 (PDT) In-Reply-To: References: <578438.38753.qm@web50502.mail.re2.yahoo.com> Date: Wed, 21 Jul 2010 08:22:40 -0700 Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:22:42 -0000 On Tue, Jul 20, 2010 at 11:43 PM, Charles Sprickman wrote: > Two things: > > -What's the preferred labelling method for disks that will be used with z= fs > these days? =C2=A0geom_label or gpt labels? =C2=A0I've been using the lat= ter and I > find them a little simpler. If the disks will only be used in FreeBSD systems, and you are using the entire disk for ZFS (no partitioning), then glabel works well, and is the easiest to use. If you want to be able to move the disks between FreeBSD, OpenSolaris, Solaris, ZFS-FUSE on Linux, etc, then you need to use GPT labels. glabel is not portable. I have not used gpart, so don't know if you can label the disk or just partitions on the disk. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 16:44:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D342106566B; Wed, 21 Jul 2010 16:44:51 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 404848FC15; Wed, 21 Jul 2010 16:44:51 +0000 (UTC) Received: from [77.109.131.203] (port=51595 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ObcPZ-00041K-MB; Wed, 21 Jul 2010 18:44:49 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <4C46E9E5.8000204@icyb.net.ua> Date: Wed, 21 Jul 2010 18:44:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> <5CABE3EC-1EE7-4B6B-85EA-70AA2A107948@hostpoint.ch> <4C46E9E5.8000204@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 16:44:51 -0000 On 21.07.2010, at 14:36, Andriy Gapon wrote: > on 21/07/2010 15:25 Markus Gebert said the following: >> On 21.07.2010, at 10:33, Andriy Gapon wrote: >>=20 >>> on 21/07/2010 03:57 Markus Gebert said the following: >>>> Another thing though: Today I compared verbose boot output from = 8-stable >>>> and the current box. I saw that the ioapic sets up IRQ routing = differently >>>> on these two systems although the hardware is the same. This seemed = not so=20 >>>> interesting at first, but then I noticed that 8-stable sets up two = routes >>>> (to lapic0 and lapic2, or sometimes lapic3) for IRQ58 (mpt0), while = current >>>> only uses one route (to lapic0). >>> My understanding that it's not "two routes", but re-routing. During = early >>> boot all interrupts are bound to BSP; later, when APs become online, = the >>> interrupts are re-distributed among available CPUs. >>=20 >> I guess you're right, misinterpretation on my side. Thanks for = clarifying this. >>=20 >>=20 >> Now being aware of this, it seems to me that in the = machdep.lapic_allclocks=3D0 >> case, there might just be more interrupts to be assigned/routed due = to "more >> clocks being used". If that's true, maybe it's just "luck" that in = this case >> the mpt interrupt gets assigned to lapic0/cpu0 and the box runs fine. = I'm just >> guessing though, since I have no clue how interrupts are assigned to = lapics >> exactly (round-robin? some logic?). >=20 > Yes, round-robin, for interrupts that not explicitly bound to specific = CPUs. > The process is deterministic, but hard to predict indeed. I see. >>>> I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box = behave=20 >>>> like the one running current. Indeed, this seems to have changed = IRQ58 to >>>> be routed to lapic0 only. And the box was running for hours without = showing >>>> the symptoms. >>>>=20 >>>> I just checked boot verbose outpout of my 8-stable box again = (booted with=20 >>>> machdep.lapic_allclocks=3D0 as mentioned above). And now it seems = to have set >>>> up IRQ routes just like the current box (one route for IRQ58 to = lapic0). >>> Not sure how to interpret this properly. One possibility is a = hardware >>> problem where interrupt message route between ioapic2 and CPU to = which lapic3 >>> belongs is flaky. Perhaps, this might be a FreeBSD problem: it could = be that >>> the system somehow tells to not set up such routes, but we don't = listen. But >>> this is far fetched. >>=20 >>=20 >> I'm not sure either. If my "theory" above proved to be true, it would = have been >> just luck, that 6.x and 7.x (and current) run just fine on the = X4100M2. A >> (short) test on Ubuntu didn't trigger the problem, so the Linux = kernel is >> either lucky too by selecting an interrupt route that is "not flaky", = or >> there's indeed some way to figure out not to use some lapics for some >> interrupts. Or we didn't test Linux thoroughly enough. >=20 > Yep, it would be interesting to see how interrupts were distributed = among CPUs on > that Linux. Well I can't provide this kind of information about _that_ Ubuntu Linux = right now, because it was wiped from the second test machine to test = current. But we have a few productive X4100M2 running Debian and there = it looks like this: ---- # uname -a Linux XX 2.6.26-2-amd64 #1 SMP Tue Mar 9 22:29:32 UTC 2010 x86_64 = GNU/Linux # cat /proc/interrupts=20 CPU0 CPU1 CPU2 CPU3 =20 0: 36 0 0 1 IO-APIC-edge = timer 1: 0 0 0 2 IO-APIC-edge = i8042 7: 1 0 0 0 IO-APIC-edge =20 8: 0 0 0 1 IO-APIC-edge = rtc0 9: 0 0 0 0 IO-APIC-fasteoi = acpi 12: 0 0 0 4 IO-APIC-edge = i8042 14: 0 0 0 74 IO-APIC-edge = ide0 21: 0 0 0 2 IO-APIC-fasteoi = ehci_hcd:usb2 22: 0 0 1 31 IO-APIC-fasteoi = ohci_hcd:usb1 56: 52836 302759221 129 50868 IO-APIC-fasteoi = eth2 57: 288921 1070387307 225 98210 IO-APIC-fasteoi = eth3 1271: 92146 45282139 9 4885 PCI-MSI-edge = ioc0 NMI: 0 0 0 0 Non-maskable = interrupts LOC: 258132347 312890202 166484456 147070084 Local timer = interrupts RES: 118623017 84540907 100591028 107693244 Rescheduling = interrupts CAL: 108384 89281 110429 104206 function call = interrupts TLB: 14719843 24105630 12456528 18955140 TLB shootdowns TRM: 0 0 0 0 Thermal event = interrupts THR: 0 0 0 0 Threshold APIC = interrupts SPU: 0 0 0 0 Spurious interrupts ERR: 1 ---- Not sure how to interpret this. At first sight no IRQ58, but I guess = they might be using MSI for mpt, which might avoid the problem entirely. Markus From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 16:51:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4761065674; Wed, 21 Jul 2010 16:51:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DBEF98FC22; Wed, 21 Jul 2010 16:51:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA02105; Wed, 21 Jul 2010 19:50:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C47256D.4030007@icyb.net.ua> Date: Wed, 21 Jul 2010 19:50:53 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Markus Gebert References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> <5CABE3EC-1EE7-4B6B-85EA-70AA2A107948@hostpoint.ch> <4C46E9E5.8000204@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 16:51:01 -0000 on 21/07/2010 19:44 Markus Gebert said the following: > 1271: 92146 45282139 9 4885 PCI-MSI-edge ioc0 ... > Not sure how to interpret this. At first sight no IRQ58, but I guess they might > be using MSI for mpt, which might avoid the problem entirely. Yep, looks like ioc0 is it. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 17:23:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B811106566C for ; Wed, 21 Jul 2010 17:23:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id A79188FC1C for ; Wed, 21 Jul 2010 17:23:30 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id kb1A1e00127AodY57hPWDK; Wed, 21 Jul 2010 17:23:30 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.westchester.pa.mail.comcast.net with comcast id khPV1e0023LrwQ23fhPVHf; Wed, 21 Jul 2010 17:23:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B3ADF9B425; Wed, 21 Jul 2010 10:23:27 -0700 (PDT) Date: Wed, 21 Jul 2010 10:23:27 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100721172327.GA87046@icarus.home.lan> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> <5CABE3EC-1EE7-4B6B-85EA-70AA2A107948@hostpoint.ch> <4C46E9E5.8000204@icyb.net.ua> <4C47256D.4030007@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C47256D.4030007@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, John Baldwin , Markus Gebert Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:23:31 -0000 On Wed, Jul 21, 2010 at 07:50:53PM +0300, Andriy Gapon wrote: > on 21/07/2010 19:44 Markus Gebert said the following: > > 1271: 92146 45282139 9 4885 PCI-MSI-edge ioc0 > ... > > Not sure how to interpret this. At first sight no IRQ58, but I guess they might > > be using MSI for mpt, which might avoid the problem entirely. > > Yep, looks like ioc0 is it. So do we know why mpt(4) isn't making use of MSI on FreeBSD? Markus' original pciconf -lvc output does show MSI and MSI-X capabilities: mpt0@pci0:134:2:0: class=0x010000 card=0x30601000 chip=0x00501000 rev=0x02 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 4-port with 1064 -StorPort' class = mass storage subclass = SCSI cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[98] = MSI supports 1 message, 64 bit cap 07[68] = PCI-X 64-bit supports 133MHz, 2048 burst read, 16 split transactions cap 11[b0] = MSI-X supports 1 message in map 0x14 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 17:36:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE9581065673 for ; Wed, 21 Jul 2010 17:36:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 78D978FC0A for ; Wed, 21 Jul 2010 17:36:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0A37946B58; Wed, 21 Jul 2010 13:36:24 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 077EC8A03C; Wed, 21 Jul 2010 13:36:23 -0400 (EDT) From: John Baldwin To: Markus Gebert Date: Wed, 21 Jul 2010 10:10:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007201559.45081.jhb@freebsd.org> <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> In-Reply-To: <6781BC8B-51E0-4F8B-9307-9C062DE70C21@hostpoint.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007211010.12409.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 21 Jul 2010 13:36:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:36:24 -0000 On Tuesday, July 20, 2010 8:57:07 pm Markus Gebert wrote: > > On 20.07.2010, at 21:59, John Baldwin wrote: > > >> I started narrowing the revisions down until I > >> found out, that while on r202386 I'm still able to trigger the MCE, r202387 > >> seems to solve the problem on CURRENT: > >> > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202387 > > > > Although this change was MFC'd, it was later disabled by default because it > > causes issues on other machines. I think there is a tunable you need to set > > in loader.conf to enable it for 8.1. Attilio (the author of that commit) > > should know which tunable to set. > > Might be this one in sys/amd64/amd64/clock.c: > > ---- > static int lapic_allclocks = 1; > TUNABLE_INT("machdep.lapic_allclocks", &lapic_allclocks); > ---- > > The r202387 changes put this into local_apic.c, guess it was moved later on (or after MFC), and that's why I couldn't find it on 8-stable. And, indeed, this tunable seems to be gone again in current. Testing with machdep.lapic_allclocks=0 right now. So far it looks very promising. I'll let it run overnight. > > Another thing though: Today I compared verbose boot output from 8-stable and the current box. I saw that the ioapic sets up IRQ routing differently on these two systems although the hardware is the same. This seemed not so interesting at first, but then I noticed that 8-stable sets up two routes (to lapic0 and lapic2, or sometimes lapic3) for IRQ58 (mpt0), while current only uses one route (to lapic0). There is only one route. The sort is probably making it confusing. What happens is that during boot we route all interrupts to lapic 0 since the other CPUs aren't ready to handle interrupts when we probe devices. However, once all the CPUs are up and running we redistribute the interrupts round-robin among the available CPUs. > I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box behave like the one running current. Indeed, this seems to have changed IRQ58 to be routed to lapic0 only. And the box was running for hours without showing the symptoms. Probably this is because using lapic_allclocks enables an extra interrupt (IRQ0 or IRQ8) that alters the round-robin alloction so that IRQ 58 now lands on CPU 0 instead of some other CPU. The routing is not "wrong", just different. Any interrupt in an I/O APIC (or MSI message) can be routed to any CPU. The OS is free to make that choice arbitrarily. However, it may be that having mpt send its interrupts to CPU 0 masks the hardware fault you are encountering. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 17:36:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1A4106567A for ; Wed, 21 Jul 2010 17:36:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B2388FC14 for ; Wed, 21 Jul 2010 17:36:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2FA9146B66; Wed, 21 Jul 2010 13:36:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0282A8A04E; Wed, 21 Jul 2010 13:36:24 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 21 Jul 2010 10:10:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <4C46B0C6.4020400@icyb.net.ua> <4C46BB12.6090903@icyb.net.ua> In-Reply-To: <4C46BB12.6090903@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007211010.53176.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 21 Jul 2010 13:36:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Markus Gebert Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:36:25 -0000 On Wednesday, July 21, 2010 5:17:06 am Andriy Gapon wrote: > on 21/07/2010 11:33 Andriy Gapon said the following: > > Not sure how to interpret this properly. > > One possibility is a hardware problem where interrupt message route between > > ioapic2 and CPU to which lapic3 belongs is flaky. > > Or, I/O path between that CPU and the PCI slot where the device resides. Or the > CPU. Or... > I think that lapic2 and lapic3 reside in a different physical package/socket, > given that you have 2x2 CPU/core configuration. > > BTW, John, could there be any problem because of this: > ioapic1: WARNING: intbase 48 != expected base 24 > ioapic2: WARNING: intbase 56 != expected base 55 > ioapic3: WARNING: intbase 24 != expected base 63 You can ignore this, this just means ACPI enumerated the I/O APICs out of order in the MADT. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 17:36:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A8BF106566B for ; Wed, 21 Jul 2010 17:36:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC83A8FC17 for ; Wed, 21 Jul 2010 17:36:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6B4DB46B90; Wed, 21 Jul 2010 13:36:28 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3AF518A051; Wed, 21 Jul 2010 13:36:27 -0400 (EDT) From: John Baldwin To: Markus Gebert Date: Wed, 21 Jul 2010 13:28:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <4C46E9E5.8000204@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007211328.20708.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 21 Jul 2010 13:36:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:36:29 -0000 On Wednesday, July 21, 2010 12:44:49 pm Markus Gebert wrote: > > On 21.07.2010, at 14:36, Andriy Gapon wrote: > > > on 21/07/2010 15:25 Markus Gebert said the following: > >> On 21.07.2010, at 10:33, Andriy Gapon wrote: > >> > >>> on 21/07/2010 03:57 Markus Gebert said the following: > >>>> Another thing though: Today I compared verbose boot output from 8-stable > >>>> and the current box. I saw that the ioapic sets up IRQ routing differently > >>>> on these two systems although the hardware is the same. This seemed not so > >>>> interesting at first, but then I noticed that 8-stable sets up two routes > >>>> (to lapic0 and lapic2, or sometimes lapic3) for IRQ58 (mpt0), while current > >>>> only uses one route (to lapic0). > >>> My understanding that it's not "two routes", but re-routing. During early > >>> boot all interrupts are bound to BSP; later, when APs become online, the > >>> interrupts are re-distributed among available CPUs. > >> > >> I guess you're right, misinterpretation on my side. Thanks for clarifying this. > >> > >> > >> Now being aware of this, it seems to me that in the machdep.lapic_allclocks=0 > >> case, there might just be more interrupts to be assigned/routed due to "more > >> clocks being used". If that's true, maybe it's just "luck" that in this case > >> the mpt interrupt gets assigned to lapic0/cpu0 and the box runs fine. I'm just > >> guessing though, since I have no clue how interrupts are assigned to lapics > >> exactly (round-robin? some logic?). > > > > Yes, round-robin, for interrupts that not explicitly bound to specific CPUs. > > The process is deterministic, but hard to predict indeed. > > I see. > > > >>>> I used 'cpuset -c -l 0 -x 58' in an attempt to make my 8-stable box behave > >>>> like the one running current. Indeed, this seems to have changed IRQ58 to > >>>> be routed to lapic0 only. And the box was running for hours without showing > >>>> the symptoms. > >>>> > >>>> I just checked boot verbose outpout of my 8-stable box again (booted with > >>>> machdep.lapic_allclocks=0 as mentioned above). And now it seems to have set > >>>> up IRQ routes just like the current box (one route for IRQ58 to lapic0). > >>> Not sure how to interpret this properly. One possibility is a hardware > >>> problem where interrupt message route between ioapic2 and CPU to which lapic3 > >>> belongs is flaky. Perhaps, this might be a FreeBSD problem: it could be that > >>> the system somehow tells to not set up such routes, but we don't listen. But > >>> this is far fetched. > >> > >> > >> I'm not sure either. If my "theory" above proved to be true, it would have been > >> just luck, that 6.x and 7.x (and current) run just fine on the X4100M2. A > >> (short) test on Ubuntu didn't trigger the problem, so the Linux kernel is > >> either lucky too by selecting an interrupt route that is "not flaky", or > >> there's indeed some way to figure out not to use some lapics for some > >> interrupts. Or we didn't test Linux thoroughly enough. > > > > Yep, it would be interesting to see how interrupts were distributed among CPUs on > > that Linux. > > > Well I can't provide this kind of information about _that_ Ubuntu Linux right now, because it was wiped from the second test machine to test current. But we have a few productive X4100M2 running Debian and there it looks like this: > > ---- > # uname -a > Linux XX 2.6.26-2-amd64 #1 SMP Tue Mar 9 22:29:32 UTC 2010 x86_64 GNU/Linux > # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 36 0 0 1 IO-APIC-edge timer > 1: 0 0 0 2 IO-APIC-edge i8042 > 7: 1 0 0 0 IO-APIC-edge > 8: 0 0 0 1 IO-APIC-edge rtc0 > 9: 0 0 0 0 IO-APIC-fasteoi acpi > 12: 0 0 0 4 IO-APIC-edge i8042 > 14: 0 0 0 74 IO-APIC-edge ide0 > 21: 0 0 0 2 IO-APIC-fasteoi ehci_hcd:usb2 > 22: 0 0 1 31 IO-APIC-fasteoi ohci_hcd:usb1 > 56: 52836 302759221 129 50868 IO-APIC-fasteoi eth2 > 57: 288921 1070387307 225 98210 IO-APIC-fasteoi eth3 > 1271: 92146 45282139 9 4885 PCI-MSI-edge ioc0 > NMI: 0 0 0 0 Non-maskable interrupts > LOC: 258132347 312890202 166484456 147070084 Local timer interrupts > RES: 118623017 84540907 100591028 107693244 Rescheduling interrupts > CAL: 108384 89281 110429 104206 function call interrupts > TLB: 14719843 24105630 12456528 18955140 TLB shootdowns > TRM: 0 0 0 0 Thermal event interrupts > THR: 0 0 0 0 Threshold APIC interrupts > SPU: 0 0 0 0 Spurious interrupts > ERR: 1 > ---- > > Not sure how to interpret this. At first sight no IRQ58, but I guess they might be using MSI for mpt, which might avoid the problem entirely. Yes, the FreeBSD mpt(4) driver should also use MSI by default unless you have disabled it for some reason. Also, Linux will dynamically reshuffle IRQs among CPUs based on load, so the I/O APIC/MSI -> CPU routing is more dynamic in that case. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 18:58:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017D01065674 for ; Wed, 21 Jul 2010 18:58:08 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 27F9A8FC15 for ; Wed, 21 Jul 2010 18:58:05 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 8FEB539824; Wed, 21 Jul 2010 20:57:33 +0200 (SAST) Date: Wed, 21 Jul 2010 20:57:33 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20100721185733.GA73306@zibbi.meraka.csir.co.za> References: <20100719202541.GA42777@zibbi.meraka.csir.co.za> <20100719204618.GA21752@icarus.home.lan> <20100720042039.GA79254@zibbi.meraka.csir.co.za> <20100721121514.GA39474@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721121514.GA39474@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.3i Cc: jfvogel@gmail.com Subject: Re: packet loss on ixgbe using vlans and routing. Was: packet loss on ixgbe using vlans and ipv6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:58:08 -0000 Ok, I found the culprit. If I do "ifconfig ix2 -rxcsum" the packet loss disappear. Still strange that it did not affect packets going to user-level. John On Wed, Jul 21, 2010 at 02:15:14PM +0200, John Hay wrote: > > Ok, after some more testing, I found that it was not only with ipv6 that > I had packet loss. Routing either ipv4 or ipv6 had some loss. > > My test setup is the Dell T710 with its ix2 connected to a 10G port of > a Nortel 4526GTX. On that port I have 2 vlans configured with half of > the 1G ports in the one vlan and the other half in the other vlan. > > If I test with iperf from one of the machines on a 1G port to the T710, > I get 920Mbit/s. If I do it simultaneously from a few machines connected > to the 1G ports, all of them basically saturate their 1G links. > > If I now try to route from the one vlan to the other, ie. doing an iperf > from a 1G connected machine, through the T710, to another 1G connected > machine, I see packet loss, sometimes 100kbits/s. > > So it seems that as long as the T710 with the 10G card is the start or > end point of the connection, I get no packet loss, but as soon as it > has to route, something go wrong. > > John > > On Tue, Jul 20, 2010 at 06:20:39AM +0200, John Hay wrote: > > On Mon, Jul 19, 2010 at 01:46:18PM -0700, Jeremy Chadwick wrote: > > > On Mon, Jul 19, 2010 at 10:25:42PM +0200, John Hay wrote: > > > > I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel > > > > 82599 cards). It is running FreeBSD RELENG_8 last updated on July 13. > > > > > > > > What I see is packet loss (0 - 40%) on IPv6 packets in vlans, when the > > > > machine is not the originator of the packets. > > > > > > > > Let me try to describe a little more. If a neigbouring machine ping6 it, > > > > there will be packet loss. If it act as a router for ipv6, there will be > > > > packet loss. This happen even when the network is pretty idle and with > > > > different switches (Nortel and Cisco equipment). The packet loss is > > > > very fluctuating. Pinging 1000 packets might loose 1% one time and the > > > > next time 30%. Looking with tcpdump, I can see the packets arriving and > > > > going out, but the packet never arrive at the next machine. (My feeling is > > > > that they get lost inside the card.) The error counters on the switch > > > > does not increment. > > > > > > > > I do not see packet loss if the machine originate the packets, for example > > > > ping6 from the machine. Also ipv4 packets do not have any packets loss. If > > > > I do not use vlans, I don't see packet loss with ipv6 either. > > > > > > > > pciconf -l of the ethernet cards: > > > > > > > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > > > > > Can you provide pciconf -lvc output for the ix[0-3] cards instead? I > > > believe Jack Vogel will need this. vmstat -i might also be helpful > > > (full output). > > > > Ok, here is it and also a netstat -m thrown in. The numbers are pretty low > > because I rebooted after compiling a kernel with IPFIREWALL, ROUTETABLES, > > MROUTING and FLOWTABLE removed. I'll add my kernel config file with empty > > and commented out lines removed. > > > > After rebooting, I first tested with vlans (that is in my rc.conf) and then > > tested with the vlans unconfigured on ix2. > > > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > > > output of vmstat -i > > > > interrupt total rate > > irq19: ehci0 28371 0 > > irq21: uhci2 uhci4+ 48 0 > > irq23: atapci0 46 0 > > irq34: mpt0 146954 2 > > cpu0: timer 112205297 1999 > > irq256: bce0 52063 0 > > irq257: bce1 1 0 > > irq258: bce2 1 0 > > irq259: bce3 1 0 > > irq260: ix0:que 0 142258 2 > > irq261: ix0:que 1 56464 1 > > irq262: ix0:que 2 56199 1 > > irq263: ix0:que 3 56198 1 > > irq264: ix0:que 4 66569 1 > > irq265: ix0:que 5 56148 1 > > irq266: ix0:que 6 56217 1 > > irq267: ix0:que 7 56311 1 > > irq268: ix0:que 8 56169 1 > > irq269: ix0:que 9 69485 1 > > irq270: ix0:que 10 56176 1 > > irq271: ix0:que 11 56205 1 > > irq272: ix0:que 12 56281 1 > > irq273: ix0:que 13 56359 1 > > irq274: ix0:que 14 56292 1 > > irq275: ix0:que 15 56197 1 > > irq276: ix0:link 2 0 > > irq277: ix1:que 0 107873 1 > > irq278: ix1:que 1 56094 0 > > irq279: ix1:que 2 56097 0 > > irq280: ix1:que 3 56096 0 > > irq281: ix1:que 4 65439 1 > > irq282: ix1:que 5 56091 0 > > irq283: ix1:que 6 56092 0 > > irq284: ix1:que 7 56098 0 > > irq285: ix1:que 8 56091 0 > > irq286: ix1:que 9 56096 0 > > irq287: ix1:que 10 56093 0 > > irq288: ix1:que 11 56091 0 > > irq289: ix1:que 12 56096 0 > > irq290: ix1:que 13 56095 0 > > irq291: ix1:que 14 57125 1 > > irq292: ix1:que 15 56093 0 > > irq293: ix1:link 1 0 > > irq294: ix2:que 0 231250 4 > > irq295: ix2:que 1 57784 1 > > irq296: ix2:que 2 69956 1 > > irq297: ix2:que 3 59498 1 > > irq298: ix2:que 4 58201 1 > > irq299: ix2:que 5 58599 1 > > irq300: ix2:que 6 57813 1 > > irq301: ix2:que 7 60075 1 > > irq302: ix2:que 8 68639 1 > > irq303: ix2:que 9 58194 1 > > irq304: ix2:que 10 60752 1 > > irq305: ix2:que 11 57628 1 > > irq306: ix2:que 12 66796 1 > > irq307: ix2:que 13 63307 1 > > irq308: ix2:que 14 60788 1 > > irq309: ix2:que 15 59102 1 > > irq310: ix2:link 5 0 > > irq311: ix3:que 0 56090 0 > > irq312: ix3:que 1 56090 0 > > irq313: ix3:que 2 56090 0 > > irq314: ix3:que 3 56090 0 > > irq315: ix3:que 4 56090 0 > > irq316: ix3:que 5 56090 0 > > irq317: ix3:que 6 56090 0 > > irq318: ix3:que 7 56090 0 > > irq319: ix3:que 8 56090 0 > > irq320: ix3:que 9 56090 0 > > irq321: ix3:que 10 56090 0 > > irq322: ix3:que 11 56090 0 > > irq323: ix3:que 12 56090 0 > > irq324: ix3:que 13 56090 0 > > irq325: ix3:que 14 56090 0 > > irq326: ix3:que 15 56090 0 > > cpu1: timer 112196134 1999 > > cpu10: timer 112196179 1999 > > cpu3: timer 112196135 1999 > > cpu8: timer 112196108 1999 > > cpu4: timer 112196161 1999 > > cpu11: timer 112196179 1999 > > cpu5: timer 112196161 1999 > > cpu13: timer 112196179 1999 > > cpu6: timer 112196161 1999 > > cpu14: timer 112196179 1999 > > cpu2: timer 112196106 1999 > > cpu12: timer 112196179 1999 > > cpu7: timer 112196161 1999 > > cpu9: timer 112196155 1999 > > cpu15: timer 112196179 1999 > > Total 1799390156 32072 > > > > netstat -m > > > > 133178/4042/137220 mbufs in use (current/cache/total) > > 133112/2062/135174/262144 mbuf clusters in use (current/cache/total/max) > > 133112/2056 mbuf+clusters out of packet secondary zone in use (current/cache) > > 0/20/20/131072 4k (page size) jumbo clusters in use (current/cache/total/max) > > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) > > 299518K/5214K/304733K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/0/0 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > 0 calls to protocol drain routines > > > > kernel config file, basically started with 64 bit and removed the stuff > > I do not need. > > > > cpu HAMMER > > ident SEEKAT > > device ipmi > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > options SCHED_ULE # ULE scheduler > > options PREEMPTION # Enable kernel thread preemption > > options INET # InterNETworking > > options INET6 # IPv6 communications protocols > > options SCTP # Stream Control Transmission Protocol > > options FFS # Berkeley Fast Filesystem > > options SOFTUPDATES # Enable FFS soft updates support > > options UFS_DIRHASH # Improve performance on big directories > > options CD9660 # ISO 9660 Filesystem > > options PROCFS # Process filesystem (requires PSEUDOFS) > > options PSEUDOFS # Pseudo-filesystem framework > > options GEOM_PART_GPT # GUID Partition Tables. > > options GEOM_LABEL # Provides labelization > > options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) > > options COMPAT_IA32 # Compatible with i386 binaries > > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > > options KTRACE # ktrace(1) support > > options STACK # stack(9) support > > options SYSVSHM # SYSV-style shared memory > > options SYSVMSG # SYSV-style message queues > > options SYSVSEM # SYSV-style semaphores > > options P1003_1B_SEMAPHORES # POSIX-style semaphores > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. > > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > > options INCLUDE_CONFIG_FILE # Include this file in kernel > > options SMP # Symmetric MultiProcessor Kernel > > device cpufreq > > device acpi > > device pci > > device ata > > device atapicd # ATAPI CDROM drives > > device mpt # LSI-Logic MPT-Fusion > > device scbus # SCSI bus (required for SCSI) > > device da # Direct Access (disks) > > device pass # Passthrough device (direct SCSI access) > > device atkbdc # AT keyboard controller > > device atkbd # AT keyboard > > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > device sc > > device agp # support several AGP chipsets > > device uart # Generic UART driver > > device loop # Network loopback > > device random # Entropy device > > device ether # Ethernet support > > device pty # BSD-style compatibility pseudo ttys > > device bpf # Berkeley packet filter > > device uhci # UHCI PCI->USB interface > > device ehci # EHCI PCI->USB interface (USB 2.0) > > device usb # USB Bus (required) > > device uhid # "Human Interface Devices" > > device ukbd # Keyboard > > device umass # Disks/Mass storage - Requires scbus and da > > device ums # Mouse > > > > kldstat > > Id Refs Address Size Name > > 1 55 0xffffffff80100000 6ea290 kernel > > 2 1 0xffffffff807eb000 19e088 zfs.ko > > 3 2 0xffffffff8098a000 3860 opensolaris.ko > > 4 2 0xffffffff8098e000 20448 krpc.ko > > 5 1 0xffffffff809af000 21100 geom_mirror.ko > > 6 1 0xffffffff809d1000 66c0 if_vlan.ko > > 7 1 0xffffffff809d8000 506c8 if_bce.ko > > 8 2 0xffffffff80a29000 3ec20 miibus.ko > > 9 1 0xffffffff80a68000 243e0 if_ixgbe.ko > > 10 1 0xffffffff80a8d000 1e08 coretemp.ko > > > > John > > -- > > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > > _______________________________________________ > > 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" > > -- > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > _______________________________________________ > 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 Wed Jul 21 19:08:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47BE81065676; Wed, 21 Jul 2010 19:08:44 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A04738FC0A; Wed, 21 Jul 2010 19:08:43 +0000 (UTC) Received: by eyh6 with SMTP id 6so2050582eyh.13 for ; Wed, 21 Jul 2010 12:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nsEObvxuyDiNPInc+L6umZ4Eg+SAo8i5qFskCZeq9HQ=; b=L2J5uPB6AnMWG5HOUm+Jb3NC7+U5ylzmNwfJqoCyyQiz7MoOW8eGqh9sYwZ6jaS+MH 5xLXMybB3CaBGl5llQHG3ox6JzgVcwtMpzoo3IuwhQIaN2uXup1id3Vd25zTOHJaG4in 0WORlL04Iz7mIOirs7QA+WozayOvcQQypaMZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=Kr0ZSvjfHQcAoZjodR0gKOPFJNJS6Kcp4amvC5+Zj0e4R8uC7N7i4WIFYKccGWlIfG qpNSkcd7UEf/beXXG6IAmKlrvxfh8Lt/urEX2aXDG8JZGUgiCv1gwp4/tIC7nhoIOR8z KIZT5HwUmccLHthdiKOalliha+wgsqovkT6zo= MIME-Version: 1.0 Received: by 10.216.47.140 with SMTP id t12mr568432web.102.1279739322307; Wed, 21 Jul 2010 12:08:42 -0700 (PDT) Received: by 10.216.138.66 with HTTP; Wed, 21 Jul 2010 12:08:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 21:08:42 +0200 Message-ID: From: Spil Oss To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:08:44 -0000 Hi Sergey, Has the change from ip to ip4 solved the problem for you? The documentation states that proto 'ip' is the same as 'all' "Matches any packet." Rule # 60 $cmd 060 skipto 1000 ip6 from any to any will have already skipped to the ipv6 rules block thus proto 'ip' should always match remaining packets. Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup scr= ipts http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148137&cat=3Dconf Don't know if that's directly related, but it may be worth a try to revert back to the RELENG_8_0 script. Will let you now my findings. Kind regards, Spil. On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote: > Hello Spill, > > I have get the same trouble after updating my 8.0 Stable. I thing you nee= d > modify some firewall rules. > > Please change > > $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > > to > > $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound > > and > > $cmd 500 divert natd ip from any to any out via $pif > > to > > $cmd 500 divert natd ip4 from any to any out via $pif > > accordingly. > > -- > > Best Regards, > > Nasonov Sergey On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: > Hi, > > Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or > firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last > night?) > - 8.1 booted fine > - connections from the system itself were fine > - connections from my jails to the internet were not working > - connections from my LAN/WLAN to the internet were not working > Reverting back to 8.0-p2 with the same configuration works fine. > > In UPDATING I see that rc.firewall and rc.firewall6 were unified. > > Setup is > - xl0 connected to internet/public IP via dhcp > - bge0/wlan0(ath0) connected to LAN > - jails have ip's on bge0 in the same subnet as the LAN > - allow all from any to any via bge0|wlan0|lo0 > - NAT using natd > > My guess is that something's changed to ipfw that is affecting my > network settings. Any clues where I went wrong? > > Help appreciated/ Kind regards, > > Spil. > > rc.conf: > firewall_enable=3D"YES" > firewall_script=3D"/etc/ipfw.rules" > > natd.conf > interface xl0 > dynamic yes > same_ports yes > # http/https to http jail > redirect_port tcp 192.168.2.3:80 80 > redirect_port tcp 192.168.2.3:443 443 > > Part of /etc/ipfw.rules > #!/bin/sh > cmd=3D"ipfw -q add" > skip=3D"skipto 500" > pif=3Dxl0 > pif6=3Dgif0 > ext6=3D"2001:dead:beef:1::1" > ks=3D"keep-state" > > ipfw -q -f flush > > # Allow internal traffic > $cmd 002 allow all from any to any via bge0 # exclude LAN traffic > $cmd 003 allow all from any to any via lo0 =A0# exclude loopback traffic > $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic > $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic > $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic > > # Allow all encapulated IPv6 to/from tunnel PoP > $cmd 010 allow ip4 from to me via $pif > $cmd 010 allow ip4 from me to via $pif > > # Black-hole some stuff using tables > $cmd 050 drop ip from "table(17)" to any in via $pif > $cmd 050 drop ip from any to "table(17)" out via $pif > > # Separate IPv6 rules (no NAT!) > $cmd 060 skipto 1000 ip6 from any to any > > $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > packets from external > $cmd 101 check-state > > # Authorized outbound packets > $cmd 130 $skip icmp from any to any out via $pif $ks > $cmd 150 $skip tcp from any to any out via $pif $ks > $cmd 151 $skip udp from any to any out via $pif $ks > > $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks > > # Deny all inbound traffic from non-routable reserved address spaces > $cmd 300 unreach host all from 192.168.0.0/16 =A0to any in via $pif > #RFC 1918 private IP > $cmd 301 unreach host all from 172.16.0.0/12 =A0 to any in via $pif > #RFC 1918 private IP > $cmd 302 unreach host all from 10.0.0.0/8 =A0 =A0 =A0to any in via $pif > #RFC 1918 private IP > $cmd 303 unreach host all from 127.0.0.0/8 =A0 =A0 to any in via $pif =A0= #loopback > $cmd 304 unreach host all from 0.0.0.0/8 =A0 =A0 =A0 to any in via $pif = =A0#loopback > $cmd 305 unreach host all from 169.254.0.0/16 =A0to any in via $pif > #DHCP auto-config > $cmd 306 unreach host all from 192.0.2.0/24 =A0 =A0to any in via $pif > #reserved for docs > $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif =A0#Sun= cluster > $cmd 308 unreach host all from 224.0.0.0/3 =A0 =A0 to any in via $pif > #Class D & E multicast > > # Deny packets that did not match the dynamic rule table > #$cmd 330 deny all from any to any frag in via $pif # All late fragments > #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK > > # Authorized inbound packets > $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-e= xceeded > $cmd 420 allow tcp from any to me ssh in via $pif setup $ks > $cmd 421 allow tcp from any to me smtp in via $pif > $cmd 422 allow tcp from any to me http in via $pif > $cmd 423 allow tcp from any to me https in via $pif > $cmd 424 allow tcp from any to me imaps in via $pif > > #$cmd 449 unreach host ip from any to any in via $pif > $cmd 448 reject log all from any to any in via $pif > $cmd 449 reject log all from any to any out via $pif > $cmd 450 reject log ip from any to any > > # This is skipto location for outbound stateful rules > $cmd 500 divert natd ip from any to any out via $pif > $cmd 510 allow ip from any to any > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 19:52:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCCA61065675; Wed, 21 Jul 2010 19:52:33 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 308E18FC08; Wed, 21 Jul 2010 19:52:32 +0000 (UTC) Received: by ewy26 with SMTP id 26so2962277ewy.13 for ; Wed, 21 Jul 2010 12:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WNpS9LKmQfwaFON59H9hHsiDRKZda/Xfh7mwvk1eWDQ=; b=JSYYdRkVliQ65f2BGQ2l7jGbbtoVqD6TMUbtWxzYkrc2z0rMQ208MnpBSQYtbeGRQx t3s2X6R9KZY6uikttBID3/lE+II+DTt2Q3d2gHWehKH+N5Efl6NdZyHd2/dY2uZuxNa+ oemAZQQp08FFtKoFFCn0lsw8icivebS/n0yrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=GyLDBOJPCEqXvwa0rNIyKN/HvkayD/nuC4RgM7XPNW3W9kq6yBBBgz0Fi9PyYc0fEU gZC/VEe2E/WPufMCjB9ee4e3MI8GzbfdIwde2WETBeIhEfDUHX0BXz2SVCc6+jis6WkZ AQO7xt5TAXs6Lc6b72GY7MaVnFpUTk31V6qbE= MIME-Version: 1.0 Received: by 10.227.156.202 with SMTP id y10mr705840wbw.48.1279741951683; Wed, 21 Jul 2010 12:52:31 -0700 (PDT) Received: by 10.216.138.66 with HTTP; Wed, 21 Jul 2010 12:52:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 21:52:31 +0200 Message-ID: From: Spil Oss To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org, snasonov@bcc.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:52:33 -0000 Hi Sergey, I'm dumbstruck! Switching 'ip' to 'ip4' in both the divert rules fixed my problem. Personally I think that should go into the UPDATING file as well. I wouldn't have found it if you hadn't told me! Many thanks, Spil. On Wed, Jul 21, 2010 at 9:08 PM, Spil Oss wrote: > Hi Sergey, > > Has the change from ip to ip4 solved the problem for you? The > documentation states that proto 'ip' is the same as 'all' "Matches any > packet." > > Rule # 60 > =A0 =A0 $cmd 060 skipto 1000 ip6 from any to any > will have already skipped to the ipv6 rules block thus proto 'ip' > should always match remaining packets. > > Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup s= cripts > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148137&cat=3Dconf > Don't know if that's directly related, but it may be worth a try to > revert back to the RELENG_8_0 script. > > Will let you now my findings. > > Kind regards, > > Spil. > > > On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote= : >> Hello Spill, >> >> I have get the same trouble after updating my 8.0 Stable. I thing you ne= ed >> modify some firewall rules. >> >> Please change >> >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound >> >> to >> >> $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound >> >> and >> >> $cmd 500 divert natd ip from any to any out via $pif >> >> to >> >> $cmd 500 divert natd ip4 from any to any out via $pif >> >> accordingly. >> >> -- >> >> Best Regards, >> >> Nasonov Sergey > > > On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: >> Hi, >> >> Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or >> firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last >> night?) >> - 8.1 booted fine >> - connections from the system itself were fine >> - connections from my jails to the internet were not working >> - connections from my LAN/WLAN to the internet were not working >> Reverting back to 8.0-p2 with the same configuration works fine. >> >> In UPDATING I see that rc.firewall and rc.firewall6 were unified. >> >> Setup is >> - xl0 connected to internet/public IP via dhcp >> - bge0/wlan0(ath0) connected to LAN >> - jails have ip's on bge0 in the same subnet as the LAN >> - allow all from any to any via bge0|wlan0|lo0 >> - NAT using natd >> >> My guess is that something's changed to ipfw that is affecting my >> network settings. Any clues where I went wrong? >> >> Help appreciated/ Kind regards, >> >> Spil. >> >> rc.conf: >> firewall_enable=3D"YES" >> firewall_script=3D"/etc/ipfw.rules" >> >> natd.conf >> interface xl0 >> dynamic yes >> same_ports yes >> # http/https to http jail >> redirect_port tcp 192.168.2.3:80 80 >> redirect_port tcp 192.168.2.3:443 443 >> >> Part of /etc/ipfw.rules >> #!/bin/sh >> cmd=3D"ipfw -q add" >> skip=3D"skipto 500" >> pif=3Dxl0 >> pif6=3Dgif0 >> ext6=3D"2001:dead:beef:1::1" >> ks=3D"keep-state" >> >> ipfw -q -f flush >> >> # Allow internal traffic >> $cmd 002 allow all from any to any via bge0 # exclude LAN traffic >> $cmd 003 allow all from any to any via lo0 =A0# exclude loopback traffic >> $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic >> $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic >> $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic >> >> # Allow all encapulated IPv6 to/from tunnel PoP >> $cmd 010 allow ip4 from to me via $pif >> $cmd 010 allow ip4 from me to via $pif >> >> # Black-hole some stuff using tables >> $cmd 050 drop ip from "table(17)" to any in via $pif >> $cmd 050 drop ip from any to "table(17)" out via $pif >> >> # Separate IPv6 rules (no NAT!) >> $cmd 060 skipto 1000 ip6 from any to any >> >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound >> packets from external >> $cmd 101 check-state >> >> # Authorized outbound packets >> $cmd 130 $skip icmp from any to any out via $pif $ks >> $cmd 150 $skip tcp from any to any out via $pif $ks >> $cmd 151 $skip udp from any to any out via $pif $ks >> >> $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks >> >> # Deny all inbound traffic from non-routable reserved address spaces >> $cmd 300 unreach host all from 192.168.0.0/16 =A0to any in via $pif >> #RFC 1918 private IP >> $cmd 301 unreach host all from 172.16.0.0/12 =A0 to any in via $pif >> #RFC 1918 private IP >> $cmd 302 unreach host all from 10.0.0.0/8 =A0 =A0 =A0to any in via $pif >> #RFC 1918 private IP >> $cmd 303 unreach host all from 127.0.0.0/8 =A0 =A0 to any in via $pif = =A0#loopback >> $cmd 304 unreach host all from 0.0.0.0/8 =A0 =A0 =A0 to any in via $pif = =A0#loopback >> $cmd 305 unreach host all from 169.254.0.0/16 =A0to any in via $pif >> #DHCP auto-config >> $cmd 306 unreach host all from 192.0.2.0/24 =A0 =A0to any in via $pif >> #reserved for docs >> $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif =A0#Su= n cluster >> $cmd 308 unreach host all from 224.0.0.0/3 =A0 =A0 to any in via $pif >> #Class D & E multicast >> >> # Deny packets that did not match the dynamic rule table >> #$cmd 330 deny all from any to any frag in via $pif # All late fragments >> #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK >> >> # Authorized inbound packets >> $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-= exceeded >> $cmd 420 allow tcp from any to me ssh in via $pif setup $ks >> $cmd 421 allow tcp from any to me smtp in via $pif >> $cmd 422 allow tcp from any to me http in via $pif >> $cmd 423 allow tcp from any to me https in via $pif >> $cmd 424 allow tcp from any to me imaps in via $pif >> >> #$cmd 449 unreach host ip from any to any in via $pif >> $cmd 448 reject log all from any to any in via $pif >> $cmd 449 reject log all from any to any out via $pif >> $cmd 450 reject log ip from any to any >> >> # This is skipto location for outbound stateful rules >> $cmd 500 divert natd ip from any to any out via $pif >> $cmd 510 allow ip from any to any >> > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 21 20:13:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558E41065670 for ; Wed, 21 Jul 2010 20:13:07 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh2.interactivevillages.com (wh2.interactivevillages.com [75.125.250.34]) by mx1.freebsd.org (Postfix) with ESMTP id 206A68FC14 for ; Wed, 21 Jul 2010 20:13:06 +0000 (UTC) Received: from 174-21-99-21.tukw.qwest.net ([174.21.99.21] helo=_HOSTNAME_) by wh2.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ObfTW-0008LB-38 for freebsd-stable@freebsd.org; Wed, 21 Jul 2010 13:01:07 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Wed, 21 Jul 2010 13:13:01 -0700 Date: Wed, 21 Jul 2010 13:13:01 -0700 From: Chip Camden To: freebsd-stable@freebsd.org Message-ID: <20100721201301.GB44184@libertas.local.camdensoftware.com> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Company: Camden Software Consulting URL: http://camdensoftware.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh2.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com Subject: no updates? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:13:07 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is probably a stupid question, but I haven't received any csup updates for a couple of days now, even though I've seen quite a few commits on the list. I'm using the cvs tag=3DRELENG_8 I've tried both cvsup4.freebsd.org and cvsup10.freebsd.org (my two fastest connections). Are the mirrors just having a hard time keeping up? Or do I need to change my configuration? I'm using /usr/share/examples/cvsup/standard-supfile, unmodified. Just in case, here's what it looks like: # $FreeBSD: src/share/examples/cvsup/standard-supfile,v 1.25.4.2 2009/08/12= 07:25:56 kensmith Exp $ # # This file contains all of the "CVSup collections" that make up the # FreeBSD-current source tree. # # CVSup (CVS Update Protocol) allows you to download the latest CVS # tree (or any branch of development therefrom) to your system easily # and efficiently (far more so than with sup, which CVSup is aimed # at replacing). If you're running CVSup interactively, and are # currently using an X display server, you should run CVSup as follows # to keep your CVS tree up-to-date: # # cvsup standard-supfile # # If not running X, or invoking cvsup from a non-interactive script, then # run it as follows: # # cvsup -g -L 2 standard-supfile # # You may wish to change some of the settings in this file to better # suit your system: # # host=3DCHANGE_THIS.FreeBSD.org # This specifies the server host which will supply the # file updates. You must change it to one of the CVSup # mirror sites listed in the FreeBSD Handbook at # http://www.freebsd.org/doc/handbook/mirrors.html. # You can override this setting on the command line # with cvsup's "-h host" option. # # base=3D/var/db # This specifies the root where CVSup will store information # about the collections you have transferred to your system. # A setting of "/var/db" will generate this information in # /var/db/sup. You can override the "base" setting on the # command line with cvsup's "-b base" option. This directory # must exist in order to run CVSup. # # prefix=3D/usr # This specifies where to place the requested files. A # setting of "/usr" will place all of the files requested # in "/usr/src" (e.g., "/usr/src/bin", "/usr/src/lib"). # The prefix directory must exist in order to run CVSup. # Defaults that apply to all the collections # # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=3DCHANGE_THIS.FreeBSD.org *default base=3D/var/db *default prefix=3D/usr *default release=3Dcvs tag=3DRELENG_8 *default delete use-rel-suffix # If you seem to be limited by CPU rather than network or disk bandwidth, t= ry # commenting out the following line. (Normally, today's CPUs are fast enou= gh # that you want to run compression.) *default compress ## Main Source Tree. # # The easiest way to get the main source tree is to use the "src-all" # mega-collection. It includes all of the individual "src-*" collections. src-all # These are the individual collections that make up "src-all". If you # use these, be sure to comment out "src-all" above. #src-base #src-bin #src-cddl #src-contrib #src-etc #src-games #src-gnu #src-include #src-kerberos5 #src-kerberosIV #src-lib #src-libexec #src-release #src-rescue #src-sbin #src-share #src-sys #src-tools #src-usrbin #src-usrsbin # These are the individual collections that make up FreeBSD's crypto # collection. They are no longer export-restricted and are a part of # src-all #src-crypto #src-eBones #src-secure #src-sys-crypto --=20 Sterling (Chip) Camden | sterling@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips= .com --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iQEcBAEBAgAGBQJMR1TNAAoJEIpckszW26+RYn0H/jx7hjev1ZYGxCUmx9DOS9+S qk6HO+1bcbp9w0q+SVDw4ybND1YnJvOq6OST7iJ20O3TujHRk4HGKLhdUf+z0p7m SCsSBgTr3EjcvyG+LHTivux4J7s8ZU6x/9XXtpM1TiPwJKM3BUUSzPXXs3+dFul/ f+6Xv4qkF4VU+T7WanhohCyD5DPvnqhciQyjvbQ4i/AM31VMa3MSQ5CywHl2MjI6 pMKTkrubGntKia6KDyJ1PGFCbht6Ov5QiotnVRR4Cxovxq6/B3YHybG6ig3g6ak7 rBRtYG/vBNCEAMTJ9s6+AdVmA/+YS5stmEF1yvnPiui7s/PgN1hrPW9Kr5JkZTw= =k1iA -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 00:02:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A3ED106566B for ; Thu, 22 Jul 2010 00:02:24 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 58B7A8FC1C for ; Thu, 22 Jul 2010 00:02:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 9EF465093D; Thu, 22 Jul 2010 01:02:23 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZHhkzzmnRnQ; Thu, 22 Jul 2010 01:02:22 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 8EF155089E ; Thu, 22 Jul 2010 01:02:22 +0100 (BST) Message-ID: <4C478A87.9070102@langille.org> Date: Wed, 21 Jul 2010 20:02:15 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Adam Vande More References: <4C4504DF.30602@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Problems replacing failing drive in ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 00:02:24 -0000 On 7/19/2010 10:50 PM, Adam Vande More wrote: > On Mon, Jul 19, 2010 at 9:07 PM, Dan Langille wrote: > >> I think it's because you pull the old drive, boot with the new drive, >>> the controller re-numbers all the devices (ie da3 is now da2, da2 is >>> now da1, da1 is now da0, da0 is now da6, etc), and ZFS thinks that all >>> the drives have changed, thus corrupting the pool. I've had this >>> happen on our storage servers a couple of times before I started using >>> glabel(8) on all our drives (dead drive on RAID controller, remove >>> drive, reboot for whatever reason, all device nodes are renumbered, >>> everything goes kablooey). >>> >> >> >> Can you explain a bit about how you use glabel(8) in conjunction with ZFS? >> If I can retrofit this into an exist ZFS array to make things easier in the >> future... >> > > If you've used whole disks in ZFS, you can't retrofit it if by retrofit you > mean an almost painless method of resolving this. GEOM setup stuff > generally should happen BEFORE the file system is on it. > > You would create your partition(s) slightly smaller than the disk, label it, > then use the resulting device as your zfs device when creating the pool. If > you have an existing full disk install, that means restoring the data after > you've done those steps. It works just as well with MBR style partitioning, > there's nothing saying you have to use GPT. GPT is just better though in > terms of ease of use IMO among other things. FYI, this is exactly what I'm doing to do. I have obtained addition HDD to serve as temporary storage. I will also use them for practicing the commands before destroying the original array. I'll post my plan to the list for review. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 00:43:31 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FC78106566B; Thu, 22 Jul 2010 00:43:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BE5DF8FC0C; Thu, 22 Jul 2010 00:43:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6M0hTbY086345; Wed, 21 Jul 2010 20:43:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6M0hT0k086332; Thu, 22 Jul 2010 00:43:29 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 22 Jul 2010 00:43:29 GMT Message-Id: <201007220043.o6M0hT0k086332@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 00:43:31 -0000 TB --- 2010-07-22 00:04:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-22 00:04:59 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2010-07-22 00:04:59 - cleaning the object tree TB --- 2010-07-22 00:05:19 - cvsupping the source tree TB --- 2010-07-22 00:05:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2010-07-22 00:43:29 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-22 00:43:29 - ERROR: unable to cvsup the source tree TB --- 2010-07-22 00:43:29 - 0.75 user 11.53 system 2310.16 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 01:58:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88E291065676 for ; Thu, 22 Jul 2010 01:58:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 48BF78FC26 for ; Thu, 22 Jul 2010 01:58:54 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6M1wrNx069393 for ; Wed, 21 Jul 2010 21:58:53 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007220158.o6M1wrNx069393@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Jul 2010 21:58:59 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RELENG_8 flowtable issue ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 01:58:55 -0000 I noticed on a recent RELENG_8 box, the CPU became pegged. Looking at top, it has something to do with flowtables last pid: 49269; load averages: 2.76, 2.29, 2.07 up 18+09:36:04 21:42:07 89 processes: 6 running, 70 sleeping, 13 waiting CPU: 0.0% user, 0.0% nice, 50.0% system, 0.0% interrupt, 50.0% idle Mem: 52M Active, 1496M Inact, 172M Wired, 16K Cache, 112M Buf, 280M Free Swap: 3072M Total, 3072M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 2 171 ki31 0K 16K RUN 0 809.5H 100.00% idle 18 root 1 44 - 0K 8K CPU0 0 117:30 100.00% flowcleaner as the flowcleaner is running full speed. Does anyone know what that might be about ? sysctl -a |grep flow kern.sigqueue.overflow: 0 net.inet.ip.output_flowtable_size: 32768 net.inet.tcp.reass.overflows: 0 net.inet.flowtable.stats: net.inet.flowtable.nmbflows: 50176 net.inet.flowtable.tcp_expire: 86400 net.inet.flowtable.fin_wait_expire: 600 net.inet.flowtable.udp_expire: 300 net.inet.flowtable.syn_expire: 300 net.inet.flowtable.enable: 0 net.inet.flowtable.debug: 0 net.inet6.ip6.auto_flowlabel: 1 # sysctl -a net.inet.flowtable.stats net.inet.flowtable.stats: table name: ipv4 collisions: 958 allocated: 0 misses: 992897 max_depth: 1 free_checks: 36419211 frees: 785503 hits: 9745703272 lookups: 9746696168 The box runs mpd5 to terminate some l2tp connections and runs ospf and has just one area. In its releng7 incarnation, all was quite solid. I am going to disable flowtables on this box for now, but if I see it happen on another, what can I do to better debug it ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 03:05:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D351065672 for ; Thu, 22 Jul 2010 03:05:44 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 40D068FC17 for ; Thu, 22 Jul 2010 03:05:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 92BBA50B7B for ; Thu, 22 Jul 2010 04:05:43 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jODQynmiKaPv for ; Thu, 22 Jul 2010 04:05:42 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 83CC350B7A for ; Thu, 22 Jul 2010 04:05:42 +0100 (BST) Message-ID: <4C47B57F.5020309@langille.org> Date: Wed, 21 Jul 2010 23:05:35 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 03:05:44 -0000 I hope my terminology is correct.... I have a ZFS array which uses raw devices. I'd rather it use glabel and supply the GEOM devices to ZFS instead. In addition, I'll also partition the HDD to avoid using the entire HDD: leave a little bit of space at the start and end. Why use glabel? * So ZFS can find and use the correct HDD should the HDD device ever get renumbered for whatever reason. e.g. /dev/da0 becomes /dev/da6 when you move it to another controller. Why use partitions? * Primarily: two HDD of a given size, say 2TB, do not always provide the same amount of available space. If you use a slightly smaller partition instead of the entire physical HDD, you're much more likely to have a happier experience when it comes time to replace an HDD. * There seems to be a consensus amongst some that leaving the start and and of your HDD empty. Give the rest to ZFS. Things I've read that led me to the above reasons: * http://docs.freebsd.org/cgi/getmsg.cgi?fetch=399538+0+current/freebsd-stable * http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055008.html * http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003620.html The plan for this plan, I'm going to play with just two HDD, because that's what I have available. Let's assume these two HDD are ad0 and ad1. I am not planning to boot from these HDD; they are for storage only. First, create a new GUID Partition Table partition scheme on the HDD: gpart create -s GPT ad0 Let's see how much space we have. This output will be used to determine SOMEVALUE in the next command. gpart show Create a new partition within that scheme: gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 Why '-b 34'? Randi pointed me to http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains what the first 33 LBA are used for. It's not for us to use here. Where SOMEVALUE is the number of blocks to use. I plan not to use all the available blocks but leave a few hundred MB free at the end. That'll allow for the variance in HDD size. Now, label the thing: glabel label -v disk00 /dev/ad0 Repeat the above with ad1 to get disk01. Repeat for all other HDD... Then create your zpool: zpool create bigtank disk00 disk01 ... etc Any suggestions/comments? Is there any advantage to using the -l option on 'gpart add' instead of the glabel above? Thanks -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 03:15:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 959D61065673 for ; Thu, 22 Jul 2010 03:15:54 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id A74E98FC19 for ; Thu, 22 Jul 2010 03:15:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 698EF50B97 for ; Thu, 22 Jul 2010 04:15:50 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcZxQF4q95kq for ; Thu, 22 Jul 2010 04:15:48 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 9534150B7B for ; Thu, 22 Jul 2010 04:15:48 +0100 (BST) Message-ID: <4C47B7DD.3070604@langille.org> Date: Wed, 21 Jul 2010 23:15:41 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> In-Reply-To: <4C47B57F.5020309@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 03:15:55 -0000 On 7/21/2010 11:05 PM, Dan Langille wrote (something close to this): > First, create a new GUID Partition Table partition scheme on the HDD: > > gpart create -s GPT ad0 > > > Let's see how much space we have. This output will be used to determine > SOMEVALUE in the next command. > > gpart show > > > Create a new partition within that scheme: > > gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 > > > Now, label the thing: > > glabel label -v disk00 /dev/ad0 Or, is this more appropriate? glabel label -v disk00 /dev/ad0s1 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 03:32:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAC491065670 for ; Thu, 22 Jul 2010 03:32:32 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 698F28FC0A for ; Thu, 22 Jul 2010 03:32:32 +0000 (UTC) Received: by gyg4 with SMTP id 4so422213gyg.13 for ; Wed, 21 Jul 2010 20:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xrvNs4k+CaqZsijJHPkyrHTvaUcjRPJ2YAk+EH9jeM8=; b=q3P6x5gPRAUm+l8Ij8RG/2o+t0i/dlKBPR4HK289sgTKzPHnpsO1g8BJ9JFTDSvOU9 WK4WH8k82Sq/Jxd6aGAQ3yqT5DjtpFx4cnkMK2fQXVh0ka4NSwCqE2LfTZc/l2SjWp4q vjr6gzsYMK701t8ghC0dJI8VyGLh8LqFIFdjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=oiSYVsTgFZgw1wat5dp7rNIgYUhR2enAg5aBcjq5GtJwIWla8ZoVPit42epf82QNWm coUxOKHo5giHSqx4A38zSotVFjiGF5r3YSDMOvvcZ/iy8Kb8vYvBR+HwKAd4N1aF0oqL 4DWz+IA9RmEK+Hd/EOx9XWqTtgqbNVuK6BWww= Received: by 10.224.11.146 with SMTP id t18mr850202qat.120.1279769551227; Wed, 21 Jul 2010 20:32:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.208 with HTTP; Wed, 21 Jul 2010 20:32:11 -0700 (PDT) In-Reply-To: <4C47B7DD.3070604@langille.org> References: <4C47B57F.5020309@langille.org> <4C47B7DD.3070604@langille.org> From: Edho P Arief Date: Thu, 22 Jul 2010 10:32:11 +0700 Message-ID: To: Dan Langille Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 03:32:32 -0000 On Thu, Jul 22, 2010 at 10:15 AM, Dan Langille wrote: >> glabel label -v disk00 /dev/ad0 > > Or, is this more appropriate? > > =C2=A0glabel label -v disk00 /dev/ad0s1 > actually it's /dev/ad0p1. GPT scheme uses p, not s. And yes, that's more appropriate - if you create zpool on disk00 labeled as ad0 it'll use entire disk, ignoring the partitioning. --=20 O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 03:34:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76DD71065673 for ; Thu, 22 Jul 2010 03:34:24 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 303508FC0A for ; Thu, 22 Jul 2010 03:34:23 +0000 (UTC) Received: by gxk24 with SMTP id 24so5298527gxk.13 for ; Wed, 21 Jul 2010 20:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=TIb8q4uxoyl2njvJc7cfFJZD/A85OU6YwVtYtuYzM9M=; b=VUbRpio4b75BEiaZS99bjfKALkCXeh1zhu/z7ZefUHqjzVmmjXxU0/i5yWd/Pnzre9 zYh/D4alKaxSKNndlO+NPHiy/73YfIfehrt7qZmaeygUiGyp8r+TzCNN659DOXJHW779 GgS8UPGtXd55bDWFJo1c4HbYE41H4cs4d3OJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j7s1WNPfKoeFsfN6H3qNwJCPDZYUQoBUzSB3AEtvYI4F0OavaSzk/qIY7M1O331RCs BVtgDeqHNx/vJlYqGRm6AYnuK2XgVCrir2EbNvLvEeRWFWbr4SnmBLNqCWpZ1mWI/fX6 nSQhQUizQWGicOcrUhup2WOBmjnyymGr90Cnw= MIME-Version: 1.0 Received: by 10.224.78.40 with SMTP id i40mr832275qak.340.1279769663307; Wed, 21 Jul 2010 20:34:23 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Wed, 21 Jul 2010 20:34:23 -0700 (PDT) In-Reply-To: <4C47B57F.5020309@langille.org> References: <4C47B57F.5020309@langille.org> Date: Wed, 21 Jul 2010 22:34:23 -0500 Message-ID: From: Adam Vande More To: Dan Langille Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 03:34:24 -0000 On Wed, Jul 21, 2010 at 10:05 PM, Dan Langille wrote: > Why '-b 34'? Randi pointed me to > http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains what > the first 33 LBA are used for. It's not for us to use here. > > Where SOMEVALUE is the number of blocks to use. I plan not to use all the > available blocks but leave a few hundred MB free at the end. That'll allow > for the variance in HDD size. > > Any suggestions/comments? Is there any advantage to using the -l option on > 'gpart add' instead of the glabel above? > You'll want to make sure your partitions are aligned, discussion here(says 4k drives, but info pertinent to all): http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031154.html My understanding is that you weren't booting from zfs, just using it as an data file system. In that case, you'd want to use "gpart add -b 512 ..." or some other multiple of 16. Even 1024 would be a good safe number. Also GPT creates partitions not slices. Your resulting partitions with be labeled something like ad0p1, ad0p2, etc. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 03:39:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFFAA1065678 for ; Thu, 22 Jul 2010 03:39:27 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 685188FC1E for ; Thu, 22 Jul 2010 03:39:27 +0000 (UTC) Received: by yxe42 with SMTP id 42so2776207yxe.13 for ; Wed, 21 Jul 2010 20:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M+tZK6u5Bmjls1a8/9r6EX/SUqX6vuvlkVjSEsVVwK8=; b=pWO3WFiM1MTDKkV6tPK6mM/sQV+BgPBm4+Ds+ke0khuASj59pF0ufteR+kq6Pv/A94 Z3YSuU6G/H4Lw8oTaeF0aY38OBa9YscYYO1LBsAacOOY1eCL5NPp3E/jAUpKKI6K+CDD pOzo413rQhjC5nzYToZ43qJ+Zj5ADdwBo78t0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=avca+EF6UD1x/BhPM4nKUv0pY9wnJ/mFuS38/q81ayImbfN7aYPIvCR2Z1v/1Ah+6m 9EIu7bIthjltepD18e38tPiuzJJfMRzjXgNxC9dRtvFhVMdya+bTy4UJINQt/1bSONv6 xJYx0dCk3I15ELtWLnQz3CZZZM5q/DtMqvYIw= MIME-Version: 1.0 Received: by 10.224.66.165 with SMTP id n37mr880467qai.10.1279769966536; Wed, 21 Jul 2010 20:39:26 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Wed, 21 Jul 2010 20:39:26 -0700 (PDT) In-Reply-To: References: <4C47B57F.5020309@langille.org> Date: Wed, 21 Jul 2010 22:39:26 -0500 Message-ID: From: Adam Vande More To: Dan Langille Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 03:39:27 -0000 On Wed, Jul 21, 2010 at 10:34 PM, Adam Vande More wrote: > > > On Wed, Jul 21, 2010 at 10:05 PM, Dan Langille wrote: > >> Why '-b 34'? Randi pointed me to >> http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains what >> the first 33 LBA are used for. It's not for us to use here. >> >> Where SOMEVALUE is the number of blocks to use. I plan not to use all the >> available blocks but leave a few hundred MB free at the end. That'll allow >> for the variance in HDD size. >> >> Any suggestions/comments? Is there any advantage to using the -l option >> on 'gpart add' instead of the glabel above? >> > > You'll want to make sure your partitions are aligned, discussion here(says > 4k drives, but info pertinent to all): > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031154.html > > My understanding is that you weren't booting from zfs, just using it as an > data file system. In that case, you'd want to use "gpart add -b 512 ..." > or some other multiple of 16. Even 1024 would be a good safe number. Also > GPT creates partitions not slices. Your resulting partitions with be > labeled something like ad0p1, ad0p2, etc. > > Also if you have an applicable SATA controller, running the ahci module with give you more speed. Only change one thing a time though. Virtualbox makes a great testbed for this, you don't need to allocate the VM a lot of RAM just make sure it boots and such. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 04:20:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA069106566B for ; Thu, 22 Jul 2010 04:20:08 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id B53D88FC08 for ; Thu, 22 Jul 2010 04:20:08 +0000 (UTC) Received: (qmail 71694 invoked by uid 0); 22 Jul 2010 04:20:07 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2010 04:20:07 -0000 Date: Thu, 22 Jul 2010 00:20:07 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Adam Vande More In-Reply-To: Message-ID: References: <4C47B57F.5020309@langille.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 04:20:09 -0000 On Wed, 21 Jul 2010, Adam Vande More wrote: > On Wed, Jul 21, 2010 at 10:05 PM, Dan Langille wrote: > >> Why '-b 34'? Randi pointed me to >> http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains what >> the first 33 LBA are used for. It's not for us to use here. >> >> Where SOMEVALUE is the number of blocks to use. I plan not to use all the >> available blocks but leave a few hundred MB free at the end. That'll allow >> for the variance in HDD size. >> >> Any suggestions/comments? Is there any advantage to using the -l option on >> 'gpart add' instead of the glabel above? >> > > You'll want to make sure your partitions are aligned, discussion here(says > 4k drives, but info pertinent to all): > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031154.html >From that thread: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031173.html (longer explanation) I'm not really understanding the alignment issue myself on a few levels: -Does it only affect the new drives with 4K blocks? -If it does not, is it generally good to start your first partition at 1MB in? How exactly does doing this "fix" the alignment issue? > My understanding is that you weren't booting from zfs, just using it as an > data file system. In that case, you'd want to use "gpart add -b 512 ..." > or some other multiple of 16. Even 1024 would be a good safe number. Also > GPT creates partitions not slices. Your resulting partitions with be > labeled something like ad0p1, ad0p2, etc. I assume the same can be applied if you do boot from zfs; you'd still create the "freebsd-boot" partition starting at 34, but your next partition (be it swap or zfs) would start either 512 or 1024 sectors in? Thanks, Charles > > > -- > Adam Vande More > _______________________________________________ > 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 22 04:29:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C5F2106564A for ; Thu, 22 Jul 2010 04:29:55 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 042FB8FC14 for ; Thu, 22 Jul 2010 04:29:54 +0000 (UTC) Received: by ywf9 with SMTP id 9so1083960ywf.13 for ; Wed, 21 Jul 2010 21:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zxsRPqwvZIINBnC9RGVxwiMUnDkJXf4cBroTEkcHL70=; b=IBaIlHDgkMvNPq7LBlGa1bEnFkt/tj5CC61AZxpbNcaw47g4ezGp9tBaSKkJ5ZbaP6 XhF434+C53tOENQ2pEFM2SlJ9iAEus0mOakx4rPupfq3HJ7QPMUE9K2yJcFUmv74VM9r oM9YcB+LjQkoIDPUY+Hk9ncK+eloM/UP67l5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YC1nX8t+4uaiv83hi6vBRSEg+SmFN0yjfHpeLnWN+5wflIMge+Xo8QnzViU8aSW6Ml Zh/kDe78zt5NlO+e34fADQ5dQ1U+i3ovPSfPGHeDO0DX8E4iJijyqeLNcVzRneN49Zaq VSZQIMEYRlRZnRN7jRRrH4/NoazDNWCzEyis8= MIME-Version: 1.0 Received: by 10.224.100.144 with SMTP id y16mr897207qan.76.1279772994177; Wed, 21 Jul 2010 21:29:54 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Wed, 21 Jul 2010 21:29:54 -0700 (PDT) In-Reply-To: References: <4C47B57F.5020309@langille.org> Date: Wed, 21 Jul 2010 23:29:54 -0500 Message-ID: From: Adam Vande More To: Charles Sprickman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 04:29:55 -0000 On Wed, Jul 21, 2010 at 11:20 PM, Charles Sprickman wrote: > > -Does it only affect the new drives with 4K blocks? > No, although blocksize does effect these symptoms > -If it does not, is it generally good to start your first partition at 1MB > in? How exactly does doing this "fix" the alignment issue? To be clear, we are talking about data partitions, not the boot one. Difficult for me to explain concisely, but basically it has to do with seek time. A mis-aligned partition will almost always have an extra seek for each standard seek you'd have on aligned one. There have been some discussions about in the archives, also this is not unique to FreeBSD so google will have a more detailed and probably better explanation. > I assume the same can be applied if you do boot from zfs; you'd still > create the "freebsd-boot" partition starting at 34, but your next partition > (be it swap or zfs) would start either 512 or 1024 sectors in? > Yes. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 05:06:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEEB21065677 for ; Thu, 22 Jul 2010 05:06:01 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 76DFA8FC08 for ; Thu, 22 Jul 2010 05:06:01 +0000 (UTC) Received: by wwe15 with SMTP id 15so2687612wwe.31 for ; Wed, 21 Jul 2010 22:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AzJLoSvVyzxsCUzQp/WWZ3wPPzW7Pof//6lVCBKha8I=; b=Mfsc+4ElJgjThjMZsxsZ+AjjhGEk6lX4OvD1fDxoeLp/HmfkiLhALDuQ4rtE8OIdA7 A6q7khwnvuSdelHGOGeFAaVDiE1Dfrs6aR1B9tVPAyukJQ7ArR5bIvqHrfBS2eNJPAmI +kuU/g/BSJx3Nhic4ZkWGqVB0I/CNUDlfiUVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L47uGF9CmDt/TxfJAL0OQF/7gj56ZO3jtup+nP1tMN//pe+vDreZTX58XUm4eB6PXT rPApW+rmqEfSApH0niTePq+V8Opu5ENS61CoTR03L6pzpzadW1EageDfxL9T2qRRrecL T/uBDUEktUsSzKc5ovBhAkyC3UygHXo2M5TaQ= MIME-Version: 1.0 Received: by 10.216.10.5 with SMTP id 5mr1244204weu.81.1279775160346; Wed, 21 Jul 2010 22:06:00 -0700 (PDT) Received: by 10.216.231.142 with HTTP; Wed, 21 Jul 2010 22:06:00 -0700 (PDT) In-Reply-To: <4C47B57F.5020309@langille.org> References: <4C47B57F.5020309@langille.org> Date: Thu, 22 Jul 2010 00:06:00 -0500 Message-ID: From: Scot Hetzel To: Dan Langille Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 05:06:02 -0000 On Wed, Jul 21, 2010 at 10:05 PM, Dan Langille wrote: > I hope my terminology is correct.... > > I have a ZFS array which uses raw devices. =A0I'd rather it use glabel an= d > supply the GEOM devices to ZFS instead. =A0In addition, I'll also partiti= on > the HDD to avoid using the entire HDD: leave a little bit of space at the > start and end. > > Why use glabel? > > =A0* So ZFS can find and use the correct HDD should the HDD device ever > =A0 get renumbered for whatever reason. =A0e.g. /dev/da0 becomes /dev/da6 > =A0 when you move it to another controller. > > Why use partitions? > > =A0* Primarily: two HDD of a given size, say 2TB, do not always provide > =A0 the same amount of available space. =A0If you use a slightly smaller > =A0 partition instead of the entire physical HDD, you're much more > =A0 likely to have a happier experience when it comes time to replace an > =A0 HDD. > > =A0* There seems to be a consensus amongst some that leaving the start an= d > =A0 and of your HDD empty. =A0Give the rest to ZFS. > > Things I've read that led me to the above reasons: > > * > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D399538+0+current/freebsd-s= table > * > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055008.ht= ml > * http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003620.html > > The plan for this plan, I'm going to play with just two HDD, because that= 's > what I have available. =A0Let's assume these two HDD are ad0 and ad1. =A0= I am > not planning to boot from these HDD; they are for storage only. > > First, create a new GUID Partition Table partition scheme on the HDD: > > =A0gpart create -s GPT ad0 > > > Let's see how much space we have. =A0This output will be used to determin= e > SOMEVALUE in the next command. > > =A0gpart show > > > Create a new partition within that scheme: > > =A0gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 > Instead of using glabel to label the partition on a GPT disk, use this command instead: gpart add -b 34 -s SOMEVALUE -t freebsd-zfs -l disk00 ad0 You will then see a /dev/gpt/disk00. Then to create the zpool use: zpool create bigtank gpt/disk00 gpt/disk02 ... Scot From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 06:32:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01E89106564A for ; Thu, 22 Jul 2010 06:32:55 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6B018FC12 for ; Thu, 22 Jul 2010 06:32:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 4E27250B7A; Thu, 22 Jul 2010 07:32:54 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZKmFqOQdVM9; Thu, 22 Jul 2010 07:32:53 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 4C59A5093D ; Thu, 22 Jul 2010 07:32:53 +0100 (BST) Message-ID: <4C47E610.2040409@langille.org> Date: Thu, 22 Jul 2010 02:32:48 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Adam Vande More References: <4C47B57F.5020309@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:32:55 -0000 On 7/21/2010 11:39 PM, Adam Vande More wrote: > On Wed, Jul 21, 2010 at 10:34 PM, Adam Vande More > wrote: > Also if you have an applicable SATA controller, running the ahci module > with give you more speed. Only change one thing a time though. > Virtualbox makes a great testbed for this, you don't need to allocate > the VM a lot of RAM just make sure it boots and such. I'm not sure of the criteria, but this is what I'm running: atapci0: port 0xdc00-0xdc0f mem 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci7 atapci1: port 0xac00-0xac0f mem 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci3 I added ahci_load="YES" to loader.conf and rebooted. Now I see: ahci0: port 0x8000-0x8007,0x7000-0x7003,0x6000-0x6007,0x5000-0x5003,0x4000-0x400f mem 0xfb3fe400-0xfb3fe7ff irq 22 at device 17.0 on pci0 Which is the onboard SATA from what I can tell, not the controllers I installed to handle the ZFS array. The onboard SATA runs a gmirror array which handles /, /tmp, /usr, and /var (i.e. the OS). ZFS runs only on on my /storage mount point. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 06:59:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB4731065673 for ; Thu, 22 Jul 2010 06:59:26 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 859F88FC16 for ; Thu, 22 Jul 2010 06:59:26 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward2.mail.yandex.net (Yandex) with ESMTP id E912838A90CF; Thu, 22 Jul 2010 10:59:24 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1279781964; bh=JvKfU0b5evn4Rq4OBe3Skj5UKPLJw9S17lJV4l7U9dI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=M8Q1chyUl7E6CwFHuM/2/1TxF7q10mn3gUUTELVNLN8bvWLW9VK2kV9qWYDpFM6My 3Ayqilet+8yaLauODYiwxAjP5F+2UrFz6MuhkM+46NzmOFapuIIlkV8oKnZ/H403Kf jaiK5DHnGOCBDwcOMt4Xo3e+1zkPd+SDp7bM9MAU= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 8D7161280A8; Thu, 22 Jul 2010 10:59:24 +0400 (MSD) Message-ID: <4C47EC47.5090000@yandex.ru> Date: Thu, 22 Jul 2010 10:59:19 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Dan Langille References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> In-Reply-To: <4C47E610.2040409@langille.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig622C7AFFD225FB7BA60F45C2" X-Yandex-TimeMark: 1279781964 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: Adam Vande More , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:59:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig622C7AFFD225FB7BA60F45C2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 22.07.2010 10:32, Dan Langille wrote: > I'm not sure of the criteria, but this is what I'm running: >=20 > atapci0: port 0xdc00-0xdc0f mem > 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci= 7 >=20 > atapci1: port 0xac00-0xac0f mem > 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci= 3 >=20 > I added ahci_load=3D"YES" to loader.conf and rebooted. Now I see: You can add siis_load=3D"YES" to loader.conf for SiI 3124. --=20 WBR, Andrey V. Elsukov --------------enig622C7AFFD225FB7BA60F45C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMR+xLAAoJEAHF6gQQyKF6DUMH/2IzAnrBulZrjgRhMFQlGRLP yXmq7pMF/fj3yMdyV3Ao292c3uEsKsodi2FRI0EVcGl0NrTJ3vb/rPQOnT1h+ivz A9FmwrWX3jIZl8EkYYxu9lMPkkW9b/tWwjfsQUpHSIyvP9amn5ygtxrbA2N27bAF DoW/Yl14C4gniSPRCNDX9aI1+ftwfxsT/81Mb8l+29+8sSTNPBV58xt0Fsf7T+MN LetyZqAAnrZuG0dJ/LlzsmeGh4R/7hTQJrq6k1Wo+UW6SELB7kmRJTmSmnKoBUME lUgQMwNhDIQOXJXdrR8B7FTm+ehlazuMFgZ0KPnwzwfcOUWKWJkYYK1sK109770= =l9EL -----END PGP SIGNATURE----- --------------enig622C7AFFD225FB7BA60F45C2-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 06:59:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDBB31065672 for ; Thu, 22 Jul 2010 06:59:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id C3ACE8FC0A for ; Thu, 22 Jul 2010 06:59:43 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta06.emeryville.ca.mail.comcast.net with comcast id kuzL1e0020FhH24A6uzjos; Thu, 22 Jul 2010 06:59:43 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta08.emeryville.ca.mail.comcast.net with comcast id kuzh1e0063LrwQ28Uuziiv; Thu, 22 Jul 2010 06:59:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8815B9B425; Wed, 21 Jul 2010 23:59:41 -0700 (PDT) Date: Wed, 21 Jul 2010 23:59:41 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20100722065941.GA6666@icarus.home.lan> References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C47E610.2040409@langille.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adam Vande More , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:59:43 -0000 On Thu, Jul 22, 2010 at 02:32:48AM -0400, Dan Langille wrote: > On 7/21/2010 11:39 PM, Adam Vande More wrote: > >On Wed, Jul 21, 2010 at 10:34 PM, Adam Vande More >> wrote: > > >Also if you have an applicable SATA controller, running the ahci module > >with give you more speed. Only change one thing a time though. > >Virtualbox makes a great testbed for this, you don't need to allocate > >the VM a lot of RAM just make sure it boots and such. > > I'm not sure of the criteria, but this is what I'm running: > > atapci0: port 0xdc00-0xdc0f mem > 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on > pci7 > > atapci1: port 0xac00-0xac0f mem > 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on > pci3 > > I added ahci_load="YES" to loader.conf and rebooted. Now I see: > > ahci0: port > 0x8000-0x8007,0x7000-0x7003,0x6000-0x6007,0x5000-0x5003,0x4000-0x400f > mem 0xfb3fe400-0xfb3fe7ff irq 22 at device 17.0 on pci0 > > Which is the onboard SATA from what I can tell, not the controllers > I installed to handle the ZFS array. The onboard SATA runs a > gmirror array which handles /, /tmp, /usr, and /var (i.e. the OS). > ZFS runs only on on my /storage mount point. The Silicon Image controllers have their own driver, siis(4), which uses AHCI as well. It's just as reliable as ahci(4), and undergoes similar/thorough testing. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 07:02:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A895106564A for ; Thu, 22 Jul 2010 07:02:40 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1258FC1E for ; Thu, 22 Jul 2010 07:02:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 6537150B9A; Thu, 22 Jul 2010 08:02:39 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqQkJuQhfTd6; Thu, 22 Jul 2010 08:02:38 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 9268950B7B ; Thu, 22 Jul 2010 08:02:38 +0100 (BST) Message-ID: <4C47ED09.7020808@langille.org> Date: Thu, 22 Jul 2010 03:02:33 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> In-Reply-To: <4C47EC47.5090000@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:02:40 -0000 On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: > On 22.07.2010 10:32, Dan Langille wrote: >> I'm not sure of the criteria, but this is what I'm running: >> >> atapci0: port 0xdc00-0xdc0f mem >> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci7 >> >> atapci1: port 0xac00-0xac0f mem >> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci3 >> >> I added ahci_load="YES" to loader.conf and rebooted. Now I see: > > You can add siis_load="YES" to loader.conf for SiI 3124. Ahh, thank you. I'm afraid to do that now, before I label my ZFS drives for fear that the ZFS array will be messed up. But I do plan to do that for the system after my plan is implemented. Thank you. :) -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 07:08:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CF5D10656DD for ; Thu, 22 Jul 2010 07:08:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3478FC1B for ; Thu, 22 Jul 2010 07:08:06 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta04.westchester.pa.mail.comcast.net with comcast id kv871e0010EZKEL54v87e8; Thu, 22 Jul 2010 07:08:07 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.westchester.pa.mail.comcast.net with comcast id kv861e0013LrwQ23Mv86PN; Thu, 22 Jul 2010 07:08:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D016B9B425; Thu, 22 Jul 2010 00:08:04 -0700 (PDT) Date: Thu, 22 Jul 2010 00:08:04 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20100722070804.GA6913@icarus.home.lan> References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C47ED09.7020808@langille.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:08:13 -0000 On Thu, Jul 22, 2010 at 03:02:33AM -0400, Dan Langille wrote: > On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: > >On 22.07.2010 10:32, Dan Langille wrote: > >>I'm not sure of the criteria, but this is what I'm running: > >> > >>atapci0: port 0xdc00-0xdc0f mem > >>0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci7 > >> > >>atapci1: port 0xac00-0xac0f mem > >>0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci3 > >> > >>I added ahci_load="YES" to loader.conf and rebooted. Now I see: > > > >You can add siis_load="YES" to loader.conf for SiI 3124. > > Ahh, thank you. > > I'm afraid to do that now, before I label my ZFS drives for fear > that the ZFS array will be messed up. But I do plan to do that for > the system after my plan is implemented. Thank you. :) They won't be messed up. ZFS will figure out, using its metadata, which drive is part of what pool despite the device name changing. I don't use glabel or GPT so I can't comment on whether or not those work reliably in this situation (I imagine they would, but I keep seeing problem reports on the lists when people have them in use.......) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 07:18:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C43106564A for ; Thu, 22 Jul 2010 07:18:14 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id CB9AA8FC17 for ; Thu, 22 Jul 2010 07:18:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 4CEFC50B97; Thu, 22 Jul 2010 08:18:13 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL2PL4AsZIiA; Thu, 22 Jul 2010 08:18:12 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 51E4750B7B ; Thu, 22 Jul 2010 08:18:12 +0100 (BST) Message-ID: <4C47F0AF.9070802@langille.org> Date: Thu, 22 Jul 2010 03:18:07 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <20100722070804.GA6913@icarus.home.lan> In-Reply-To: <20100722070804.GA6913@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:18:14 -0000 On 7/22/2010 3:08 AM, Jeremy Chadwick wrote: > On Thu, Jul 22, 2010 at 03:02:33AM -0400, Dan Langille wrote: >> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>> On 22.07.2010 10:32, Dan Langille wrote: >>>> I'm not sure of the criteria, but this is what I'm running: >>>> >>>> atapci0: port 0xdc00-0xdc0f mem >>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci7 >>>> >>>> atapci1: port 0xac00-0xac0f mem >>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci3 >>>> >>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>> >>> You can add siis_load="YES" to loader.conf for SiI 3124. >> >> Ahh, thank you. >> >> I'm afraid to do that now, before I label my ZFS drives for fear >> that the ZFS array will be messed up. But I do plan to do that for >> the system after my plan is implemented. Thank you. :) > > They won't be messed up. ZFS will figure out, using its metadata, which > drive is part of what pool despite the device name changing. I now have: siis0: port 0xdc00-0xdc0f mem 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci7 siis1: port 0xac00-0xac0f mem 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci3 And my zpool is now: $ zpool status pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada4 ONLINE 0 0 0 Whereas previously, it was ad devices (see http://docs.freebsd.org/cgi/getmsg.cgi?fetch=399538+0+current/freebsd-stable). Thank you (and to Andrey V. Elsukov who posted the same suggestion at the same time you did). I appreciate it. > I don't > use glabel or GPT so I can't comment on whether or not those work > reliably in this situation (I imagine they would, but I keep seeing > problem reports on the lists when people have them in use.......) Really? The whole basis of the action plan I'm highlighting in this post is to avoid ZFS-related problems when devices get renumbered and ZFS is using device names (e.g. /dev/ad0> instead of labels (e.g. gpt/disk00). -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 07:30:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9BA106566C for ; Thu, 22 Jul 2010 07:30:11 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 558D88FC13 for ; Thu, 22 Jul 2010 07:30:10 +0000 (UTC) Received: (qmail 67384 invoked by uid 0); 22 Jul 2010 07:30:10 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2010 07:30:10 -0000 Date: Thu, 22 Jul 2010 03:30:09 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Dan Langille In-Reply-To: <4C47ED09.7020808@langille.org> Message-ID: References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:30:11 -0000 On Thu, 22 Jul 2010, Dan Langille wrote: > On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >> On 22.07.2010 10:32, Dan Langille wrote: >>> I'm not sure of the criteria, but this is what I'm running: >>> >>> atapci0: port 0xdc00-0xdc0f mem >>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci7 >>> >>> atapci1: port 0xac00-0xac0f mem >>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on pci3 >>> >>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >> >> You can add siis_load="YES" to loader.conf for SiI 3124. > > Ahh, thank you. > > I'm afraid to do that now, before I label my ZFS drives for fear that the ZFS > array will be messed up. But I do plan to do that for the system after my > plan is implemented. Thank you. :) You may even get hotplug support if you're lucky. :) I just built a box and gave it a spin with the "old" ata stuff and then with the "new" (AHCI) stuff. It does perform a bit better and my BIOS claims it supports hotplug with ahci enabled as well... Still have to test that. Charles > -- > Dan Langille - http://langille.org/ > _______________________________________________ > 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 22 07:36:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9794D1065673 for ; Thu, 22 Jul 2010 07:36:24 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66CAC8FC16 for ; Thu, 22 Jul 2010 07:36:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id EEB5550B97; Thu, 22 Jul 2010 08:36:23 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfwm7MxgmTcz; Thu, 22 Jul 2010 08:36:22 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id C322350B7B ; Thu, 22 Jul 2010 08:36:22 +0100 (BST) Message-ID: <4C47F4F1.8030804@langille.org> Date: Thu, 22 Jul 2010 03:36:17 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Charles Sprickman References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:36:24 -0000 On 7/22/2010 3:30 AM, Charles Sprickman wrote: > On Thu, 22 Jul 2010, Dan Langille wrote: > >> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>> On 22.07.2010 10:32, Dan Langille wrote: >>>> I'm not sure of the criteria, but this is what I'm running: >>>> >>>> atapci0: port 0xdc00-0xdc0f mem >>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on >>>> pci7 >>>> >>>> atapci1: port 0xac00-0xac0f mem >>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on >>>> pci3 >>>> >>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>> >>> You can add siis_load="YES" to loader.conf for SiI 3124. >> >> Ahh, thank you. >> >> I'm afraid to do that now, before I label my ZFS drives for fear that >> the ZFS array will be messed up. But I do plan to do that for the >> system after my plan is implemented. Thank you. :) > > You may even get hotplug support if you're lucky. :) > > I just built a box and gave it a spin with the "old" ata stuff and then > with the "new" (AHCI) stuff. It does perform a bit better and my BIOS > claims it supports hotplug with ahci enabled as well... Still have to > test that. Well, I don't have anything to support hotplug. All my stuff is internal. http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:03:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A63C0106564A for ; Thu, 22 Jul 2010 08:03:06 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 41F958FC24 for ; Thu, 22 Jul 2010 08:03:05 +0000 (UTC) Received: (qmail 99828 invoked by uid 0); 22 Jul 2010 08:03:05 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2010 08:03:05 -0000 Date: Thu, 22 Jul 2010 04:03:05 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Dan Langille In-Reply-To: <4C47F4F1.8030804@langille.org> Message-ID: References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:03:06 -0000 On Thu, 22 Jul 2010, Dan Langille wrote: > On 7/22/2010 3:30 AM, Charles Sprickman wrote: >> On Thu, 22 Jul 2010, Dan Langille wrote: >> >>> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>>> On 22.07.2010 10:32, Dan Langille wrote: >>>>> I'm not sure of the criteria, but this is what I'm running: >>>>> >>>>> atapci0: port 0xdc00-0xdc0f mem >>>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on >>>>> pci7 >>>>> >>>>> atapci1: port 0xac00-0xac0f mem >>>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on >>>>> pci3 >>>>> >>>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>>> >>>> You can add siis_load="YES" to loader.conf for SiI 3124. >>> >>> Ahh, thank you. >>> >>> I'm afraid to do that now, before I label my ZFS drives for fear that >>> the ZFS array will be messed up. But I do plan to do that for the >>> system after my plan is implemented. Thank you. :) >> >> You may even get hotplug support if you're lucky. :) >> >> I just built a box and gave it a spin with the "old" ata stuff and then >> with the "new" (AHCI) stuff. It does perform a bit better and my BIOS >> claims it supports hotplug with ahci enabled as well... Still have to >> test that. > > Well, I don't have anything to support hotplug. All my stuff is internal. > > http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg The frankenbox I'm testing on is a retrofitted 1U (it had a scsi backplane, now has none). I am not certain, but I think with 8.1 (which it's running) and all the cam integration stuff, hotplug is possible. Is a special backplane required? I seriously don't know... I'm going to give it a shot though. Oh, you also might get NCQ. Try: [root@h21 /tmp]# camcontrol tags ada0 (pass0:ahcich0:0:0:0): device openings: 32 Charles > > > -- > Dan Langille - http://langille.org/ > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:06:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12DC1065678 for ; Thu, 22 Jul 2010 08:06:20 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0658FC2D for ; Thu, 22 Jul 2010 08:06:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id E80F650BB1; Thu, 22 Jul 2010 09:06:19 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiUIinPJhR9o; Thu, 22 Jul 2010 09:06:19 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id DA25750BAF ; Thu, 22 Jul 2010 09:06:18 +0100 (BST) Message-ID: <4C47FBF5.6050305@langille.org> Date: Thu, 22 Jul 2010 04:06:13 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Charles Sprickman References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:06:20 -0000 On 7/22/2010 4:03 AM, Charles Sprickman wrote: > On Thu, 22 Jul 2010, Dan Langille wrote: > >> On 7/22/2010 3:30 AM, Charles Sprickman wrote: >>> On Thu, 22 Jul 2010, Dan Langille wrote: >>> >>>> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>>>> On 22.07.2010 10:32, Dan Langille wrote: >>>>>> I'm not sure of the criteria, but this is what I'm running: >>>>>> >>>>>> atapci0: port 0xdc00-0xdc0f mem >>>>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on >>>>>> pci7 >>>>>> >>>>>> atapci1: port 0xac00-0xac0f mem >>>>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on >>>>>> pci3 >>>>>> >>>>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>>>> >>>>> You can add siis_load="YES" to loader.conf for SiI 3124. >>>> >>>> Ahh, thank you. >>>> >>>> I'm afraid to do that now, before I label my ZFS drives for fear that >>>> the ZFS array will be messed up. But I do plan to do that for the >>>> system after my plan is implemented. Thank you. :) >>> >>> You may even get hotplug support if you're lucky. :) >>> >>> I just built a box and gave it a spin with the "old" ata stuff and then >>> with the "new" (AHCI) stuff. It does perform a bit better and my BIOS >>> claims it supports hotplug with ahci enabled as well... Still have to >>> test that. >> >> Well, I don't have anything to support hotplug. All my stuff is internal. >> >> http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg >> > > The frankenbox I'm testing on is a retrofitted 1U (it had a scsi > backplane, now has none). > > I am not certain, but I think with 8.1 (which it's running) and all the > cam integration stuff, hotplug is possible. Is a special backplane > required? I seriously don't know... I'm going to give it a shot though. > > Oh, you also might get NCQ. Try: > > [root@h21 /tmp]# camcontrol tags ada0 > (pass0:ahcich0:0:0:0): device openings: 32 # camcontrol tags ada0 (pass0:siisch2:0:0:0): device openings: 31 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:08:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 113571065673 for ; Thu, 22 Jul 2010 08:08:19 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id D491D8FC14 for ; Thu, 22 Jul 2010 08:08:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 78D715093D; Thu, 22 Jul 2010 09:08:18 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IpY7y1YhRl9; Thu, 22 Jul 2010 09:08:14 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 644635089E ; Thu, 22 Jul 2010 09:08:14 +0100 (BST) Message-ID: <4C47FC69.40805@langille.org> Date: Thu, 22 Jul 2010 04:08:09 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Charles Sprickman References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:08:19 -0000 On 7/22/2010 4:03 AM, Charles Sprickman wrote: > On Thu, 22 Jul 2010, Dan Langille wrote: > >> On 7/22/2010 3:30 AM, Charles Sprickman wrote: >>> On Thu, 22 Jul 2010, Dan Langille wrote: >>> >>>> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>>>> On 22.07.2010 10:32, Dan Langille wrote: >>>>>> I'm not sure of the criteria, but this is what I'm running: >>>>>> >>>>>> atapci0: port 0xdc00-0xdc0f mem >>>>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on >>>>>> pci7 >>>>>> >>>>>> atapci1: port 0xac00-0xac0f mem >>>>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on >>>>>> pci3 >>>>>> >>>>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>>>> >>>>> You can add siis_load="YES" to loader.conf for SiI 3124. >>>> >>>> Ahh, thank you. >>>> >>>> I'm afraid to do that now, before I label my ZFS drives for fear that >>>> the ZFS array will be messed up. But I do plan to do that for the >>>> system after my plan is implemented. Thank you. :) >>> >>> You may even get hotplug support if you're lucky. :) >>> >>> I just built a box and gave it a spin with the "old" ata stuff and then >>> with the "new" (AHCI) stuff. It does perform a bit better and my BIOS >>> claims it supports hotplug with ahci enabled as well... Still have to >>> test that. >> >> Well, I don't have anything to support hotplug. All my stuff is internal. >> >> http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg >> > > The frankenbox I'm testing on is a retrofitted 1U (it had a scsi > backplane, now has none). > > I am not certain, but I think with 8.1 (which it's running) and all the > cam integration stuff, hotplug is possible. Is a special backplane > required? I seriously don't know... I'm going to give it a shot though. > > Oh, you also might get NCQ. Try: > > [root@h21 /tmp]# camcontrol tags ada0 > (pass0:ahcich0:0:0:0): device openings: 32 # camcontrol tags ada0 (pass0:siisch2:0:0:0): device openings: 31 resending with this: ada{0..4} give the above. # camcontrol tags ada5 (pass5:ahcich0:0:0:0): device openings: 32 That's part of the gmirror array for the OS, along with ad6 which has similar output. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:11:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 766B51065678 for ; Thu, 22 Jul 2010 08:11:11 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 44EB58FC1D for ; Thu, 22 Jul 2010 08:11:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id DC79E5093D; Thu, 22 Jul 2010 09:11:10 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pYNi1GmoCQX; Thu, 22 Jul 2010 09:11:09 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id C8AF35089E ; Thu, 22 Jul 2010 09:11:09 +0100 (BST) Message-ID: <4C47FD18.7030002@langille.org> Date: Thu, 22 Jul 2010 04:11:04 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Charles Sprickman References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:11:11 -0000 On 7/22/2010 4:03 AM, Charles Sprickman wrote: > On Thu, 22 Jul 2010, Dan Langille wrote: > >> On 7/22/2010 3:30 AM, Charles Sprickman wrote: >>> On Thu, 22 Jul 2010, Dan Langille wrote: >>> >>>> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>>>> On 22.07.2010 10:32, Dan Langille wrote: >>>>>> I'm not sure of the criteria, but this is what I'm running: >>>>>> >>>>>> atapci0: port 0xdc00-0xdc0f mem >>>>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on >>>>>> pci7 >>>>>> >>>>>> atapci1: port 0xac00-0xac0f mem >>>>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on >>>>>> pci3 >>>>>> >>>>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>>>> >>>>> You can add siis_load="YES" to loader.conf for SiI 3124. >>>> >>>> Ahh, thank you. >>>> >>>> I'm afraid to do that now, before I label my ZFS drives for fear that >>>> the ZFS array will be messed up. But I do plan to do that for the >>>> system after my plan is implemented. Thank you. :) >>> >>> You may even get hotplug support if you're lucky. :) >>> >>> I just built a box and gave it a spin with the "old" ata stuff and then >>> with the "new" (AHCI) stuff. It does perform a bit better and my BIOS >>> claims it supports hotplug with ahci enabled as well... Still have to >>> test that. >> >> Well, I don't have anything to support hotplug. All my stuff is internal. >> >> http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg >> > > The frankenbox I'm testing on is a retrofitted 1U (it had a scsi > backplane, now has none). > > I am not certain, but I think with 8.1 (which it's running) and all the > cam integration stuff, hotplug is possible. Is a special backplane > required? I seriously don't know... I'm going to give it a shot though. > > Oh, you also might get NCQ. Try: > > [root@h21 /tmp]# camcontrol tags ada0 > (pass0:ahcich0:0:0:0): device openings: 32 # camcontrol tags ada0 (pass0:siisch2:0:0:0): device openings: 31 resending with this: ada{0..4} give the above. # camcontrol tags ada5 (pass5:ahcich0:0:0:0): device openings: 32 That's part of the gmirror array for the OS, along with ad6 which has similar output. And again with this output from one of the ZFS drives: # camcontrol identify ada0 pass0: ATA-8 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model Hitachi HDS722020ALA330 firmware revision JKAOA28A serial number JK1130YAH531ST WWN 5000cca221d068d5 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 3907029168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enable Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes no 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no 0/0x0 unload no no free-fall no no data set management (TRIM) no -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:14:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8253106564A for ; Thu, 22 Jul 2010 08:14:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 98D0E8FC0C for ; Thu, 22 Jul 2010 08:14:07 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta04.emeryville.ca.mail.comcast.net with comcast id kwE71e0021GXsucA4wE76A; Thu, 22 Jul 2010 08:14:07 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta07.emeryville.ca.mail.comcast.net with comcast id kwE61e0033LrwQ28UwE6sr; Thu, 22 Jul 2010 08:14:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 101419B425; Thu, 22 Jul 2010 01:14:06 -0700 (PDT) Date: Thu, 22 Jul 2010 01:14:06 -0700 From: Jeremy Chadwick To: Charles Sprickman Message-ID: <20100722081406.GA8483@icarus.home.lan> References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adam Vande More , "Andrey V. Elsukov" , freebsd-stable , Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:14:07 -0000 On Thu, Jul 22, 2010 at 04:03:05AM -0400, Charles Sprickman wrote: > On Thu, 22 Jul 2010, Dan Langille wrote: > >Well, I don't have anything to support hotplug. All my stuff is internal. > > > >http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg > > The frankenbox I'm testing on is a retrofitted 1U (it had a scsi > backplane, now has none). > > I am not certain, but I think with 8.1 (which it's running) and all > the cam integration stuff, hotplug is possible. Is a special > backplane required? I seriously don't know... I'm going to give it > a shot though. Yes, a special backplane is required. > Oh, you also might get NCQ. Try: > > [root@h21 /tmp]# camcontrol tags ada0 > (pass0:ahcich0:0:0:0): device openings: 32 NCQ should be enabled by default. "camcontrol identify" will provide much more verbose details about the state of these disks. Don't confuse "identify" with "inquiry". -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:20:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BEC51065672 for ; Thu, 22 Jul 2010 08:20:32 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 09E998FC16 for ; Thu, 22 Jul 2010 08:20:31 +0000 (UTC) Received: from [178.34.160.12] (helo=alya) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1Obr13-000BWJ-Sg; Thu, 22 Jul 2010 12:20:30 +0400 From: Boris Samorodov To: Dan Langille References: <4C47B57F.5020309@langille.org> <4C47B7DD.3070604@langille.org> Date: Thu, 22 Jul 2010 12:20:28 +0400 In-Reply-To: <4C47B7DD.3070604@langille.org> (Dan Langille's message of "Wed, 21 Jul 2010 23:15:41 -0400") Message-ID: <52881603@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:20:32 -0000 On Wed, 21 Jul 2010 23:15:41 -0400 Dan Langille wrote: > On 7/21/2010 11:05 PM, Dan Langille wrote (something close to this): > > First, create a new GUID Partition Table partition scheme on the HDD: > > gpart create -s GPT ad0 > > > > Let's see how much space we have. This output will be used to determine > > SOMEVALUE in the next command. > > > > gpart show > > > > Create a new partition within that scheme: > > gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 > > > > Now, label the thing: > > glabel label -v disk00 /dev/ad0 That command will destroy secondary GPT. > Or, is this more appropriate? > glabel label -v disk00 /dev/ad0s1 -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 08:51:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 920481065677 for ; Thu, 22 Jul 2010 08:51:15 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 330FA8FC1D for ; Thu, 22 Jul 2010 08:51:14 +0000 (UTC) Received: (qmail 42947 invoked by uid 0); 22 Jul 2010 08:51:12 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2010 08:51:12 -0000 Date: Thu, 22 Jul 2010 04:51:11 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Boris Samorodov In-Reply-To: <52881603@ipt.ru> Message-ID: References: <4C47B57F.5020309@langille.org> <4C47B7DD.3070604@langille.org> <52881603@ipt.ru> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 08:51:15 -0000 On Thu, 22 Jul 2010, Boris Samorodov wrote: > On Wed, 21 Jul 2010 23:15:41 -0400 Dan Langille wrote: >> On 7/21/2010 11:05 PM, Dan Langille wrote (something close to this): > >>> First, create a new GUID Partition Table partition scheme on the HDD: >>> gpart create -s GPT ad0 >>> >>> Let's see how much space we have. This output will be used to determine >>> SOMEVALUE in the next command. >>> >>> gpart show >>> >>> Create a new partition within that scheme: >>> gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 >>> >>> Now, label the thing: >>> glabel label -v disk00 /dev/ad0 > > That command will destroy secondary GPT. I was just reading about GUID partitioning last night and saw that one of the benefits is that there's a copy of the partition table kept at the end of the disk. That seems like a pretty neat feature. Do you by any chance have a reference I can point to (I was documenting stuff about GPT in an internal wiki and this is a nice piece of info to have)? Also, how does one access/use the "backup" partition table? Thanks, Charles >> Or, is this more appropriate? >> glabel label -v disk00 /dev/ad0s1 > > -- > WBR, Boris Samorodov (bsam) > Research Engineer, http://www.ipt.ru Telephone & Internet SP > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > _______________________________________________ > 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 22 09:45:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023A71065675 for ; Thu, 22 Jul 2010 09:45:40 +0000 (UTC) (envelope-from bsam@ns.kfs.ru) Received: from ns.kfs.ru (kfs.kfs.ru [194.186.81.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9AAA38FC15 for ; Thu, 22 Jul 2010 09:45:39 +0000 (UTC) Received: from bsam by ns.kfs.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ObsLQ-000P3x-F1; Thu, 22 Jul 2010 13:45:36 +0400 To: Charles Sprickman References: <4C47B57F.5020309@langille.org> <4C47B7DD.3070604@langille.org> <52881603@ipt.ru> From: Boris Samorodov Date: Thu, 22 Jul 2010 13:45:36 +0400 In-Reply-To: (Charles Sprickman's message of "Thu\, 22 Jul 2010 04\:51\:11 -0400 \(EDT\)") Message-ID: <52875423@serv3.int.kfs.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 09:45:40 -0000 Charles Sprickman writes: > On Thu, 22 Jul 2010, Boris Samorodov wrote: >> On Wed, 21 Jul 2010 23:15:41 -0400 Dan Langille wrote: >>> On 7/21/2010 11:05 PM, Dan Langille wrote (something close to this): >> >>>> First, create a new GUID Partition Table partition scheme on the HDD: >>>> gpart create -s GPT ad0 >>>> >>>> Let's see how much space we have. This output will be used to determine >>>> SOMEVALUE in the next command. >>>> >>>> gpart show >>>> >>>> Create a new partition within that scheme: >>>> gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 >>>> >>>> Now, label the thing: >>>> glabel label -v disk00 /dev/ad0 >> >> That command will destroy secondary GPT. > > I was just reading about GUID partitioning last night and saw that one > of the benefits is that there's a copy of the partition table kept at > the end of the disk. That seems like a pretty neat feature. > > Do you by any chance have a reference I can point to (I was > documenting stuff about GPT in an internal wiki and this is a nice > piece of info to have)? > > Also, how does one access/use the "backup" partition table? http://en.wikipedia.org/wiki/GUID_Partition_Table -- WBR, bsam From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 10:16:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92DAC1065672; Thu, 22 Jul 2010 10:16:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 82E448FC16; Thu, 22 Jul 2010 10:16:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o6MAG1Fj014668; Thu, 22 Jul 2010 20:16:02 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 22 Jul 2010 20:16:01 +1000 (EST) From: Ian Smith To: Spil Oss In-Reply-To: Message-ID: <20100722153846.S62748@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1630664149-1279790660=:62748" Content-ID: <20100722194247.N62748@sola.nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org, snasonov@bcc.ru Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 10:16:14 -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. --0-1630664149-1279790660=:62748 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20100722194247.L62748@sola.nimnet.asn.au> On Wed, 21 Jul 2010, Spil Oss wrote: > Hi Sergey, > > I'm dumbstruck! > > Switching 'ip' to 'ip4' in both the divert rules fixed my problem. > Personally I think that should go into the UPDATING file as well. I > wouldn't have found it if you hadn't told me! > > Many thanks, > > Spil. This points to a number of issues, not least the effect of people being led to using the currently dreadful IPFW section of the handbook, which contains so many conceptual and factual errors that I really don't know where to begin on a solution .. so I won't discuss that further except as it relates to the actual ruleset you're using. In your just-filed PR http://www.freebsd.org/cgi/query-pr.cgi?pr=148827 you say your ruleset is based on '30.6.5.7 An Example NAT and Stateful Ruleset', so I'm assuming it's broadly based on example #2 there. > On Wed, Jul 21, 2010 at 9:08 PM, Spil Oss wrote: > > Hi Sergey, > > > > Has the change from ip to ip4 solved the problem for you? The > > documentation states that proto 'ip' is the same as 'all' "Matches any > > packet." > > > > Rule # 60 > >     $cmd 060 skipto 1000 ip6 from any to any > > will have already skipped to the ipv6 rules block thus proto 'ip' > > should always match remaining packets. You don't show any rules beyond number 510, so we must take it on faith that you're handling your ip6 traffic appropriately. I don't know much about it, and will be guided by the IPv6 rules lately in rc.firewall. However if natd is barfing on being passed ip6 packets, that should be fixed in natd, which should do nothing with packets it doesn't care about - as it does with ip4 packets not eligible for NAT translation - except to re-enter the firewall at the next higher-numbered rule, which of course relies on sysctl net.inet.ip.fw.one_pass being set to 0. Either that or ipfw should explicitly decline to divert non-ip4 traffic. I don't know whether or how this would also affect ipfw in-kernel nat. If in fact no ip6 packets are being passed to natd as rule 60 indicates, at least for traffic inbound to ipfw, then that is indeed strange, but I suspect that on the outbound pass, using this rather confusing 'skipto 500 .. keep-state' logic, perhaps some outbound ip6 packets may have been being passed to natd .. Could you check to see if it works only changing the _outbound_ divert rule from ip to ip4, leaving the inbound one at 'ip'? If so, this would validate your original theory re rule 60, on the inbound pass. If not, it may be a useful data point for resolving the problem. > > Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup scripts > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148137&cat=conf > > Don't know if that's directly related, but it may be worth a try to > > revert back to the RELENG_8_0 script. > > > > Will let you now my findings. Did you try that, to see whether it was an issue? More below .. > > Kind regards, > > > > Spil. > > > > > > On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote: > >> Hello Spill, > >> > >> I have get the same trouble after updating my 8.0 Stable. I thing you need > >> modify some firewall rules. > >> > >> Please change > >> > >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > >> > >> to > >> > >> $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound > >> > >> and > >> > >> $cmd 500 divert natd ip from any to any out via $pif > >> > >> to > >> > >> $cmd 500 divert natd ip4 from any to any out via $pif > >> > >> accordingly. > >> > >> -- > >> > >> Best Regards, > >> > >> Nasonov Sergey > > > > > > On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: > >> Hi, > >> > >> Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or > >> firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last > >> night?) > >> - 8.1 booted fine > >> - connections from the system itself were fine > >> - connections from my jails to the internet were not working > >> - connections from my LAN/WLAN to the internet were not working > >> Reverting back to 8.0-p2 with the same configuration works fine. > >> > >> In UPDATING I see that rc.firewall and rc.firewall6 were unified. > >> > >> Setup is > >> - xl0 connected to internet/public IP via dhcp > >> - bge0/wlan0(ath0) connected to LAN > >> - jails have ip's on bge0 in the same subnet as the LAN > >> - allow all from any to any via bge0|wlan0|lo0 The latter point looks problematic, see below. > >> - NAT using natd > >> > >> My guess is that something's changed to ipfw that is affecting my > >> network settings. Any clues where I went wrong? > >> > >> Help appreciated/ Kind regards, > >> > >> Spil. > >> > >> rc.conf: > >> firewall_enable="YES" > >> firewall_script="/etc/ipfw.rules" > >> > >> natd.conf > >> interface xl0 > >> dynamic yes > >> same_ports yes > >> # http/https to http jail > >> redirect_port tcp 192.168.2.3:80 80 > >> redirect_port tcp 192.168.2.3:443 443 > >> > >> Part of /etc/ipfw.rules > >> #!/bin/sh > >> cmd="ipfw -q add" > >> skip="skipto 500" > >> pif=xl0 > >> pif6=gif0 > >> ext6="2001:dead:beef:1::1" > >> ks="keep-state" > >> > >> ipfw -q -f flush > >> > >> # Allow internal traffic > >> $cmd 002 allow all from any to any via bge0 # exclude LAN traffic > >> $cmd 003 allow all from any to any via lo0  # exclude loopback traffic > >> $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic > >> $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic > >> $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic There are problems wih this, based on the apparent misunderstanding (by the present IPFW section's author) of how 'via' works when direction (in or out) and/or a specific interface (recv or xmit) is not specified. I'm assuming that apart from lo0, traffic coming in on some or all of bge0, wlan0, bridge0 and tun0 is to be translated by NAT if destined to be going out on the public interface xl0, right? Certainly you've indicated that your jails are on bge0 with 192.168.x.x addresses, but these are local aliases which wouldn't show bge0 as the recv interface: "A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface." Let's consider just one initial packet coming in from bge0 from some private LAN address, other than your local jail IPs, that's destined for an outside address and so needs to be NAT'd before transmission. On the inbound pass, the packet comes in on bge0 and so satisfies 'via bge0' so is immediately allowed in, and that's it. That may be ok, as NAT is here only to be performed on the outbound pass, but it could be anything, and there's no protection here against it being spoofed, as opposed to placement of NAT rules in the rc.firewall 'simple' ruleset. So having been allowed in, after kernel routing (but before NAT, as we haven't reached any check-state rule yet) it reenters the firewall for the outbound pass with its xmit interface set to xl0, but with its recv interface still set to bge0. Thus the unqualified 'via bge0' is still true, so this packet is passed immediately, with source address still set to the private LAN address, without having been translated by NAT. As are similarly any packets bound for the outside initially coming in on wlan0, bridge0 or tun0 that originate from other than the local host. This could be obviated by replacing 'via $if' by 'in recv $if' in the rules above, so such packets going out pass through the firewall rules, including setting state for reply packets received on the outside iface. So as is, the rules below are only applied to outbound packets that are NOT received on those interfaces, which doesn't sound like what you'd intend, except packets generated by or destined for the local box. > >> # Allow all encapulated IPv6 to/from tunnel PoP > >> $cmd 010 allow ip4 from to me via $pif > >> $cmd 010 allow ip4 from me to via $pif Taken on faith. > >> # Black-hole some stuff using tables > >> $cmd 050 drop ip from "table(17)" to any in via $pif > >> $cmd 050 drop ip from any to "table(17)" out via $pif > >> > >> # Separate IPv6 rules (no NAT!) > >> $cmd 060 skipto 1000 ip6 from any to any > >> > >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > >> packets from external > >> $cmd 101 check-state > >> > >> # Authorized outbound packets > >> $cmd 130 $skip icmp from any to any out via $pif $ks > >> $cmd 150 $skip tcp from any to any out via $pif $ks > >> $cmd 151 $skip udp from any to any out via $pif $ks > >> > >> $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks > >> > >> # Deny all inbound traffic from non-routable reserved address spaces > >> $cmd 300 unreach host all from 192.168.0.0/16  to any in via $pif > >> #RFC 1918 private IP > >> $cmd 301 unreach host all from 172.16.0.0/12   to any in via $pif > >> #RFC 1918 private IP > >> $cmd 302 unreach host all from 10.0.0.0/8      to any in via $pif > >> #RFC 1918 private IP > >> $cmd 303 unreach host all from 127.0.0.0/8     to any in via $pif  #loopback > >> $cmd 304 unreach host all from 0.0.0.0/8       to any in via $pif  #loopback > >> $cmd 305 unreach host all from 169.254.0.0/16  to any in via $pif > >> #DHCP auto-config > >> $cmd 306 unreach host all from 192.0.2.0/24    to any in via $pif > >> #reserved for docs > >> $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif  #Sun cluster > >> $cmd 308 unreach host all from 224.0.0.0/3     to any in via $pif > >> #Class D & E multicast > >> > >> # Deny packets that did not match the dynamic rule table > >> #$cmd 330 deny all from any to any frag in via $pif # All late fragments The author (here and in other writings) expounds that fragmented packets are necessarily bad, and indicate an attack of some sort. Not in fact so; eg if you were using say zen.spamhaus.org as an RBL you'll be seeing valid fragmented UDP port 53 packets of around 2000 bytes total all day. I gather DNSSEC will also require acceptance of fragmented datagrams. The default rc.firewall rules pass IP frags, and I suggest you do too. > >> #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK > >> > >> # Authorized inbound packets > >> $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-exceeded Add icmptype 3 here to pass unreachables including path MTU discovery. > >> $cmd 420 allow tcp from any to me ssh in via $pif setup $ks > >> $cmd 421 allow tcp from any to me smtp in via $pif > >> $cmd 422 allow tcp from any to me http in via $pif > >> $cmd 423 allow tcp from any to me https in via $pif > >> $cmd 424 allow tcp from any to me imaps in via $pif > >> > >> #$cmd 449 unreach host ip from any to any in via $pif > >> $cmd 448 reject log all from any to any in via $pif > >> $cmd 449 reject log all from any to any out via $pif > >> $cmd 450 reject log ip from any to any Security-wise you'd be better off just dropping these using deny than reject (deprecated, equivalent to unreach host), here and above. However I don't wish to let such details obscure the more major issue. > >> > >> # This is skipto location for outbound stateful rules > >> $cmd 500 divert natd ip from any to any out via $pif > >> $cmd 510 allow ip from any to any cheers, Ian --0-1630664149-1279790660=:62748-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 10:20:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6581065673 for ; Thu, 22 Jul 2010 10:20:29 +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 B6BE18FC16 for ; Thu, 22 Jul 2010 10:20:28 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-158-44.lns6.adl6.internode.on.net [121.45.158.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6MAKI5t042162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Jul 2010 19:50:25 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4C47B57F.5020309@langille.org> Date: Thu, 22 Jul 2010 19:50:18 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <3D5AABDD-F51B-4B7A-BC7F-BAA72F829A21@gsoft.com.au> References: <4C47B57F.5020309@langille.org> To: Dan Langille X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 10:20:29 -0000 On 22/07/2010, at 12:35, Dan Langille wrote: > Why use glabel? >=20 > * So ZFS can find and use the correct HDD should the HDD device ever > get renumbered for whatever reason. e.g. /dev/da0 becomes /dev/da6 > when you move it to another controller. >=20 > Why use partitions? >=20 > * Primarily: two HDD of a given size, say 2TB, do not always provide > the same amount of available space. If you use a slightly smaller > partition instead of the entire physical HDD, you're much more > likely to have a happier experience when it comes time to replace an > HDD. >=20 > * There seems to be a consensus amongst some that leaving the start = and > and of your HDD empty. Give the rest to ZFS. I would combine both! GPT generates a UUID for each partition and glabel presents this so ZFS = can use it, eg I have.. [cain 19:45] ~ >sudo zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ = WRITE CKSUM tank ONLINE 0 = 0 0 raidz2 ONLINE 0 = 0 0 gptid/d7467802-418f-11df-bcfc-001517e077fb ONLINE 0 = 0 0 gptid/d7eeeced-418f-11df-bcfc-001517e077fb ONLINE 0 = 0 0 gptid/d8761aa0-418f-11df-bcfc-001517e077fb ONLINE 0 = 0 0 gptid/d9083d18-418f-11df-bcfc-001517e077fb ONLINE 0 = 0 0 gptid/d97203ec-418f-11df-bcfc-001517e077fb ONLINE 0 = 0 0 and on each disk.. [cain 19:46] ~ >gpart list ada0 =20 Geom name: ada0 fwheads: 16 fwsectors: 63 last: 1953525134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: (null) length: 8589934592 offset: 17408 type: freebsd-swap index: 1 end: 16777249 start: 34 2. Name: ada0p2 Mediasize: 991614917120 (924G) Sectorsize: 512 Mode: r1w1e2 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: (null) length: 991614917120 offset: 8589952000 type: freebsd-zfs index: 2 end: 1953525134 start: 16777250 Consumers: 1. Name: ada0 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e3 The only tedious part is working out which drive has what UUIDs on it = because gpart doesn't list them. The advantage of using the UUIDs is that if you setup another machine = the same way you don't have to worry about things when you plug in the = disks from it to recover something. Or perhaps you are upgrading at the = same time as replacing hardware so you have all the disks in at once. > Create a new partition within that scheme: >=20 > gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 >=20 > Why '-b 34'? Randi pointed me to = http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains what = the first 33 LBA are used for. It's not for us to use here. If you don't specify -b it will DTRT - that's how I did it. You can also specify the size (and start) in human units (Gb etc). -- 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 Thu Jul 22 10:24:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C84EF106567D for ; Thu, 22 Jul 2010 10:24:37 +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 2FE068FC12 for ; Thu, 22 Jul 2010 10:24:36 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-158-44.lns6.adl6.internode.on.net [121.45.158.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6MAOMLc042265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Jul 2010 19:54:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Thu, 22 Jul 2010 19:54:22 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <5609C94D-CDD7-4798-9E60-7686086999A1@gsoft.com.au> References: <4C47B57F.5020309@langille.org> To: Adam Vande More X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Charles Sprickman , freebsd-stable , Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 10:24:37 -0000 On 22/07/2010, at 13:59, Adam Vande More wrote: > To be clear, we are talking about data partitions, not the boot one. > Difficult for me to explain concisely, but basically it has to do with = seek > time. A mis-aligned partition will almost always have an extra seek = for > each standard seek you'd have on aligned one. There have been some > discussions about in the archives, also this is not unique to FreeBSD = so > google will have a more detailed and probably better explanation. Newer disks have 4kb sectors internally at least, and some expose it to = the OS. If you create your partitions unaligned to this every read and write = will involve at least one more sector than it would otherwise and that = hurts performance. The disks which don't expose it have a jumper which offsets all accesses = to Windows XP's performance doesn't take a dive but I'm not sure if that = helps FreeBSD. -- 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 Thu Jul 22 12:50:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3BE01065673 for ; Thu, 22 Jul 2010 12:50:14 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 758D88FC08 for ; Thu, 22 Jul 2010 12:50:14 +0000 (UTC) Received: from zidane.cc.vt.edu (zidane.cc.vt.edu [198.82.163.227]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id o6MCnSxT007747; Thu, 22 Jul 2010 08:49:43 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by zidane.cc.vt.edu (MOS 4.1.8-GA FastPath queued) with ESMTP id JQE01492; Thu, 22 Jul 2010 08:49:43 -0400 (EDT) Received: from gromit.tower.lib.vt.edu (gromit.tower.lib.vt.edu [128.173.51.22]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id o6MCngDA005619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Jul 2010 08:49:43 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <4C47B57F.5020309@langille.org> Date: Thu, 22 Jul 2010 08:49:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A35E293-87C2-4E96-863F-1734B2ECA796@gromit.dlib.vt.edu> References: <4C47B57F.5020309@langille.org> To: Dan Langille X-Mailer: Apple Mail (2.1081) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Mirapoint-IP-Reputation: reputation=neutral-1, source=Fixed, refid=n/a, actions=MAILHURDLE SPF TAG X-Junkmail-Status: score=10/50, host=zidane.cc.vt.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020207.4C483E67.0111,ss=1,fgs=0, ip=0.0.0.0, so=2009-09-22 00:05:22, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: freebsd-stable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:50:14 -0000 On Jul 21, 2010, at 11:05 PM, Dan Langille wrote: > I hope my terminology is correct.... >=20 > I have a ZFS array which uses raw devices. I'd rather it use glabel = and supply the GEOM devices to ZFS instead. In addition, I'll also = partition the HDD to avoid using the entire HDD: leave a little bit of = space at the start and end. >=20 > Why use glabel? >=20 > * So ZFS can find and use the correct HDD should the HDD device ever > get renumbered for whatever reason. e.g. /dev/da0 becomes /dev/da6 > when you move it to another controller. I have created ZFS pools using this strategy. However, about a year ago = I still fell foul of the drive shuffling problem, when GEOM labels = appeared not to be detected properly: = http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003654.html This was using RELENG_7, and the problem was provoked by external USB = drives. The same issue might not occur with FreeBSD 8.x, but I thought I'd point = out my experience as a possible warning about using glabel. Nowadays, I use GPT labels ("gpart ... -l somelabel", referenced via = /dev/gpt/somelabel). > Why use partitions? >=20 > * Primarily: two HDD of a given size, say 2TB, do not always provide > the same amount of available space. If you use a slightly smaller > partition instead of the entire physical HDD, you're much more > likely to have a happier experience when it comes time to replace an > HDD. >=20 > * There seems to be a consensus amongst some that leaving the start = and > and of your HDD empty. Give the rest to ZFS. You should also try and accommodate 4K sector size drives these days. = Apparently, the performance boosts from hitting 4K-aligned sectors can = be very good. Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 14:28:55 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26F5106564A; Thu, 22 Jul 2010 14:28:55 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 768308FC27; Thu, 22 Jul 2010 14:28:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6MEStP6035807; Thu, 22 Jul 2010 14:28:55 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6MEStnW035806; Thu, 22 Jul 2010 14:28:55 GMT (envelope-from danger) Date: Thu, 22 Jul 2010 14:28:55 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20100722142855.GA35739@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Status Report April-June, 2010 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 14:28:55 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between April and June 2010. It is the second of the four reports planned for 2010, and contains 47 entries. During this period, a lot of work has gone into the development of new minor version of FreeBSD, 8.1-RELEASE, which should be released within days. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Please note that the deadline for submissions covering the period between July and September 2010 is October 15th, 2010. __________________________________________________________________ Google Summer of Code * Binary Package Patch Infrastructure -- pkg_patch * Collective Resource Limits (aka. Jobs) * ExtFS Status Report * File System Changes Notification * Google Summer of Code 2010 * Making Ports Work with Clang * Namecache Improvements -- dircache * Package Management Library -- libpkg * Packet-Capturing Stack -- ringmap Projects * Clang Replacing GCC in the Base System * DAHDI/FreeBSD Project * Distributed Audit * General-Purpose DMA Framework * GEOM-Based Pseudo-RAID Implementation -- geom_pseudoraid * GPIO Framework * New System Installer -- pc-sysinstall * OpenAFS Port * Resource Containers * V4L Support in Linux Emulator FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Core Team Election * Release Engineering Team * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * libnetstat(3) Kernel * Interrupt Threads * Jail-Based Virtualization * Kernel Event Timers Infrastructure * ZFS Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Japanese Documentation Project * The FreeBSD Spanish Documentation Project Userland Programs * BSD-Licensed grep in Base System * BSD-Licensed iconv in Base System * FreeBSD Services Control -- fsc Architectures * Flattened Device Tree for Embedded FreeBSD * FreeBSD on the Sony Playstation 3 * FreeBSD/avr32 * FreeBSD/powerpc64 * FreeBSD/sparc64 Ports * Chromium Web Browser * FreeBSD Haskell * Ports Collection Miscellaneous * BSD-Day@2010 * BSDCan * meetBSD 2010 -- The BSD Conference __________________________________________________________________ Binary Package Patch Infrastructure -- pkg_patch URL: http://wiki.FreeBSD.org/IvanVoras/pkg_patch Contact: Ivan Voras The pkg_patch project is about creating a binary package patch infrastructure which would allow users to patch their live system's packages in an easy and efficient way. It is a C program written to interface with libpkg (for things which are common to all pkg utilities) meant to be included in the base system when it is done. It comes with built-in mass patch creation and application commands. It is funded by Google Summer of Code 2010. Open tasks: 1. Finish the project. 2. Get some testing for it. 3. Convince the Port Management Team it is actually a Good Thing to have even as an experimental feature. 4. Agree upon the policy on which package patches will be created (i.e. from which point in time to which point in time), assuming the "stable" package tree idea has still not gotten traction. __________________________________________________________________ BSD-Day@2010 URL: http://wiki.freebsd.org/BSDDay_2010 Contact: Gábor Páli The purpose of this one-day event is to gather Central European developers of today's open-source BSD systems to popularize their work and their organization, and to provide an interface for real-life communication. There are no formalities, no papers, and no registration or participation fee. However the invited developers are encouraged to give a talk on their favorite BSD-related topic or join the live forum, then have a beer with the other folks around. The goal is to motivate potential future developers and users, especially undergraduate university students to work with BSD systems. This year's BSD-Day will be held in Budapest, Hungary at Eötvös Loránd University, Faculty of Informatics on November 20, 2010. Open tasks: 1. Apply as a developer, we are still looking for BSD people in the area. __________________________________________________________________ BSD-Licensed grep in Base System URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 008/gabor_textproc/grep Contact: Gábor Kövesdán A portbuild test showed that grep is basically ready to enter HEAD, but there were a few failures that seem to be related. These have to be investigated and fixed before committing grep to 9-CURRENT. Open tasks: 1. Investigate and fix some minor issues. __________________________________________________________________ BSD-Licensed iconv in Base System URL: http://kovesdan.org/patches/iconv-20100708.diff Contact: Gábor Kövesdán The work has been completed and the GNU compatibility levels seems to be quite high. One exception is the fallback support. It is difficult to implement that facility in this implementation because the design is somewhat different. Probably, it will not be a big problem because that functionality is not even documented in the GNU version so few applications might use it. Open tasks: 1. Run a portbuild test and solve possible problems that show up. __________________________________________________________________ BSDCan URL: http://www.BSDCan.org/2010/ Contact: Dan Langille BSDCan 2010 was our 7th conference. As has become the custom, a FreeBSD developer summit was held in the two days before the conference. Record numbers attended the Dev Summit which carried over into the conference proper. It was great to see representatives from so many more companies. I saw many great ideas take root and the start of cooperation on several projects. The talks during the Dev Summit are beginning to attract a wider audience, and we have been talking about opening this up to the general audience by creating a fourth track at BSDCan 2011. As impossible as it sounds, each year has seen an increase in the quality of talks and the number of proposals submitted. Open tasks: 1. I need people to help with various pre-conference tasks: website updates, booking travel, etc. __________________________________________________________________ Chromium Web Browser URL: http://chromium.hybridsource.org URL: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=146302 Contact: Ruben Chromium is a Webkit-based web browser that is largely BSD-licensed. It works very well on FreeBSD and supports new features like HTML 5 video. This effort uses a new hybrid-source model, where the FreeBSD patches are largely kept closed for a limited time. I submitted Chromium to ports a couple of months ago and recently updated the submission to the stable 5.0.375 branch. The port is ready to be committed pending final legal approval by the FreeBSD Foundation. Further work remains to port Chromium to FreeBSD completely, such as porting the task manager fully and making sure extensions work properly. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach In the past quarter we imported Clang into FreeBSD and it is being built by default on i386/amd64/powerpc. We have not yet commited the necessary changes to let world compile with Clang. Some bugs and warnings were fixed in HEAD as a result of the Clang import and people are exploring more and more areas (DTrace, etc). There are some bug fixes in Clang/LLVM as well that stem from the import (unknown pragmas warnings, etc). Roman Divacky and Matthew Fleming are working on ELF writer in LLVM. This is meant as a replacement for assembler (currently we use an outdated GNU as(1)). This work is progressing nice, currently it is able to produce working variants of hello world in C and C++, and some other small programs from "configure run". Open tasks: 1. Import of newer Clang/LLVM into HEAD. 2. Help with ARM/MIPS/SPARC64. 3. Start pushing src patches into HEAD. 4. More testing of Clang on third-party applications (ports). 5. More work on the ELF writer. __________________________________________________________________ Collective Resource Limits (aka. Jobs) URL: http://wiki.FreeBSD.org/G%C3%A1borSoC2010 URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 010/gabor_jobs/irix_jobs Contact: Gábor Kövesdán The SGI IRIX operating system has a concept, called job, which is used to group processes together and then apply resource limits on them. The purpose of this project is to implement this facility on FreeBSD. I spent most of the time familiarizing myself with how things are done inside the kernel, how syscalls work, etc. So far, I have the basic understanding needed and I added the most important syscalls to group processes together into jobs and manipulate collective resource limits on them. There is a bug, which I am tracking down at the moment, after this I can start to implement actual resource limit enforcement. For some of the limit types, it will be relatively easy but some others will take more effort and studies. Open tasks: 1. Fix the showstopper bug, which prevent me working on actual limit enforcement. 2. Implement limit enforcements for all of the limits supported by IRIX. 3. Add support for userland facilities and make utilities jobs-aware, like showing jobs in ps(1), etc. __________________________________________________________________ DAHDI/FreeBSD Project URL: http://www.asterisk.org/dahdi/ URL: https://spreadsheets.google.com/pub?key=0Arw6eRL10yIwdGhLdGJWUHF4b3ExQz Bsd3BGd2tublE&hl=en&single=true&gid=0&output=html Contact: Max Khon The purpose of DAHDI/FreeBSD project is to make it possible to use FreeBSD as a base system for software PBX solutions. DAHDI (Digium/Asterisk Hardware Device Interface) is an open-source device driver framework and a set of hardware drivers for E1/T1, ISDN digital, and FXO/FXS analog cards [1]. Asterisk is one of the most popular open-source software PBX solutions [2]. The project includes porting DAHDI framework and hardware drivers for E1/T1, FXO/FXS analog, and ISDN digital cards to FreeBSD. This also includes TDMoE support, software and HW echo cancellation (Octasic, VPMADT032), and hardware transcoding support (TC400B). The work is ongoing in the official DAHDI SVN repository with the close collaboration with DAHDI folks at Digium. The project is nearing completion. The DAHDI framework and hardware drivers telephony cards have been ported and tested. There are a number of success stories from early adopters who have been using E1/T1 and FXO/FXS cards on FreeBSD for several months. __________________________________________________________________ Distributed Audit URL: http://p4web.freebsd.org/@md=d&cd=//&c=wHa@//depot/projects/soc2010/dis audit/?ac=83 URL: http://wiki.FreeBSD.org/SOC2010SergioLigregni Contact: Sergio Ligregni 90% of the functionality is working, the daemons sync two systems in a master-slave paradigm. Open tasks: 1. Standardize the code to meet FreeBSD requirements. 2. Implement SSL in network communication. 3. Perform security improvements and bug fixing, strlxxx() functions, memcpy() instead of strcpy() when using non-char variables. 4. Integrate with the current Audit subsystem. __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDfoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart SIFTR was recently imported into HEAD and will be backported to 8-STABLE in time to be included in 8.2-RELEASE. TCP reassembly queue autotuning will be ready for public testing within the next week and will be committed soon after. It too will be backported to 8-STABLE after an appropriate burn in period. Open tasks: 1. Try SIFTR out and let me know if you run into any problems. 2. Solicit external testing for and commit the reassembly queue autotuning patch. __________________________________________________________________ ExtFS Status Report URL: http://wiki.FreeBSD.org/SOC2010ZhengLiu Contact: Zheng Liu This project has two goals: pre-allocation algorithm and ext4 read-only mode. The aim of pre-allocation algorithm is to implement a reservation window mechanism. Now this mechanism has been introduced. The performance comparison can be found on the wiki. The aim of ext4 read-only mode is to make it possible to read ext4 file system in read-only mode when the hard disk is formatted with default features. Currently it only supports a few features, such as extents, huge_file. Others features will be added, such as dir_index, uninit_bg, dir_nlink, flex_bg and extra_isize. My work resides in extfs and ext4fs branch of Perforce. __________________________________________________________________ File System Changes Notification Contact: Ilya Putsikau The aim of the project is to implement an inotify-compatible file system change notification mechanism for FreeBSD and later, and add inotify support to linuxulator. The result, fsnotify is already functional but not yet compatible with inotify in some details. Open tasks: 1. Add access permissions checks. 2. Port inotify test cases. 3. Fix compatibility issues. 4. Add linuxulator support. __________________________________________________________________ Flattened Device Tree for Embedded FreeBSD URL: http://wiki.FreeBSD.org/FlattenedDeviceTree Contact: Rafal Jaworowski The purpose of this project was to provide FreeBSD with support for the Flattened Device Tree (FDT) technology. A mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumers of this technology are embedded FreeBSD platforms (ARM, MIPS, PowerPC), where a lot of designs are based on similar chips, but have different assignment of pins, memory layout, addresses ranges, interrupts routing and other resources. Current state highlights: * All code and documentation developed during the course of this project was merged with HEAD, which covers FDT support for the following platforms and systems: * Marvell ARM + DB-88F5182 + DB-88F5281 + DB-88F6281 + DB-78100 + SheevaPlug * Freescale PowerPC + MPC8555CDS + MPC8572DS * The FDT infrastructure (bus drivers, helper libraries, and routines shared across architectures and platforms) allows for easier porting to new platforms or variations. The initially supported systems offer a working example of how to migrate towards FDT approach. Work on this project was sponsored by the FreeBSD Foundation. Open tasks: 1. Improve how-to and guidelines for new adopters (how to convert to FDT and so on). 2. Migrate more existing embedded FreeBSD platforms (ARM, MIPS) to FDT approach. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://wiki.FreeBSD.org/Bugathons URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/easy_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/prs_for_all_groups.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth After a long hiatus, we aim to hold a bugathon on the weekend of the 6th - 9th August. Everybody is welcome to help resolve or progress PRs from the database. We appreciate the help of committers and non-committers alike, please join us on IRC in #freebsd-bugbusters on EFnet if you are free at any time over that weekend and can help. Please see the "Bugathon" URL for more information. Mark Linimon and Gavin Atkinson held a session on the State of Bugbusting at BSDCan, which was well attended and led to some interesting discussions. Time was also found to sit down with several committers to discuss long-standing PRs. The bugbusting team continue work on trying to make the GNATS PR database more accessible and easier for committers to find and resolve PRs. As a result, PRs continue to be classified as they arrive, by adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. Reports are generated from these nightly, grouping related PRs in one place, sorted by tag or man page. Mark Linimon continues work on producing a new report, Summary Chart of PRs with Tags, which sorts tagged PRs into logical groups such as file system, network drivers, libraries, and so forth. The slice labels are clickable and may further subdivide the groups. The chart is updated once a day. You can consider it as a prototype for browsing "subcategories" of kernel PRs. The "recommended list" has been split up into "non-trivial PRs which need committer evaluation" and the "easy list" of trivial PRs, to try to focus some attention on the latter. Various new reports exist, including "PRs containing code for new device drivers", "PRs which are from FreeBSD vendors or OEMs", and "PRs referencing other BSDs". It is now possible for interested parties to be emailed a weekly, customized, report similar in style to the above. If you are interested in setting one up, contact linimon@FreeBSD.org. Our clearance rate of PRs, especially in kern and bin, seems to be improving. The number of non-ports PRs has stayed almost constant since the last status report. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Plan and manage the bugathon in August, and get as many people as possible interested in participating. 2. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Core Team Election Contact: Core Team The 2010 FreeBSD core team election was recently completed. The FreeBSD core team acts as the project's "board of directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, et cetera), and making any other administrative or policy decisions as needed. The core team has been elected by FreeBSD developers every 2 years since 2000, and this marks our 6th democratically elected core team. The new core team would like to thank outgoing members Kris Kennaway, Giorgos Keramidas, George V. Neville-Neil, Murray Stokely, and Peter Wemm for their service over the past two (and in some cases, many more) years. The core team would also especially like to thank Dag-Erling SmÅ™grav for running the election. The newly elected core team members are: * John Baldwin * Konstantin Belousov * Warner Losh * Pav Lucistnik * Colin Percival The returning core team members are: * Wilko Bulte * Brooks Davis * Hiroki Sato * Robert Watson __________________________________________________________________ FreeBSD Haskell URL: http://wiki.FreeBSD.org/Haskell URL: http://www.FreeBSD.org/ports/haskell.html URL: http://www.haskell.org/mailman/listinfo/freebsd-haskell Contact: Gábor Páli Contact: Giuseppe Pilichi Contact: Ashish Shukla Our efforts on porting the generalized, general-purpose purely functional programming language, Haskell has rallied, since two new committers, Giuseppe Pilichi and Ashish Shukla joined recently, forming the FreeBSD Haskell Team. Over the last months, FreeBSD/i386 and FreeBSD/amd64 have become Tier-1 platforms, featuring officially supported vanilla binary distributions for the Glasgow Haskell Compiler starting from version 6.12.1. We introduced a unified ports infrastructure for Haskell Cabal ports, which also makes possible the direct translation of Cabal package descriptions to FreeBSD ports. The number of Haskell package ports increases steadily. Open tasks: 1. Improve support for Haskell Cabal packages and their translation. 2. Create a port for Haskell Platform. 3. Add more Haskell package ports. 4. Test and send feedback. __________________________________________________________________ FreeBSD on the Sony Playstation 3 URL: http://svn.FreeBSD.org/viewvc/base/user/nwhitehorn/ps3/ Contact: Nathan Whitehorn Work has begun to port FreeBSD/powerpc64 to the IBM Cell-based Sony Playstation 3, using the OtherOS feature present on some models of the console. As of July 14, the FreeBSD boot loader is ported, and it is possible to netboot a kernel, which has support for the framebuffer, MMU, and device discovery. Once work on drivers for the network interface and interrupt controller is complete, it will be possible to boot the console multi-user. __________________________________________________________________ FreeBSD Services Control -- fsc URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes FreeBSD Services Control is a mix of binaries which integrate into the rc.d system and provide for service (daemon) monitoring. It knows about signals, pidfiles, and uses very few resources. The fsc daemon (fscd) runs in the background once the system has started. Services are then added to this daemon via the fscadm control utility, and from there they will be monitored. When they die, depending on the reason, they will be restarted. Certain signals may be ignored (list not decided) and fscd will remove that service from monitoring. Every action is logged to the system logging daemon. Additionally, the fscadm utility may be used to inquire about what services are monitored, their pidfile location, and current process ID. FSC provides several advantages over the third-party daemontools package. For example, fscd uses push notifications instead of polling; fscd is an internal, FreeBSD-maintained software package accessible to all developers, where daemontools would have to be a port and require us to maintain patches; fscd could be easily integrated with the current rc.d infrastructure. Partially based on the ideas of daemontools and Solaris Service Service Mangement Facility (SMF), this could be an extremely useful tool for FreeBSD systems. Open tasks: 1. Testing. Get feedback on how it works in various environments. 2. Code review. 3. Other ideas on the rc.d integration. 4. Update the manual pages. __________________________________________________________________ FreeBSD/avr32 URL: http://wiki.FreeBSD.org/FreeBSD/avr32 Contact: Oleksandr Tymoshenko The FreeBSD/avr32 project was started by Arnar Mar Sing, and actively developed by him and Ulf Lilleengen. It successfully reached single-user stage but since then has not progressed much. At the moment I am trying to get it back into shape. So far some problems with toolchain on i386 host have been fixed, buildkernel succeeds, buildworld succeeds with some exceptions. Next step would be fixing pmap and bringing port back to single-user stage. __________________________________________________________________ FreeBSD/powerpc64 URL: http://people.FreeBSD.org/~nwhitehorn/FreeBSD-9.0-20100715-SNAP-powerpc 64/ Contact: Nathan Whitehorn On July 13, FreeBSD/powerpc64 was integrated into HEAD. This provides support for fully 64-bit operation on 64-bit PowerPC machines conforming to the Book-S specification, including the PowerPC 970, Cell, and POWER4-7. Hardware support is currently limited to Apple machines, although this should expand in the near future. Currently supported hardware: * Apple Xserve G5 * Apple Power Macintosh G5 * Apple iMac G5 __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Since the last status report some issues with cas(4) have been fixed, allowing it to work with Sun GigaSwift Ethernet 1.0 MMF cards (Cassini Kuheen, part no. 501-5524) as well as the on-board interfaces of Sun Fire B100s server blades (for the Sun Fire B1600 platform). Support for Fujitsu (Siemens) PRIMEPOWER 250 based on SPARC64 V CPUs has been added. PRIMEPOWER 450, 650, and 850 likely also work but have not been tested. This also means that the building blocks for support of machines based on SPARC64 VI and VII CPUs like the Fujitsu/Sun SPARC Enterprise Mx000 series are now in place, but they need testing as well. The problems with Schizo version 7 bridges (actually the firmware of these machines) triggering panics during boot finally should be solved. The work on getting Sun Fire V1280 supported has been stalled due to access to such machines no longer being available. The above mentioned improvements are/will be available in FreeBSD 8.1-RELEASE and 7.4-RELEASE. Open tasks: 1. Access to machines based on SPARC64 VI and VII CPUs, like the Fujitsu/Sun SPARC Enterprise Mx000 series would be appreciated. 2. Someone adding support for 64-bit SPARC V9 to Clang/LLVM, and getting it on par with GCC would be appreciated. __________________________________________________________________ General-Purpose DMA Framework URL: http://wiki.FreeBSD.org/SOC2010JakubKlama URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=eCv@//depot/projects/soc2010/jce el_dma/?ac=83 Contact: Jakub Klama This project purpose is adding support for general purpose DMA engines found in most embedded devices. GPDMA framework provides a unified KOBJ interface to DMA engine drivers and unified programming interface to use direct memory transfers in kernel and userspace applications. This project is a part of Google Summer of Code 2010 and it is a work in progress. Current status can be observed on the wiki page. Open tasks: 1. Add support for more DMA engines. 2. Complete, clean up, and merge with HEAD. __________________________________________________________________ GEOM-Based Pseudo-RAID Implementation -- geom_pseudoraid URL: http://acm.poly.edu/~spawk/geom_pseudoraid-20100715.tbz Contact: Boris Kochergin The old ata(4) driver is believed to be going away sometime in the future, to be replaced with ATA_CAM [1]. However, ATA pseudo-RAID support in FreeBSD, ataraid(4), is implemented as part of said ata(4) driver, which means that it, too, will be going away. It was decided that pseudo-RAID support is desirable and that it should be reimplemented in GEOM [2] [ 3], which this project aims to do. Currently, RAID-1 arrays can be used on VIA Tech V-RAID and Adaptec HostRAID controllers in a limited capacity. There is no support for writing metadata yet, so disks are not marked degraded, there is no rebuild support, etc. These features are planned, along with support for more hardware and RAID-0 and SPAN arrays. A major setback for the current code is that it uses the device(9) family of functions to identify ATA pseudo-RAID controllers and constructs arrays based on that information. Unfortunately, ATA_CAM does not appear to add its devices to the device tree, so that tactic cannot be used with ATA_CAM. While this is fine for development of the actual RAID parts of the code, the project will be somewhat useless in the absence of the old ata(4) driver. There has been talk of exporting PCI information to GEOM [4] [5], but the work does not appear to have been completed yet. Open tasks: 1. Obtain documentation for or reverse-engineer metadata formats for which there is no write support in the ataraid(4) driver (for example, Adaptec HostRAID). 2. Add CAM support for exporting PCI information to GEOM. __________________________________________________________________ Google Summer of Code 2010 URL: http://wiki.FreeBSD.org/SummerOfCode2010Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson We are once again participating in the Google Summer of Code. This is our 6th year of participation and we hope to once again see great results from our 18 students. Coding officially began May 24th, and we are in the middle of the mid-term evaluation period. You can see and comment on weekly status reports on the mailing list or on the wiki. __________________________________________________________________ GPIO Framework URL: http://wiki.FreeBSD.org/GPIO Contact: Luiz Otavio O Souza Contact: Oleksandr Tymoshenko Implementation of General Purpose Input/Output interface for FreeBSD. Current GPIO bus implementation allows user to control pins from userland and it could be expanded to support various type of peripheral devices. So far there are two drivers: * gpioled provides simple led(4) functionality. * gpioiic implements I2C over GPIO. Framework is used in Alexandr Rybalko's port of FreeBSD to D-Link DIR-320 and in Luis Otavio O Souza's work of bringing FreeBSD to RouterBoard. __________________________________________________________________ Interrupt Threads Contact: John Baldwin For a while I have wanted to rework interrupt threads to address a few issues. The new design uses per-CPU queues of interrupt handlers. Interrupt threads are allocated by a CPU from a pool and bound to that CPU while draining that CPU's queue of handlers. Non-filter handlers can also reschedule themselves at the back of the current CPU's queue while executing. Filters with handlers are now always enabled and should provide a full replacement for the various uses of filters with "fast" taskqueues. A new class of "manual" handlers are also available which are not automatically scheduled, but are only explicitly scheduled from a filter. Thus, a filter can potentially schedule multiple handlers. The code has been tested on amd64, but it needs wider review and testing. I hope to start soliciting review and feedback soon with the goal of getting the code into 9.0. __________________________________________________________________ Jail-Based Virtualization URL: http://www.FreeBSDFoundation.org/project%20announcements.shtml#Bjoern URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=Z8Q@//depot/user/bz/vimage/src/? ac=83 Contact: Bjoern A. Zeeb The project started with some cleanup on the network stack after all the import work and adjustments for virtualization to minimize changes to earlier branches. These made it into the tree already and to 8-STABLE, and it will be included in the upcoming 8.1 release. The first major task was to generalize the virtualization framework, so that virtualization of further subsystems would be easier and could be achieved with less duplication. In addition some documentation on the virtual network stack programming was written to help developers virtualizing their code. The interactive kernel debugger support was improved and libjail along with jls and netstat can work on core dumps now and query individual jails and attached virtual network stacks. The second major task was network stack teardown, a concept introduced with the network stack virtualization. The primary goal was to prototype a shutdown of the (virtual) network stacks from top to bottom, which means letting interfaces go last rather than first. Work in this area is still in progress and will have to continue to allow long term stability and a leak and panic free shutdown. The work on this project had been sponsored by the FreeBSD Foundation and CK Software GmbH. Special thanks also to John Baldwin and Philip Paeps for helping with review and suggestions. Open tasks: 1. Merge stabilised change sets. 2. Work further down the network stack freeing all resources for a stable, safe teardown. __________________________________________________________________ Kernel Event Timers Infrastructure Contact: Alexander Motin Modern x86 systems include four different types of event timers: i8254, RTC, LAPIC, and HPET. First three are already supported by FreeBSD. Depending on hardware and loader tunables, periodic interrupts from them are used to trigger all time-based events in kernel. That code has a long history, that made it tangled and at the same time limited and hard-coded. New kernel event timers infrastructure was started to allow different event timer hardware to be operated in uniform way and to allow more features to be supported. Work consists of three main parts: writing machine-independent timer driver API and management code, updating existing drivers and improving HPET driver to support event timers. The new driver API provides unified support for both per-CPU (independent for every CPU core) and global timers in periodic and one-shot modes. Management code at this moment uses only periodic mode, while one-shot mode use is planned by later tickless kernel work. Different kinds of timers have different capabilities and could be present in hardware in different combinations. In every situation the infrastructure automatically chooses two best event timers to supply system with hardclock(), statclock(), and profclock() events. If some timer is not functioning -- it will be replaced. If there is no second timer -- it will be emulated. The administrator may affect that choice using loader tunables during boot and sysctl variables in run-time (kern.eventtimer.*, and so on). Most of the code was recently committed to HEAD. Now it is used by i386 and amd64 architectures. Open tasks: 1. Troubleshoot possible hardware and software issues. 2. Port other architectures to the new infrastructure. 3. Implement tickless kernel, utilizing new features, such as per-CPU and one-shot timers. __________________________________________________________________ libnetstat(3) URL: http://wiki.FreeBSD.org/LibNetstat URL: http://people.FreeBSD.org/~pgj/libnetstat/ URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2009/&c=mGl@//dep ot/projects/soc2009/pgj_libstat/?ac=83 Contact: Gábor Páli Contact: Aman Jassal This project is about creating a wrapper library to support monitoring and management of networking with avoiding direct use of the FreeBSD kvm(3) and sysctl(3) interfaces. This approach would allow the kernel implementation to change and monitoring applications to be extended without breaking applications and requiring them to be recompiled. We decided to merge the sources from the last year's Summer of Code project back to the FreeBSD src/ repository piece by piece, and we have defined several phases of integration. * Standardize the in-kernel networking statistics structures. * Build a sysctl(3) interface, and add export routines. * Add a library, libnetstat(3) to work with the exported information, and to provide further functions in order to support extracting information via kvm(3). This library implements abstractions over the gathered data. * Adapt sources of the existing applications, i.e. netstat(1) and bsnmpd(1) to use the abstractions offered by the library, resulting in a cleaner and simpler code. * Add new applications on the top of the library, e.g. nettop(1). The first phase has been already posted for review. Note that we are looking for a sponsor with an src commit bit and enough time to represent the effort towards the Project. Open tasks: 1. Review the sources. 2. Pick a task from the list, and send patches. 3. Comment the patches, help them to improve. __________________________________________________________________ Making Ports Work with Clang URL: http://wiki.FreeBSD.org/SOC2010AndriusMorkunas URL: http://wiki.FreeBSD.org/PortsAndClang URL: http://rainbow-runner.nl/~andrius/soc/ URL: http://rainbow-runner.nl/clang/patches/ Contact: Andrius Morkunas First part of the project is mostly complete. I added support for new PORTS_CC variable which should be used in make.conf instead of CC to change ports compiler. This allows user to change ports compiler easily, while still respecting USE_GCC. Some patches were written to get ports to work with Clang, and a lot of old patches written prior to the Google Summer of Code project were updated. There are still a lot of broken ports, and some that cannot be built because of Clang/LLVM bugs, but at this point, Clang can build most ports. Open tasks: 1. Fix broken ports that do not work with Clang. 2. Test patched ports with Clang, report Clang bugs. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetbsd.org URL: http://picasaweb.google.com/meetbsd/MeetBSD2010Day1# URL: http://picasaweb.google.com/meetbsd/MeetBSD2010Day2# URL: http://picasaweb.google.com/meetbsd/MeetBSD2010SocialEvent# Contact: meetBSD Information meetBSD 2010 took place on July 2 - 3 in Krakow, Poland at the Faculty of Mathematics and Computer Science building of the Jagiellonian University. The gathering was a much successful event which brought together developers, contributors, and users of the BSD systems from around the world. We had many interesting presentations, of various character and appeal for the diversified audience. Attendees had a chance for taking the BSD Certification exam during the conference, as well as the advantage of face to face side conversations and discussions, which continued long during the social event on Friday night! The conference presentation slides are already available for download. Video recordings edition is being finalized, and their publication is expected shortly. We hope you enjoyed the event and had great time in Krakow. See you again soon! __________________________________________________________________ Namecache Improvements -- dircache URL: http://wiki.FreeBSD.org/SOC2010GlebKurtsov Contact: Gleb Kurtsou I have been reimplementing VFS namecache to make it granularly locked and supporting reliable full-path lookup without calling underlying file system routines. I have successfully implemented directory cache that works in idealized environment with tmpfs. I am currently working on adding support for entries without associated vnodes and for "weak" entries and incomplete cached path. __________________________________________________________________ New System Installer -- pc-sysinstall URL: http://lists.FreeBSD.org/pipermail/svn-src-all/2010-June/025660.html URL: http://www.BSDCan.org/2010/schedule/attachments/142_pc-sysinstall-kris- moore-2010.pdf Contact: Kris Moore Contact: M. Warner Losh The new system installation backend, pc-sysinstall, was merged into HEAD recently and work is already underway to make it more functional and useful as a complete replacement to standard "sysinstall". It is written 100% in shell, not requiring any additional tools from what is standard to FreeBSD. The backend already supports a number of exciting features such as: * ZFS (Including support for raidz/mirror/multiple device pool setups). * Disk encryption via GELI(8). * Auto labeling of file systems with glabel(8). * Big disk support using GPT/EFI. * Full Installation Logging, which is saved to disk for post-install inspection. In addition to the features above, pc-sysinstall is unique, in that every install ends up being a scripted install. Front-ends, be it GUI- or text-based, simply generate the appropriate system configuration file, and pc-sysinstall does the grunt work of the actual installation. This is important for a couple of reasons. First, it makes the task of front-end development much easier by not needing to worry about a backend-driven program flow. Second it means that any front-end can be used to generate the installation configuration file, which can then be copied or modified to perform automated installs. While pc-sysinstall is still relatively new, it is already in use as the default backend for PC-BSD 8.0 and 8.1, and has been getting a very good reception and any bugs found are fixed quickly. A text-based front-end is already in the works which will allow installation media to be created without X11 support. __________________________________________________________________ OpenAFS Port URL: http://openafs.org URL: http://web.mit.edu/freebsd/openafs/openafs.shar Contact: Benjamin Kaduk Contact: Derrick Brashear AFS is a distributed network filesystem that originated from the Andrew Project at Carnegie-Mellon University; the OpenAFS client implementation has not been particularly useful on FreeBSD since the 4.X releases. Recent work on the OpenAFS codebase has updated it to be consistent with current versions of FreeBSD, and the client, though still considered experimental, is now relatively stable for light (single-threaded) use on 9-CURRENT. The auxiliary utilities for managing and examining the filesystem are functional, and reading and writing files works sufficiently well to copy /usr/src into and out of AFS. Compiling and running executables in AFS is unsuccessful, though, as mmap() is not always reliable. There are several known outstanding issues that are being worked on, but detailed bug reports are welcome at port-freebsd@openafs.org. Open tasks: 1. Fix the {get,put}pages vnode operations for more reliable mmap() operation. 2. Update VFS locking to allow the use of disk-based client caches as well as memory-based caches. 3. Track down races and deadlocks that appear under load. 4. Integrate with the bsd.kmod.mk kernel-module build infrastructure. __________________________________________________________________ Package Management Library -- libpkg URL: http://wiki.FreeBSD.org/SOC2010DavidForsythe URL: http://code.google.com/p/libpkg Contact: David Forsythe The libpkg library will allow for fairly fine grained control over package management. Presently libpkg has complete read functionality. Info and delete tools that have most of the current package tool features have already been implemented, and once they are completed they can be considered replacements for their counterparts. Once the write and logging aspects of the library are more mature, add and create tools can be created quickly. A new set of more maintainable package tools that leverage libpkg will hopefully be available soon after. __________________________________________________________________ Packet-Capturing Stack -- ringmap URL: http://code.google.com/p/ringmap/ URL: http://ringmap.googlecode.com/files/ringmap_slides.pdf Contact: Alexander Fiveg The ringmap stack is a complete FreeBSD packet-capturing mplementation specialized for very high-speed networks. Similar to the "zero-copy BPF" implementation, the idea of ringmap is to eliminate packet copy operations by using shared memory buffers. However, unlike the "zero-copy BPF" model, ringmap eliminates ALL packet copies during capturing: the network adapter's DMA buffer is mapped directly into user-space. The ringmap stack also adapts libpcap accordingly to provide userspace applications with access to the captured packets without any additional overhead. In the context of Google Summer of Code 2010: * The ringmap software was ported to 9-CURRENT. * Ringmap was redesigned to make it easier to port to other adapters and to integrate it with other network drivers. * Also ringmap was extended to be multi-threaded. Open tasks: 1. Porting ringmap to 10GbE (integrating with ixgbe driver). 2. Porting the entire ringmap code from 9-CURRENT to -STABLE. 3. Evaluation tests. 4. Documentation. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team A significant part of quarter two was spent coordinating efforts for inclusion of Xorg 7.5, KDE 4, GNOME 2, plus preparation of ports for the 8.1 release process. Due to the success of enforcing Feature Safe ports commits during 7.3-RELEASE, it was continued for the recent src/ freeze. The port count is approaching 22,000 ports. The open PR count currently floats at about 1200 entries. Since the last report, we added four new committers, and had two old committers rejoin us. The Ports Management Team is very grateful to the FreeBSD Foundation for sponsoring two new head nodes for the ports building cluster, pointyhat. Each of the new head nodes has a larger capacity, both with regard to performance but also in amount of space available for the staging areas, allowing for faster, and thus more, build cycles. Additionally, having two head nodes will allow us to dedicate one of them for building production-ready binary packages, adding predicability for our users to when what types of packages are available for installation, and dedicate the other for regression testing of large port updates, ports infrastructure improvements, the cluster scheduling code, and FreeBSD itself. Over the last few weeks, Mark Linimon has been working hard to get the first of the two new nodes online and has already completed its first package build. This has involved a substantial rework of our custom codebase. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * ale: Update of math/gmp. * delphij: Changes to Mk/bsd.ldap.mk. * gahr: Inclusion of USE_GL=glew. * pgollucci: Changes to Mk/bsd.*apache.mk plus updates to devel/apr and www/apache*. * Testing of x11/xorg, x11/gnome2, x11/kde4, and lang/mono * A test run make fetch run. * A test run for devel/gettext. * mm: Inclusion of USE_XZ. * ale: Request to switch default mysql from 5.0-EOL to 5.1-GA. alepulver's Licensing Framework Summer of Code project has made it into the tree and the Port Management Team is currently assessing the fallout and it will come up with guidelines and documentation in due time. Open tasks: 1. Looking for help fixing ports broken on 9-CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing, and closing. __________________________________________________________________ Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team has been working on the FreeBSD 8.1-RELEASE. At the time of this writing the final builds have been completed and uploaded to the master FTP site. The release announcement should be made within the next couple of days. __________________________________________________________________ Resource Containers Contact: Edward Tomasz Napieral/a As of now, FreeBSD only offers very rudimentary resource controls -- resource limits for many resources (e.g. SysV IPC) are missing, and there is no way to set resource limits for jails. As a result, users who want to run many different workloads on a single physical machine often have to replace jails with several FreeBSD instances running in virtual machines. The goal of this project is to implement resource containers and a simple per-jail resource limits mechanism. Resource containers are also a prerequisite for other resource management mechanisms, such as Hierarchical Resource Limits, for "Collective Limits on Set of Processes (aka. Jobs)" Google Summer of Code 2010 project, for implementing mechanism similar to Linux cgroups, and might be also used to e.g. provide precise resource usage accounting for administrative or billing purposes. This project is being sponsored by The FreeBSD Foundation. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We were proud to be a sponsor for BSDCan in May. We also committed to sponsoring MeetBSD 2010 Poland and California. We provided 12 travel grants for BSDCan. The Foundation and Core Team held a summit on BSD-licensed toolchains at BSDCan 2010. We officially kicked off five new projects that we are funding. They are BSNMP Improvements by Shteryana Shopova, Userland DTrace by Rui Paulo, FreeBSD jail-based virtualization by Bjoern Zeeb, DAHDI FreeBSD driver port by Max Khon, and Resource Containers project by Edward Tomasz Napieral/a. We continued our work on infrastructure projects to beef up hardware for package building, network testing, etc. This includes purchasing equipment as well as managing equipment donations. We are half way through the year and we have raised around $48,000 towards our goal of $350,000. Find out how to make a donation at http://www.FreeBSDFoundation.org/donate/. Our semi-annual newsletter will be published soon. Check out our website to find out more! __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de URL: http://www.FreeBSD.de/mailinglists.html Contact: Johann Kois Contact: Benedict Reuschling A number of updates to the documentation were made since the last status report. We are especially grateful for the contributions from external people who sent the translations. People like Fabian Ruch, who updated the porters-handbook to the latest version (which had been on his to-do list for quite some time), and Benjamin Lukas, who did a great job with the from-scratch translation of the MAC chapter of the German handbook. We thank them both for their contributions and hope they will continue their efforts to enhance the German documentation. Frank Börner was released from Benedicts mentorship and is now a full committer to the German Documentation Project. We are always looking for fresh blood that is willing to be mentored by us as a first step in becoming committers for the documentation project themselves. Johann is keeping up the German website with the latest version. But we could use more translators for sections that are not fully translated yet. Open tasks: 1. Read the translations and report bugs that you have found (even small ones). 2. Translate new parts of the documentation and the website. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli Thanks to Katalin Konkoly, the first few chapters of the FreeBSD Handbook translation have been reviewed, therefore many typos and mistranslations were spotted and fixed. Apart from this, we are still keeping the existing documentation and web page translations up to date, currently without plans on further work. If you are interested in helping us, or you have any comments, or requests regarding the translations, do not hesitate to contact the project via the email addresses mentioned in the entry. Open tasks: 1. Review translations and send feedback. 2. Translate release notes. 3. Add more article translations. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki This project focuses on updating the www/ja and doc/ja_JP.eucJP/ trees. Since last year www/ja tree has been mostly synchronized with the English counterpart and doc/ja_JP.eucJP has also been updated steadily. We are now working on FreeBSD Handbook and Porter's Handbook. Open tasks: 1. More Japanese translation of FreeBSD Handbook and contents of www.FreeBSD.org. 2. Pre-/post-commit review of the translation. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/doc/es/articles/fdp-es/ Contact: Gábor Kövesdán Contact: Vicente Carrasco Vayá We need manpower. Existing documentation set has not been updated for quite some time because of lack of volunteers. Current members are busy with other projects and real life at the moment and we have not received anything from outside contributors. It is a shame because there are lots of users in Spain and Latin-America, as well. Besides, the world's first Free Software Street has been recently inaugurated in Spain. This obviously means that there is interest in free software but unfortunately, this translation project is not going very well nowadays. Open tasks: 1. Review and update existing translations. __________________________________________________________________ V4L Support in Linux Emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd Some bug fixes were applied, and the code was also tested and made to work with the cuse4bsd webcam driver, which supports a great many camera chipsets. The code is still only in 9-CURRENT. We were going to MFC it to 8.x but ran into the code freeze for 8.1, so missed that. However, the code does work on 8-STABLE. We will try to get it MFC'd for 8.2. __________________________________________________________________ ZFS URL: http://wiki.FreeBSD.org/ZFS URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/ zfs Contact: Pawel Jakub Dawidek Contact: Martin Matuska Contact: Xin Li The ZFS file system has been updated to version 15 on HEAD and it will be MFC'ed to 8-STABLE around September 13th, 2010. Work is in progress on porting the recent ZFS version 26 with deduplication functionality. Open tasks: 1. Fix bugs, unresolved issues and to-dos in Perforce. __________________________________________________________________ (c) 1995-2010 The FreeBSD Project. All rights reserved. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 15:26:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7CB1106564A for ; Thu, 22 Jul 2010 15:26:34 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 73A448FC15 for ; Thu, 22 Jul 2010 15:26:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ObxfM-0006cK-3x for freebsd-stable@freebsd.org; Thu, 22 Jul 2010 17:26:32 +0200 Received: from 193.33.173.33 ([193.33.173.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Jul 2010 17:26:32 +0200 Received: from c.kworr by 193.33.173.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Jul 2010 17:26:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Volodymyr Kostyrko Date: Thu, 22 Jul 2010 18:26:23 +0300 Lines: 14 Message-ID: References: <4C47B57F.5020309@langille.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 193.33.173.33 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 In-Reply-To: <4C47B57F.5020309@langille.org> Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:26:34 -0000 22.07.2010 06:05, Dan Langille wrote: > Create a new partition within that scheme: > > gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 > > Why '-b 34'? Randi pointed me to > http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains what > the first 33 LBA are used for. It's not for us to use here. gpart is not so dumb to not protect this space. If you don't specify -b when creating first partition it automagically defaults to 34. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 19:37:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93404106564A; Thu, 22 Jul 2010 19:37:13 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F138B8FC0A; Thu, 22 Jul 2010 19:37:12 +0000 (UTC) Received: by bwz12 with SMTP id 12so1341701bwz.13 for ; Thu, 22 Jul 2010 12:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=YrTc3tYvaSH9M1FLCZFv6BYZIMChzbbUZ9l3Hqd+MVk=; b=Gq0vbgXrzNRpqyqz5e7+9WFnI99LScj7xpfZCCzzFZ0e644MXHmmtkpbf4bjIXcixD CIHRpEoGj/4CPBGnr/YvwZ3+UMvK2A5I6oQnLR12xtK+/mzcTaBxbh4YDRA/1v/hYpdu QAq/yEAoVYsECwIaXHzB4Yo82C6YYcakEwJWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=V1+XQeCL0gRFCRHxlerT3KV6G4L4GpUV/7lzZK1KmhUOHuLcq6Pb7r0FCZNiyHukzz MHlQikIb3NohPFlkvOVi26HCwomcssZrRKDwGYePKFV0ex8x/Pz1ZprchOK+ZjDQ2Xlk SE1tLbrDm3wHt+MElnKaulSqZU71tMnn4V4tg= MIME-Version: 1.0 Received: by 10.204.34.2 with SMTP id j2mr1826237bkd.21.1279827431493; Thu, 22 Jul 2010 12:37:11 -0700 (PDT) Received: by 10.204.54.135 with HTTP; Thu, 22 Jul 2010 12:37:11 -0700 (PDT) Date: Thu, 22 Jul 2010 21:37:11 +0200 Message-ID: From: Oliver Pinter To: security@freebsd.org, stable@freebsd.org, rene@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: vuxml alert - mDNS - patch available in bug tracking system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 19:37:13 -0000 For a month ago every day become an portaudit alert, that the mdnsd is still vulnerable. The fix is available since ~1 month http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/147007 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 21:38:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC751065679 for ; Thu, 22 Jul 2010 21:38:36 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 99EB08FC23 for ; Thu, 22 Jul 2010 21:38:36 +0000 (UTC) Received: (qmail 50336 invoked by uid 1000); 22 Jul 2010 21:38:36 -0000 Date: Thu, 22 Jul 2010 14:38:36 -0700 From: "Mahlon E. Smith" To: freebsd-stable@freebsd.org Message-ID: <20100722213836.GH15227@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N8ia4yKhAKKETby7" Content-Disposition: inline X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 21:38:36 -0000 --N8ia4yKhAKKETby7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Picked up a couple of these powerhouse machines to be VirtualBox hosts. 24 core, 96G of RAM. Trying to put (amd64) both 8.0-RELEASE and 8.1-RC2 on it with no luck whatsoever so far. Any help provided would be greatly appreciated, I'm chomping at the bit pretty hard to put this hardware to use, and was fairly surprised that FreeBSD didn't work on it through the gate. I've grabbed some screenshots from the DRAC, and dumped them here: http://www.dropbox.com/gallery/7234177/1/r810?h=3Df5fb1d (sorry, I realize that's not -incredibly- helpful and partially truncated. I'm currently limited to what I can screenshot, though I suppose I could boot via console and log it all... come to think of it, I'll go give that a try to get more comprehensive output.) If I disable all the CPU options in the BIOS, I can get it to boot, but it hangs after mounting md0 (I never see the sysinstall screen.) Same deal if I try booting in safe mode or without ACPI. Otherwise, it spews errors for about 30 seconds so quickly I can't read them, then panics with a page fault in swapper. I'm sure we'd like to get BSD installing reliably on such a beast, and I'm more than happy to play the guinea pig if someone would be willing to provide some direction with some things to try. Help! These are expensive paperweights! :) -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --N8ia4yKhAKKETby7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMSLpc1bsjBDapbeMRAuXpAKCEVjXCL3Sf0XGUje8/VTGM/hwCLQCdFfP7 OjtFTOayRFNXL8Lo7F7Dp50= =n3LD -----END PGP SIGNATURE----- --N8ia4yKhAKKETby7-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 22:04:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F76C106564A for ; Thu, 22 Jul 2010 22:04:29 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4095E8FC15 for ; Thu, 22 Jul 2010 22:04:28 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6MM3aua041538; Thu, 22 Jul 2010 15:03:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=GScYNvvbzoJP0UdChgcyYqBru2soNDeBVyT/QF+A2WD5y3B1gpSrVl7DZRlVsnbX From: Sean Bruno To: "Mahlon E. Smith" In-Reply-To: <20100722213836.GH15227@martini.nu> References: <20100722213836.GH15227@martini.nu> Content-Type: text/plain; charset="UTF-8" Date: Thu, 22 Jul 2010 15:03:36 -0700 Message-ID: <1279836216.2456.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 22 Jul 2010 22:04:29 -0000 On Thu, 2010-07-22 at 14:38 -0700, Mahlon E. Smith wrote: > Picked up a couple of these powerhouse machines to be VirtualBox hosts. > 24 core, 96G of RAM. Trying to put (amd64) both 8.0-RELEASE and 8.1-RC2 > on it with no luck whatsoever so far. Any help provided would be greatly > appreciated, I'm chomping at the bit pretty hard to put this hardware to > use, and was fairly surprised that FreeBSD didn't work on it through the > gate. > > I've grabbed some screenshots from the DRAC, and dumped them here: > > http://www.dropbox.com/gallery/7234177/1/r810?h=f5fb1d > > (sorry, I realize that's not -incredibly- helpful and partially > truncated. I'm currently limited to what I can screenshot, though I > suppose I could boot via console and log it all... come to think of it, > I'll go give that a try to get more comprehensive output.) > > If I disable all the CPU options in the BIOS, I can get it to boot, but > it hangs after mounting md0 (I never see the sysinstall screen.) Same > deal if I try booting in safe mode or without ACPI. > > Otherwise, it spews errors for about 30 seconds so quickly I can't read > them, then panics with a page fault in swapper. > > I'm sure we'd like to get BSD installing reliably on such a beast, and > I'm more than happy to play the guinea pig if someone would be willing > to provide some direction with some things to try. Help! These are > expensive paperweights! :) > > -- > Mahlon E. Smith > http://www.martini.nu/contact.html Funny you should mention this box. I've been arm wrestling with this beastie for a couple of weeks and finally had some amount of success today. A couple of things: 1. Reduce your RAM to 64G (seriously) 2. Don't use the H200 Dell RAID controller. It's not supported yet. -- Use the 6i or whatever the mfi(4) card is called. 3. Don't compile in the ipmi(4) when you get the system up. -- I know there's an unpatched problem on 7 that is fixed in HEAD, but have no idea if its patched in 8 4. Try doing serial console installs. -- at the Beastie prompt, hit [6]. then at the OK prompt, type "set console=comconsole" Sean From owner-freebsd-stable@FreeBSD.ORG Thu Jul 22 22:08:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBAAC106566B for ; Thu, 22 Jul 2010 22:08:20 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id BD0C58FC15 for ; Thu, 22 Jul 2010 22:08:20 +0000 (UTC) Received: (qmail 53572 invoked by uid 1000); 22 Jul 2010 22:08:21 -0000 Date: Thu, 22 Jul 2010 15:08:21 -0700 From: "Mahlon E. Smith" To: freebsd-stable@freebsd.org Message-ID: <20100722220821.GI15227@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , freebsd-stable@freebsd.org References: <20100722213836.GH15227@martini.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X0cz4bGbQuRbxrVl" Content-Disposition: inline In-Reply-To: <20100722213836.GH15227@martini.nu> X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 22:08:20 -0000 --X0cz4bGbQuRbxrVl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 22, 2010, Mahlon E. Smith wrote: >=20 > [...] > I suppose I could boot via console and log it all... come to think of > it, I'll go give that a try to get more comprehensive output Okay, here we go, output below my sig. "panic: Built bad topology" -- oh, dear. That's a new one for me. Clues/suggestions happily accepted. -- Mahlon E. Smith =20 http://www.martini.nu/contact.html OK boot -v SMAP type=3D01 base=3D0000000000000000 len=3D00000000000a0000 SMAP type=3D01 base=3D0000000000100000 len=3D000000007f538000 SMAP type=3D02 base=3D000000007f638000 len=3D0000000000016000 SMAP type=3D03 base=3D000000007f64e000 len=3D000000000007f000 SMAP type=3D02 base=3D000000007f6cd000 len=3D0000000000933000 SMAP type=3D02 base=3D0000000080000000 len=3D0000000010000000 SMAP type=3D02 base=3D00000000f17f0000 len=3D0000000000002000 SMAP type=3D02 base=3D00000000fe000000 len=3D0000000002000000 SMAP type=3D01 base=3D0000000100000000 len=3D0000001780000000 Copyright (c) 1992-2010 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 8.1-RC2 #0: Tue Jun 29 20:21:55 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8126c000. Preloaded mfs_root "/boot/mfsroot" at 0xffffffff8126c1d0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1995012507 Hz CPU: Intel(R) Xeon(R) CPU E7540 @ 2.00GHz (1995.01-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x206e6 Family =3D 6 Model =3D 2e St= epping =3D 6 Features=3D0xbfebfbff Features2=3D0xbce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 103079215104 (98304 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x00000000012f8000 - 0x000000007f637fff, 2117337088 bytes (516928 pages) 0x0000000100000000 - 0x00000017c7d9ffff, 97842233344 bytes (23887264 pages) avail memory =3D 99488772096 (94879 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target INTR: Adding local APIC 16 as a target INTR: Adding local APIC 17 as a target INTR: Adding local APIC 18 as a target INTR: Adding local APIC 19 as a target INTR: Adding local APIC 22 as a target INTR: Adding local APIC 23 as a target INTR: Adding local APIC 32 as a target INTR: Adding local APIC 33 as a target INTR: Adding local APIC 36 as a target INTR: Adding local APIC 37 as a target INTR: Adding local APIC 38 as a target INTR: Adding local APIC 39 as a target INTR: Adding local APIC 48 as a target INTR: Adding local APIC 49 as a target INTR: Adding local APIC 50 as a target INTR: Adding local APIC 51 as a target INTR: Adding local APIC 54 as a target INTR: Adding local APIC 55 as a target INTR: Adding local APIC 64 as a target INTR: Adding local APIC 65 as a target INTR: Adding local APIC 68 as a target INTR: Adding local APIC 69 as a target INTR: Adding local APIC 70 as a target INTR: Adding local APIC 71 as a target INTR: Adding local APIC 80 as a target INTR: Adding local APIC 81 as a target FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 cpu4 (AP): APIC ID: 6 cpu5 (AP): APIC ID: 7 cpu6 (AP): APIC ID: 16 cpu7 (AP): APIC ID: 17 cpu8 (AP): APIC ID: 18 cpu9 (AP): APIC ID: 19 cpu10 (AP): APIC ID: 22 cpu11 (AP): APIC ID: 23 cpu12 (AP): APIC ID: 32 cpu13 (AP): APIC ID: 33 cpu14 (AP): APIC ID: 36 cpu15 (AP): APIC ID: 37 cpu16 (AP): APIC ID: 38 cpu17 (AP): APIC ID: 39 cpu18 (AP): APIC ID: 48 cpu19 (AP): APIC ID: 49 cpu20 (AP): APIC ID: 50 cpu21 (AP): APIC ID: 51 cpu22 (AP): APIC ID: 54 cpu23 (AP): APIC ID: 55 cpu24 (AP): APIC ID: 64 cpu25 (AP): APIC ID: 65 cpu26 (AP): APIC ID: 68 cpu27 (AP): APIC ID: 69 cpu28 (AP): APIC ID: 70 cpu29 (AP): APIC ID: 71 cpu30 (AP): APIC ID: 80 cpu31 (AP): APIC ID: 81 cpu (AP): APIC ID: 82 (disabled) cpu (AP): APIC ID: 83 (disabled) cpu (AP): APIC ID: 86 (disabled) cpu (AP): APIC ID: 87 (disabled) cpu (AP): APIC ID: 96 (disabled) cpu (AP): APIC ID: 97 (disabled) cpu (AP): APIC ID: 100 (disabled) cpu (AP): APIC ID: 101 (disabled) cpu (AP): APIC ID: 102 (disabled) cpu (AP): APIC ID: 103 (disabled) cpu (AP): APIC ID: 112 (disabled) cpu (AP): APIC ID: 113 (disabled) cpu (AP): APIC ID: 114 (disabled) cpu (AP): APIC ID: 115 (disabled) cpu (AP): APIC ID: 118 (disabled) cpu (AP): APIC ID: 119 (disabled) APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 25 APIC: CPU 2 has ACPI ID 5 APIC: CPU 3 has ACPI ID 29 APIC: CPU 4 has ACPI ID 9 APIC: CPU 5 has ACPI ID 33 APIC: CPU 6 has ACPI ID 13 APIC: CPU 7 has ACPI ID 37 APIC: CPU 8 has ACPI ID 17 APIC: CPU 9 has ACPI ID 41 APIC: CPU 10 has ACPI ID 21 APIC: CPU 11 has ACPI ID 45 APIC: CPU 12 has ACPI ID 2 APIC: CPU 13 has ACPI ID 26 APIC: CPU 14 has ACPI ID 6 APIC: CPU 15 has ACPI ID 30 APIC: CPU 16 has ACPI ID 10 APIC: CPU 17 has ACPI ID 34 APIC: CPU 18 has ACPI ID 14 APIC: CPU 19 has ACPI ID 38 APIC: CPU 20 has ACPI ID 18 APIC: CPU 21 has ACPI ID 42 APIC: CPU 22 has ACPI ID 22 APIC: CPU 23 has ACPI ID 46 APIC: CPU 24 has ACPI ID 3 APIC: CPU 25 has ACPI ID 27 APIC: CPU 26 has ACPI ID 7 APIC: CPU 27 has ACPI ID 31 APIC: CPU 28 has ACPI ID 11 APIC: CPU 29 has ACPI ID 35 APIC: CPU 30 has ACPI ID 15 APIC: CPU 31 has ACPI ID 39 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x010000-0x01ffff at 0xffffff8aa535f000 x86bios: EBDA 0x09e000-0x09ffff at 0xffffff000009e000 x86bios: ROM 0x0a0000-0x0effff at 0xffffff00000a0000 WARNING: Non-uniform processors. WARNING: Using suboptimal topology. panic: Built bad topology at 0xffffffff80c55e20. CPU mask 0x0 !=3D 0xFFFFF= FFF cpuid =3D 0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80595e68 stack pointer =3D 0x28:0xffffffff81270b20 frame pointer =3D 0x28:0xffffffff81270b60 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 0 (swapper) trap number =3D 12 panic: page fault cpuid =3D 0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80595e68 stack pointer =3D 0x28:0xffffffff81270790 frame pointer =3D 0x28:0xffffffff812707d0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 0 (swapper) trap number =3D 12 panic: page fault cpuid =3D 0 kernel trap 12 with interrupts disabled (... and so on with the page faults.) --X0cz4bGbQuRbxrVl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMSMFU1bsjBDapbeMRAv1/AKC5FpcmFqL+9ynuvlwrW7yjG2AFlwCdHwKr pBFJUOnfYimPjvG1J3zmSgI= =3GOa -----END PGP SIGNATURE----- --X0cz4bGbQuRbxrVl-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 00:36:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D95B11065670 for ; Fri, 23 Jul 2010 00:36:11 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id B1D178FC1A for ; Fri, 23 Jul 2010 00:36:11 +0000 (UTC) Received: (qmail 67717 invoked by uid 1000); 23 Jul 2010 00:36:11 -0000 Date: Thu, 22 Jul 2010 17:36:11 -0700 From: "Mahlon E. Smith" To: sbruno@freebsd.org Message-ID: <20100723003611.GA66678@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , sbruno@freebsd.org, "freebsd-stable@freebsd.org" References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <1279836216.2456.14.camel@localhost.localdomain> X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "freebsd-stable@freebsd.org" Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 00:36:11 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 22, 2010, Sean Bruno wrote: >=20 > Funny you should mention this box. I've been arm wrestling with this > beastie for a couple of weeks and finally had some amount of success > today. >=20 > A couple of things: >=20 > 1. Reduce your RAM to 64G (seriously) > 2. Don't use the H200 Dell RAID controller. It's not supported yet. > -- Use the 6i or whatever the mfi(4) card is called. > 3. Don't compile in the ipmi(4) when you get the system up. > -- I know there's an unpatched problem on 7 that is fixed in HEAD, but > have no idea if its patched in 8 > 4. Try doing serial console installs.=20 > -- at the Beastie prompt, hit [6]. then at the OK prompt, type "set =20 > console=3Dcomconsole" Thanks for the suggestions, Sean. On a whim I decided to try with 8.1-RELEASE (since I obviously started trying to get this goin' before it came out) -- lo, it put me right into the sysinstall. ... that was an easy fix. Heh. (Is kern.smb.disabled set for the 8.1 install or something? I didn't change anything in between attempts.) In any event -- yaaaaay! Install worked great, though it appears I need to keep hyperthreading ("logical processors" bios option) disabled for it to boot reliably. Similar errors as before if I enable it. real memory =3D 103079215104 (98304 MB) avail memory =3D 99492831232 (94883 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs FreeBSD/SMP: 4 package(s) x 6 core(s) Holy cow, that's a nice sight. Got one panic shortly after getting it on the network: http://dl.dropbox.com/u/7234177/panic.jpg =2E.. but it looks like I'll have a lot of kernel and sysctl tweaking to do regardless ("ix0: RX Descriptors exceed system mbuf max, using default instead!"), so I'll report back to the list if the panic re-appears after some tuning. -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFMSOP71bsjBDapbeMRAsXIAJoCjrX6/egwb8ng9wkHi74WdP4AdQCgqqNw utI/Nqycb60VDuvZeEit4Z4= =BWSn -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 00:47:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54A761065673 for ; Fri, 23 Jul 2010 00:47:29 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 297C48FC1F for ; Fri, 23 Jul 2010 00:47:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 17AAE5093D for ; Fri, 23 Jul 2010 01:47:28 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCeG18C9JU00 for ; Fri, 23 Jul 2010 01:47:24 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 993BE5089E for ; Fri, 23 Jul 2010 01:47:24 +0100 (BST) Message-ID: <4C48E695.6030602@langille.org> Date: Thu, 22 Jul 2010 20:47:17 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> In-Reply-To: <4C47B57F.5020309@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 00:47:29 -0000 Thank you to all the helpful discussion. It's been very helpful and educational. Based on the advice and suggestions, I'm going to adjust my original plan as follows. NOTE: glabel will not be used. First, create a new GUID Partition Table partition scheme on the HDD: gpart create -s GPT ad0 Let's see how much space we have. This output will be used to determine SOMEVALUE in the next command. gpart show Create a new partition within that scheme: gpart add -b 1024 -s SOMEVALUE -t freebsd-zfs -l disk00 ad0 The -b 1024 ensures alignment on a 4KB boundary. SOMEVALUE will be set so approximately 200MB is left empty at the end of the HDD. That's part more than necessary to accommodate the different actualy size of 2TB HDD. Repeat the above with ad1 to get disk01. Repeat for all other HDD... Then create your zpool: zpool create bigtank gpt/disk00 gpt/disk02 ... etc This plan will be applied to an existing 5 HDD ZFS pool. I have two new empty HDD which will be added to this new array (giving me 7 x 2TB HDD). The array is raidz1 and I'm wondering if I want to go to raidz2. That would be about 10TB and I'm only using up 3.1TB at present. That represents about 4 months of backups. I do not think I can adjust the existing zpool on the fly. I think I need to copy everything elsewhere (i.e the 2 empty drives). Then start the new zpool from scratch. The risk: when the data is on the 2 spare HDD, there is no redundancy. I wonder if my friend Jerry has a spare 2TB HDD I could borrow for the evening. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 00:48:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F82410656EC; Fri, 23 Jul 2010 00:48:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12CBA8FC18; Fri, 23 Jul 2010 00:48:18 +0000 (UTC) Received: by pvh1 with SMTP id 1so3816533pvh.13 for ; Thu, 22 Jul 2010 17:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=dg5ecx9nvYSfL9rpGYaSwRkwppi/xmMGdZN2Gsd5wLg=; b=Ib7SGKKAyfwpP+hTKscDe55uT2O5jdMto+HTSLu2eYr6dbo8Ki8OZWgu2TCIuhA2rC MFsrYDlw4HMNHqHRNvbbZxK0CqHKHV/zKQpacPcxEmE5yN/+g/CYcJkz464xXIvTx8Aw wrftDuESpKcOjxK6Xp9bBFyb/vQSbDq11Fx7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=d2n1Ov70kZsXHV8VcS80Sq9bjNc8KoxUztIcHKphfKWtpSuK0ra22Dr88g6aylLoQT Atez4wInzBAOAadLzWV8w84kj0SzNzD8Kn+iLdYjQ0YTUr+obu+4sAbAJ6tcf50wZ4E5 un8rsvwamSfKVdQ+T1t8mVqIXzsefnajm/Mcw= Received: by 10.142.136.1 with SMTP id j1mr3209471wfd.329.1279846098423; Thu, 22 Jul 2010 17:48:18 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n2sm11057019wfl.13.2010.07.22.17.48.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 17:48:17 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 22 Jul 2010 17:47:32 -0700 From: Pyun YongHyeon Date: Thu, 22 Jul 2010 17:47:32 -0700 To: "Mahlon E. Smith" , sbruno@freebsd.org, "freebsd-stable@freebsd.org" Message-ID: <20100723004732.GH16185@michelle.cdnetworks.com> References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> <20100723003611.GA66678@martini.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100723003611.GA66678@martini.nu> User-Agent: Mutt/1.4.2.3i Cc: jfv@FreeBSD.org Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 00:48:19 -0000 On Thu, Jul 22, 2010 at 05:36:11PM -0700, Mahlon E. Smith wrote: > On Thu, Jul 22, 2010, Sean Bruno wrote: > > > > Funny you should mention this box. I've been arm wrestling with this > > beastie for a couple of weeks and finally had some amount of success > > today. > > > > A couple of things: > > > > 1. Reduce your RAM to 64G (seriously) > > 2. Don't use the H200 Dell RAID controller. It's not supported yet. > > -- Use the 6i or whatever the mfi(4) card is called. > > 3. Don't compile in the ipmi(4) when you get the system up. > > -- I know there's an unpatched problem on 7 that is fixed in HEAD, but > > have no idea if its patched in 8 > > 4. Try doing serial console installs. > > -- at the Beastie prompt, hit [6]. then at the OK prompt, type "set > > console=comconsole" > > > Thanks for the suggestions, Sean. > > On a whim I decided to try with 8.1-RELEASE (since I obviously started > trying to get this goin' before it came out) -- lo, it put me right into > the sysinstall. ... that was an easy fix. Heh. (Is kern.smb.disabled > set for the 8.1 install or something? I didn't change anything > in between attempts.) In any event -- yaaaaay! > > Install worked great, though it appears I need to keep hyperthreading > ("logical processors" bios option) disabled for it to boot reliably. > Similar errors as before if I enable it. > > real memory = 103079215104 (98304 MB) > avail memory = 99492831232 (94883 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs > FreeBSD/SMP: 4 package(s) x 6 core(s) > > Holy cow, that's a nice sight. > > Got one panic shortly after getting it on the network: > http://dl.dropbox.com/u/7234177/panic.jpg > > ... but it looks like I'll have a lot of kernel and sysctl tweaking to > do regardless ("ix0: RX Descriptors exceed system mbuf max, using default Nonetheless it should not panic. Jack may want to know back trace information for the panic above.(CCed) > instead!"), so I'll report back to the list if the panic re-appears after > some tuning. > > -- > Mahlon E. Smith > http://www.martini.nu/contact.html From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 00:52:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C1F5106566C for ; Fri, 23 Jul 2010 00:52:01 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id E4A128FC1A for ; Fri, 23 Jul 2010 00:52:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L5Z00MF3JQNBW50@asmtp026.mac.com>; Thu, 22 Jul 2010 17:52:00 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007220136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-07-22_07:2010-07-23, 2010-07-22, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <20100723003611.GA66678@martini.nu> Date: Thu, 22 Jul 2010 17:51:59 -0700 Message-id: <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> <20100723003611.GA66678@martini.nu> To: "Mahlon E. Smith" X-Mailer: Apple Mail (2.1081) Cc: sbruno@freebsd.org, "freebsd-stable@freebsd.org" Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 00:52:01 -0000 Hi, Mahlon-- On Jul 22, 2010, at 5:36 PM, Mahlon E. Smith wrote: > Install worked great, though it appears I need to keep hyperthreading > ("logical processors" bios option) disabled for it to boot reliably. > Similar errors as before if I enable it. I believe FreeBSD ships with MAXCPU set to 32 by default (check "sysctl kern.smp.maxcpus"); your machine with hyperthreading enabled probably goes past that #, which is why it crashes with the topology error being reported.... Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 01:23:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9D51065677 for ; Fri, 23 Jul 2010 01:23:07 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (pop3.nitronet.pl [195.90.106.28]) by mx1.freebsd.org (Postfix) with ESMTP id C0BFB8FC17 for ; Fri, 23 Jul 2010 01:23:06 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oc6yf-000KxW-8k for freebsd-stable@freebsd.org; Fri, 23 Jul 2010 03:23:05 +0200 Date: Fri, 23 Jul 2010 03:22:59 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <718046944.20100723032259@nitronet.pl> To: Dan Langille In-Reply-To: <4C48E695.6030602@langille.org> References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 01:23:07 -0000 > I do not think I can adjust the existing zpool on the fly. I think I > need to copy everything elsewhere (i.e the 2 empty drives). Then start > the new zpool from scratch. You can, and you should (for educational purposes if not for fun :>), unless you wish to change raidz1 to raidz2. Replace, wait for resilver, if redoing used disk then offline it, wipe magic with dd (16KB at the beginning and end of disk/partition will do), carry on with GPT, rinse and repeat with next disk. When last vdev's replace finishes, your pool will grow automagically. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 01:28:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469D01065675 for ; Fri, 23 Jul 2010 01:28:27 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE4C8FC2E for ; Fri, 23 Jul 2010 01:28:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 78AA35093D for ; Fri, 23 Jul 2010 02:28:26 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+v5J4pEUbgK for ; Fri, 23 Jul 2010 02:28:26 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 075A25089E for ; Fri, 23 Jul 2010 02:28:25 +0100 (BST) Message-ID: <4C48F033.60800@langille.org> Date: Thu, 22 Jul 2010 21:28:19 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> In-Reply-To: <718046944.20100723032259@nitronet.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 01:28:27 -0000 On 7/22/2010 9:22 PM, Pawel Tyll wrote: >> I do not think I can adjust the existing zpool on the fly. I think I >> need to copy everything elsewhere (i.e the 2 empty drives). Then start >> the new zpool from scratch. > You can, and you should (for educational purposes if not for fun :>), > unless you wish to change raidz1 to raidz2. Replace, wait for > resilver, if redoing used disk then offline it, wipe magic with dd > (16KB at the beginning and end of disk/partition will do), carry on > with GPT, rinse and repeat with next disk. When last vdev's replace > finishes, your pool will grow automagically. So... the smaller size won't mess things up... -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 01:51:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C071106564A for ; Fri, 23 Jul 2010 01:51:32 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (pop3.nitronet.pl [195.90.106.28]) by mx1.freebsd.org (Postfix) with ESMTP id 178828FC13 for ; Fri, 23 Jul 2010 01:51:31 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oc7QA-000Nn1-L3 for freebsd-stable@freebsd.org; Fri, 23 Jul 2010 03:51:30 +0200 Date: Fri, 23 Jul 2010 03:51:27 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1201761644.20100723035127@nitronet.pl> To: freebsd-stable@freebsd.org In-Reply-To: <4C48F033.60800@langille.org> References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C48F033.60800@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 01:51:32 -0000 > So... the smaller size won't mess things up... If by smaller size you mean smaller size of existing drives/partitions, then growing zpools by replacing smaller vdevs with larger ones is supported and works. What isn't supported is basically everything else: - you can't change number of raid columns (add/remove vdevs from raid) - you can't change number of parity columns (raidz1->2 or 3) - you can't change vdevs to smaller ones, even if pool's free space would permit that. Good news is these features are planned/being worked on. If you can attach more drives to your system without disconnecting existing drives, then you can grow your pool pretty much risk-free. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 02:12:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB13106566C for ; Fri, 23 Jul 2010 02:12:18 +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 362A98FC1D for ; Fri, 23 Jul 2010 02:12:17 +0000 (UTC) Received: from [203.31.81.38] ([203.31.81.38]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6N2CAE7012531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Jul 2010 11:42:15 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Fri, 23 Jul 2010 11:42:10 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <297025B9-5F9C-4DFD-9C1D-31CA4E059119@gsoft.com.au> References: <4C47B57F.5020309@langille.org> To: Volodymyr Kostyrko X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.5 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 02:12:18 -0000 On 23/07/2010, at 24:56, Volodymyr Kostyrko wrote: > 22.07.2010 06:05, Dan Langille wrote: >> Create a new partition within that scheme: >>=20 >> gpart add -b 34 -s SOMEVALUE -t freebsd-zfs ad0 >>=20 >> Why '-b 34'? Randi pointed me to >> http://en.wikipedia.org/wiki/GUID_Partition_Table where it explains = what >> the first 33 LBA are used for. It's not for us to use here. >=20 > gpart is not so dumb to not protect this space. If you don't specify = -b when creating first partition it automagically defaults to 34. Maybe it should default to 40 to get 4k alignment..? (Probably a POLA/legacy issue there) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 06:35:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 609C6106566B for ; Fri, 23 Jul 2010 06:35:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8648FC12 for ; Fri, 23 Jul 2010 06:35:57 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OcBrP-0006jG-G7 for freebsd-stable@freebsd.org; Fri, 23 Jul 2010 09:35:55 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jul 2010 09:35:55 +0300 From: Daniel Braniss Message-ID: Subject: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 06:35:58 -0000 It seems that the latest changes (last 7 days) introduced this problem: ... run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config ... i'll try to hunt this down, but any help is welcome. danny From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 06:44:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5A31065674 for ; Fri, 23 Jul 2010 06:44:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 14C1B8FC14 for ; Fri, 23 Jul 2010 06:44:23 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta07.emeryville.ca.mail.comcast.net with comcast id lJYY1e0031eYJf8A7JkP84; Fri, 23 Jul 2010 06:44:23 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.emeryville.ca.mail.comcast.net with comcast id lJkN1e0063LrwQ201JkNCc; Fri, 23 Jul 2010 06:44:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0EE1B9B425; Thu, 22 Jul 2010 23:44:22 -0700 (PDT) Date: Thu, 22 Jul 2010 23:44:22 -0700 From: Jeremy Chadwick To: Daniel Braniss Message-ID: <20100723064421.GA40830@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 06:44:24 -0000 On Fri, Jul 23, 2010 at 09:35:55AM +0300, Daniel Braniss wrote: > It seems that the latest changes (last 7 days) introduced this problem: > ... > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > ... > > i'll try to hunt this down, but any help is welcome. Recent to semi-recent commits relevant to xpt that I can find The problem might not be even in xpt though. Which xpt piece pertains to you probably depends on your system setup/configuration. Dates/times are in PDT/UTC-0700: -rw-r--r-- 1 root wheel 6037 1 Mar 22:48 /usr/src/sys/cam/cam_xpt_internal.h -rw-r--r-- 1 root wheel 124773 9 May 10:19 /usr/src/sys/cam/cam_xpt.c -rw-r--r-- 1 root wheel 72556 23 May 10:41 /usr/src/sys/cam/scsi/scsi_xpt.c -rw-r--r-- 1 root wheel 56663 19 Jul 05:28 /usr/src/sys/cam/ata/ata_xpt.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt_internal.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/scsi/scsi_xpt.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 07:25:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE131065677 for ; Fri, 23 Jul 2010 07:25:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB7D8FC15 for ; Fri, 23 Jul 2010 07:25:55 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OcCdl-00079z-BZ; Fri, 23 Jul 2010 10:25:53 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20100723064421.GA40830@icarus.home.lan> References: <20100723064421.GA40830@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Thu, 22 Jul 2010 23:44:22 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jul 2010 10:25:53 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 07:25:55 -0000 > On Fri, Jul 23, 2010 at 09:35:55AM +0300, Daniel Braniss wrote: > > It seems that the latest changes (last 7 days) introduced this problem: > > ... > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > > ... > > > > i'll try to hunt this down, but any help is welcome. > > Recent to semi-recent commits relevant to xpt that I can find The > problem might not be even in xpt though. Which xpt piece pertains to > you probably depends on your system setup/configuration. Dates/times > are in PDT/UTC-0700: > > -rw-r--r-- 1 root wheel 6037 1 Mar 22:48 /usr/src/sys/cam/cam_xpt_internal.h > -rw-r--r-- 1 root wheel 124773 9 May 10:19 /usr/src/sys/cam/cam_xpt.c > -rw-r--r-- 1 root wheel 72556 23 May 10:41 /usr/src/sys/cam/scsi/scsi_xpt.c > -rw-r--r-- 1 root wheel 56663 19 Jul 05:28 /usr/src/sys/cam/ata/ata_xpt.c > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt_internal.h > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/scsi/scsi_xpt.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c thanks Jeremy, i'll try and make some sence of the changes. here is some more info: there are one disk and one dvd connected via SATA CPU: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz (3325.02-MHz K8-class CPU)^M Origin = "GenuineIntel" Id = 0x20652 Family = 6 Model = 25 Stepping = 2^M Features=0xbfebfbff^M Features2=0x298e3ff^M AMD Features=0x28100800^M AMD Features2=0x1^M ... atapci0: port 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 at device 22.2 on pci0^M atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf0b0^M ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49^M atapci0: [MPSAFE]^M atapci0: [ITHREAD]^M ata2: on atapci0^M atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf0f0^M atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf0e0^M ata2: reset tp1 mask=03 ostat0=7f ostat1=7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata2: reset tp2 stat0=ff stat1=ff devices=0x0^M ata2: [MPSAFE]^M ata2: [ITHREAD]^M ata3: on atapci0^M atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xf0d0^M atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xf0c0^M ata3: reset tp1 mask=03 ostat0=7f ostat1=7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f^M ata3: reset tp2 stat0=ff stat1=ff devices=0x0^M ata3: [MPSAFE]^M ata3: [ITHREAD]^M ... ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xfe425000-0xfe4257ff irq 19 at device 31.2 on pci0^M ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfe425000^M ahci0: attempting to allocate 1 MSI vectors (1 supported)^M msi: routing MSI IRQ 257 to local APIC 0 vector 53^M ahci0: using IRQ 257 for MSI^M ahci0: [MPSAFE]^M ahci0: [ITHREAD]^M ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported^M ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PMD SSC PSC 32cmd EM eSATA 6ports^M ahci0: Caps2: APST^M ahci0: EM Caps: ALHD XMT SMB LED^M ahcich0: at channel 0 on ahci0^M ahcich0: [MPSAFE]^M ahcich0: [ITHREAD]^M ahcich0: Caps:^M ahcich1: at channel 1 on ahci0^M ahcich1: [MPSAFE]^M ahcich1: [ITHREAD]^M ahcich1: Caps:^M ahcich2: at channel 4 on ahci0^M ahcich2: [MPSAFE]^M ahcich2: [ITHREAD]^M ahcich2: Caps: HPCP ESP^M ... ata2: Identifying devices: 00000000^M ata2: New devices: 00000000^M ata3: Identifying devices: 00000000^M ata3: New devices: 00000000^M usbus0: 480Mbps High Speed USB v2.0^M usbus1: 480Mbps High Speed USB v2.0^M ahcich0: AHCI reset...^M ugen0.1: at usbus0^M uhub0: on usbus0^M ugen1.1: at usbus1^M uhub1: on usbus1^M ahcich0: SATA connect time=0ms status=00000123^M ahcich0: ready wait time=0ms^M ahcich0: AHCI reset done: device found^M (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000^M ... From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 07:41:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 630F41065760 for ; Fri, 23 Jul 2010 07:41:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E1DDD8FC13 for ; Fri, 23 Jul 2010 07:41:08 +0000 (UTC) Received: by fxm13 with SMTP id 13so5309578fxm.13 for ; Fri, 23 Jul 2010 00:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=MNFDqrXUpjYG7n8g6fM2aUFcLNJG/82aGrHRQRP8WMo=; b=o2mCibhh62zn+SL2ia+pCkikig96MEG85gUA3q6YrlqKuKUmkBuPwGPQrQ7JHr9PwF kMmb0bh/e7K+dgLfNdVzZ4tS/Vd1/OgYpfIM8zVidQcYhTe3BRshe/WukqIA3BU4Tnkd 3PuUvxu6IWTVnIjzyU0aBjGjDfnP9+BZ7E/Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Od1siGHXDSC2a4ASp1NaONZ7Qa5yAGXkm77eZrXP0tpXegTJ0ACrIyJJfX+5VP/N43 f5dYDN8FlWicMRr3SpRi/zNOfZ0r7GdwmfiTFQxopqwRUEUqOotUSmHR5bQv6zHCbhwL mKpYyxfNCqkfiv0y/hKQClfqYgnNNZXnMqogM= Received: by 10.86.76.3 with SMTP id y3mr2343514fga.79.1279870867796; Fri, 23 Jul 2010 00:41:07 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm3633349fav.2.2010.07.23.00.41.06 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 00:41:07 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C494790.4070305@FreeBSD.org> Date: Fri, 23 Jul 2010 10:41:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Daniel Braniss , FreeBSD Stable References: <20100723064421.GA40830@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 07:41:09 -0000 Daniel Braniss wrote: >> On Fri, Jul 23, 2010 at 09:35:55AM +0300, Daniel Braniss wrote: >>> It seems that the latest changes (last 7 days) introduced this problem: >>> ... >>> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config >>> ... >>> >>> i'll try to hunt this down, but any help is welcome. >> Recent to semi-recent commits relevant to xpt that I can find The >> problem might not be even in xpt though. Which xpt piece pertains to >> you probably depends on your system setup/configuration. Dates/times >> are in PDT/UTC-0700: >> >> -rw-r--r-- 1 root wheel 6037 1 Mar 22:48 /usr/src/sys/cam/cam_xpt_internal.h >> -rw-r--r-- 1 root wheel 124773 9 May 10:19 /usr/src/sys/cam/cam_xpt.c >> -rw-r--r-- 1 root wheel 72556 23 May 10:41 /usr/src/sys/cam/scsi/scsi_xpt.c >> -rw-r--r-- 1 root wheel 56663 19 Jul 05:28 /usr/src/sys/cam/ata/ata_xpt.c >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt_internal.h >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/scsi/scsi_xpt.c >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c > > thanks Jeremy, i'll try and make some sence of the changes. > > here is some more info: > there are one disk and one dvd connected via SATA I recently had report about alike problem with "PIONEER DVD-RW DVR-215 1.19" drive. Don't you have the same device or another Pioneer? In that case this patch: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c.diff?r1=1.3.2.29;r2=1.3.2.30;f=h allowed system to boot, though problem seemed to be hardware. Try this patch, it at least may give additional info about the problem. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 08:00:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 644431065670; Fri, 23 Jul 2010 08:00:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id CD9CA8FC22; Fri, 23 Jul 2010 08:00:35 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OcDBK-0007RD-SL; Fri, 23 Jul 2010 11:00:34 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Alexander Motin In-reply-to: <4C494790.4070305@FreeBSD.org> References: <20100723064421.GA40830@icarus.home.lan> <4C494790.4070305@FreeBSD.org> Comments: In-reply-to Alexander Motin message dated "Fri, 23 Jul 2010 10:41:04 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jul 2010 11:00:34 +0300 From: Daniel Braniss Message-ID: Cc: FreeBSD Stable , Jeremy Chadwick Subject: WITNESS is the culprit was Re: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 08:00:36 -0000 > Daniel Braniss wrote: > >> On Fri, Jul 23, 2010 at 09:35:55AM +0300, Daniel Braniss wrote: > >>> It seems that the latest changes (last 7 days) introduced this problem: > >>> ... > >>> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > >>> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > >>> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > >>> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > >>> ... > >>> > >>> i'll try to hunt this down, but any help is welcome. > >> Recent to semi-recent commits relevant to xpt that I can find The > >> problem might not be even in xpt though. Which xpt piece pertains to > >> you probably depends on your system setup/configuration. Dates/times > >> are in PDT/UTC-0700: > >> > >> -rw-r--r-- 1 root wheel 6037 1 Mar 22:48 /usr/src/sys/cam/cam_xpt_internal.h > >> -rw-r--r-- 1 root wheel 124773 9 May 10:19 /usr/src/sys/cam/cam_xpt.c > >> -rw-r--r-- 1 root wheel 72556 23 May 10:41 /usr/src/sys/cam/scsi/scsi_xpt.c > >> -rw-r--r-- 1 root wheel 56663 19 Jul 05:28 /usr/src/sys/cam/ata/ata_xpt.c > >> > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt_internal.h > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/scsi/scsi_xpt.c > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c > > > > thanks Jeremy, i'll try and make some sence of the changes. > > > > here is some more info: > > there are one disk and one dvd connected via SATA > > I recently had report about alike problem with "PIONEER DVD-RW DVR-215 > 1.19" drive. Don't you have the same device or another Pioneer? > > In that case this patch: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c.diff?r1=1.3.2.29;r2=1.3.2.30;f=h > allowed system to boot, though problem seemed to be hardware. Try this > patch, it at least may give additional info about the problem. That was my first guess, so I detached the DVD, but the problem persisted. the device is: ATAPI DVD A DH16AAS JL34> Removable CD-ROM SCSI-0 device anyways, I compiled a kernel without WITNESS, and it now works ok! thanks all, danny From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 08:06:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6BD71065670 for ; Fri, 23 Jul 2010 08:06:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 614508FC18 for ; Fri, 23 Jul 2010 08:06:27 +0000 (UTC) Received: by fxm13 with SMTP id 13so5321556fxm.13 for ; Fri, 23 Jul 2010 01:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=HxeGNY8DA2TWHDhCUCtmjK6pF/j36x7UEUlb7EB2pRk=; b=dNeHK/0Kv3asZLVOP78WLoNcHDRjpZfJ18NGJJVw4X1/fGCYEUju7paHnpCO3qpvtC 94vNM0jnk/6f/z8eTptFd3z1IQTA6amowC7PyKkiQc4iDLxLGAn/I/sV/frivp5ypF/Z 8XS5Ym9PWsQmOqKo9n0cvDsWMlZeUxhS+F7vY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=vGtfTxKpFZZzOnFqh8itksYM2TLnyd+WzXefynlsNDk174Ky+/gXe20BLP9btz2d8K 3jiSvOqILAc3Q7mfYAS/8i0A4jQAVfw4Hd8BugvP5XKHKCeZi9BGzLl790lQQNgZkh6m UtAGea8ts8xM41rLaTdMUDOWZoiXZGdGDC560= Received: by 10.223.126.71 with SMTP id b7mr2878531fas.97.1279872385568; Fri, 23 Jul 2010 01:06:25 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d15sm42100faa.1.2010.07.23.01.06.24 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 01:06:24 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C494D7D.6040608@FreeBSD.org> Date: Fri, 23 Jul 2010 11:06:21 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Daniel Braniss References: <20100723064421.GA40830@icarus.home.lan> <4C494790.4070305@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: WITNESS is the culprit was Re: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 08:06:28 -0000 Daniel Braniss wrote: >> Daniel Braniss wrote: >>>> On Fri, Jul 23, 2010 at 09:35:55AM +0300, Daniel Braniss wrote: >>>>> It seems that the latest changes (last 7 days) introduced this problem: >>>>> ... >>>>> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >>>>> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config >>>>> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config >>>>> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config >>>>> ... >>>>> >>>>> i'll try to hunt this down, but any help is welcome. >>>> Recent to semi-recent commits relevant to xpt that I can find The >>>> problem might not be even in xpt though. Which xpt piece pertains to >>>> you probably depends on your system setup/configuration. Dates/times >>>> are in PDT/UTC-0700: >>>> >>>> -rw-r--r-- 1 root wheel 6037 1 Mar 22:48 /usr/src/sys/cam/cam_xpt_internal.h >>>> -rw-r--r-- 1 root wheel 124773 9 May 10:19 /usr/src/sys/cam/cam_xpt.c >>>> -rw-r--r-- 1 root wheel 72556 23 May 10:41 /usr/src/sys/cam/scsi/scsi_xpt.c >>>> -rw-r--r-- 1 root wheel 56663 19 Jul 05:28 /usr/src/sys/cam/ata/ata_xpt.c >>>> >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt_internal.h >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/scsi/scsi_xpt.c >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c >>> thanks Jeremy, i'll try and make some sence of the changes. >>> >>> here is some more info: >>> there are one disk and one dvd connected via SATA >> I recently had report about alike problem with "PIONEER DVD-RW DVR-215 >> 1.19" drive. Don't you have the same device or another Pioneer? >> >> In that case this patch: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_xpt.c.diff?r1=1.3.2.29;r2=1.3.2.30;f=h >> allowed system to boot, though problem seemed to be hardware. Try this >> patch, it at least may give additional info about the problem. > > That was my first guess, so I detached the DVD, but the problem persisted. > the device is: > ATAPI DVD A DH16AAS JL34> Removable CD-ROM SCSI-0 device > > anyways, I compiled a kernel without WITNESS, and it now works ok! That's hardly a solution or reason. Still please try the patch (or fresh 8-STABLE with it), may be it tell more. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 09:54:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 613561065672; Fri, 23 Jul 2010 09:54:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C56A48FC08; Fri, 23 Jul 2010 09:53:59 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OcEx4-0008oD-QY; Fri, 23 Jul 2010 12:53:58 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Alexander Motin In-reply-to: Your message of Fri, 23 Jul 2010 11:06:21 +0300 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jul 2010 12:53:58 +0300 From: Daniel Braniss Message-ID: Cc: FreeBSD Stable Subject: Re: WITNESS is the culprit was Re: latest 8.1 hangs on xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 09:54:00 -0000 > That's hardly a solution or reason. of course it's not, just that last successful boot had WITNESS configured, and with the latest patches it hang, compiling without WITNESS allowed the boot to proceed. > Still please try the patch (or fresh > 8-STABLE with it), may be it tell more. > according to my logs (i do some hulahups sync'ing via svn/hg which makes it abit of a problem following versions :-) your patch seems to be all ready in my kernel: hg log ata_xpt.c -p changeset: 2939:440362ab79cb branch: 8 tag: tip parent: 2938:fc1c9d5f4b38 parent: 2937:846cb2242d34 user: danny@cs.huji.ac.il date: Fri Jul 23 08:41:24 2010 +0300 summary: -- merge from head -- diff -r fc1c9d5f4b38 -r 440362ab79cb sys/cam/ata/ata_xpt.c --- a/sys/cam/ata/ata_xpt.c Fri Jul 23 08:40:46 2010 +0300 +++ b/sys/cam/ata/ata_xpt.c Fri Jul 23 08:41:24 2010 +0300 @@ -134,6 +134,7 @@ uint32_t pm_prv; int restart; int spinup; + int faults; u_int caps; struct cam_periph *periph; } probe_softc; @@ -738,14 +739,28 @@ ident_buf = &path->device->ident_data; if ((done_ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) { -device_fail: if ((!softc->restart) && - cam_periph_error(done_ccb, 0, 0, NULL) == ERESTART) { + if (softc->restart) { + if (bootverbose) { + cam_error_print(done_ccb, + CAM_ESF_ALL, CAM_EPF_ALL); + } + } else if (cam_periph_error(done_ccb, 0, 0, NULL) == ERESTART) return; - } else if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) { + if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) { /* Don't wedge the queue */ xpt_release_devq(done_ccb->ccb_h.path, /*count*/1, /*run_queue*/TRUE); } + if (softc->restart) { + softc->faults++; + if ((done_ccb->ccb_h.status & CAM_STATUS_MASK) == + CAM_CMD_TIMEOUT) + softc->faults += 4; + if (softc->faults < 10) + goto done; + else + softc->restart = 0; + } else /* Old PIO2 devices may not support mode setting. */ if (softc->action == PROBE_SETMODE && ata_max_pmode(ident_buf) <= ATA_PIO2 && @@ -761,7 +776,7 @@ * already marked unconfigured, notify the peripheral * drivers that this device is no more. */ - if ((path->device->flags & CAM_DEV_UNCONFIGURED) == 0) +device_fail: if ((path->device->flags & CAM_DEV_UNCONFIGURED) == 0) xpt_async(AC_LOST_DEVICE, path, NULL); found = 0; goto done; @@ -1209,6 +1224,12 @@ !(work_ccb->cpi.hba_misc & PIM_NOBUSRESET) && !timevalisset(&request_ccb->ccb_h.path->bus->last_reset)) { reset_ccb = xpt_alloc_ccb_nowait(); + if (reset_ccb == NULL) { + request_ccb->ccb_h.status = CAM_RESRC_UNAVAIL; + xpt_free_ccb(work_ccb); + xpt_done(request_ccb); + return; + } xpt_setup_ccb(&reset_ccb->ccb_h, request_ccb-> ccb_h.path, CAM_PRIORITY_NONE); reset_ccb->ccb_h.func_code = XPT_RESET_BUS; @@ -1228,6 +1249,7 @@ malloc(sizeof(ata_scan_bus_info), M_CAMXPT, M_NOWAIT); if (scan_info == NULL) { request_ccb->ccb_h.status = CAM_RESRC_UNAVAIL; + xpt_free_ccb(work_ccb); xpt_done(request_ccb); return; } cheers, danny From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 10:48:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65553106564A for ; Fri, 23 Jul 2010 10:48:22 +0000 (UTC) (envelope-from jon@witchspace.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id CA0FA8FC08 for ; Fri, 23 Jul 2010 10:48:21 +0000 (UTC) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100723104820.FARH3266.mtaout01-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Fri, 23 Jul 2010 11:48:20 +0100 Received: from witchspace.com ([86.28.98.4]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with SMTP id <20100723104820.QXHA1593.aamtaout04-winn.ispmail.ntl.com@witchspace.com> for ; Fri, 23 Jul 2010 11:48:20 +0100 Received: (qmail 13724 invoked from network); 23 Jul 2010 09:51:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (192.168.0.1) by 192.168.0.100 with SMTP; 23 Jul 2010 09:51:56 -0000 Message-ID: <4C497370.3010803@witchspace.com> Date: Fri, 23 Jul 2010 11:48:16 +0100 From: Jonathan Belson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=DhNl2YeytwJssBBGe49HJX82LNDFEEVkpVB34RXKaPo= c=1 sm=0 a=XCep0buvX5cA:10 a=VphdPIyG4kEA:10 a=8nJEP1OIZ-IA:10 a=PkMCkVwOlbyyANZ8FucA:9 a=6nvFbDqL2N0n299N6QAA:7 a=eu0ZdkvqExswZ5rzEhiQOIckyUUA:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: 900.tcpwrap and stale log messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 10:48:22 -0000 Hiya Early this morning I read through the daily status e-mails from a server I administer. I was unpleasantly surprised to see a refused ssh connection from an external IP address, which shouldn't be possible since the machine is only accessible via a VPN :-O It wasn't until after I'd spoken to the network admin I realised what the problem was - /var/log/messages contained log messages that spanned back into 2009 (the machine is only used for SVN access so isn't very busy), and 900.tcpwrap had taken entries from both July 22 2010 (yesterday) and July 22nd 2009, when the machine was on a different network... :-( How. Embarrassing. It isn't really 900.tcpwrap's fault as the log messages only record the month, date and time, but is there any reason why the year isn't recorded in the log too? I realise this issue isn't likely to come up often, but it should be fairly easy to prevent. Cheers, --Jon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 10:58:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A38801065674 for ; Fri, 23 Jul 2010 10:58:01 +0000 (UTC) (envelope-from holm@pegasus.freibergnet.de) Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1918FC15 for ; Fri, 23 Jul 2010 10:58:00 +0000 (UTC) Received: from pegasus.freibergnet.de (localhost [127.0.0.1]) by pegasus.freibergnet.de (8.14.4/8.14.4) with ESMTP id o6NAJOjJ096977 for ; Fri, 23 Jul 2010 12:19:24 +0200 (CEST) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.14.4/8.14.4/Submit) id o6NAJO2K096976 for freebsd-stable@freebsd.org; Fri, 23 Jul 2010 12:19:24 +0200 (CEST) (envelope-from holm) Date: Fri, 23 Jul 2010 12:19:24 +0200 From: Holm Tiffe To: freebsd-stable@freebsd.org Message-ID: <20100723101924.GB96573@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Organization: FreibergNet Internet Services, TSHT Priority: normal X-Phone: +49-3731-74222 X-Mobile: +49-172-8790741 X-Fax: +49-3731-74200 Subject: Floppy driver broken on 8.1-PRERELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: holm@freibergnet.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 10:58:01 -0000 Hi guys, can please someone explain what the heck this is good for? $ uname -a FreeBSD unicorn.tsht.lan 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #9: Wed Jul 7 15:31:25 CEST 2010 r@unicorn.tsht.lan:/data/FreeBSD/obj/data/FreeBSD/src/sys/UNICORN i386 $ fdformat /dev/fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV done. $ dd if=/dev/fd0 of=/dev/null bs=1440k dd: /dev/fd0: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.119664 secs (0 bytes/sec) $ dd if=/dev/fd0 of=/dev/null bs=18k 80+0 records in 80+0 records out 1474560 bytes transferred in 47.954204 secs (30749 bytes/sec) $ mformat -s18 -h2 -t80 a: $ mcopy cool111.exe a: plain_io: Input/output error buffer_flush: write: Input/output error write in copy: Input/output error plain_io: Input/output error buffer_flush: write: Input/output error plain_io: Input/output error buffer_flush: write: Input/output error plain_io: Input/output error buffer_flush: write: Input/output error plain_io: Input/output error buffer_flush: write: Input/output error plain_io: Input/output error buffer_flush: write: Input/output error $ mdir a: Volume in drive A has no label Volume Serial Number is 070F-B873 Directory for A:/ cool111 exe 131072 2010-07-23 12:12 cool111.exe 1 file 131 072 bytes 1 195 520 bytes free $ ls -l cool111.exe -rw-r--r-- 1 holm holm 623235 Jul 20 21:09 cool111.exe $ ...and no, this is not abroken floppy, tried several of them already. Why I can't read 1440K blocks from the floppy anymore? dmesg.boot: Copyright (c) 1992-2010 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 8.1-PRERELEASE #9: Wed Jul 7 15:31:25 CEST 2010 r@unicorn.tsht.lan:/data/FreeBSD/obj/data/FreeBSD/src/sys/UNICORN i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3000+ (2109.49-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Family = 6 Model = a Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 2147483648 (2048 MB) avail memory = 2092113920 (1995 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 128M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xd8000000-0xdfffffff,0xe9000000-0xe900ffff irq 15 at device 0.0 on pci1 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 128MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe0000000-0xe7ffffff,0xe9010000-0xe901ffff at device 0.1 on pci1 de0: port 0xa000-0xa07f mem 0xeb003000-0xeb00307f irq 15 at device 9.0 on pci0 de0: Cogent 21040 [10Mb/s] pass 2.3 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:92:90:09:8d de0: [ITHREAD] puc0: port 0xa400-0xa407,0xa800-0xa807,0xac00-0xac1f mem 0xeb000000-0xeb000fff,0xeb001000-0xeb001fff irq 5 at device 10.0 on pci0 puc0: [FILTER] uart2: <16550 or compatible> on puc0 uart2: [FILTER] uart3: <16550 or compatible> on puc0 uart3: [FILTER] ahc0: port 0xb000-0xb0ff mem 0xeb002000-0xeb002fff irq 11 at device 11.0 on pci0 ahc0: [ITHREAD] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs amd0: port 0xb400-0xb47f irq 15 at device 13.0 on pci0 amd0: [GIANT-LOCKED] amd0: [ITHREAD] uhci0: port 0xb800-0xb81f irq 15 at device 16.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xbc00-0xbc1f irq 15 at device 16.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xc000-0xc01f irq 5 at device 16.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xeb004000-0xeb0040ff irq 11 at device 16.3 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcm0: port 0xc800-0xc8ff irq 5 at device 17.5 on pci0 pcm0: [ITHREAD] pcm0: pcm0: rl0: port 0xcc00-0xccff mem 0xeb005000-0xeb0050ff irq 5 at device 19.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0d:61:c3:c4:5a rl0: [ITHREAD] atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fd1: <1200-KB 5.25" drive> on fdc0 drive 1 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2109486108 Hz quality 800 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 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 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered (probe6:ahc0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe6:ahc0:0:6:0): CAM status: SCSI Status Error (probe6:ahc0:0:6:0): SCSI status: Check Condition (probe6:ahc0:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe5:ahc0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe5:ahc0:0:5:0): CAM status: SCSI Status Error (probe5:ahc0:0:5:0): SCSI status: Check Condition (probe5:ahc0:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) sa0 at ahc0 bus 0 scbus0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers sa1 at ahc0 bus 0 scbus0 target 6 lun 0 sa1: Removable Sequential Access SCSI-CCS device sa1: 3.300MB/s transfers da0 at ahc0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da0: Command Queueing enabled da0: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da1 at ahc0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da1: Command Queueing enabled da1: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da2 at ahc0 bus 0 scbus0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da2: Command Queueing enabled da2: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da3 at ahc0 bus 0 scbus0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da2 at ahc0 bus 0 scbus0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da2: Command Queueing enabled da2: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da3 at ahc0 bus 0 scbus0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da3: Command Queueing enabled da3: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) GEOM_CONCAT: Device gc0d created (id=2065581164). GEOM_CONCAT: Disk da0d attached to gc0d. GEOM_CONCAT: Device data created (id=2038144655). GEOM_CONCAT: Disk da0g attached to data. GEOM_MIRROR: Device mirror/gm0a launched (2/2). GEOM_CONCAT: Disk da1d attached to gc0d. GEOM_CONCAT: Device gc0d activated. GEOM_MIRROR: Device mirror/gm0e launched (2/2). GEOM_MIRROR: Device mirror/gm0f launched (2/2). GEOM_CONCAT: Disk da1g attached to data. GEOM_CONCAT: Disk da2a attached to data. GEOM_CONCAT: Disk da2b attached to data. GEOM_CONCAT: Device data activated. Trying to mount root from ufs:/dev/mirror/gm0a Kid Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, info@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 11:12:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579D3106564A for ; Fri, 23 Jul 2010 11:12:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 068678FC16 for ; Fri, 23 Jul 2010 11:12:25 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id lNqJ1e0030EZKEL51PCRtr; Fri, 23 Jul 2010 11:12:25 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.westchester.pa.mail.comcast.net with comcast id lPCQ1e0083LrwQ23MPCRHc; Fri, 23 Jul 2010 11:12:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8A7CE9B425; Fri, 23 Jul 2010 04:12:23 -0700 (PDT) Date: Fri, 23 Jul 2010 04:12:23 -0700 From: Jeremy Chadwick To: Jonathan Belson Message-ID: <20100723111223.GA47358@icarus.home.lan> References: <4C497370.3010803@witchspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C497370.3010803@witchspace.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: 900.tcpwrap and stale log messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 11:12:26 -0000 On Fri, Jul 23, 2010 at 11:48:16AM +0100, Jonathan Belson wrote: > Early this morning I read through the daily status e-mails from a > server I administer. I was unpleasantly surprised to see a refused > ssh connection from an external IP address, which shouldn't be > possible since the machine is only accessible via a VPN :-O > > It wasn't until after I'd spoken to the network admin I realised > what the problem was - /var/log/messages contained log messages that > spanned back into 2009 (the machine is only used for SVN access so > isn't very busy), and 900.tcpwrap had taken entries from both July > 22 2010 (yesterday) and July 22nd 2009, when the machine was on a > different network... :-( How. Embarrassing. > > It isn't really 900.tcpwrap's fault as the log messages only record > the month, date and time, but is there any reason why the year isn't > recorded in the log too? I realise this issue isn't likely to come > up often, but it should be fairly easy to prevent. You've opened a big can of worms. Congratulations. :-) The crux of the problem is that syslog doesn't log the year. Thus, /var/log/messages and /var/log/messages.*.{gz,bz2} only contain entries that contain month and day, as I'm sure you've noticed. /etc/periodic/security/900.tcpwrap explicitly goes looking for lines in /var/log/messages and /var/log/messages.*.{gz,bz2} that contain a string matching output from: date -v-1d "+%b %e " You can't solve this problem by rotating your /var/log/messages file, for example, on a daily basis, because the script explicitly looks at /var/log/messages and /var/log/messages.*.{gz,bz2}. The only solution, as I see it, is to do all of these things: 1a) Change /etc/newsyslog.conf to rotate your /var/log/messages file on a daily basis, rather than based on size. 1b) The rotation should happen sometime *after* 900.tcpwrap runs (it's a daily script, so that means it runs at 03:01 every day local time). 2a) Change 900.tcpwrap to only look at /var/log/messages and not /var/log/messages.*.{gz,bz2}. 2b) Since changing things in /etc/periodic/security won't stick during mergemaster (unless you use IGNORE_FILES in /etc/rc/mergemaster.rc), you should probably put your version of the script in /usr/local/etc/periodic/security and change the names of the rc variables to key off of something that doesn't conflict with the base system version. There are other solutions, of course, but they'd require touching a lot of things and probably breaking historic naming conventions and expectations. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 11:24:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 984DE1065676 for ; Fri, 23 Jul 2010 11:24:23 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE0A8FC0C for ; Fri, 23 Jul 2010 11:24:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 96D6150B7A; Fri, 23 Jul 2010 12:24:22 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDSTyQ8wTSEK; Fri, 23 Jul 2010 12:24:20 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id AA94250A93 ; Fri, 23 Jul 2010 12:24:20 +0100 (BST) Message-ID: <4C497BDE.7020506@langille.org> Date: Fri, 23 Jul 2010 07:24:14 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Pawel Tyll References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C48F033.60800@langille.org> <1201761644.20100723035127@nitronet.pl> In-Reply-To: <1201761644.20100723035127@nitronet.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 11:24:23 -0000 On 7/22/2010 9:51 PM, Pawel Tyll wrote: >> So... the smaller size won't mess things up... > If by smaller size you mean smaller size of existing > drives/partitions, then growing zpools by replacing smaller vdevs > with larger ones is supported and works. What isn't supported is > basically everything else: > - you can't change number of raid columns (add/remove vdevs from raid) > - you can't change number of parity columns (raidz1->2 or 3) > - you can't change vdevs to smaller ones, even if pool's free space > would permit that. Isn't what I'm doing breaking the last one? > > Good news is these features are planned/being worked on. > > If you can attach more drives to your system without disconnecting > existing drives, then you can grow your pool pretty much risk-free. > > > _______________________________________________ > 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" > -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 11:42:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30034106566B for ; Fri, 23 Jul 2010 11:42:39 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by mx1.freebsd.org (Postfix) with ESMTP id 931BC8FC0C for ; Fri, 23 Jul 2010 11:42:38 +0000 (UTC) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com ([77.103.165.1] helo=propellor.libeljournal.com country=GB ident=hirez) by v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4c49802c.6ce4.87; Fri, 23 Jul 2010 12:42:36 +0100 (envelope-sender ) Received: from localhost (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id 4BECC1705A; Fri, 23 Jul 2010 12:42:36 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by localhost (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgJwUqa1LFVW; Fri, 23 Jul 2010 12:42:31 +0100 (BST) Received: from ballard.futurenet.co.uk (propellor.libeljournal.com [172.16.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by propellor.libeljournal.com (Postfix) with ESMTPSA id A22E71701A; Fri, 23 Jul 2010 12:42:31 +0100 (BST) Message-ID: <4C498024.7050106@libeljournal.com> Date: Fri, 23 Jul 2010 12:42:28 +0100 From: John Hawkes-Reed User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> In-Reply-To: <4C48E695.6030602@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 11:42:39 -0000 Dan Langille wrote: > Thank you to all the helpful discussion. It's been very helpful and > educational. Based on the advice and suggestions, I'm going to adjust > my original plan as follows. [ ... ] Since I still have the medium-sized ZFS array on the bench, testing this GPT setup seemed like a good idea. The hardware's a Supermicro X8DTL-iF m/b + 12Gb memory, 2x 5502 Xeons, 3x Supermicro USASLP-L8I 3G SAS controllers and 24x Hitachi 2Tb drives. Partitioning the drives with the command-line: gpart add -s 1800G -t freebsd-zfs -l disk00 da0[1] gave the following results with bonnie-64: (Bonnie -r -s 5000|20000|50000)[2] -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 5 97.7 92.8 387.2 40.1 341.8 45.7 178.7 81.6 972.4 54.7 335 1.5 20 98.0 87.0 434.9 45.2 320.9 42.5 141.4 87.4 758.0 53.5 178 1.6 50 98.0 92.0 435.7 46.0 325.4 44.7 143.4 93.1 788.6 57.1 140 1.5 Repartitioning with gpart add -b 1024 -s 1800G -t freebsd-zfs -l disk00 da0[1] gave the following: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 5 97.8 93.4 424.5 45.4 338.4 46.1 180.0 93.9 934.9 57.8 308 1.5 20 97.6 91.7 448.4 49.2 338.5 45.9 176.1 91.8 914.7 57.3 180 1.3 50 96.3 90.3 452.8 47.6 330.9 44.7 174.8 74.5 917.9 53.6 134 1.2 ... So it would seem that bothering to align the blocks does make a difference. For an apples/oranges comparison, here's the output from the other box we built. The hardware's more or less the same - the drive controller's an Areca-1280, but the OS was Solaris 10.latest: --------Sequential Output------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 5 116.8 75.0 524.7 65.4 156.3 20.3 161.6 99.2 2924.0 100.0 199999 300.0 20 139.9 95.4 503.5 51.7 106.6 13.4 97.6 62.0 133.0 8.8 346 4.2 50 147.4 95.8 465.8 50.1 106.1 13.5 97.9 62.5 143.8 8.7 195 4.1 [1] da0 - da23, obviously. [2] Our assumption locally is that the first test is likely just stressing the bandwidth to memory and the ZFS cache. -- JH-R From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 15:11:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB7B71065672; Fri, 23 Jul 2010 15:11:39 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id D0BC18FC22; Fri, 23 Jul 2010 15:11:39 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6NFB3ER023576; Fri, 23 Jul 2010 08:11:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=OHvtjF2ERIEiwEgX9t0bSGfaC/Rxqd4PSczj1PC5VQTawdyJTLze21VeldHRKs3W From: Sean Bruno To: Chuck Swiger In-Reply-To: <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> <20100723003611.GA66678@martini.nu> <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 23 Jul 2010 08:11:03 -0700 Message-ID: <1279897863.2525.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "sbruno@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 15:11:40 -0000 On Thu, 2010-07-22 at 17:51 -0700, Chuck Swiger wrote: > Hi, Mahlon-- > > On Jul 22, 2010, at 5:36 PM, Mahlon E. Smith wrote: > > Install worked great, though it appears I need to keep hyperthreading > > ("logical processors" bios option) disabled for it to boot reliably. > > Similar errors as before if I enable it. > > I believe FreeBSD ships with MAXCPU set to 32 by default (check "sysctl kern.smp.maxcpus"); your machine with hyperthreading enabled probably goes past that #, which is why it crashes with the topology error being reported.... > > Regards, confirmed. Yahoo has modified FreeBSD SMP CPU code to handle up to 64 CPUS, I think I'll take a look at it and try to get it committed to HEAD today. Sean From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 15:11:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D8E31065675 for ; Fri, 23 Jul 2010 15:11:40 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2A98FC25 for ; Fri, 23 Jul 2010 15:11:40 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6NFBREh088516; Fri, 23 Jul 2010 08:11:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=vWvfm1ygEVG/LREBoZZPbpFzcy4TYEhvSa7E9y5ezNzSxGt64ozelDukbbTu1RpX From: Sean Bruno To: Chuck Swiger In-Reply-To: <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> <20100723003611.GA66678@martini.nu> <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 23 Jul 2010 08:11:27 -0700 Message-ID: <1279897887.2525.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jul 2010 15:11:40 -0000 On Thu, 2010-07-22 at 17:51 -0700, Chuck Swiger wrote: > Hi, Mahlon-- > > On Jul 22, 2010, at 5:36 PM, Mahlon E. Smith wrote: > > Install worked great, though it appears I need to keep hyperthreading > > ("logical processors" bios option) disabled for it to boot reliably. > > Similar errors as before if I enable it. > > I believe FreeBSD ships with MAXCPU set to 32 by default (check "sysctl kern.smp.maxcpus"); your machine with hyperthreading enabled probably goes past that #, which is why it crashes with the topology error being reported.... > > Regards, confirmed. Yahoo has modified FreeBSD SMP CPU code to handle up to 64 CPUS, I think I'll take a look at it and try to get it committed to HEAD today. Sean From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 15:17:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E5C106564A for ; Fri, 23 Jul 2010 15:17:54 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AADB48FC1F for ; Fri, 23 Jul 2010 15:17:53 +0000 (UTC) Received: by fxm13 with SMTP id 13so5574555fxm.13 for ; Fri, 23 Jul 2010 08:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e2BWL7UhCQUgiRffOjnZbSt/xG7THc7rh38xrJ+u2aA=; b=Q6ZFj/JXgm69AfOzohbguW0TSeSvRs0DILfl5AoW8/I8PTDHl89TyA3wZnRLjy1gzX 4/M/iAmsYkFy43c+ee4qojgaGAdQlQK137sqTttI36hwvlppWXV1Cte5x90weR18JAWY qm1YLe17inp3+U4WmDadA1I4kCuuqGguLemz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Chgapnk4pr4ZveRqYCYmNLE/o2mJKgZM2ELED/6ELzl1kgrWprLRNAab7qi6B17IKZ xwOGOy5Q/B+hiw6d/yjRfL5LxgIJYa6aldVdFDmTyX6mfqwjBBBO7yKRZDcbrTDYOue5 Mr/b8FxVmZSDEaMJCktj+BviHFywe6tvJLY14= MIME-Version: 1.0 Received: by 10.239.155.74 with SMTP id h10mr331846hbc.30.1279898272307; Fri, 23 Jul 2010 08:17:52 -0700 (PDT) Received: by 10.239.173.201 with HTTP; Fri, 23 Jul 2010 08:17:52 -0700 (PDT) In-Reply-To: <718046944.20100723032259@nitronet.pl> References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> Date: Fri, 23 Jul 2010 10:17:52 -0500 Message-ID: From: Tom Evans To: Pawel Tyll Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 15:17:54 -0000 On Thu, Jul 22, 2010 at 8:22 PM, Pawel Tyll wrote: >> I do not think I can adjust the existing zpool on the fly. =C2=A0I think= I >> need to copy everything elsewhere (i.e the 2 empty drives). =C2=A0Then s= tart >> the new zpool from scratch. > You can, and you should (for educational purposes if not for fun :>), > unless you wish to change raidz1 to raidz2. Replace, wait for > resilver, if redoing used disk then offline it, wipe magic with dd > (16KB at the beginning and end of disk/partition will do), carry on > with GPT, rinse and repeat with next disk. When last vdev's replace > finishes, your pool will grow automagically. > If you do do it like this, be sure to leave the drive you are replacing attached to the array. Otherwise, in a raidz, if you were to suffer a disk failure on one of the other disks whilst replacing/growing the array, your raidz would be badly broken. Other than that, I can thoroughly recommend this method, I had data on 2 x 1.5 TB drives, and set up my raidz initially with 4 x 1.5 TB, 2 x 0.5 TB, copying data off the 1.5 TB drives onto the array and replacing each 0.5 TB drive when done. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 18:04:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53D561065672 for ; Fri, 23 Jul 2010 18:04:51 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D363E8FC21 for ; Fri, 23 Jul 2010 18:04:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o6NI4mwu047088; Fri, 23 Jul 2010 22:04:48 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 23 Jul 2010 22:04:48 +0400 (MSD) From: Dmitry Morozovsky To: John Hawkes-Reed In-Reply-To: <4C498024.7050106@libeljournal.com> Message-ID: References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <4C498024.7050106@libeljournal.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (woozle.rinet.ru [0.0.0.0]); Fri, 23 Jul 2010 22:04:49 +0400 (MSD) Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 18:04:51 -0000 On Fri, 23 Jul 2010, John Hawkes-Reed wrote: JH> Since I still have the medium-sized ZFS array on the bench, testing this GPT JH> setup seemed like a good idea. JH> JH> The hardware's a Supermicro X8DTL-iF m/b + 12Gb memory, 2x 5502 Xeons, 3x JH> Supermicro USASLP-L8I 3G SAS controllers and 24x Hitachi 2Tb drives. [snip] JH> For an apples/oranges comparison, here's the output from the other box we JH> built. The hardware's more or less the same - the drive controller's an JH> Areca-1280, but the OS was Solaris 10.latest: JH> JH> --------Sequential Output------- ---Sequential Input-- --Random-- JH> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- JH> JH> GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU JH> 5 116.8 75.0 524.7 65.4 156.3 20.3 161.6 99.2 2924.0 100.0 199999 300.0 . ~~~~~~ Frakking Cylons! You have quite a beast! ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 19:08:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55A0F106567F for ; Fri, 23 Jul 2010 19:08:05 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by mx1.freebsd.org (Postfix) with ESMTP id 79F4A8FC28 for ; Fri, 23 Jul 2010 19:08:04 +0000 (UTC) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com ([77.103.165.1] helo=propellor.libeljournal.com country=GB ident=hirez) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4c49e892.1f35.35 for freebsd-stable@freebsd.org; Fri, 23 Jul 2010 20:08:02 +0100 (envelope-sender ) Received: from localhost (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id 38AF51705A for ; Fri, 23 Jul 2010 20:08:02 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by localhost (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+LmBvKPoo9V for ; Fri, 23 Jul 2010 20:07:58 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id 611071701A for ; Fri, 23 Jul 2010 20:07:58 +0100 (BST) Message-ID: <4C49E88B.9030508@libeljournal.com> Date: Fri, 23 Jul 2010 20:07:55 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <4C498024.7050106@libeljournal.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 19:08:05 -0000 On 23/07/2010 19:04, Dmitry Morozovsky wrote: > On Fri, 23 Jul 2010, John Hawkes-Reed wrote: > > JH> Since I still have the medium-sized ZFS array on the bench, testing this GPT > JH> setup seemed like a good idea. > JH> > JH> The hardware's a Supermicro X8DTL-iF m/b + 12Gb memory, 2x 5502 Xeons, 3x > JH> Supermicro USASLP-L8I 3G SAS controllers and 24x Hitachi 2Tb drives. > > [snip] > > JH> For an apples/oranges comparison, here's the output from the other box we > JH> built. The hardware's more or less the same - the drive controller's an > JH> Areca-1280, but the OS was Solaris 10.latest: > JH> > JH> --------Sequential Output------- ---Sequential Input-- --Random-- > JH> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > JH> > JH> GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU > JH> 5 116.8 75.0 524.7 65.4 156.3 20.3 161.6 99.2 2924.0 100.0 199999 300.0 > > . ~~~~~~ > > Frakking Cylons! You have quite a beast! ;-) :D Like I said, I think those numbers were the Bonnie test data fitting inside the cache. Making all the bits work together has been a bit of a nightmare, but we're really pleased with the performance and stability of 8.1 + ZFS. (Having said that, the kit will spit the drives out of the cab over the weekend for spite...) -- JH-R From owner-freebsd-stable@FreeBSD.ORG Fri Jul 23 23:49:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA4F41065674 for ; Fri, 23 Jul 2010 23:49:31 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB4C8FC08 for ; Fri, 23 Jul 2010 23:49:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id B5AEC50B7A for ; Sat, 24 Jul 2010 00:49:29 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZyqb9vfRtPD for ; Sat, 24 Jul 2010 00:49:28 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id D78A650A93 for ; Sat, 24 Jul 2010 00:49:28 +0100 (BST) Message-ID: <4C4A2A7F.7060807@langille.org> Date: Fri, 23 Jul 2010 19:49:19 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> In-Reply-To: <4C48E695.6030602@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 23:49:31 -0000 On 7/22/2010 8:47 PM, Dan Langille wrote: > Thank you to all the helpful discussion. It's been very helpful and > educational. Based on the advice and suggestions, I'm going to adjust my > original plan as follows. > > NOTE: glabel will not be used. > > > First, create a new GUID Partition Table partition scheme on the HDD: > > gpart create -s GPT ad0 > > > Let's see how much space we have. This output will be used to determine > SOMEVALUE in the next command. > > gpart show > > > Create a new partition within that scheme: > > gpart add -b 1024 -s SOMEVALUE -t freebsd-zfs -l disk00 ad0 > > The -b 1024 ensures alignment on a 4KB boundary. > > SOMEVALUE will be set so approximately 200MB is left empty at the end of > the HDD. That's part more than necessary to accommodate the different > actualy size of 2TB HDD. > > Repeat the above with ad1 to get disk01. Repeat for all other HDD... > > Then create your zpool: > > zpool create bigtank gpt/disk00 gpt/disk02 ... etc > > > This plan will be applied to an existing 5 HDD ZFS pool. I have two new > empty HDD which will be added to this new array (giving me 7 x 2TB HDD). > The array is raidz1 and I'm wondering if I want to go to raidz2. That > would be about 10TB and I'm only using up 3.1TB at present. That > represents about 4 months of backups. > > I do not think I can adjust the existing zpool on the fly. I think I > need to copy everything elsewhere (i.e the 2 empty drives). Then start > the new zpool from scratch. > > The risk: when the data is on the 2 spare HDD, there is no redundancy. I > wonder if my friend Jerry has a spare 2TB HDD I could borrow for the > evening. > The work is in progress. Updates are at http://beta.freebsddiary.org/zfs-with-gpart.php which will be updated frequently as the work continues. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 00:14:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 275611065680 for ; Sat, 24 Jul 2010 00:14:00 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 08C8A8FC15 for ; Sat, 24 Jul 2010 00:14:00 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o6O0Dx53028262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 17:13:59 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o6O0Dw02028261; Fri, 23 Jul 2010 17:13:58 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA10240; Fri, 23 Jul 10 17:12:32 PDT Date: Fri, 23 Jul 2010 17:12:35 -0700 From: perryh@pluto.rain.com To: holm@freibergnet.de Message-Id: <4c4a2ff3.t5Wfu61In0E4+QtF%perryh@pluto.rain.com> References: <20100723101924.GB96573@pegasus.freiberg-net.de> In-Reply-To: <20100723101924.GB96573@pegasus.freiberg-net.de> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Floppy driver broken on 8.1-PRERELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 00:14:00 -0000 Holm Tiffe wrote: > Why I can't read 1440K blocks from the floppy anymore? Perhaps something changed in the DMA driver, such that it is no longer able to handle a request exceeding 65K (which was the hardwired limit of the "original" PC DMA controller). I've long used bs=120b for floppies, and never had a problem. Why 120? # 120*512 = 61440, which is less than 65K. # For both 1.2MB and 1.44MB floppies, 120 sectors is a multiple of the track length. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 01:33:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9A8106566C for ; Sat, 24 Jul 2010 01:33:21 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1F96E8FC13 for ; Sat, 24 Jul 2010 01:33:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 335185093D; Sat, 24 Jul 2010 02:33:20 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AoUrRYAZQ5u; Sat, 24 Jul 2010 02:33:19 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id F12F15089E ; Sat, 24 Jul 2010 02:33:18 +0100 (BST) Message-ID: <4C4A42D5.7080805@langille.org> Date: Fri, 23 Jul 2010 21:33:09 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Pawel Tyll References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> In-Reply-To: <718046944.20100723032259@nitronet.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 01:33:21 -0000 On 7/22/2010 9:22 PM, Pawel Tyll wrote: >> I do not think I can adjust the existing zpool on the fly. I think I >> need to copy everything elsewhere (i.e the 2 empty drives). Then start >> the new zpool from scratch. > You can, and you should (for educational purposes if not for fun :>), > unless you wish to change raidz1 to raidz2. Replace, wait for > resilver, if redoing used disk then offline it, wipe magic with dd > (16KB at the beginning and end of disk/partition will do), carry on > with GPT, rinse and repeat with next disk. When last vdev's replace > finishes, your pool will grow automagically. Pawell and I had an online chat about part of my strategy. To be clear: I have a 5x2TB raidz1 array. I have 2x2TB empty HDD My goal was to go to raidz2 by: - copy data to empty HDD - redo the zpool to be raidz2 - copy back the data - add in the two previously empty HDD to the zpol I now understand that after a raidz array has been created, you can't add a new HDD to it. I'd like to, but it sounds like you cannot. "It is not possible to add a disk as a column to a RAID-Z, RAID-Z2, or RAID-Z3 vdev." http://en.wikipedia.org/wiki/ZFS#Limitations So, it seems I have a 5-HDD zpool and it's going to stay that way. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 01:54:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24D471065677 for ; Sat, 24 Jul 2010 01:54:53 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id E92948FC08 for ; Sat, 24 Jul 2010 01:54:52 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 65BDC1819B0 for ; Fri, 23 Jul 2010 21:54:51 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 0B0001819B1 for ; Fri, 23 Jul 2010 21:54:51 -0400 (EDT) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 068B11819B0 for ; Fri, 23 Jul 2010 21:54:51 -0400 (EDT) Received: from [192.168.1.101] (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id C26515B0038 for ; Fri, 23 Jul 2010 21:54:50 -0400 (EDT) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d3HvdOrfZymXpOvBzLsG" Organization: U. Buffalo Date: Fri, 23 Jul 2010 21:54:50 -0400 Message-ID: <1279936490.31236.11.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Subject: FreeBSD 8.1-RELEASE Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 01:54:53 -0000 --=-d3HvdOrfZymXpOvBzLsG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those of you who don't subscribe to the freebsd-announce list: http://www.freebsd.org/releases/8.1R/announce.html Enjoy. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-d3HvdOrfZymXpOvBzLsG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkxKR+AACgkQ/G14VSmup/ZLywCfZxsI/PbMPPYJZC0F4vJzbwfy DDUAnA3PCCbw8N8S3zbGMjXpl1Ich4de =dUJC -----END PGP SIGNATURE----- --=-d3HvdOrfZymXpOvBzLsG-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 02:25:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F5A7106564A for ; Sat, 24 Jul 2010 02:25:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CB1A18FC08 for ; Sat, 24 Jul 2010 02:25:21 +0000 (UTC) Received: by iwn35 with SMTP id 35so1009202iwn.13 for ; Fri, 23 Jul 2010 19:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=L14ESZwOAQ0TmYWIE9q68hm+kosuFSpGhOnnWgorcu0=; b=PsXYkqp8H8uwoh/Al0bm3poDHj+TjHWAA45q7sSrB46axgtUg4n4FSBEjmji+iyhGU +Mbz21TL0JYMnl4Rd3shMt1xBxO+PE6eLxjHgg5W+AWn/GWpPm4TnS6E6keutWTi2WWZ cgwQodztIZR0crw2sR6WWUyqp5ibJwS1C4sz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=HEgsuufTfVpQrV/0jfxiU1u0ZeOLgzD03szCEM+QqPIONbZkS6cn+r9lPUwtb55Gdf 23CC+mmTWc3EpIM85GBaYCLfyncaLwkH/sglogDbBea3qb91TitnafAoCUitiJUaVzmg kxlMBHQmjDSsFL8Ur021Bl9PETsEti8f++kFQ= MIME-Version: 1.0 Received: by 10.231.157.207 with SMTP id c15mr4419295ibx.143.1279938321143; Fri, 23 Jul 2010 19:25:21 -0700 (PDT) Received: by 10.231.161.208 with HTTP; Fri, 23 Jul 2010 19:25:20 -0700 (PDT) In-Reply-To: <4C4A42D5.7080805@langille.org> References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> Date: Fri, 23 Jul 2010 19:25:20 -0700 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 02:25:22 -0000 On Fri, Jul 23, 2010 at 6:33 PM, Dan Langille wrote: > Pawell and I had an online chat about part of my strategy. =C2=A0To be cl= ear: > > I have a 5x2TB raidz1 array. > > I have 2x2TB empty HDD > > My goal was to go to raidz2 by: > - copy data to empty HDD > - redo the zpool to be raidz2 > - copy back the data > - add in the two previously empty HDD to the zpol > > I now understand that after a raidz array has been created, you can't add= a > new HDD to it. =C2=A0I'd like to, but it sounds like you cannot. > > "It is not possible to add a disk as a column to a RAID-Z, RAID-Z2, or > RAID-Z3 vdev." http://en.wikipedia.org/wiki/ZFS#Limitations > > So, it seems I have a 5-HDD zpool and it's going to stay that way. You can fake it out by using sparse files for members of the new raidz2 vdev (when creating the vdev), then offline the file-based members so that you are running a degraded pool, copy the data to the pool, then replace the file-based members with physical harddrives. I've posted a theoretical method for doing so here: http://forums.freebsd.org/showpost.php?p=3D93889&postcount=3D7 It's theoretical as I have not investigated how to create sparse files on FreeBSD, nor have I done this. It's based on several posts to the zfs-discuss mailing list where several people have done this on OpenSolaris. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 02:31:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26824106564A for ; Sat, 24 Jul 2010 02:31:23 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 09A668FC08 for ; Sat, 24 Jul 2010 02:31:22 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6O2VG2A040462; Fri, 23 Jul 2010 19:31:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer; b=gp3Ddr85Hnk5ZmlYtp9QhqDOvvMyIgvGhhY0JbLaz97t0owWoME1HJWNLD8LsNlV From: Sean Bruno To: Chuck Swiger In-Reply-To: <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> <20100723003611.GA66678@martini.nu> <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> Content-Type: multipart/mixed; boundary="=-Fy8nXNJ6QUDhcRZDZBTC" Date: Fri, 23 Jul 2010 19:31:15 -0700 Message-ID: <1279938675.2442.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Cc: "freebsd-stable@freebsd.org" Subject: Re: Unable to install 8.x on a PowerEdge R810 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "freebsd-stable@freebsd.org" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 02:31:23 -0000 --=-Fy8nXNJ6QUDhcRZDZBTC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2010-07-22 at 17:51 -0700, Chuck Swiger wrote: > Hi, Mahlon-- > > On Jul 22, 2010, at 5:36 PM, Mahlon E. Smith wrote: > > Install worked great, though it appears I need to keep hyperthreading > > ("logical processors" bios option) disabled for it to boot reliably. > > Similar errors as before if I enable it. > > I believe FreeBSD ships with MAXCPU set to 32 by default (check "sysctl kern.smp.maxcpus"); your machine with hyperthreading enabled probably goes past that #, which is why it crashes with the topology error being reported.... > > Regards, Kind of a large patch, but in order to make an omlette, you need to break a few servers. This is a diff against -CURRENT, not stable-8 as I didn't get a chance to test it. It is directly based off of changes that peter@ made to the Yahoo FreeBSD 7 tree. I have compile and boot tested this on my local machines, but I don't have 64 CPU machines to test upon. Sean --=-Fy8nXNJ6QUDhcRZDZBTC Content-Disposition: attachment; filename="cpumask.diff" Content-Type: text/x-patch; name="cpumask.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit Index: sys/kern/subr_smp.c =================================================================== --- sys/kern/subr_smp.c (revision 210421) +++ sys/kern/subr_smp.c (working copy) @@ -181,7 +181,7 @@ id = td->td_oncpu; if (id == NOCPU) return; - ipi_selected(1 << id, IPI_AST); + ipi_selected(cputomask(id), IPI_AST); } /* @@ -318,7 +318,7 @@ CTR1(KTR_SMP, "restart_cpus(%x)", map); /* signal other cpus to restart */ - atomic_store_rel_int(&started_cpus, map); + atomic_store_rel_long(&started_cpus, map); /* wait for each to clear its bit */ while ((stopped_cpus & map) != 0) @@ -396,11 +396,11 @@ } CPU_FOREACH(i) { - if (((1 << i) & map) != 0) + if ((cputomask(i) & map) != 0) ncpus++; } if (ncpus == 0) - panic("ncpus is 0 with map=0x%x", map); + panic("ncpus is 0 with map=0x%lx", map); /* obtain rendezvous lock */ mtx_lock_spin(&smp_ipi_mtx); @@ -416,10 +416,10 @@ atomic_store_rel_int(&smp_rv_waiters[0], 0); /* signal other processors, which will enter the IPI with interrupts off */ - ipi_selected(map & ~(1 << curcpu), IPI_RENDEZVOUS); + ipi_selected(map & ~cputomask(curcpu), IPI_RENDEZVOUS); /* Check if the current CPU is in the map */ - if ((map & (1 << curcpu)) != 0) + if ((map & cputomask(curcpu)) != 0) smp_rendezvous_action(); if (teardown_func == smp_no_rendevous_barrier) @@ -491,7 +491,7 @@ panic("Built bad topology at %p. CPU count %d != %d", top, top->cg_count, mp_ncpus); if (top->cg_mask != all_cpus) - panic("Built bad topology at %p. CPU mask 0x%X != 0x%X", + panic("Built bad topology at %p. CPU mask 0x%lX != 0x%lX", top, top->cg_mask, all_cpus); return (top); } @@ -535,7 +535,7 @@ parent->cg_children++; for (; parent != NULL; parent = parent->cg_parent) { if ((parent->cg_mask & child->cg_mask) != 0) - panic("Duplicate children in %p. mask 0x%X child 0x%X", + panic("Duplicate children in %p. mask 0x%lX child 0x%lX", parent, parent->cg_mask, child->cg_mask); parent->cg_mask |= child->cg_mask; parent->cg_count += child->cg_count; Index: sys/kern/sched_ule.c =================================================================== --- sys/kern/sched_ule.c (revision 210421) +++ sys/kern/sched_ule.c (working copy) @@ -851,7 +851,7 @@ * IPI the target cpu to force it to reschedule with the new * workload. */ - ipi_selected(1 << TDQ_ID(low), IPI_PREEMPT); + ipi_cpu(TDQ_ID(low), IPI_PREEMPT); } tdq_unlock_pair(high, low); return (moved); @@ -974,7 +974,7 @@ return; } tdq->tdq_ipipending = 1; - ipi_selected(1 << cpu, IPI_PREEMPT); + ipi_cpu(cpu, IPI_PREEMPT); } /* @@ -2411,7 +2411,7 @@ cpu = ts->ts_cpu; ts->ts_cpu = sched_pickcpu(td, 0); if (cpu != PCPU_GET(cpuid)) - ipi_selected(1 << cpu, IPI_PREEMPT); + ipi_cpu(cpu, IPI_PREEMPT); #endif } @@ -2642,11 +2642,11 @@ sbuf_printf(sb, "%*s\n", indent, "", indent, cg->cg_level); - sbuf_printf(sb, "%*s ", indent, "", + sbuf_printf(sb, "%*s ", indent, "", cg->cg_count, cg->cg_mask); first = TRUE; for (i = 0; i < MAXCPU; i++) { - if ((cg->cg_mask & (1 << i)) != 0) { + if ((cg->cg_mask & cputomask(i)) != 0) { if (!first) sbuf_printf(sb, ", "); else Index: sys/kern/kern_ktr.c =================================================================== --- sys/kern/kern_ktr.c (revision 210421) +++ sys/kern/kern_ktr.c (working copy) @@ -211,7 +211,7 @@ if ((ktr_mask & mask) == 0) return; cpu = KTR_CPU; - if (((1 << cpu) & ktr_cpumask) == 0) + if ((cputomask(cpu) & ktr_cpumask) == 0) return; #if defined(KTR_VERBOSE) || defined(KTR_ALQ) td = curthread; Index: sys/kern/kern_pmc.c =================================================================== --- sys/kern/kern_pmc.c (revision 210421) +++ sys/kern/kern_pmc.c (working copy) @@ -34,6 +34,7 @@ #include "opt_hwpmc_hooks.h" #include +#include #include #include #include @@ -110,7 +111,7 @@ { #ifdef SMP return (pmc_cpu_is_present(cpu) && - (hlt_cpus_mask & (1 << cpu)) == 0); + (hlt_cpus_mask & cputomask(cpu)) == 0); #else return (1); #endif @@ -137,7 +138,7 @@ pmc_cpu_is_primary(int cpu) { #ifdef SMP - return ((logical_cpus_mask & (1 << cpu)) == 0); + return ((logical_cpus_mask & cputomask(cpu)) == 0); #else return (1); #endif Index: sys/kern/subr_pcpu.c =================================================================== --- sys/kern/subr_pcpu.c (revision 210421) +++ sys/kern/subr_pcpu.c (working copy) @@ -88,7 +88,7 @@ KASSERT(cpuid >= 0 && cpuid < MAXCPU, ("pcpu_init: invalid cpuid %d", cpuid)); pcpu->pc_cpuid = cpuid; - pcpu->pc_cpumask = 1 << cpuid; + pcpu->pc_cpumask = cputomask(cpuid); cpuid_to_pcpu[cpuid] = pcpu; SLIST_INSERT_HEAD(&cpuhead, pcpu, pc_allcpu); cpu_pcpu_init(pcpu, cpuid, size); Index: sys/kern/sched_4bsd.c =================================================================== --- sys/kern/sched_4bsd.c (revision 210421) +++ sys/kern/sched_4bsd.c (working copy) @@ -1086,7 +1086,7 @@ me = PCPU_GET(cpumask); /* Don't bother if we should be doing it ourself. */ - if ((me & idle_cpus_mask) && (cpunum == NOCPU || me == (1 << cpunum))) + if ((me & idle_cpus_mask) && (cpunum == NOCPU || me == cputomask(cpunum))) return (0); dontuse = me | stopped_cpus | hlt_cpus_mask; @@ -1108,7 +1108,7 @@ /* If they are both on, compare and use loop if different. */ if (forward_wakeup_use_loop) { if (map != map3) { - printf("map (%02X) != map3 (%02X)\n", map, + printf("map (%02lX) != map3 (%02lX)\n", map, map3); map = map3; } @@ -1120,7 +1120,7 @@ /* If we only allow a specific CPU, then mask off all the others. */ if (cpunum != NOCPU) { KASSERT((cpunum <= mp_maxcpus),("forward_wakeup: bad cpunum.")); - map &= (1 << cpunum); + map &= cputomask(cpunum); } else { /* Try choose an idle die. */ if (forward_wakeup_use_htt) { Index: sys/dev/hwpmc/hwpmc_mod.c =================================================================== --- sys/dev/hwpmc/hwpmc_mod.c (revision 210421) +++ sys/dev/hwpmc/hwpmc_mod.c (working copy) @@ -1991,7 +1991,7 @@ * had already processed the interrupt). We don't * lose the interrupt sample. */ - atomic_clear_int(&pmc_cpumask, (1 << PCPU_GET(cpuid))); + atomic_clear_long(&pmc_cpumask, PCPU_GET(cpuid)); pmc_process_samples(PCPU_GET(cpuid)); break; @@ -4083,7 +4083,7 @@ done: /* mark CPU as needing processing */ - atomic_set_rel_int(&pmc_cpumask, (1 << cpu)); + atomic_set_rel_long(&pmc_cpumask, cputomask(cpu)); return (error); } @@ -4193,7 +4193,7 @@ break; if (ps->ps_nsamples == PMC_SAMPLE_INUSE) { /* Need a rescan at a later time. */ - atomic_set_rel_int(&pmc_cpumask, (1 << cpu)); + atomic_set_rel_long(&pmc_cpumask, cputomask(cpu)); break; } @@ -4782,7 +4782,7 @@ PMCDBG(MOD,INI,0, "%s", "cleanup"); /* switch off sampling */ - atomic_store_rel_int(&pmc_cpumask, 0); + atomic_store_rel_long(&pmc_cpumask, 0); pmc_intr = NULL; sx_xlock(&pmc_sx); Index: sys/geom/eli/g_eli.c =================================================================== --- sys/geom/eli/g_eli.c (revision 210421) +++ sys/geom/eli/g_eli.c (working copy) @@ -499,7 +499,7 @@ g_eli_cpu_is_disabled(int cpu) { #ifdef SMP - return ((hlt_cpus_mask & (1 << cpu)) != 0); + return ((hlt_cpus_mask & cputomask(cpu)) != 0); #else return (0); #endif Index: sys/i386/include/smp.h =================================================================== --- sys/i386/include/smp.h (revision 210421) +++ sys/i386/include/smp.h (working copy) @@ -62,6 +62,7 @@ void init_secondary(void); int ipi_nmi_handler(void); void ipi_selected(cpumask_t cpus, u_int ipi); +#define ipi_cpu(_c, _i) ipi_selected(cputomask(_c), _i) void ipi_all_but_self(u_int ipi); #ifndef XEN void ipi_bitmap_handler(struct trapframe frame); Index: sys/i386/include/_types.h =================================================================== --- sys/i386/include/_types.h (revision 210421) +++ sys/i386/include/_types.h (working copy) @@ -74,7 +74,7 @@ * Standard type definitions. */ typedef unsigned long __clock_t; /* clock()... */ -typedef unsigned int __cpumask_t; +typedef unsigned long __cpumask_t; typedef __int32_t __critical_t; typedef long double __double_t; typedef long double __float_t; Index: sys/i386/i386/vm_machdep.c =================================================================== --- sys/i386/i386/vm_machdep.c (revision 210421) +++ sys/i386/i386/vm_machdep.c (working copy) @@ -613,7 +613,7 @@ /* Restart CPU #0. */ /* XXX: restart_cpus(1 << 0); */ - atomic_store_rel_int(&started_cpus, (1 << 0)); + atomic_store_rel_long(&started_cpus, cputomask(0)); cnt = 0; while (cpu_reset_proxy_active == 0 && cnt < 10000000) Index: sys/i386/i386/mp_machdep.c =================================================================== --- sys/i386/i386/mp_machdep.c (revision 210421) +++ sys/i386/i386/mp_machdep.c (working copy) @@ -1313,7 +1313,7 @@ * Set the mask of receiving CPUs for this purpose. */ if (ipi == IPI_STOP_HARD) - atomic_set_int(&ipi_nmi_pending, cpus); + atomic_set_long(&ipi_nmi_pending, cpus); CTR3(KTR_SMP, "%s: cpus: %x ipi: %x", __func__, cpus, ipi); while ((cpu = ffs(cpus)) != 0) { @@ -1376,7 +1376,7 @@ if ((ipi_nmi_pending & cpumask) == 0) return (1); - atomic_clear_int(&ipi_nmi_pending, cpumask); + atomic_clear_long(&ipi_nmi_pending, cpumask); cpustop_handler(); return (0); } @@ -1394,14 +1394,14 @@ savectx(&stoppcbs[cpu]); /* Indicate that we are stopped */ - atomic_set_int(&stopped_cpus, cpumask); + atomic_set_long(&stopped_cpus, cpumask); /* Wait for restart */ while (!(started_cpus & cpumask)) ia32_pause(); - atomic_clear_int(&started_cpus, cpumask); - atomic_clear_int(&stopped_cpus, cpumask); + atomic_clear_long(&started_cpus, cpumask); + atomic_clear_long(&stopped_cpus, cpumask); if (cpu == 0 && cpustop_restartfunc != NULL) { cpustop_restartfunc(); Index: sys/cddl/dev/dtrace/amd64/dtrace_subr.c =================================================================== --- sys/cddl/dev/dtrace/amd64/dtrace_subr.c (revision 210421) +++ sys/cddl/dev/dtrace/amd64/dtrace_subr.c (working copy) @@ -120,14 +120,14 @@ if (cpu == DTRACE_CPUALL) cpus = all_cpus; else - cpus = (cpumask_t) (1 << cpu); + cpus = cputomask(cpu); /* If the current CPU is in the set, call the function directly: */ - if ((cpus & (1 << curcpu)) != 0) { + if ((cpus & cputomask(curcpu)) != 0) { (*func)(arg); /* Mask the current CPU from the set */ - cpus &= ~(1 << curcpu); + cpus &= ~cputomask(curcpu); } /* If there are any CPUs in the set, cross-call to those CPUs */ Index: sys/amd64/include/smp.h =================================================================== --- sys/amd64/include/smp.h (revision 210421) +++ sys/amd64/include/smp.h (working copy) @@ -62,6 +62,7 @@ void init_secondary(void); int ipi_nmi_handler(void); void ipi_selected(cpumask_t cpus, u_int ipi); +void ipi_cpu(int cpu, u_int ipi); void ipi_all_but_self(u_int ipi); void ipi_bitmap_handler(struct trapframe frame); u_int mp_bootaddress(u_int); Index: sys/amd64/include/param.h =================================================================== --- sys/amd64/include/param.h (revision 210421) +++ sys/amd64/include/param.h (working copy) @@ -64,7 +64,7 @@ #endif #if defined(SMP) || defined(KLD_MODULE) -#define MAXCPU 32 +#define MAXCPU 64 #else #define MAXCPU 1 #endif Index: sys/amd64/include/_types.h =================================================================== --- sys/amd64/include/_types.h (revision 210421) +++ sys/amd64/include/_types.h (working copy) @@ -61,7 +61,7 @@ * Standard type definitions. */ typedef __int32_t __clock_t; /* clock()... */ -typedef unsigned int __cpumask_t; +typedef unsigned long __cpumask_t; typedef __int64_t __critical_t; typedef double __double_t; typedef float __float_t; Index: sys/amd64/amd64/vm_machdep.c =================================================================== --- sys/amd64/amd64/vm_machdep.c (revision 210421) +++ sys/amd64/amd64/vm_machdep.c (working copy) @@ -543,7 +543,7 @@ printf("cpu_reset: Restarting BSP\n"); /* Restart CPU #0. */ - atomic_store_rel_int(&started_cpus, 1 << 0); + atomic_store_rel_long(&started_cpus, cputomask(0)); cnt = 0; while (cpu_reset_proxy_active == 0 && cnt < 10000000) Index: sys/amd64/amd64/mptable.c =================================================================== --- sys/amd64/amd64/mptable.c (revision 210421) +++ sys/amd64/amd64/mptable.c (working copy) @@ -888,13 +888,13 @@ * already in the table, then kill the fixup. */ for (id = 0; id <= MAX_LAPIC_ID; id++) { - if ((id_mask & 1 << id) == 0) + if ((id_mask & (1ul << id)) == 0) continue; /* First, make sure we are on a logical_cpus boundary. */ if (id % logical_cpus != 0) return; for (i = id + 1; i < id + logical_cpus; i++) - if ((id_mask & 1 << i) != 0) + if ((id_mask & (1ul << i)) != 0) return; } @@ -911,7 +911,7 @@ i, id); lapic_create(i, 0); } - id_mask &= ~(1 << id); + id_mask &= ~(1ul << id); } } #endif /* MPTABLE_FORCE_HTT */ Index: sys/amd64/amd64/cpu_switch.S =================================================================== --- sys/amd64/amd64/cpu_switch.S (revision 210421) +++ sys/amd64/amd64/cpu_switch.S (working copy) @@ -74,7 +74,7 @@ jz 1f /* release bit from old pm_active */ movq PCPU(CURPMAP),%rdx - LK btrl %eax,PM_ACTIVE(%rdx) /* clear old */ + LK btrq %rax, VM_PMAP+PM_ACTIVE(%rdx) /* clear old */ 1: movq TD_PCB(%rsi),%r8 /* newtd->td_proc */ movq PCB_CR3(%r8),%rdx @@ -138,14 +138,14 @@ movl PCPU(CPUID), %eax /* Release bit from old pmap->pm_active */ movq PCPU(CURPMAP),%rcx - LK btrl %eax,PM_ACTIVE(%rcx) /* clear old */ + LK btrq %rax, VM_PMAP+PM_ACTIVE(%rdx) /* clear old */ SETLK %rdx, TD_LOCK(%rdi) /* Release the old thread */ swact: /* Set bit in new pmap->pm_active */ movq TD_PROC(%rsi),%rdx /* newproc */ movq P_VMSPACE(%rdx), %rdx addq $VM_PMAP,%rdx - LK btsl %eax,PM_ACTIVE(%rdx) /* set new */ + LK btsq %rax,PM_ACTIVE(%rdx) /* set new */ movq %rdx,PCPU(CURPMAP) sw1: Index: sys/amd64/amd64/pmap.c =================================================================== --- sys/amd64/amd64/pmap.c (revision 210421) +++ sys/amd64/amd64/pmap.c (working copy) @@ -567,7 +567,7 @@ PMAP_LOCK_INIT(kernel_pmap); kernel_pmap->pm_pml4 = (pdp_entry_t *)PHYS_TO_DMAP(KPML4phys); kernel_pmap->pm_root = NULL; - kernel_pmap->pm_active = -1; /* don't allow deactivation */ + kernel_pmap->pm_active = (cpumask_t)-1; /* don't allow deactivation */ TAILQ_INIT(&kernel_pmap->pm_pvchunk); /* @@ -926,8 +926,8 @@ void pmap_invalidate_page(pmap_t pmap, vm_offset_t va) { - u_int cpumask; - u_int other_cpus; + cpumask_t cpumask; + cpumask_t other_cpus; sched_pin(); if (pmap == kernel_pmap || pmap->pm_active == all_cpus) { @@ -947,8 +947,8 @@ void pmap_invalidate_range(pmap_t pmap, vm_offset_t sva, vm_offset_t eva) { - u_int cpumask; - u_int other_cpus; + cpumask_t cpumask; + cpumask_t other_cpus; vm_offset_t addr; sched_pin(); @@ -972,8 +972,8 @@ void pmap_invalidate_all(pmap_t pmap) { - u_int cpumask; - u_int other_cpus; + cpumask_t cpumask; + cpumask_t other_cpus; sched_pin(); if (pmap == kernel_pmap || pmap->pm_active == all_cpus) { @@ -5002,8 +5002,8 @@ pmap = vmspace_pmap(td->td_proc->p_vmspace); oldpmap = PCPU_GET(curpmap); #ifdef SMP - atomic_clear_int(&oldpmap->pm_active, PCPU_GET(cpumask)); - atomic_set_int(&pmap->pm_active, PCPU_GET(cpumask)); + atomic_clear_long(&oldpmap->pm_active, PCPU_GET(cpumask)); + atomic_set_long(&pmap->pm_active, PCPU_GET(cpumask)); #else oldpmap->pm_active &= ~PCPU_GET(cpumask); pmap->pm_active |= PCPU_GET(cpumask); Index: sys/amd64/amd64/mp_machdep.c =================================================================== --- sys/amd64/amd64/mp_machdep.c (revision 210421) +++ sys/amd64/amd64/mp_machdep.c (working copy) @@ -127,7 +127,7 @@ * Local data and functions. */ -static u_int logical_cpus; +static cpumask_t logical_cpus; static volatile cpumask_t ipi_nmi_pending; /* used to hold the AP's until we are ready to release them */ @@ -892,7 +892,7 @@ panic("AP #%d (PHY# %d) failed!", cpu, apic_id); } - all_cpus |= (1 << cpu); /* record AP in CPU map */ + all_cpus |= cputomask(cpu); /* record AP in CPU map */ } /* build our map of 'other' CPUs */ @@ -1050,27 +1050,16 @@ static void smp_targeted_tlb_shootdown(cpumask_t mask, u_int vector, vm_offset_t addr1, vm_offset_t addr2) { - int ncpu, othercpus; + int cpu, ncpu, othercpus; othercpus = mp_ncpus - 1; - if (mask == (u_int)-1) { - ncpu = othercpus; - if (ncpu < 1) + if (mask == (cpumask_t)-1) { + if (othercpus < 1) return; } else { mask &= ~PCPU_GET(cpumask); if (mask == 0) return; - ncpu = bitcount32(mask); - if (ncpu > othercpus) { - /* XXX this should be a panic offence */ - printf("SMP: tlb shootdown to %d other cpus (only have %d)\n", - ncpu, othercpus); - ncpu = othercpus; - } - /* XXX should be a panic, implied by mask == 0 above */ - if (ncpu < 1) - return; } if (!(read_rflags() & PSL_I)) panic("%s: interrupts disabled", __func__); @@ -1078,10 +1067,18 @@ smp_tlb_addr1 = addr1; smp_tlb_addr2 = addr2; atomic_store_rel_int(&smp_tlb_wait, 0); - if (mask == (u_int)-1) + if (mask == (cpumask_t)-1) { + ncpu = othercpus; ipi_all_but_self(vector); - else - ipi_selected(mask, vector); + } else { + ncpu = 0; + while ((cpu = ffsl(mask)) != 0) { + cpu--; + mask &= ~cputomask(cpu); + lapic_ipi_vectored(vector, cpu_apic_ids[cpu]); + ncpu++; + } + } while (smp_tlb_wait < ncpu) ia32_pause(); mtx_unlock_spin(&smp_ipi_mtx); @@ -1225,12 +1222,12 @@ * Set the mask of receiving CPUs for this purpose. */ if (ipi == IPI_STOP_HARD) - atomic_set_int(&ipi_nmi_pending, cpus); + atomic_set_long(&ipi_nmi_pending, cpus); CTR3(KTR_SMP, "%s: cpus: %x ipi: %x", __func__, cpus, ipi); - while ((cpu = ffs(cpus)) != 0) { + while ((cpu = ffsl(cpus)) != 0) { cpu--; - cpus &= ~(1 << cpu); + cpus &= ~(cputomask(cpu)); KASSERT(cpu_apic_ids[cpu] != -1, ("IPI to non-existent CPU %d", cpu)); @@ -1251,6 +1248,41 @@ } /* + * send an IPI to a specific cpu. + */ +void +ipi_cpu(int cpu, u_int ipi) +{ + u_int bitmap = 0; + u_int old_pending; + u_int new_pending; + + if (IPI_IS_BITMAPED(ipi)) { + bitmap = 1 << ipi; + ipi = IPI_BITMAP_VECTOR; + } + +#ifdef STOP_NMI + if (ipi == IPI_STOP && stop_cpus_with_nmi) { + ipi_nmi_selected(cputomask(cpu)); + return; + } +#endif + CTR3(KTR_SMP, "%s: cpu: %d ipi: %x", __func__, cpu, ipi); + + KASSERT(cpu_apic_ids[cpu] != -1, + ("IPI to non-existent CPU %d", cpu)); + + if (bitmap) { + do { + old_pending = cpu_ipi_pending[cpu]; + new_pending = old_pending | bitmap; + } while (!atomic_cmpset_int(&cpu_ipi_pending[cpu],old_pending, new_pending)); + } + lapic_ipi_vectored(ipi, cpu_apic_ids[cpu]); +} + +/* * send an IPI to all CPUs EXCEPT myself */ void @@ -1268,7 +1300,7 @@ * Set the mask of receiving CPUs for this purpose. */ if (ipi == IPI_STOP_HARD) - atomic_set_int(&ipi_nmi_pending, PCPU_GET(other_cpus)); + atomic_set_long(&ipi_nmi_pending, PCPU_GET(other_cpus)); CTR2(KTR_SMP, "%s: ipi: %x", __func__, ipi); lapic_ipi_vectored(ipi, APIC_IPI_DEST_OTHERS); @@ -1289,7 +1321,7 @@ if ((ipi_nmi_pending & cpumask) == 0) return (1); - atomic_clear_int(&ipi_nmi_pending, cpumask); + atomic_clear_long(&ipi_nmi_pending, cpumask); cpustop_handler(); return (0); } @@ -1302,19 +1334,19 @@ cpustop_handler(void) { int cpu = PCPU_GET(cpuid); - int cpumask = PCPU_GET(cpumask); + cpumask_t cpumask = PCPU_GET(cpumask); savectx(&stoppcbs[cpu]); /* Indicate that we are stopped */ - atomic_set_int(&stopped_cpus, cpumask); + atomic_set_long(&stopped_cpus, cpumask); /* Wait for restart */ while (!(started_cpus & cpumask)) ia32_pause(); - atomic_clear_int(&started_cpus, cpumask); - atomic_clear_int(&stopped_cpus, cpumask); + atomic_clear_long(&started_cpus, cpumask); + atomic_clear_long(&stopped_cpus, cpumask); if (cpu == 0 && cpustop_restartfunc != NULL) { cpustop_restartfunc(); @@ -1340,7 +1372,7 @@ if (savectx2(stopxpcbs[cpu])) { fpugetregs(curthread, stopfpu); wbinvd(); - atomic_set_int(&stopped_cpus, cpumask); + atomic_set_long(&stopped_cpus, cpumask); } else fpusetregs(curthread, stopfpu); @@ -1348,8 +1380,8 @@ while (!(started_cpus & cpumask)) ia32_pause(); - atomic_clear_int(&started_cpus, cpumask); - atomic_clear_int(&stopped_cpus, cpumask); + atomic_clear_long(&started_cpus, cpumask); + atomic_clear_long(&stopped_cpus, cpumask); /* Restore CR3 and enable interrupts */ load_cr3(cr3); @@ -1381,7 +1413,7 @@ int error; mask = hlt_cpus_mask; - error = sysctl_handle_int(oidp, &mask, 0, req); + error = sysctl_handle_long(oidp, &mask, 0, req); if (error || !req->newptr) return (error); @@ -1395,11 +1427,11 @@ mask |= hyperthreading_cpus_mask; if ((mask & all_cpus) == all_cpus) - mask &= ~(1<<0); + mask &= ~cputomask(0); hlt_cpus_mask = mask; return (error); } -SYSCTL_PROC(_machdep, OID_AUTO, hlt_cpus, CTLTYPE_INT|CTLFLAG_RW, +SYSCTL_PROC(_machdep, OID_AUTO, hlt_cpus, CTLTYPE_LONG|CTLFLAG_RW, 0, 0, sysctl_hlt_cpus, "IU", "Bitmap of CPUs to halt. 101 (binary) will halt CPUs 0 and 2."); @@ -1422,7 +1454,7 @@ hlt_cpus_mask |= hyperthreading_cpus_mask; if ((hlt_cpus_mask & all_cpus) == all_cpus) - hlt_cpus_mask &= ~(1<<0); + hlt_cpus_mask &= ~~cputomask(0); hlt_logical_cpus = disable; return (error); @@ -1460,7 +1492,7 @@ hlt_logical_cpus = 0; if ((hlt_cpus_mask & all_cpus) == all_cpus) - hlt_cpus_mask &= ~(1<<0); + hlt_cpus_mask &= ~cputomask(0); hyperthreading_allowed = allowed; return (error); @@ -1506,9 +1538,9 @@ int mp_grab_cpu_hlt(void) { - u_int mask = PCPU_GET(cpumask); + cpumask_t mask = PCPU_GET(cpumask); #ifdef MP_WATCHDOG - u_int cpuid = PCPU_GET(cpuid); + cpumask_t cpuid = PCPU_GET(cpuid); #endif int retval; Index: sys/amd64/amd64/intr_machdep.c =================================================================== --- sys/amd64/amd64/intr_machdep.c (revision 210421) +++ sys/amd64/amd64/intr_machdep.c (working copy) @@ -444,7 +444,7 @@ */ /* The BSP is always a valid target. */ -static cpumask_t intr_cpus = (1 << 0); +static cpumask_t intr_cpus = cputomask(0); static int current_cpu; /* @@ -466,7 +466,7 @@ current_cpu++; if (current_cpu > mp_maxid) current_cpu = 0; - } while (!(intr_cpus & (1 << current_cpu))); + } while (!(intr_cpus & cputomask(current_cpu))); mtx_unlock_spin(&icu_lock); return (apic_id); } @@ -497,7 +497,7 @@ printf("INTR: Adding local APIC %d as a target\n", cpu_apic_ids[cpu]); - intr_cpus |= (1 << cpu); + intr_cpus |= cputomask(cpu); } /* Index: sys/sys/smp.h =================================================================== --- sys/sys/smp.h (revision 210421) +++ sys/sys/smp.h (working copy) @@ -89,7 +89,8 @@ * time, thus permitting us to configure sparse maps of cpuid-dependent * (per-CPU) structures. */ -#define CPU_ABSENT(x_cpu) ((all_cpus & (1 << (x_cpu))) == 0) +#include +#define CPU_ABSENT(x_cpu) ((all_cpus & (cputomask(x_cpu))) == 0) /* * Macros to iterate over non-absent CPUs. CPU_FOREACH() takes an Index: sys/sys/gmon.h =================================================================== --- sys/sys/gmon.h (revision 210421) +++ sys/sys/gmon.h (working copy) @@ -197,6 +197,7 @@ #define GPROF_FROMS 2 /* struct: from location hash bucket */ #define GPROF_TOS 3 /* struct: destination/count structure */ #define GPROF_GMONPARAM 4 /* struct: profiling parameters (see above) */ +#define GPROF_FREEBUF 5 /* int: free flat profiling buffer */ #ifdef _KERNEL Index: sys/sys/systm.h =================================================================== --- sys/sys/systm.h (revision 210421) +++ sys/sys/systm.h (working copy) @@ -423,4 +423,6 @@ return (x); } +#define cputomask(_cpu) ((__cpumask_t)1 << _cpu) + #endif /* !_SYS_SYSTM_H_ */ --=-Fy8nXNJ6QUDhcRZDZBTC-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 02:32:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E736F106566C for ; Sat, 24 Jul 2010 02:32:18 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id BADF78FC1A for ; Sat, 24 Jul 2010 02:32:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 2924D5093D for ; Sat, 24 Jul 2010 03:32:18 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5+nqozx+hVp for ; Sat, 24 Jul 2010 03:32:17 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 289A75089E for ; Sat, 24 Jul 2010 03:32:17 +0100 (BST) Message-ID: <4C4A50A7.2090305@langille.org> Date: Fri, 23 Jul 2010 22:32:07 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 02:32:19 -0000 On 7/23/2010 10:25 PM, Freddie Cash wrote: > On Fri, Jul 23, 2010 at 6:33 PM, Dan Langille wrote: >> Pawell and I had an online chat about part of my strategy. To be clear: >> >> I have a 5x2TB raidz1 array. >> >> I have 2x2TB empty HDD >> >> My goal was to go to raidz2 by: >> - copy data to empty HDD >> - redo the zpool to be raidz2 >> - copy back the data >> - add in the two previously empty HDD to the zpol >> >> I now understand that after a raidz array has been created, you can't add a >> new HDD to it. I'd like to, but it sounds like you cannot. >> >> "It is not possible to add a disk as a column to a RAID-Z, RAID-Z2, or >> RAID-Z3 vdev." http://en.wikipedia.org/wiki/ZFS#Limitations >> >> So, it seems I have a 5-HDD zpool and it's going to stay that way. > > You can fake it out by using sparse files for members of the new > raidz2 vdev (when creating the vdev), then offline the file-based > members so that you are running a degraded pool, copy the data to the > pool, then replace the file-based members with physical harddrives. So I'm creating a 7 drive pool, with 5 real drives members and two file-based members. > I've posted a theoretical method for doing so here: > http://forums.freebsd.org/showpost.php?p=93889&postcount=7 > > It's theoretical as I have not investigated how to create sparse files > on FreeBSD, nor have I done this. It's based on several posts to the > zfs-discuss mailing list where several people have done this on > OpenSolaris. I see no downside. There is no risk that "it won't work and I'll lose all the data". -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 02:42:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF30A1065670 for ; Sat, 24 Jul 2010 02:42:48 +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 747A58FC08 for ; Sat, 24 Jul 2010 02:42:47 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-158-44.lns6.adl6.internode.on.net [121.45.158.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o6O2gcsQ012962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Jul 2010 12:12:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Sat, 24 Jul 2010 12:12:37 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> To: Freddie Cash X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 02:42:49 -0000 On 24/07/2010, at 11:55, Freddie Cash wrote: > It's theoretical as I have not investigated how to create sparse files > on FreeBSD, nor have I done this. It's based on several posts to the > zfs-discuss mailing list where several people have done this on > OpenSolaris. FYI you would do.. truncate -s 1T /tmp/fake-disk1 mdconfig -a -t vnode -f /tmp/fake-disk1 etc.. Although you'd want to determine the exact size of your real disks from = geom and use that. -- 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 Sat Jul 24 02:51:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14935106566B for ; Sat, 24 Jul 2010 02:51:24 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id D8D1B8FC15 for ; Sat, 24 Jul 2010 02:51:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 3ECEC5093D; Sat, 24 Jul 2010 03:51:23 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEZ0AaIP66KJ; Sat, 24 Jul 2010 03:51:22 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 87A9E5089E ; Sat, 24 Jul 2010 03:51:22 +0100 (BST) Message-ID: <4C4A5520.7060209@langille.org> Date: Fri, 23 Jul 2010 22:51:12 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Daniel O'Connor References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 02:51:24 -0000 On 7/23/2010 10:42 PM, Daniel O'Connor wrote: > > On 24/07/2010, at 11:55, Freddie Cash wrote: >> It's theoretical as I have not investigated how to create sparse files >> on FreeBSD, nor have I done this. It's based on several posts to the >> zfs-discuss mailing list where several people have done this on >> OpenSolaris. > > FYI you would do.. > truncate -s 1T /tmp/fake-disk1 > mdconfig -a -t vnode -f /tmp/fake-disk1 > > etc.. > > Although you'd want to determine the exact size of your real disks from geom and use that. $ dd if=/dev/zero of=/tmp/sparsefile1.img bs=1 count=0 oseek=2000G 0+0 records in 0+0 records out 0 bytes transferred in 0.000025 secs (0 bytes/sec) $ ls -l /tmp/sparsefile1.img -rw-r--r-- 1 dan wheel 2147483648000 Jul 23 22:49 /tmp/sparsefile1.img $ ls -lh /tmp/sparsefile1.img -rw-r--r-- 1 dan wheel 2.0T Jul 23 22:49 /tmp/sparsefile1.img -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 03:03:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5CB1065673 for ; Sat, 24 Jul 2010 03:03:16 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id BD4608FC22 for ; Sat, 24 Jul 2010 03:03:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id DE5845093D; Sat, 24 Jul 2010 04:03:15 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvpaAZWz9mJh; Sat, 24 Jul 2010 04:03:15 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 263DF5089E ; Sat, 24 Jul 2010 04:03:15 +0100 (BST) Message-ID: <4C4A57E9.7070108@langille.org> Date: Fri, 23 Jul 2010 23:03:05 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Daniel O'Connor References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> <4C4A5520.7060209@langille.org> In-Reply-To: <4C4A5520.7060209@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 03:03:17 -0000 On 7/23/2010 10:51 PM, Dan Langille wrote: > On 7/23/2010 10:42 PM, Daniel O'Connor wrote: >> >> On 24/07/2010, at 11:55, Freddie Cash wrote: >>> It's theoretical as I have not investigated how to create sparse >>> files on FreeBSD, nor have I done this. It's based on several >>> posts to the zfs-discuss mailing list where several people have >>> done this on OpenSolaris. >> >> FYI you would do.. truncate -s 1T /tmp/fake-disk1 mdconfig -a -t >> vnode -f /tmp/fake-disk1 >> >> etc.. >> >> Although you'd want to determine the exact size of your real disks >> from geom and use that. > > > $ dd if=/dev/zero of=/tmp/sparsefile1.img bs=1 count=0 oseek=2000G > 0+0 records in 0+0 records out 0 bytes transferred in 0.000025 secs > (0 bytes/sec) > > $ ls -l /tmp/sparsefile1.img -rw-r--r-- 1 dan wheel 2147483648000 > Jul 23 22:49 /tmp/sparsefile1.img > > $ ls -lh /tmp/sparsefile1.img -rw-r--r-- 1 dan wheel 2.0T Jul 23 > 22:49 /tmp/sparsefile1.img Going a bit further, and actually putting 30MB of data in there: $ rm sparsefile1.img $ dd if=/dev/zero of=/tmp/sparsefile1.img bs=1 count=0 oseek=2000G 0+0 records in 0+0 records out 0 bytes transferred in 0.000030 secs (0 bytes/sec) $ ls -lh /tmp/sparsefile1.img -rw-r--r-- 1 dan wheel 2.0T Jul 23 22:59 /tmp/sparsefile1.img $ dd if=/dev/zero of=sparsefile1.img bs=1M count=30 conv=notrunc 30+0 records in 30+0 records out 31457280 bytes transferred in 0.396570 secs (79323405 bytes/sec) $ ls -l sparsefile1.img -rw-r--r-- 1 dan wheel 2147483648000 Jul 23 23:00 sparsefile1.img $ ls -lh sparsefile1.img -rw-r--r-- 1 dan wheel 2.0T Jul 23 23:00 sparsefile1.img $ -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 05:00:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EC03106564A for ; Sat, 24 Jul 2010 05:00:04 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 221D48FC0A for ; Sat, 24 Jul 2010 05:00:03 +0000 (UTC) Received: by qyk31 with SMTP id 31so830465qyk.13 for ; Fri, 23 Jul 2010 22:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+knYN0frnf+d6vh8t5xkhOZPGcC5Qhwzkg1x4Y8zDCA=; b=cs96Ik/jU2CCZ2oF3uICiLbk4JlmLakLdDxJzraQEAB+WmXlaI3dcK4ZGkFnjp3hIb usb2U+y2EUQBVlfieJmu/mD1wfeXqHMFs750A/dMAw/lZqkfU5G1kYtehNVIA8lAjwKh /g5z2sN89sJ9zzobBx5oZbrcltN/7KEuHO8p0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fvqwvJAwSn9TYB8BVegY3YRQJsNAQpqq2mXXM00tKgAdnCuKwxroKzmdGAet8U8hxD jg22pDZNsMXxM/3sJbZ3jM85hYyWjPFuXTTW7mUr5zSj+J70pxGeM0/+NILQAqcgSzDt VXev3T22gVRIqTMHdbul8RuiJVatXwvt2T27w= MIME-Version: 1.0 Received: by 10.224.123.67 with SMTP id o3mr3265776qar.161.1279947603295; Fri, 23 Jul 2010 22:00:03 -0700 (PDT) Received: by 10.229.29.71 with HTTP; Fri, 23 Jul 2010 22:00:03 -0700 (PDT) In-Reply-To: References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> Date: Sat, 24 Jul 2010 00:00:03 -0500 Message-ID: From: Adam Vande More To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 05:00:04 -0000 On Fri, Jul 23, 2010 at 9:25 PM, Freddie Cash wrote: > It's theoretical as I have not investigated how to create sparse files > on FreeBSD, nor have I done this. It's based on several posts to the > zfs-discuss mailing list where several people have done this on > OpenSolaris. > Easiest way to create sparse eg 20 GB assuming test.img doesn't exist already truncate -s 20g test.img ls -sk test.img 1 test.img The other standard dd method works fine too, trucate just makes it easy. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 11:56:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098B91065674 for ; Sat, 24 Jul 2010 11:56:39 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (pop3.nitronet.pl [195.90.106.28]) by mx1.freebsd.org (Postfix) with ESMTP id B84118FC17 for ; Sat, 24 Jul 2010 11:56:38 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OcdLJ-0003kb-1H for freebsd-stable@freebsd.org; Sat, 24 Jul 2010 13:56:37 +0200 Date: Sat, 24 Jul 2010 13:56:30 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <136751861.20100724135630@nitronet.pl> To: freebsd-stable@freebsd.org In-Reply-To: References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Adam Vande More Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 11:56:39 -0000 > Easiest way to create sparse eg 20 GB assuming test.img doesn't exist > already No no no. Easiest way to do what you want to do: mdconfig -a -t malloc -s 3t -u 0 mdconfig -a -t malloc -s 3t -u 1 Just make sure to offline and delete mds ASAP, unless you have 6TB of RAM waiting to be filled ;) - note that with RAIDZ2 you have no redundancy with two fake disks gone, and if going with RAIDZ1 this won't work at all. I can't figure out a safe way (data redundancy all the way) of doing things with only 2 free disks and 3.5TB data - third disk would make things easier, fourth would make them trivial; note that temporary disks 3 and 4 don't have to be 2TB, 1.5TB will do. I've done this dozen of times, had no problems, no gray hair, and not a bit of data lost ;) From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 12:41:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1CCB1065676 for ; Sat, 24 Jul 2010 12:41:43 +0000 (UTC) (envelope-from stacey@vickiandstacey.com) Received: from smarthost02.mail.zen.net.uk (smarthost02.mail.zen.net.uk [212.23.3.141]) by mx1.freebsd.org (Postfix) with ESMTP id 708C08FC15 for ; Sat, 24 Jul 2010 12:41:43 +0000 (UTC) Received: from [82.68.31.182] (helo=unknown) by smarthost02.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1Oce2v-0002XK-8y; Sat, 24 Jul 2010 12:41:41 +0000 Date: Sat, 24 Jul 2010 13:41:40 +0100 From: S Roberts To: Randi Harper Message-ID: <20100724134140.000004b6@unknown> In-Reply-To: References: <20100403174812.59c40c99.matheus@eternamente.info> <20100403205856.GA20454@icarus.home.lan> <201004040405.55356.bruce@cran.org.uk> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-Smarthost02-IP: [82.68.31.182] Cc: Bruce Cran , Jeremy, freebsd-stable@freebsd.org, Chadwick Subject: Re: install touching mbr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 12:41:43 -0000 Hello, On Mon, 5 Apr 2010 22:28:25 -0700 Randi Harper wrote: > On Sat, Apr 3, 2010 at 8:05 PM, Bruce Cran wrote: > > On Saturday 03 April 2010 21:58:56 Jeremy Chadwick wrote: > >> On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: > >> > I just installed a 8.0R amd64 from memstick. when asked, I said > >> > to leave mbr untouched. when I rebooted, it was freebsd > >> > bootloader that was on control. this options is not what I think > >> > it should, or there is really a issue here ? > >> > >> I can confirm this behaviour. =A0Someone may have broken something > >> when tinkering around in that part of sysinstall (since the > >> Standard vs. BootMgr options were moved around compared to > >> previous releases). > > > > I have a patch at http://reviews.freebsdish.org/r/15/ waiting to be > > committed. I believe the "None" option won't change the bootcode > > itself but will still mark the FreeBSD partition as active. > > > > -- > > Bruce Cran >=20 > I disagree with some of the wording. Specifically, lines 100-102 of > usr.sbin/sade/menus.c >=20 > "If you will only have FreeBSD on the machine the boot manager is not > needed and it slows down the boot while offering you the choice of > which operating system to boot." >=20 > ^^ not 100% true, as the boot manager also provides the option of PXE > booting. This statement seems excessively wordy and unnecessary. >=20 > Also, should this be broken up into two patches? One for the change in > sade, the other for sysinstall? I'm not picky about this, but you are > fixing two issues in two separate programs. Any chance that this patch review was completed, approved and made it into 8.1 Release? Thanks. Regards, S Roberts >=20 > -- randi > _______________________________________________ > 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 24 13:01:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63D891065675 for ; Sat, 24 Jul 2010 13:01:28 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 364088FC08 for ; Sat, 24 Jul 2010 13:01:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 8429D50B7A; Sat, 24 Jul 2010 14:01:27 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frLn+xhKuiG8; Sat, 24 Jul 2010 14:01:26 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 5604450A93 ; Sat, 24 Jul 2010 14:01:26 +0100 (BST) Message-ID: <4C4AE419.2020503@langille.org> Date: Sat, 24 Jul 2010 09:01:13 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Pawel Tyll References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <718046944.20100723032259@nitronet.pl> <4C4A42D5.7080805@langille.org> <136751861.20100724135630@nitronet.pl> In-Reply-To: <136751861.20100724135630@nitronet.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 13:01:28 -0000 On 7/24/2010 7:56 AM, Pawel Tyll wrote: >> Easiest way to create sparse eg 20 GB assuming test.img doesn't exist >> already You trim posts too much... there is no way to compare without opening another email. Adam wrote: > truncate -s 20g test.img > ls -sk test.img > 1 test.img > No no no. Easiest way to do what you want to do: > mdconfig -a -t malloc -s 3t -u 0 > mdconfig -a -t malloc -s 3t -u 1 In what way is that easier? Now I have /dev/md0 and /dev/md1 as opposed to two sparse files. > Just make sure to offline and delete mds ASAP, unless you have 6TB of > RAM waiting to be filled ;) - note that with RAIDZ2 you have no > redundancy with two fake disks gone, and if going with RAIDZ1 this > won't work at all. I can't figure out a safe way (data redundancy all > the way) of doing things with only 2 free disks and 3.5TB data - third > disk would make things easier, fourth would make them trivial; note > that temporary disks 3 and 4 don't have to be 2TB, 1.5TB will do. The lack of redundancy is noted and accepted. Thanks. :) -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 16:51:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C1910656DE for ; Sat, 24 Jul 2010 16:51:31 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id A609B8FC08 for ; Sat, 24 Jul 2010 16:51:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id D883D50B7A for ; Sat, 24 Jul 2010 17:13:08 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo8xY0Y1x44s for ; Sat, 24 Jul 2010 17:13:07 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id B1FA350A93 for ; Sat, 24 Jul 2010 17:13:07 +0100 (BST) Message-ID: <4C4B1106.8070402@langille.org> Date: Sat, 24 Jul 2010 12:12:54 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> <4C47FD18.7030002@langille.org> In-Reply-To: <4C47FD18.7030002@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 16:51:32 -0000 On 7/22/2010 4:11 AM, Dan Langille wrote: > On 7/22/2010 4:03 AM, Charles Sprickman wrote: >> On Thu, 22 Jul 2010, Dan Langille wrote: >> >>> On 7/22/2010 3:30 AM, Charles Sprickman wrote: >>>> On Thu, 22 Jul 2010, Dan Langille wrote: >>>> >>>>> On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: >>>>>> On 22.07.2010 10:32, Dan Langille wrote: >>>>>>> I'm not sure of the criteria, but this is what I'm running: >>>>>>> >>>>>>> atapci0: port 0xdc00-0xdc0f mem >>>>>>> 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on >>>>>>> pci7 >>>>>>> >>>>>>> atapci1: port 0xac00-0xac0f mem >>>>>>> 0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on >>>>>>> pci3 >>>>>>> >>>>>>> I added ahci_load="YES" to loader.conf and rebooted. Now I see: >>>>>> >>>>>> You can add siis_load="YES" to loader.conf for SiI 3124. >>>>> >>>>> Ahh, thank you. >>>>> >>>>> I'm afraid to do that now, before I label my ZFS drives for fear that >>>>> the ZFS array will be messed up. But I do plan to do that for the >>>>> system after my plan is implemented. Thank you. :) >>>> >>>> You may even get hotplug support if you're lucky. :) >>>> >>>> I just built a box and gave it a spin with the "old" ata stuff and then >>>> with the "new" (AHCI) stuff. It does perform a bit better and my BIOS >>>> claims it supports hotplug with ahci enabled as well... Still have to >>>> test that. >>> >>> Well, I don't have anything to support hotplug. All my stuff is >>> internal. >>> >>> http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg >>> >>> >> >> The frankenbox I'm testing on is a retrofitted 1U (it had a scsi >> backplane, now has none). >> >> I am not certain, but I think with 8.1 (which it's running) and all the >> cam integration stuff, hotplug is possible. Is a special backplane >> required? I seriously don't know... I'm going to give it a shot though. >> >> Oh, you also might get NCQ. Try: >> >> [root@h21 /tmp]# camcontrol tags ada0 >> (pass0:ahcich0:0:0:0): device openings: 32 > > # camcontrol tags ada0 > (pass0:siisch2:0:0:0): device openings: 31 > > resending with this: > > ada{0..4} give the above. > > # camcontrol tags ada5 > (pass5:ahcich0:0:0:0): device openings: 32 > > That's part of the gmirror array for the OS, along with ad6 which has > similar output. > > And again with this output from one of the ZFS drives: > > # camcontrol identify ada0 > pass0: ATA-8 SATA 2.x device > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > protocol ATA/ATAPI-8 SATA 2.x > device model Hitachi HDS722020ALA330 > firmware revision JKAOA28A > serial number JK1130YAH531ST > WWN 5000cca221d068d5 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 268435455 sectors > LBA48 supported 3907029168 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM 7200 > > Feature Support Enable Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management yes no 0/0x00 > automatic acoustic management yes no 254/0xFE 128/0x80 > media status notification no no > power-up in Standby yes no > write-read-verify no no 0/0x0 > unload no no > free-fall no no > data set management (TRIM) no Does this support NCQ? -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 18:50:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC138106566C for ; Sat, 24 Jul 2010 18:50:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3138FC08 for ; Sat, 24 Jul 2010 18:50:05 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id luWW1e0050mv7h05Duq5V3; Sat, 24 Jul 2010 18:50:05 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta11.westchester.pa.mail.comcast.net with comcast id luq41e0093LrwQ23Xuq5kF; Sat, 24 Jul 2010 18:50:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1C35B9B425; Sat, 24 Jul 2010 11:50:03 -0700 (PDT) Date: Sat, 24 Jul 2010 11:50:03 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20100724185003.GA96773@icarus.home.lan> References: <4C47E610.2040409@langille.org> <4C47EC47.5090000@yandex.ru> <4C47ED09.7020808@langille.org> <4C47F4F1.8030804@langille.org> <4C47FD18.7030002@langille.org> <4C4B1106.8070402@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4B1106.8070402@langille.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 18:50:05 -0000 On Sat, Jul 24, 2010 at 12:12:54PM -0400, Dan Langille wrote: > On 7/22/2010 4:11 AM, Dan Langille wrote: > >On 7/22/2010 4:03 AM, Charles Sprickman wrote: > >>On Thu, 22 Jul 2010, Dan Langille wrote: > >> > >>>On 7/22/2010 3:30 AM, Charles Sprickman wrote: > >>>>On Thu, 22 Jul 2010, Dan Langille wrote: > >>>> > >>>>>On 7/22/2010 2:59 AM, Andrey V. Elsukov wrote: > >>>>>>On 22.07.2010 10:32, Dan Langille wrote: > >>>>>>>I'm not sure of the criteria, but this is what I'm running: > >>>>>>> > >>>>>>>atapci0: port 0xdc00-0xdc0f mem > >>>>>>>0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on > >>>>>>>pci7 > >>>>>>> > >>>>>>>atapci1: port 0xac00-0xac0f mem > >>>>>>>0xfbbffc00-0xfbbffc7f,0xfbbf0000-0xfbbf7fff irq 19 at device 4.0 on > >>>>>>>pci3 > >>>>>>> > >>>>>>>I added ahci_load="YES" to loader.conf and rebooted. Now I see: > >>>>>> > >>>>>>You can add siis_load="YES" to loader.conf for SiI 3124. > >>>>> > >>>>>Ahh, thank you. > >>>>> > >>>>>I'm afraid to do that now, before I label my ZFS drives for fear that > >>>>>the ZFS array will be messed up. But I do plan to do that for the > >>>>>system after my plan is implemented. Thank you. :) > >>>> > >>>>You may even get hotplug support if you're lucky. :) > >>>> > >>>>I just built a box and gave it a spin with the "old" ata stuff and then > >>>>with the "new" (AHCI) stuff. It does perform a bit better and my BIOS > >>>>claims it supports hotplug with ahci enabled as well... Still have to > >>>>test that. > >>> > >>>Well, I don't have anything to support hotplug. All my stuff is > >>>internal. > >>> > >>>http://sphotos.ak.fbcdn.net/hphotos-ak-ash1/hs430.ash1/23778_106837706002537_100000289239443_171753_3508473_n.jpg > >>> > >>> > >> > >>The frankenbox I'm testing on is a retrofitted 1U (it had a scsi > >>backplane, now has none). > >> > >>I am not certain, but I think with 8.1 (which it's running) and all the > >>cam integration stuff, hotplug is possible. Is a special backplane > >>required? I seriously don't know... I'm going to give it a shot though. > >> > >>Oh, you also might get NCQ. Try: > >> > >>[root@h21 /tmp]# camcontrol tags ada0 > >>(pass0:ahcich0:0:0:0): device openings: 32 > > > ># camcontrol tags ada0 > >(pass0:siisch2:0:0:0): device openings: 31 > > > >resending with this: > > > >ada{0..4} give the above. > > > ># camcontrol tags ada5 > >(pass5:ahcich0:0:0:0): device openings: 32 > > > >That's part of the gmirror array for the OS, along with ad6 which has > >similar output. > > > >And again with this output from one of the ZFS drives: > > > ># camcontrol identify ada0 > >pass0: ATA-8 SATA 2.x device > >pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > > >protocol ATA/ATAPI-8 SATA 2.x > >device model Hitachi HDS722020ALA330 > >firmware revision JKAOA28A > >serial number JK1130YAH531ST > >WWN 5000cca221d068d5 > >cylinders 16383 > >heads 16 > >sectors/track 63 > >sector size logical 512, physical 512, offset 0 > >LBA supported 268435455 sectors > >LBA48 supported 3907029168 sectors > >PIO supported PIO4 > >DMA supported WDMA2 UDMA6 > >media RPM 7200 > > > >Feature Support Enable Value Vendor > >read ahead yes yes > >write cache yes yes > >flush cache yes yes > >overlap no > >Tagged Command Queuing (TCQ) no no > >Native Command Queuing (NCQ) yes 32 tags > >SMART yes yes > >microcode download yes yes > >security yes no > >power management yes yes > >advanced power management yes no 0/0x00 > >automatic acoustic management yes no 254/0xFE 128/0x80 > >media status notification no no > >power-up in Standby yes no > >write-read-verify no no 0/0x0 > >unload no no > >free-fall no no > >data set management (TRIM) no > > Does this support NCQ? Does *what* support NCQ? The output above, despite having lost its whitespace formatting, indicates the drive does support NCQ and due to using CAM (via ahci.ko or siis.ko) has NCQ in use: > >Native Command Queuing (NCQ) yes 32 tags A binary verification (does it/does it not) is also visible in your kernel log, ex: ada2: Command Queueing enabled -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 20:35:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40FD4106564A for ; Sat, 24 Jul 2010 20:35:38 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3728FC08 for ; Sat, 24 Jul 2010 20:35:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 19E4750B7A; Sat, 24 Jul 2010 21:35:37 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmqQHle637rf; Sat, 24 Jul 2010 21:35:36 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 21A005089E ; Sat, 24 Jul 2010 21:35:36 +0100 (BST) Message-ID: <4C4B4E89.8040101@langille.org> Date: Sat, 24 Jul 2010 16:35:21 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: John Hawkes-Reed References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <4C498024.7050106@libeljournal.com> In-Reply-To: <4C498024.7050106@libeljournal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 20:35:38 -0000 On 7/23/2010 7:42 AM, John Hawkes-Reed wrote: > Dan Langille wrote: >> Thank you to all the helpful discussion. It's been very helpful and >> educational. Based on the advice and suggestions, I'm going to adjust >> my original plan as follows. > > [ ... ] > > Since I still have the medium-sized ZFS array on the bench, testing this > GPT setup seemed like a good idea. > bonnie -s 50000 > The hardware's a Supermicro X8DTL-iF m/b + 12Gb memory, 2x 5502 Xeons, > 3x Supermicro USASLP-L8I 3G SAS controllers and 24x Hitachi 2Tb drives. > > Partitioning the drives with the command-line: > gpart add -s 1800G -t freebsd-zfs -l disk00 da0[1] gave the following > results with bonnie-64: (Bonnie -r -s 5000|20000|50000)[2] What test is this? I just installed benchmarks/bonnie and I see no -r option. Right now, I'm trying this: bonnie -s 50000 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 24 22:33:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D993106566B for ; Sat, 24 Jul 2010 22:33:08 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by mx1.freebsd.org (Postfix) with ESMTP id E93AB8FC14 for ; Sat, 24 Jul 2010 22:33:07 +0000 (UTC) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com ([77.103.165.1] helo=propellor.libeljournal.com country=GB ident=hirez) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4c4b6a1f.5fbf.24; Sat, 24 Jul 2010 23:33:03 +0100 (envelope-sender ) Received: from localhost (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id 5465E17085; Sat, 24 Jul 2010 23:33:03 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by localhost (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VhicgRvBggh; Sat, 24 Jul 2010 23:32:59 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id 3972B1707D; Sat, 24 Jul 2010 23:32:59 +0100 (BST) Message-ID: <4C4B6A19.5050309@libeljournal.com> Date: Sat, 24 Jul 2010 23:32:57 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C47B57F.5020309@langille.org> <4C48E695.6030602@langille.org> <4C498024.7050106@libeljournal.com> <4C4B4E89.8040101@langille.org> In-Reply-To: <4C4B4E89.8040101@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Langille Subject: Re: Using GTP and glabel for ZFS arrays X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 22:33:08 -0000 On 24/07/2010 21:35, Dan Langille wrote: > On 7/23/2010 7:42 AM, John Hawkes-Reed wrote: >> Dan Langille wrote: >>> Thank you to all the helpful discussion. It's been very helpful and >>> educational. Based on the advice and suggestions, I'm going to adjust >>> my original plan as follows. >> >> [ ... ] >> >> Since I still have the medium-sized ZFS array on the bench, testing this >> GPT setup seemed like a good idea. >> bonnie -s 50000 >> The hardware's a Supermicro X8DTL-iF m/b + 12Gb memory, 2x 5502 Xeons, >> 3x Supermicro USASLP-L8I 3G SAS controllers and 24x Hitachi 2Tb drives. >> >> Partitioning the drives with the command-line: >> gpart add -s 1800G -t freebsd-zfs -l disk00 da0[1] gave the following >> results with bonnie-64: (Bonnie -r -s 5000|20000|50000)[2] > > What test is this? I just installed benchmarks/bonnie and I see no -r > option. Right now, I'm trying this: bonnie -s 50000 http://code.google.com/p/bonnie-64/ -- JH-R