From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 00:16:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48F11065670; Sun, 1 Jan 2012 00:16:56 +0000 (UTC) (envelope-from adrian.chadd@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 3C8C58FC0C; Sun, 1 Jan 2012 00:16:55 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so20229233vbb.13 for ; Sat, 31 Dec 2011 16:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3QOKk0brNpNymel4Xe5JPA9QKFC8RuMETf0B2pbfZiA=; b=p3DXrZVrzqEOHJ0R4FQkBpXK+6eirq1ieHO2ijwOR+NgjeAYGloDjOYUcXzen348bR nsSBg8YDsKXmNO8jZYl1/aojbq4xFoYO8K2PN7++l8CkbBUt36pOl0RrBafTGo8OsVWi 7cTazdbQ0n8QvYLDrbuj4jXSVCZLrE/DLTrSo= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr14674422vdf.117.1325377015498; Sat, 31 Dec 2011 16:16:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Sat, 31 Dec 2011 16:16:55 -0800 (PST) In-Reply-To: <863B2CE2-BB30-4E67-8CB7-9BBFACB9A20A@airwired.net> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> <863B2CE2-BB30-4E67-8CB7-9BBFACB9A20A@airwired.net> Date: Sat, 31 Dec 2011 16:16:55 -0800 X-Google-Sender-Auth: 4bQMlh-3KCih596kXtMnap9_PJA Message-ID: From: Adrian Chadd To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: List Mailing FreeBSD-STABLE , Garrett Cooper , mav@freebsd.org, freebsd-current@freebsd.org, Jeremy Chadwick Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 00:16:56 -0000 On 31 December 2011 16:08, Dan Allen wrote: > Almost every day I csup from RELENG_x and build. =A0The traces of RELENG_= 8 are gone, so no, unfortunately I cannot give you a uname -a from those da= ys. Would you consider having a small partition to do the same for HEAD? :P > However, I have a build log file, and I see that I moved from RELENG_8 to= RELENG_9 on Friday, Dec 23, 2011. =A0I csup'd at 12:24:26 MST and discover= ed the failure at 15:41 MST. > > This "nooptions NEW_PCIB" fix does seem rather tenuous if it is not docum= ented. =A0Wouldn't a better route be something like > > =A0if (ACPI < 2.0) > =A0 =A0oldCode(); > =A0else > =A0 =A0newCodeForNewACPI(); > > so that it will always work for everyone without having to build a specia= l kernel? =A0After all, I went from a working system to a hung system which= is not the best upgrade path... ;-) Well it's hard to test stuff out without the hardware. :) And it's quite possible a lot of silly looking issues are actually working around real bugs in the hardware. I'm glad this issue was solved so quickly for you. Let's hope we can get you onto testing out HEAD (in a separate partition!) so we can ensure we don't break the basic stuff. :) Adrian From owner-freebsd-current@FreeBSD.ORG Sat Dec 31 23:17:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DC231065673 for ; Sat, 31 Dec 2011 23:17:47 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4458FC0C for ; Sat, 31 Dec 2011 23:17:46 +0000 (UTC) Received: (qmail 13523 invoked by uid 89); 31 Dec 2011 23:20:15 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 31 Dec 2011 23:20:15 -0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Dan Allen In-Reply-To: Date: Sat, 31 Dec 2011 16:17:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04292366-1297-488F-9239-98565828DDC8@airwired.net> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> To: Garrett Cooper X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Sun, 01 Jan 2012 00:50:26 +0000 Cc: freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE , Jeremy Chadwick Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 23:17:47 -0000 On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: > Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and > try booting the new kernel. See if this works. It worked! No hang, power button works. Nice. I hope this = experimental option stays in. Thank you everyone for your help. Happy New Years! Dan From owner-freebsd-current@FreeBSD.ORG Sat Dec 31 23:31:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5CF1065673 for ; Sat, 31 Dec 2011 23:31:53 +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 BC5148FC16 for ; Sat, 31 Dec 2011 23:31:53 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta01.emeryville.ca.mail.comcast.net with comcast id FzXn1i0020cQ2SLA1zXnim; Sat, 31 Dec 2011 23:31:47 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id FzUL1i00M1t3BNj8WzULE9; Sat, 31 Dec 2011 23:28:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 42842102C1E; Sat, 31 Dec 2011 15:31:52 -0800 (PST) Date: Sat, 31 Dec 2011 15:31:52 -0800 From: Jeremy Chadwick To: Dan Allen Message-ID: <20111231233152.GA54245@icarus.home.lan> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04292366-1297-488F-9239-98565828DDC8@airwired.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 01 Jan 2012 00:50:36 +0000 Cc: Garrett Cooper , mav@freebsd.org, freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 23:31:54 -0000 On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote: > On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: > > > Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and > > try booting the new kernel. See if this works. > > It worked! No hang, power button works. Nice. I hope this experimental option stays in. > > Thank you everyone for your help. Happy New Years! This option isn't documented **anywhere** in the entire src tree. It's purely #ifdef all over. The code in question was committed 7 months ago. It was MFC'd to RELENG_8 6 months ago. Here's the HEAD commit message: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420 The RELENG_8 MFC is revision 1.386.2.15. The committer is jhb@, with mav@ being the individual who tested it, so I imagine either of these folks will have some excellent insights as to what's causing Dan's problem. I'm CC'ing them both directly on this thread. In the meantime: Dan, when you say in your original mail, "I just upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you please provide uname -a output from the system when it was running RELENG_8? I'm looking specifically for the exact time when the kernel was built, because there may have been fixes (that broke things for you) between the above commit and present-day RELENG_8 (I have not examined all commits). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 00:08:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C291065676 for ; Sun, 1 Jan 2012 00:08:12 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id BA87D8FC13 for ; Sun, 1 Jan 2012 00:08:11 +0000 (UTC) Received: (qmail 29807 invoked by uid 89); 1 Jan 2012 00:10:40 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 1 Jan 2012 00:10:40 -0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <20111231233152.GA54245@icarus.home.lan> Date: Sat, 31 Dec 2011 17:08:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <863B2CE2-BB30-4E67-8CB7-9BBFACB9A20A@airwired.net> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Sun, 01 Jan 2012 00:50:44 +0000 Cc: Garrett Cooper , mav@freebsd.org, freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 00:08:12 -0000 On 31 Dec 2011, at 4:31 PM, Jeremy Chadwick wrote: > In the meantime: Dan, when you say in your original mail, "I just > upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you > please provide uname -a output from the system when it was running > RELENG_8? I'm looking specifically for the exact time when the kernel > was built Almost every day I csup from RELENG_x and build. The traces of RELENG_8 = are gone, so no, unfortunately I cannot give you a uname -a from those = days. However, I have a build log file, and I see that I moved from RELENG_8 = to RELENG_9 on Friday, Dec 23, 2011. I csup'd at 12:24:26 MST and = discovered the failure at 15:41 MST. This "nooptions NEW_PCIB" fix does seem rather tenuous if it is not = documented. Wouldn't a better route be something like if (ACPI < 2.0) oldCode(); else newCodeForNewACPI(); so that it will always work for everyone without having to build a = special kernel? After all, I went from a working system to a hung = system which is not the best upgrade path... ;-) Dan From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 02:14:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05A63106564A; Sun, 1 Jan 2012 02:14:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 92DE98FC08; Sun, 1 Jan 2012 02:14:55 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so16740778obb.13 for ; Sat, 31 Dec 2011 18:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IEeRanD2MGuEvI+KGPD7qvMu/rPyzdC0K6GRhRstuhg=; b=j3AedlJgs+t5HwPPu/cDrfe2MYnVpewvqqrxmrHU+lIG9YsVsbN/vpAJm90yBxFcjo Wls2HwoWD0VsAMLCwQga1+2TNxoPi8roSWgXTufIxU8uichuMDcqNCDwFEqbJOPyZ+/7 PhC/s2/+VITE0q0oTZY1pF2Sasak/M46B5AKI= MIME-Version: 1.0 Received: by 10.182.51.37 with SMTP id h5mr37900029obo.51.1325384094922; Sat, 31 Dec 2011 18:14:54 -0800 (PST) Received: by 10.182.152.6 with HTTP; Sat, 31 Dec 2011 18:14:54 -0800 (PST) In-Reply-To: <20111231233152.GA54245@icarus.home.lan> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> Date: Sat, 31 Dec 2011 18:14:54 -0800 Message-ID: From: Garrett Cooper To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dan Allen , freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE , mav@freebsd.org Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 02:14:56 -0000 On Sat, Dec 31, 2011 at 3:31 PM, Jeremy Chadwick wrote: > On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote: >> On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: >> >> > Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and >> > try booting the new kernel. See if this works. >> >> It worked! =A0No hang, power button works. =A0Nice. =A0I hope this exper= imental option stays in. >> >> Thank you everyone for your help. =A0Happy New Years! > > This option isn't documented **anywhere** in the entire src tree. =A0It's > purely #ifdef all over. > > The code in question was committed 7 months ago. =A0It was MFC'd to > RELENG_8 6 months ago. =A0Here's the HEAD commit message: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420 > > The RELENG_8 MFC is revision 1.386.2.15. > > The committer is jhb@, with mav@ being the individual who tested it, so > I imagine either of these folks will have some excellent insights as to > what's causing Dan's problem. =A0I'm CC'ing them both directly on this > thread. > > In the meantime: Dan, when you say in your original mail, "I just > upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you > please provide uname -a output from the system when it was running > RELENG_8? =A0I'm looking specifically for the exact time when the kernel > was built, because there may have been fixes (that broke things for you) > between the above commit and present-day RELENG_8 (I have not examined > all commits). It's going to be the feature that's going to cause headaches post-9.0-RELEASE based on my observations of several mailing list posts and the fact that 9.0 isn't actually RELEASEd yet (people have run into issues with acpi, atkbdc, mfi, and usb so far, but that's probably not everything). If it could be made into a runtime tunable, that would be awesome, but that would require changes to driver structures and methods. With a little pointer aliasing and tunable guard sprinkling it wouldn't be hard to solve -- but it's still work. In the meantime, could someone please commit PR # 163748 to note what NEW_PCIB is and MFC it to RELENG_9 and could we consider disabling NEW_PCIB on i386 and pc98 until all the issues are ironed out? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 12:17:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C2CA106564A for ; Sun, 1 Jan 2012 12:17:33 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id F00668FC0C for ; Sun, 1 Jan 2012 12:17:32 +0000 (UTC) Received: by eekc50 with SMTP id c50so17613174eek.13 for ; Sun, 01 Jan 2012 04:17:31 -0800 (PST) Received: by 10.14.50.204 with SMTP id z52mr18308902eeb.92.1325420251612; Sun, 01 Jan 2012 04:17:31 -0800 (PST) Received: from gizmo.my.domain (nat140-249-205-109.tvoe.tv. [109.205.249.140]) by mx.google.com with ESMTPS id t1sm176223655eeb.3.2012.01.01.04.17.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jan 2012 04:17:30 -0800 (PST) From: Oleg Ginzburg To: freebsd-current@freebsd.org Date: Sun, 1 Jan 2012 16:18:07 +0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: <201112292137.33189.olevole@olevole.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201011618.08008.olevole@olevole.ru> Cc: Ryan Stone Subject: Re: segfault from php/freebsd/dtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 12:17:33 -0000 On Saturday 31 December 2011 23:25:51 Ryan Stone wrote: > On Thu, Dec 29, 2011 at 12:37 PM, Oleg Ginzburg wrote: > > Hi maillist, > > > > I try to use dtrace + php/dtrace on the freebsd. In certain cases ive get > > Segmentation fault and don't understand what of subsystem has a problem. > > Yes, Userland DTrace is unfortunately still very experimental at this > point. I've got a list of at least 10 outstanding bugs that I hope to > start addressing early in the new year. > > In your case, dtrace(1) and/or libproc does not clean up after itself > properly in the case of an error. I can assume that it is: --//Cut of /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c//-- if (fbsd_thread_active) { gdb_assert (proc_handle.pid == 0); << Here is 484 string mentioned by backtrace << fbsd_thread_active = 0; } --- related with the first process php which I start for providing php dtrace probes. Thanks to this process other code passes through php/dtrace and this process doesn't stop. Last action by backtrace is: #0 0x00000008021c6a37 in strlen () from /lib/libc.so.7 Unfortunately at the expense of DEBUG symbols, process have a bit more memory, so this problem isn't present and i couldn't see value of variables in this place and whence it is caused. > I'm not entirely sure what is > causing the segfault in php, though. Which version are you running? > The output of uname -a would be helpful. At the moment of test (on December, 23th) it there was last version 9- RELENG/amd64 from SVN %uname -a: FreeBSD fbsd-strace.my.domain 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Fri Dec 23 16:56:09 MSK 2011 root@t.my.domain:/usr/obj/usr/src/sys/G-DTRACE amd64 Kernel config: %cat /sys/amd64/conf/G-DTRACE include GENERIC ident G-DTRACE options KDTRACE_HOOKS # all architectures - enable general DTrace hooks options DDB_CTF # all architectures - kernel ELF linker loads CTF data options KDTRACE_FRAME # amd64 - ensure frames are compiled in makeoptions WITH_CTF=1 #nomakeoptions DEBUG #nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD4 #nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD5 #nooptions COMPAT_FREEBSD6 # Compatible with FreeBSD6 #nooptions COMPAT_FREEBSD7 # Compatible with FreeBSD7 %cat /etc/make.conf WITH_CTF=1 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 12:58:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E8B106566C; Sun, 1 Jan 2012 12:58:25 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9468FC14; Sun, 1 Jan 2012 12:58:25 +0000 (UTC) Received: by eekc50 with SMTP id c50so17626866eek.13 for ; Sun, 01 Jan 2012 04:58:24 -0800 (PST) Received: by 10.213.3.214 with SMTP id 22mr98793ebo.2.1325421144933; Sun, 01 Jan 2012 04:32:24 -0800 (PST) Received: from rnote.ddteam.net (170-249-133-95.pool.ukrtel.net. [95.133.249.170]) by mx.google.com with ESMTPS id q67sm114529129eea.8.2012.01.01.04.32.22 (version=SSLv3 cipher=OTHER); Sun, 01 Jan 2012 04:32:23 -0800 (PST) Date: Sun, 1 Jan 2012 14:32:18 +0200 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20120101143218.7a42f001.ray@ddteam.net> In-Reply-To: References: X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-arch@freebsd.org Subject: Re: [patch] bsdbox changes for base system: add LOCAL_ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 12:58:25 -0000 On Fri, 23 Dec 2011 16:42:06 -0800 Adrian Chadd wrote: > Hi, > > Here are two patches which implement some useful features for crunch > building: > > * Add LOCAL_TOOLS_DIR in src/Makefile.inc1, which adds entries to the > 'build-tools' target. This is needed for cross-building bsdbox (and > any external directory added by LOCAL_DIRS) That makes me happy :) > * If CRUNCH_SUPPRESS_ALL_LINKS is set to 'yes', don't auto-populate > the crunch-gen hard links. > > I may end up changing the latter to CRUNCH_GENERATE_LINKS and default > that to yes, then allow the bsdbox build system to change that to > 'no', but the intent is the same. > > I'd like to commit this tomorrow if possible, so I can then follow it > up with the bsdbox import. > > Thanks, > > > Adrian Do it Adrian :) > > [adrian@pcbsd-macvm] ~/work/freebsd/head/src> svn diff Makefile.inc1 > share/mk Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 228757) > +++ Makefile.inc1 (working copy) > @@ -15,6 +15,8 @@ > # -DNO_WWWUPDATE do not update www in ${MAKE} update > # -DNO_CTF do not run the DTrace CTF conversion tools on built > # objects LOCAL_DIRS="list of dirs" to add additional dirs to the > # SUBDIR list > +# LOCAL_TOOL_DIRS="list of dirs" to add additional dirs to the > build-tools +# list > # TARGET="machine" to crossbuild world for a different machine > # type TARGET_ARCH= may be required when a TARGET supports multiple > # endians > > @@ -104,6 +106,8 @@ > CLEANDIR= cleandir > .endif > > +LOCAL_TOOL_DIRS?= '' > + > CVS?= cvs > CVSFLAGS?= -A -P -d -I! > SVN?= svn > @@ -1102,6 +1106,7 @@ > bin/csh \ > bin/sh \ > ${_rescue} \ > + ${LOCAL_TOOL_DIRS} \ > lib/ncurses/ncurses \ > lib/ncurses/ncursesw \ > ${_share} \ > Index: share/mk/bsd.crunchgen.mk > =================================================================== > --- share/mk/bsd.crunchgen.mk (revision 228757) > +++ share/mk/bsd.crunchgen.mk (working copy) > @@ -22,6 +22,8 @@ > # Specific links can be suppressed by setting > # CRUNCH_SUPPRESS_LINK_$(NAME) to 1. > # > +# If CRUNCH_SUPPRESS_ALL_LINKS is set to yes, no links will be > generated. +# > > # $FreeBSD$ > > @@ -39,6 +41,7 @@ > .else > CANONICALOBJDIR:= /usr/obj${.CURDIR} > .endif > +CRUNCH_SUPPRESS_ALL_LINKS?= no > > CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h > > @@ -51,6 +54,7 @@ > .else > $(OUTPUTS): $(.CURDIR)/../../$(D)/$(P)/Makefile > .endif > +.if ${CRUNCH_SUPPRESS_ALL_LINKS} != "yes" > .ifndef CRUNCH_SUPPRESS_LINK_${P} > LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(P) > .endif > @@ -59,6 +63,7 @@ > LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(A) > .endif > .endfor > +.endif > .endfor > .endfor > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 13:55:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D20A106566C; Sun, 1 Jan 2012 13:55:40 +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 C656B8FC13; Sun, 1 Jan 2012 13:55:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6045046B09; Sun, 1 Jan 2012 08:55:39 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CA395B91E; Sun, 1 Jan 2012 08:55:38 -0500 (EST) Message-ID: <4F0065E1.8000808@FreeBSD.org> Date: Sun, 01 Jan 2012 08:55:45 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sun, 01 Jan 2012 08:55:39 -0500 (EST) Cc: Dan Allen , freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE , mav@freebsd.org, Jeremy Chadwick Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 13:55:40 -0000 On 12/31/11 9:14 PM, Garrett Cooper wrote: > On Sat, Dec 31, 2011 at 3:31 PM, Jeremy Chadwick > wrote: >> On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote: >>> On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: >>> >>>> Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and >>>> try booting the new kernel. See if this works. >>> >>> It worked! No hang, power button works. Nice. I hope this experimental option stays in. >>> >>> Thank you everyone for your help. Happy New Years! >> >> This option isn't documented **anywhere** in the entire src tree. It's >> purely #ifdef all over. >> >> The code in question was committed 7 months ago. It was MFC'd to >> RELENG_8 6 months ago. Here's the HEAD commit message: >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420 >> >> The RELENG_8 MFC is revision 1.386.2.15. >> >> The committer is jhb@, with mav@ being the individual who tested it, so >> I imagine either of these folks will have some excellent insights as to >> what's causing Dan's problem. I'm CC'ing them both directly on this >> thread. >> >> In the meantime: Dan, when you say in your original mail, "I just >> upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you >> please provide uname -a output from the system when it was running >> RELENG_8? I'm looking specifically for the exact time when the kernel >> was built, because there may have been fixes (that broke things for you) >> between the above commit and present-day RELENG_8 (I have not examined >> all commits). > > It's going to be the feature that's going to cause headaches > post-9.0-RELEASE based on my observations of several mailing list > posts and the fact that 9.0 isn't actually RELEASEd yet (people have > run into issues with acpi, atkbdc, mfi, and usb so far, but that's > probably not everything). > If it could be made into a runtime tunable, that would be awesome, > but that would require changes to driver structures and methods. With > a little pointer aliasing and tunable guard sprinkling it wouldn't be > hard to solve -- but it's still work. Eh, almost all the problems are not with the PCI-PCI bridge bits, but with the later changes to the ACPI Host-PCI bridge driver, and that is changeable via a tunable. (debug.acpi.disabled="hostres") All of the problems in this case are due to the BIOS providing incomplete or flat-out erroneous information in the ACPI tables about which resource ranges each Host-PCI bridge decodes. Also, there is supposed to be language in the 9.0 errata mentioning this tunable. I had suggested to re@ that we disable it for 9.0 by default, but instead they decided to document it instead since I made the suggestion fairly late in the process (even though at this point that was more like a month ago). Finally, I made a commit this week to HEAD that probably "fixes" most of the issues with BIOSes lying about their Host-PCI bridges (the problem is the BIOS says two different things in two different places when it programs a BAR or other resource that it then claims the parent bridge doesn't handle). The commit specifically fixed a Dell Optiplex GX620, so I imagine it will fix a GX270 just as well (revision 228961). The ACPI bits are not a simple matter of "only use it for ACPI 2.0" to reference an earlier e-mail in this thread. The boxes in question almost certainly have ACPI 3.0 or later BIOSes at this point (remember ACPI 1.0 came out in the 1999/2000 timeframe). The PCI-PCI bridge changes are also not specific to only newer versions of PCI, they go back to the rev 1.1 of the PCI-PCI bridge specification and are fixing deficiencies in our handling of the I/O resource windows in bridges. Together the changes in NEW_PCIB are the last remaining bits to make it possible to use "PNP OS" set to yes for PCI devices. Granted, at this point most BIOSes no longer have that option and just always set it to no, but it is important infrastructure to have in place for hotplug PCI (and cardbus (9 should no longer need the hw.cbb.start_memory tunable hacks on various laptops due to NEW_PCIB), etc.). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 22:25:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F38F106564A; Sun, 1 Jan 2012 22:25:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 15AE88FC15; Sun, 1 Jan 2012 22:25:19 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so17125055obb.13 for ; Sun, 01 Jan 2012 14:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nzE9GF152X6AJ9Z5Aemu3RjTInO1eWRMMe8pItv3iAc=; b=HEnxw3IfIErjmaezc3c5E2F/ps5R2hN8UuEpBadCD6uhAhbgvwacB9FwS3vU3Ug7IG Yq+5ediy9Igwq03mMw9/m8yAoGd52m3LFZwDmcd8uBqdSW57r7HchT2jPqgHbYLroxeI Tqvbdt5jq8oO7a4TGxAgsAIhWgeTI9WgpLaq0= MIME-Version: 1.0 Received: by 10.182.2.136 with SMTP id 8mr40234669obu.71.1325456719489; Sun, 01 Jan 2012 14:25:19 -0800 (PST) Received: by 10.182.152.6 with HTTP; Sun, 1 Jan 2012 14:25:19 -0800 (PST) In-Reply-To: References: <4EF34E52.2040905@FreeBSD.org> <20111223005932.GA65042@freebsd.org> <25FBBF23-CDFA-429E-966D-A90409D8F2BD@gmail.com> <201112230937.08971.jhb@freebsd.org> Date: Sun, 1 Jan 2012 14:25:19 -0800 Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [patch] Cleaning up amd64 kernel optimization options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 22:25:20 -0000 On Fri, Dec 23, 2011 at 12:34 PM, Garrett Cooper wrote= : > On Fri, Dec 23, 2011 at 6:37 AM, John Baldwin wrote: >> On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote: >>> On Dec 22, 2011, at 4:59 PM, Alexander Best wrote= : >>> >>> > On Thu Dec 22 11, Benjamin Kaduk wrote: >>> >> On Thu, 22 Dec 2011, Alexander Best wrote: >>> >> >>> >>> On Thu Dec 22 11, Dimitry Andric wrote: >>> >>>> Hi, >>> >>>> >>> >>>> I would like to ask some feedback on the attached patch, which cle= ans up >>> >>>> the kernel optimization options for amd64. =A0This was touched upo= n >>> >>>> earlier by Alexander Best in freebsd-toolchain, here: >>> >>> >>> >>> i've been using such settings for a few months now and haven't noti= ced any >>> >>> problems. >>> >>> >>> >>> however bruce evans raised a good point (in a private mail). when y= ou >>> >>> compile a >>> >>> kernel without debugging enabled, -O2 is the default. if you experi= ence >>> >>> issues, >>> >>> and enable debugging, -O0 now becomes the default. in case the prob= lems >>> >>> with >>> >>> the kernel were caused by the -O2 option and aren't present with th= e -O0 >>> >>> option, the newly built kernel with debugging enabled will not help= you >>> >>> fix the >>> >>> problems. in that case you would need to set -O2 explicitly in CFLA= GS. his >>> >>> exact words were: >>> >>> >>> >>> " >>> >>> I don't like -O2 for anything. =A0However, if it is only a default,= it is >>> >>> not a problem provided it can be canceled easily. =A0And for debugg= ing, you >>> >>> want the default to be the same as without debugging, so that (by d= efault) >>> >>> you debug the same code that caused the problem. >>> >>> " >>> >>> >>> >>> however i don't think this is fixable. using -O0 for debuggable and >>> >>> non-debuggable kernels will cause too much of a slowdown. >>> >>> >>> >>> having -O2 as the default flag for non-debuggable kernels and -O2 -= g for >>> >>> debuggable kernels might cause situations, where debugging isn't po= ssible, >>> >>> where with -O0 -g it would have been. >>> >>> >>> >>> so i guess although bruces concerns are valid, they are impossible = to >>> >>> solve. >>> >> >>> >> Where does -O0 come in? =A0I only see talk of -O (i.e. -O1) versus -= O2. >>> > >>> > sorry. of course i meant -O: >>> > >>> > .if defined(DEBUG) >>> > _MINUS_O=3D =A0 =A0 =A0 -O >>> > CTFFLAGS+=3D =A0 =A0 =A0-g >>> > .else >>> > [..] >>> >>> Back in the 7.x days, I ran into some code that wasn't easily to debug = because the compiler optimized things out with -O2 by inlining and >> otherwise shifting around code, so setting breakpoints in gdb became dif= ficult. So from that point on I've gotten into the habit of doing -O >> explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. >> >> I still leave -O2 in, but what I do is this: >> >> =A0make DEBUG_FLAGS=3D"-g -fno-inline" >> >> Just adding -fno-inline makes a world of difference. > > Sweet -- thanks for the tip ;). Just as a sidenote, this option doesn't work when compiling mii(4), re(4), etc [as modules at least]. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jan 1 22:59:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2301106566C for ; Sun, 1 Jan 2012 22:59:20 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC268FC0C for ; Sun, 1 Jan 2012 22:59:19 +0000 (UTC) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q01L5xBv001345 for ; Mon, 2 Jan 2012 08:05:59 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q01L5uKD008378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 08:05:57 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q01L5sRG032978; Mon, 2 Jan 2012 08:05:54 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q01L5r0n032977; Mon, 2 Jan 2012 08:05:53 +1100 (EST) (envelope-from peter) Date: Mon, 2 Jan 2012 08:05:53 +1100 From: Peter Jeremy To: Randy Bush Message-ID: <20120101210552.GG55604@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="raC6veAxrt5nqIoY" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD current mailing list Subject: Re: lost inode, no backup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 22:59:20 -0000 --raC6veAxrt5nqIoY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I know it's been a week but no-one else has offered any input. On 2011-Dec-25 08:39:02 -0500, Randy Bush wrote: >FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33= :51 UTC 2011 root@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64 =2E.. >on reboot, /usr/home was empty, as iff the inode had been lost. but no >lost+found and fsck found no problem. =2E.. >/dev/da0s1f 138G 111G 15G 88% /usr =2E.. ># 4 - /usr >/sbin/dump 0Luaf - /dev/da0s1f | $SSH $USYS "/bin/cat > $DDIR/usr" > >and which had run quite happily a few hours before =2E.. > DUMP: DUMP: 56980137 tape blocks =2E.. >except that on all backups since the system moved to 10-current, home is >empty in the usr file!!! all other directories there are good. It's not explicitly specified but I presume /usr/home is a directory within /usr. (Not a symlink or mountpoint). What version were you running before 10-current? Is /usr UFS2 with softupdates+journalling? Is userland (specifically /sbin/dump and fsck) aligned with the kernel? Any idea what SVN revision your system corresponds to? Have there been any unclean shutdowns of the system? "Tape blocks" reported by dump(8) are (as far as I can tell) always 1KB. Your df(1) output reports 111GB used in /usr but dump(8) only shows ~57GB being backed up. Do you have any idea why there's such a difference? How much space would you expect to be used in /usr? Do you have the fsck(8) output? If so, how much space does it report? Have you checked the dumps for all the other filesystems? Are any of them missing data or containing unexpectedly empty directories? I don't suppose you have the output from hd(1), stat(1) and "ls -al" of /usr & /usr/home? --=20 Peter Jeremy --raC6veAxrt5nqIoY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEUEARECAAYFAk8AyrAACgkQ/opHv/APuIf1OQCfYJ7zIVTiEVoibuV0qWMpDNT8 964AmMnu1TR3fTBDE8RbION1bBQO9j8= =grZ+ -----END PGP SIGNATURE----- --raC6veAxrt5nqIoY-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 00:17:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A95801065676 for ; Mon, 2 Jan 2012 00:17:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 879348FC14 for ; Mon, 2 Jan 2012 00:17:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RhVax-000074-QY; Mon, 02 Jan 2012 00:17:43 +0000 Date: Mon, 02 Jan 2012 09:17:42 +0900 Message-ID: From: Randy Bush To: Peter Jeremy In-Reply-To: <20120101210552.GG55604@server.vk2pj.dyndns.org> References: <20120101210552.GG55604@server.vk2pj.dyndns.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: lost inode, no backup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 00:17:45 -0000 [ i fear that, at this point, this only serves as a oddity i have seen and reported just in case someone else sees something similar and the two clues can be summed ] > I know it's been a week but no-one else has offered any input. no blame, was very very strange. never seen anything like it before. and i pieced my world back together, with very little loss, as there were other modes of backup in place, belt and braces. i only actually lost some months of mail in imap folders of procmail mailing list spew, such as freebsd-current. > It's not explicitly specified but I presume /usr/home is a directory > within /usr. (Not a symlink or mountpoint). indeed. > What version were you running before 10-current? 9-[then-]current. the machine is the one server which only has my personal crud, so it is the bleeding edge. it converted to -10 about when the problems with backup content seem to have started last (northern hemispheric) summer. so the issue could have been some file state that happened long ago and just did not surface until the much later upgrade. > Is /usr UFS2 with softupdates+journalling? /dev/da0s1f on /usr (ufs, local, soft-updates) > Is userland (specifically /sbin/dump and fsck) aligned with the > kernel? should have been. but lots of things in life should have been. > Any idea what SVN revision your system corresponds to? i guess i could restore a dump and find out. > Have there been any unclean shutdowns of the system? quite likely. a neighbor on the same vmware host did some exciting resource demand messes the other month. > "Tape blocks" reported by dump(8) are (as far as I can tell) always > 1KB. Your df(1) output reports 111GB used in /usr but dump(8) only > shows ~57GB being backed up. Do you have any idea why there's such a > difference? /usr/home not being backed up. among other things, /usr/home/randy/rair contains a unison rsync of my laptop's ~randy, i.e. it's large. > How much space would you expect to be used in /usr? /dev/da0s1f 128G 55G 63G 47% /usr > Do you have the fsck(8) output? If so, how much space does it report? not sure what it is you expect # fsck da0s1f ** /dev/da0s1f (NO WRITE) ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ... lots'o whining 613062 files, 28926263 used, 38606650 free (134698 frags, 4808994 blocks, 0.2% fragmentation) # du -sh /usr/home 48G /usr/home > Have you checked the dumps for all the other filesystems? Are any of > them missing data or containing unexpectedly empty directories? checked (very pseudo) random directories and filesystems. all good. > I don't suppose you have the output from hd(1), stat(1) and "ls -al" > of /usr & /usr/home? not the ones which were borked, only current seemingly good ones. randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 18:35:44 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 665581065673; Mon, 2 Jan 2012 18:35:44 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 329A88FC08; Mon, 2 Jan 2012 18:35:44 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q02IZf26027844; Mon, 2 Jan 2012 18:35:42 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F01F8FD.4020901@FreeBSD.org> Date: Mon, 02 Jan 2012 19:35:41 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20111222 Thunderbird/10.0 MIME-Version: 1.0 To: Kirk McKusick References: <201112290004.pBT04iQH012044@chez.mckusick.com> In-Reply-To: <201112290004.pBT04iQH012044@chez.mckusick.com> X-Enigmail-Version: 1.4a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig446BCA13FCC2AF3331ACDC50" Cc: current@FreeBSD.org, Don Lewis , Attilio Rao , phk@phk.freebsd.dk, kib@FreeBSD.org, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 18:35:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig446BCA13FCC2AF3331ACDC50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29.12.11 01:04, Kirk McKusick wrote: > Rather than changing BKVASIZE, I would try running the cvs2svn > conversion on a 16K/2K filesystem and see if that sorts out the > problem. If it does, it tells us that doubling the main block > size and reducing the number of buffers by half is the problem. > If that is the problem, then we will have to increase the KVM > allocated to the buffer cache. >=20 This does not make a difference. I tried on 32K/4K with/without journal and on 16K/2K all exhibit the same problem. At some point during the cvs2svn conversion the sycer starts to use 100% CPU. The whole process hangs at that point sometimes for hours, from time to time it does continue doing some work, but really really slow. It's usually between revision 210000 and 220000, when the resulting svn file gets bigger than about 11-12Gb. At that point an ls in the target dir hangs in state ufs. I broke into ddb and ran all commands which i thought could be useful. The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt The machine is still in ddb and i could run any additional commands, the kernel is from Attilio's vmcontention branch, which was MFCed yesterday, and updated after the MFC. The same problem happens on 9.0-RC3. If i run the same test on a zfs filesystem i don't see any problems. Florian --------------enig446BCA13FCC2AF3331ACDC50 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk8B+P0ACgkQapo8P8lCvwn0jgCfVz1TSKKrCsB1jFIU24pB8YKt 8qkAn0w3jrw+halyrLXKl2JTLL9U0E/o =pj/5 -----END PGP SIGNATURE----- --------------enig446BCA13FCC2AF3331ACDC50-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 20:47:17 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0360106566B for ; Mon, 2 Jan 2012 20:47:17 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 603EA8FC08 for ; Mon, 2 Jan 2012 20:47:17 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q02Kl3IM005792; Mon, 2 Jan 2012 12:47:07 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201022047.q02Kl3IM005792@gw.catspoiler.org> Date: Mon, 2 Jan 2012 12:47:03 -0800 (PST) From: Don Lewis To: flo@FreeBSD.org In-Reply-To: <4F01F8FD.4020901@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: attilio@FreeBSD.org, current@FreeBSD.org, mckusick@mckusick.com, phk@phk.freebsd.dk, kib@FreeBSD.org, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 20:47:17 -0000 On 2 Jan, Florian Smeets wrote: > On 29.12.11 01:04, Kirk McKusick wrote: >> Rather than changing BKVASIZE, I would try running the cvs2svn >> conversion on a 16K/2K filesystem and see if that sorts out the >> problem. If it does, it tells us that doubling the main block >> size and reducing the number of buffers by half is the problem. >> If that is the problem, then we will have to increase the KVM >> allocated to the buffer cache. >> > > This does not make a difference. I tried on 32K/4K with/without journal > and on 16K/2K all exhibit the same problem. At some point during the > cvs2svn conversion the sycer starts to use 100% CPU. The whole process > hangs at that point sometimes for hours, from time to time it does > continue doing some work, but really really slow. It's usually between > revision 210000 and 220000, when the resulting svn file gets bigger than > about 11-12Gb. At that point an ls in the target dir hangs in state ufs. > > I broke into ddb and ran all commands which i thought could be useful. > The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000 cpustop_handler() at cpustop_handler+0x2b ipi_nmi_handler() at ipi_nmi_handler+0x50 trap() at trap+0x1a8 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8082ba43, rsp = 0xffffff8000270fe0, rbp = 0xffffff88c97829a0 --- _mtx_assert() at _mtx_assert+0x13 pmap_remove_write() at pmap_remove_write+0x38 vm_object_page_remove_write() at vm_object_page_remove_write+0x1f vm_object_page_clean() at vm_object_page_clean+0x14d vfs_msync() at vfs_msync+0xf1 sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff88c9782d00, rbp = 0 --- I thinks this explains why the r228838 patch seems to help the problem. Instead of an application call to msync(), you're getting bitten by the syncer doing the equivalent. I don't know why the syncer is CPU bound, though. From my understanding of the patch it only optimizes the I/O. Without the patch, I would expect that the syncer would just spend a lot of time waiting on I/O. My guess is that this is actually a vm problem. There are nested loops in vm_object_page_clean() and vm_object_page_remove_write(), so you could be doing something that's causing lots of looping in that code. I think that ls is hanging because it's stumbling across the vnode that the syncer has locked. From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 21:29:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 735CD106564A for ; Mon, 2 Jan 2012 21:29:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 27E4A8FC12 for ; Mon, 2 Jan 2012 21:29:22 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 77B9025D386D for ; Mon, 2 Jan 2012 21:29:21 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9FC72BD8571 for ; Mon, 2 Jan 2012 21:29:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id I7w-qYLJtOYb for ; Mon, 2 Jan 2012 21:29:19 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5E035BD8574 for ; Mon, 2 Jan 2012 21:29:18 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jan 2012 21:29:18 +0000 Message-Id: To: FreeBSD current mailing list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 21:29:22 -0000 Hi, why do we send all these empty headings for periodic emails or given = there is no output to this one can we 1) suppress the empty sections (to me that sounds a bit like a wrong return code or something maybe?), and 2) add an option to suppress "empty" periodic emails entirely? Sample: ------- Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: /etc/group is fine Security check: (output mailed separately) Checking for denied zone transfers (AXFR and IXFR): -- End of daily output -- ------- I'd also like to get the hostname out of the headings of the security = emails if possible. It's in the Subject:. There's no need to have each = section header starting differently. I understand that it would be a POLA problem = given a lot of people parse these emails automatically so adding an option for that = would be ok with me as well. Any takers? /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 21:45:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3783106566C; Mon, 2 Jan 2012 21:45:49 +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 52E388FC27; Mon, 2 Jan 2012 21:45:48 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q02LjRG6030143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 23:45:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id q02LjR9K037665; Mon, 2 Jan 2012 23:45:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id q02LjRFp037664; Mon, 2 Jan 2012 23:45:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jan 2012 23:45:27 +0200 From: Kostik Belousov To: Don Lewis Message-ID: <20120102214527.GJ50300@deviant.kiev.zoral.com.ua> References: <4F01F8FD.4020901@FreeBSD.org> <201201022047.q02Kl3IM005792@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KV5J30b1nBuIoEpe" Content-Disposition: inline In-Reply-To: <201201022047.q02Kl3IM005792@gw.catspoiler.org> 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=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: mckusick@mckusick.com, flo@freebsd.org, current@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, kib@freebsd.org, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 21:45:49 -0000 --KV5J30b1nBuIoEpe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 02, 2012 at 12:47:03PM -0800, Don Lewis wrote: > On 2 Jan, Florian Smeets wrote: > > On 29.12.11 01:04, Kirk McKusick wrote: > >> Rather than changing BKVASIZE, I would try running the cvs2svn > >> conversion on a 16K/2K filesystem and see if that sorts out the > >> problem. If it does, it tells us that doubling the main block > >> size and reducing the number of buffers by half is the problem. > >> If that is the problem, then we will have to increase the KVM > >> allocated to the buffer cache. > >>=20 > >=20 > > This does not make a difference. I tried on 32K/4K with/without journal > > and on 16K/2K all exhibit the same problem. At some point during the > > cvs2svn conversion the sycer starts to use 100% CPU. The whole process > > hangs at that point sometimes for hours, from time to time it does > > continue doing some work, but really really slow. It's usually between > > revision 210000 and 220000, when the resulting svn file gets bigger than > > about 11-12Gb. At that point an ls in the target dir hangs in state ufs. > >=20 > > I broke into ddb and ran all commands which i thought could be useful. > > The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt >=20 > Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000 > cpustop_handler() at cpustop_handler+0x2b > ipi_nmi_handler() at ipi_nmi_handler+0x50 > trap() at trap+0x1a8 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip =3D 0xffffffff8082ba43, rsp =3D 0xffffff8000270fe0, rb= p =3D 0xffffff88c97829a0 --- > _mtx_assert() at _mtx_assert+0x13 > pmap_remove_write() at pmap_remove_write+0x38 > vm_object_page_remove_write() at vm_object_page_remove_write+0x1f > vm_object_page_clean() at vm_object_page_clean+0x14d > vfs_msync() at vfs_msync+0xf1 > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x135 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff88c9782d00, rbp =3D 0 --- >=20 > I thinks this explains why the r228838 patch seems to help the problem. > Instead of an application call to msync(), you're getting bitten by the > syncer doing the equivalent. I don't know why the syncer is CPU bound, > though. From my understanding of the patch it only optimizes the I/O. > Without the patch, I would expect that the syncer would just spend a lot > of time waiting on I/O. My guess is that this is actually a vm problem. > There are nested loops in vm_object_page_clean() and > vm_object_page_remove_write(), so you could be doing something that's > causing lots of looping in that code. r228838 allows the system to skip 50-70% of the code when initiating a write of the UFS file page, due to async clustering. The system has to maintain 75% less amount of writes in progress. > I think that ls is hanging because it's stumbling across the vnode that > the syncer has locked. This is the only reasonable explanation. Low-tech profile is to periodically break out into ddb and do backtrace for the syncer thread. More advanced techniques is to use dtrace or normal profiling. --KV5J30b1nBuIoEpe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8CJXYACgkQC3+MBN1Mb4hAhwCgnXR4RBhr8tclLUzeF3NYg/OX PRkAnjqHmH2duLg7tqvS/llmmjzaI2nb =VUIS -----END PGP SIGNATURE----- --KV5J30b1nBuIoEpe-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 22:04:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D0F106566B for ; Mon, 2 Jan 2012 22:04:37 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 71F248FC0C for ; Mon, 2 Jan 2012 22:04:37 +0000 (UTC) Received: from msx3.exchange.alogis.com (msx3exchange.alogis.com [10.1.1.6] (may be forged)) by alogis.com (8.13.4/8.13.1) with ESMTP id q02Lriie089780; Mon, 2 Jan 2012 22:53:44 +0100 (CET) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Mon, 2 Jan 2012 22:56:02 +0100 From: Holger Kipp To: "Bjoern A. Zeeb" Thread-Topic: periodic emails Thread-Index: AQHMyZYxfBayyzNstUKHi56Dip3MhJX5n3aD Date: Mon, 2 Jan 2012 21:56:01 +0000 Message-ID: <0EA6967F-258E-45E3-B00B-1646A8A9E909@alogis.com> References: In-Reply-To: Accept-Language: en-GB, de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:04:38 -0000 Hi, Am 02.01.2012 um 22:33 schrieb "Bjoern A. Zeeb" : > why do we send all these empty headings for periodic emails It contains the info what has been done, so you know that the jobs have bee= n performed correctly. If it does not contain the section headings, the job= s might not have been run at all. I like it the way it is... exactly for this reason Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 22:14:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACD2F106564A for ; Mon, 2 Jan 2012 22:14:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2408FC0C for ; Mon, 2 Jan 2012 22:14:36 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so18013874obb.13 for ; Mon, 02 Jan 2012 14:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Be41hgelLzfHjg/s52YPsulclO9JH+vOjtMjrk0UzKU=; b=HweUJMiVp08t7/UuQU4zq8iFtJslPHhj4vog8DPa5AKk1GCHwIrJpfZky2xFNG8xSZ 3l6pCc3Zd4GG2CUcll+83LiTmPnlGIoTTyzCDGe+omOCrJaxPzAz9G+WY9L5hj4UaFaR MnkCavYZMgXp+ApjLFXO5pqRN4WMwYGz11EG8= MIME-Version: 1.0 Received: by 10.182.1.67 with SMTP id 3mr43030125obk.31.1325542475771; Mon, 02 Jan 2012 14:14:35 -0800 (PST) Received: by 10.182.152.6 with HTTP; Mon, 2 Jan 2012 14:14:35 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Jan 2012 14:14:35 -0800 Message-ID: From: Garrett Cooper To: "Bjoern A. Zeeb" Content-Type: multipart/mixed; boundary=f46d044469e7672daa04b592e822 Cc: FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:14:36 -0000 --f46d044469e7672daa04b592e822 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 2, 2012 at 1:29 PM, Bjoern A. Zeeb wrote: > Hi, > > why do we send all these empty headings for periodic emails or given ther= e is > no output to this one can we > > 1) suppress the empty sections (to me that sounds a bit like a wrong > =A0 return code or something maybe?), and > 2) add an option to suppress "empty" periodic emails entirely? > > Sample: > ------- > Removing stale files from /var/preserve: > > Cleaning out old system announcements: > > Removing stale files from /var/rwho: > > Backup passwd and group files: > > Verifying group file syntax: > /etc/group is fine > > Security check: > =A0 (output mailed separately) > > Checking for denied zone transfers (AXFR and IXFR): > > -- End of daily output -- > ------- > > > I'd also like to get the hostname out of the headings of the security ema= ils > if possible. =A0It's in the Subject:. =A0There's no need to have each sec= tion header > starting differently. =A0I understand that it would be a POLA problem giv= en a lot > of people parse these emails automatically so adding an option for that w= ould be > ok with me as well. > > Any takers? How does this look for starters? The attached patch's goal is to provide a generic, rc(5)-like infrastructure that would quiet down the periodic emails for 120.clean-preserve . Thanks, -Garrett --f46d044469e7672daa04b592e822 Content-Type: application/octet-stream; name="quiet-periodic-mail-noise-v01.patch" Content-Disposition: attachment; filename="quiet-periodic-mail-noise-v01.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gwy1q7kn1 SW5kZXg6IGV0Yy9wZXJpb2RpYy5zdWJyCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy5zdWJy CShyZXZpc2lvbiAwKQorKysgZXRjL3BlcmlvZGljLnN1YnIJKHdvcmtpbmcgY29weSkKQEAgLTAs MCArMSwxMDUgQEAKKyMgJEZyZWVCU0QkCisjCisjIENvcHlyaWdodCAoYykgMTk5Ny0yMDA0IFRo ZSBGcmVlQlNEIEZvdW5kYXRpb24sIEluYy4KKyMgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyMKKyMg UmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBv ciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRo ZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0OgorIyAxLiBSZWRpc3RyaWJ1dGlvbnMg b2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorIyAgICBub3Rp Y2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIu CisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUg YWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyMgICAgZG9jdW1lbnRhdGlvbiBhbmQv b3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyMKKyMg VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgRlJFRUJTRCBGT1VOREFUSU9OLCBJTkMu IEFORCBDT05UUklCVVRPUlMKKyMgYGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVE IFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVECisjIFRPLCBUSEUgSU1QTElF RCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSCisjIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgRk9V TkRBVElPTiBPUiBDT05UUklCVVRPUlMKKyMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJ UkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorIyBDT05TRVFVRU5USUFM IERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRgor IyBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJP RklUUzsgT1IgQlVTSU5FU1MKKyMgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04g QU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4KKyMgQ09OVFJBQ1QsIFNUUklDVCBM SUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkKKyMg QVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4g SUYgQURWSVNFRCBPRiBUSEUKKyMgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisjCisjIHBl cmlvZGljLnN1YnIKKyMJZnVuY3Rpb25zIHVzZWQgYnkgcGVyaW9kaWMoNSkgc2NyaXB0cworIwor IwlNYW55IG9mIHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25zIHdlcmUgZ3JhYmJlZCB3aG9sZXNhbGUg ZnJvbSByYy5zdWJyLgorIworCisjCisjIGNoZWNreWVzbm8gdmFyCisjCVRlc3QgJDEgdmFyaWFi bGUsIGFuZCB3YXJuIGlmIG5vdCBzZXQgdG8gWUVTIG9yIE5PLgorIwlSZXR1cm4gMCBpZiBpdCdz ICJ5ZXMiIChldCBhbCksIG5vbnplcm8gb3RoZXJ3aXNlLgorIworY2hlY2t5ZXNubygpCit7CisJ ZXZhbCBfdmFsdWU9XCQkezF9CisJZGVidWcgImNoZWNreWVzbm86ICQxIGlzIHNldCB0byAkX3Zh bHVlLiIKKwljYXNlICRfdmFsdWUgaW4KKworCQkjCSJ5ZXMiLCAidHJ1ZSIsICJvbiIsIG9yICIx IgorCVtZeV1bRWVdW1NzXXxbVHRdW1JyXVtVdV1bRWVdfFtPb11bTm5dfDEpCisJCXJldHVybiAw CisJCTs7CisKKwkJIwkibm8iLCAiZmFsc2UiLCAib2ZmIiwgb3IgIjAiCisJW05uXVtPb118W0Zm XVtBYV1bTGxdW1NzXVtFZV18W09vXVtGZl1bRmZdfDApCisJCXJldHVybiAxCisJCTs7CisJKikK KwkJd2FybiAiXCQkezF9IGlzIG5vdCBzZXQgcHJvcGVybHkgLSBzZWUgJHtyY3Zhcl9tYW5wYWdl fS4iCisJCXJldHVybiAxCisJCTs7CisJZXNhYworfQorCisjCisjIGRlYnVnIG1lc3NhZ2UKKyMJ SWYgZGVidWdnaW5nIGlzIGVuYWJsZWQgaW4gcmMuY29uZiBvdXRwdXQgbWVzc2FnZSB0byBzdGRl cnIuCisjCUJFV0FSRSB0aGF0IHlvdSBkb24ndCBjYWxsIGFueSBzdWJyb3V0aW5lIHRoYXQgaXRz ZWxmIGNhbGxzIHRoaXMKKyMJZnVuY3Rpb24uCisjCitkZWJ1ZygpCit7CisJY2FzZSAke3Blcmlv ZGljX2RlYnVnfSBpbgorCVtZeV1bRWVdW1NzXXxbVHRdW1JyXVtVdV1bRWVdfFtPb11bTm5dfDEp CisJCWlmIFsgLXggL3Vzci9iaW4vbG9nZ2VyIF07IHRoZW4KKwkJCWxvZ2dlciAiJDA6IERFQlVH OiAkKiIKKwkJZmkKKwkJZWNobyAxPiYyICIkMDogREVCVUc6ICQqIgorCQk7OworCWVzYWMKK30K KworIworIyBlcnIgZXhpdHZhbCBtZXNzYWdlCisjCURpc3BsYXkgbWVzc2FnZSB0byBzdGRlcnIg YW5kIGxvZyB0byB0aGUgc3lzbG9nLCBhbmQgZXhpdCB3aXRoIGV4aXR2YWwuCisjCitlcnIoKQor eworCWV4aXR2YWw9JDEKKwlzaGlmdAorCisJaWYgWyAteCAvdXNyL2Jpbi9sb2dnZXIgXTsgdGhl bgorCQlsb2dnZXIgIiQwOiBFUlJPUjogJCoiCisJZmkKKwllY2hvIDE+JjIgIiQwOiBFUlJPUjog JCoiCisJZXhpdCAkZXhpdHZhbAorfQorCisjCisjIHdhcm4gbWVzc2FnZQorIwlEaXNwbGF5IG1l c3NhZ2UgdG8gc3RkZXJyIGFuZCBsb2cgdG8gdGhlIHN5c2xvZy4KKyMKK3dhcm4oKQoreworCWlm IFsgLXggL3Vzci9iaW4vbG9nZ2VyIF07IHRoZW4KKwkJbG9nZ2VyICIkMDogV0FSTklORzogJCoi CisJZmkKKwllY2hvIDE+JjIgIiQwOiBXQVJOSU5HOiAkKiIKK30KKwoKUHJvcGVydHkgY2hhbmdl cyBvbjogZXRjL3BlcmlvZGljLnN1YnIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBZGRlZDogc3ZuOmV4ZWN1dGFibGUK IyMgLTAsMCArMSAjIworKgpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzEyMC5jbGVhbi1wcmVz ZXJ2ZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvMTIwLmNsZWFuLXByZXNlcnZl CShyZXZpc2lvbiAyMjkzMTYpCisrKyBldGMvcGVyaW9kaWMvZGFpbHkvMTIwLmNsZWFuLXByZXNl cnZlCSh3b3JraW5nIGNvcHkpCkBAIC01LDYgKzUsOCBAQAogIyBSZW1vdmUgc3RhbGUgZmlsZXMg aW4gL3Zhci9wcmVzZXJ2ZQogIwogCisuIC9ldGMvcGVyaW9kaWMuc3VicgorCiAjIElmIHRoZXJl IGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCiAjCiBp ZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCkBAIC0xMywzMSArMTUsMzAgQEAK ICAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKIGZpCiAKLWNhc2UgIiRkYWlseV9jbGVhbl9wcmVz ZXJ2ZV9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQoraWYgY2hlY2t5ZXNubyBkYWlseV9j bGVhbl9wcmVzZXJ2ZV9lbmFibGU7IHRoZW4KKwlyYz0wCiAJaWYgWyAteiAiJGRhaWx5X2NsZWFu X3ByZXNlcnZlX2RheXMiIF0KIAl0aGVuCi0JICAgIGVjaG8gJyRkYWlseV9jbGVhbl9wcmVzZXJ2 ZV9lbmFibGUgaXMgc2V0IGJ1dCcgXAorCSAgICBlcnIgMiAnJGRhaWx5X2NsZWFuX3ByZXNlcnZl X2VuYWJsZSBpcyBzZXQgYnV0JyBcCiAJCSckZGFpbHlfY2xlYW5fcHJlc2VydmVfZGF5cyBpcyBu b3QnCi0JICAgIHJjPTIKIAllbGlmIFsgISAtZCAvdmFyL3ByZXNlcnZlIF0KIAl0aGVuCi0JICAg IGVjaG8gJyRkYWlseV9jbGVhbl9wcmVzZXJ2ZV9lbmFibGUgaXMgc2V0IGJ1dCAvdmFyL3ByZXNl cnZlJyBcCisJICAgIGVyciAyICckZGFpbHlfY2xlYW5fcHJlc2VydmVfZW5hYmxlIGlzIHNldCBi dXQgL3Zhci9wcmVzZXJ2ZScgXAogCQkiZG9lc24ndCBleGlzdCIKLQkgICAgcmM9MgogCWVsc2UK LQkgICAgZWNobyAiIgotCSAgICBlY2hvICJSZW1vdmluZyBzdGFsZSBmaWxlcyBmcm9tIC92YXIv cHJlc2VydmU6IgogCisJICAgIGlmIGNoZWNreWVzbm8gZGFpbHlfY2xlYW5fcHJlc2VydmVfdmVy Ym9zZTsgdGhlbgorCQllY2hvICIiCisJCWVjaG8gIlJlbW92aW5nIHN0YWxlIGZpbGVzIGZyb20g L3Zhci9wcmVzZXJ2ZToiCisJICAgIGZpCisKIAkgICAgaWYgY2QgL3Zhci9wcmVzZXJ2ZQogCSAg ICB0aGVuCi0JCWNhc2UgIiRkYWlseV9jbGVhbl9wcmVzZXJ2ZV92ZXJib3NlIiBpbgotCQkgICAg W1l5XVtFZV1bU3NdKQorCQlpZiBjaGVja3llc25vIGRhaWx5X2NsZWFuX3ByZXNlcnZlX3ZlcmJv c2U7IHRoZW4KIAkJCXByaW50PS1wcmludDs7Ci0JCSAgICAqKQorCQllbHNlCiAJCQlwcmludD07 OwotCQllc2FjCi0KKwkJZmkKIAkJcmM9JChmaW5kIC4gISAtbmFtZSAuIC1tdGltZSArJGRhaWx5 X2NsZWFuX3ByZXNlcnZlX2RheXMgXAogCQkgICAgLWRlbGV0ZSAkcHJpbnQgfCB0ZWUgL2Rldi9z dGRlcnIgfCB3YyAtbCkKIAkJWyAteiAiJHByaW50IiBdICYmIHJjPTAKQEAgLTQ1LDkgKzQ2LDcg QEAKIAkgICAgZWxzZQogCQlyYz0zCiAJICAgIGZpCi0JZmk7OworCWZpCitmaQogCi0gICAgKikg IHJjPTA7OwotZXNhYwotCiBleGl0ICRyYwo= --f46d044469e7672daa04b592e822-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 22:15:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15421065673 for ; Mon, 2 Jan 2012 22:15:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 682A88FC18 for ; Mon, 2 Jan 2012 22:15:16 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so18014185obb.13 for ; Mon, 02 Jan 2012 14:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6nNwn9AE5oqBt0x8Ts79Zcxqc5JxU5HaQmqIB2/DfyI=; b=iVqDN+CU6r64urkZ31RarWDWcR3UikYeGR1QIdrsQTPhQU8LvZeeiTJQYaJelv12mb w/bCDuoOps1Q1tsQiSTglYHJDJrDtrdMCQSk4kXAakDT9D7UqqaYPhHp+h9zFyjJZ/h9 eaaFhJ1WlwV1Mq5R/PL7aWXNztS7krc51eeX8= MIME-Version: 1.0 Received: by 10.182.187.37 with SMTP id fp5mr17888834obc.21.1325542516716; Mon, 02 Jan 2012 14:15:16 -0800 (PST) Received: by 10.182.152.6 with HTTP; Mon, 2 Jan 2012 14:15:16 -0800 (PST) In-Reply-To: <0EA6967F-258E-45E3-B00B-1646A8A9E909@alogis.com> References: <0EA6967F-258E-45E3-B00B-1646A8A9E909@alogis.com> Date: Mon, 2 Jan 2012 14:15:16 -0800 Message-ID: From: Garrett Cooper To: Holger Kipp Content-Type: text/plain; charset=ISO-8859-1 Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:15:17 -0000 On Mon, Jan 2, 2012 at 1:56 PM, Holger Kipp wrote: > Hi, > > Am 02.01.2012 um 22:33 schrieb "Bjoern A. Zeeb" : > >> why do we send all these empty headings for periodic emails > > It contains the info what has been done, so you know that the jobs have been performed correctly. If it does not contain the section headings, the jobs might not have been run at all. > > I like it the way it is... exactly for this reason Perhaps, and that's fine as the default, but the problem is that the periodic scripts aren't completely honoring the _verbose flags assigned to them. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 22:45:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3E1E71065670 for ; Mon, 2 Jan 2012 22:45:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2837014DFEA; Mon, 2 Jan 2012 22:45:27 +0000 (UTC) Message-ID: <4F023387.1060300@FreeBSD.org> Date: Mon, 02 Jan 2012 14:45:27 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:45:29 -0000 On 01/02/2012 14:14, Garrett Cooper wrote: > How does this look for starters? The attached patch's goal is to > provide a generic, rc(5)-like infrastructure that would quiet down the > periodic emails for 120.clean-preserve . The periodic scripts are badly in need of attention, so effort in that area is much appreciated. Regarding your patch, rather than copying functions from rc.subr, why not just source it? Yes, you will get more than you need, but I think that the virtue of not having to maintain the same code in 2 places far outweighs that minor drawback. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 22:49:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F491065672; Mon, 2 Jan 2012 22:49:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 40C668FC0C; Mon, 2 Jan 2012 22:49:32 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so18031323obb.13 for ; Mon, 02 Jan 2012 14:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FvE/fGhT4sxQhIS5hwF1e33CWu63mM1Y579+hexJkIA=; b=ApRcaRj/Dh1V1NEHs3IJaGYF95OXp6MHu+z4/1z2fuHRqjQ/aatq/b4XrRfpE2z4nE BOR7zY2GsMSUr444oX49pnQiz8q2vCbrttGMTwoFx840/9Zp4dupKxAcZf/Ql/vIqEfD kQDUzGIKIfesrWSF0DHsfEDnIFi3SAVTc4W7w= MIME-Version: 1.0 Received: by 10.182.193.99 with SMTP id hn3mr42673517obc.61.1325544571906; Mon, 02 Jan 2012 14:49:31 -0800 (PST) Received: by 10.182.152.6 with HTTP; Mon, 2 Jan 2012 14:49:31 -0800 (PST) In-Reply-To: <4F023387.1060300@FreeBSD.org> References: <4F023387.1060300@FreeBSD.org> Date: Mon, 2 Jan 2012 14:49:31 -0800 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:49:32 -0000 On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton wrote: > On 01/02/2012 14:14, Garrett Cooper wrote: > >> =A0 =A0 How does this look for starters? The attached patch's goal is to >> provide a generic, rc(5)-like infrastructure that would quiet down the >> periodic emails for 120.clean-preserve . > > The periodic scripts are badly in need of attention, so effort in that > area is much appreciated. > > Regarding your patch, rather than copying functions from rc.subr, why > not just source it? Yes, you will get more than you need, but I think > that the virtue of not having to maintain the same code in 2 places far > outweighs that minor drawback. That works too, assuming that rc.subr isn't too rc(5) centric. Thanks for the feedback! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 22:51:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 841F51065672 for ; Mon, 2 Jan 2012 22:51:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 145DD15F110; Mon, 2 Jan 2012 22:51:57 +0000 (UTC) Message-ID: <4F02350D.2050500@FreeBSD.org> Date: Mon, 02 Jan 2012 14:51:57 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Garrett Cooper References: <4F023387.1060300@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:51:59 -0000 On 01/02/2012 14:49, Garrett Cooper wrote: > On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton wrote: >> On 01/02/2012 14:14, Garrett Cooper wrote: >> >>> How does this look for starters? The attached patch's goal is to >>> provide a generic, rc(5)-like infrastructure that would quiet down the >>> periodic emails for 120.clean-preserve . >> >> The periodic scripts are badly in need of attention, so effort in that >> area is much appreciated. >> >> Regarding your patch, rather than copying functions from rc.subr, why >> not just source it? Yes, you will get more than you need, but I think >> that the virtue of not having to maintain the same code in 2 places far >> outweighs that minor drawback. > > That works too, assuming that rc.subr isn't too rc(5) centric. Well of course it's rc-centric, but that's not the point. :) If you're going to be using the exact same code from rc.subr, you might as well just source it. The things that you'll get by doing that which are only relevant to rc you just ignore. > Thanks for the feedback! Glad to help. -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:01:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C73721065670; Mon, 2 Jan 2012 23:01:41 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 7093E8FC0A; Mon, 2 Jan 2012 23:01:41 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 516F625D3810; Mon, 2 Jan 2012 23:01:40 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 703C9BD8585; Mon, 2 Jan 2012 23:01:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 3-Roi1seXu+u; Mon, 2 Jan 2012 23:01:38 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0B385BD8584; Mon, 2 Jan 2012 23:01:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F02350D.2050500@FreeBSD.org> Date: Mon, 2 Jan 2012 23:01:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: Garrett Cooper , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:01:42 -0000 On 2. Jan 2012, at 22:51 , Doug Barton wrote: > On 01/02/2012 14:49, Garrett Cooper wrote: >> On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton = wrote: >>> On 01/02/2012 14:14, Garrett Cooper wrote: >>>=20 >>>> How does this look for starters? The attached patch's goal is to >>>> provide a generic, rc(5)-like infrastructure that would quiet down = the >>>> periodic emails for 120.clean-preserve . >>>=20 >>> The periodic scripts are badly in need of attention, so effort in = that >>> area is much appreciated. >>>=20 >>> Regarding your patch, rather than copying functions from rc.subr, = why >>> not just source it? Yes, you will get more than you need, but I = think >>> that the virtue of not having to maintain the same code in 2 places = far >>> outweighs that minor drawback. >>=20 >> That works too, assuming that rc.subr isn't too rc(5) centric. >=20 > Well of course it's rc-centric, but that's not the point. :) If = you're > going to be using the exact same code from rc.subr, you might as well > just source it. The things that you'll get by doing that which are = only > relevant to rc you just ignore. >=20 >> Thanks for the feedback! >=20 > Glad to help. While the checkyesno code for sure is great to handle all these options everywhere and doing some serious cleanup sweep. I am all in favour of = this. But isn't the real problem here deferring the output of the header = depending on the other output or even just the correct exit code? Looking at periodic(8) it says: Each script is required to exit with one of the following values: 0 The script has produced nothing notable in its output. The _show_success variable controls the masking of this = out- put. 1 The script has produced some notable information in its = output. The _show_info variable controls the masking of this = out- put. 2 The script has produced some warnings due to invalid = configuration settings. The _show_badconfig variable controls the = mask- ing of this output. >2 The script has produced output that must not be masked. Could it even be that if setting the correct "*_show_*" config option could do the right thing for me already? I have no clue how that = "masking" is done and in which category "has not produced any output but the heading" would fall into and if other things would possibly be hidden as well? /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:04:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 872DB106566C for ; Mon, 2 Jan 2012 23:04:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 38E9D8FC21 for ; Mon, 2 Jan 2012 23:04:43 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4ABEF25D3810; Mon, 2 Jan 2012 23:04:42 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 818FDBD8584; Mon, 2 Jan 2012 23:04:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id UtuQtsLUDN-k; Mon, 2 Jan 2012 23:04:40 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 8CACCBD8585; Mon, 2 Jan 2012 23:04:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <0EA6967F-258E-45E3-B00B-1646A8A9E909@alogis.com> Date: Mon, 2 Jan 2012 23:04:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4D5C13D5-4911-4E9B-8B67-568C7DCF835F@lists.zabbadoz.net> References: <0EA6967F-258E-45E3-B00B-1646A8A9E909@alogis.com> To: Holger Kipp X-Mailer: Apple Mail (2.1084) Cc: FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:04:43 -0000 On 2. Jan 2012, at 21:56 , Holger Kipp wrote: > Am 02.01.2012 um 22:33 schrieb "Bjoern A. Zeeb" = : >=20 >> why do we send all these empty headings for periodic emails >=20 > It contains the info what has been done, so you know that the jobs = have been performed correctly. If it does not contain the section = headings, the jobs might not have been run at all. >=20 > I like it the way it is... exactly for this reason Yeah, that's why I asked for "knobs". I don't want these daily emails. I am fine if in that case I'll get the weekly summary or something long these lines. I always assume that on error cron or the scripts will spam me anyway. But I don't need the electrons wasted to handle the email, the TLS, and delivery, the storage and the time to skip them every day if they have nothing to say;-) /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!= From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:09:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 84E20106566C for ; Mon, 2 Jan 2012 23:09:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id CD8CD14F0A8; Mon, 2 Jan 2012 23:09:02 +0000 (UTC) Message-ID: <4F02390E.4080303@FreeBSD.org> Date: Mon, 02 Jan 2012 15:09:02 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:09:03 -0000 On 01/02/2012 15:01, Bjoern A. Zeeb wrote: > Looking at periodic(8) it says: > > Each script is required to exit with one of the following values: > > 0 The script has produced nothing notable in its output. The > _show_success variable controls the masking of this out- > put. > > 1 The script has produced some notable information in its output. > The _show_info variable controls the masking of this out- > put. > > 2 The script has produced some warnings due to invalid configuration > settings. The _show_badconfig variable controls the mask- > ing of this output. > > >2 The script has produced output that must not be masked. > > > Could it even be that if setting the correct "*_show_*" config option > could do the right thing for me already? I have no clue how that "masking" is > done and in which category "has not produced any output but the heading" > would fall into and if other things would possibly be hidden as well? I'm not sure which problem you're trying to solve. Are you trying to solve the problem of "scripts that are enabled but don't have any output other than the header should not output anything at all?" If so, then yes, then *_show_success="NO" is likely what you're after. I assumed from your OP that you were trying to solve a different problem, but it's starting to seem like I read it wrong. Can you clarify? Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:10:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8678C1065690; Mon, 2 Jan 2012 23:10:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A17F8FC18; Mon, 2 Jan 2012 23:10:46 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so18041435obb.13 for ; Mon, 02 Jan 2012 15:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BhbHyazb6TIYE8czVx03iFK9prk0zvnQ4R+QsQOAlgw=; b=htC7BgSeFuGsh8zwqzJzBiAKcp/o1SABbHBk3oXbW/uXGdTUQIxMsX6eBJlUZ1XdT1 /JYA2bjjiUrDwlvQDME/VuwDW6RfVdUFrsT4cICwu50cRqEB3srAuikFkcDLdW4sUV3Z 9QHX24CIaM+/7VJ9bMIMlUjYBd1im4rvyCSlg= MIME-Version: 1.0 Received: by 10.182.187.37 with SMTP id fp5mr17988195obc.21.1325545845749; Mon, 02 Jan 2012 15:10:45 -0800 (PST) Received: by 10.182.152.6 with HTTP; Mon, 2 Jan 2012 15:10:45 -0800 (PST) In-Reply-To: <4F02390E.4080303@FreeBSD.org> References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> <4F02390E.4080303@FreeBSD.org> Date: Mon, 2 Jan 2012 15:10:45 -0800 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:10:46 -0000 On Mon, Jan 2, 2012 at 3:09 PM, Doug Barton wrote: > On 01/02/2012 15:01, Bjoern A. Zeeb wrote: >> Looking at periodic(8) it says: >> >> =A0 =A0 =A0Each script is required to exit with one of the following val= ues: >> >> =A0 =A0 =A00 =A0 =A0 The script has produced nothing notable in its outp= ut. =A0The >> =A0 =A0 =A0 =A0 =A0 =A0_show_success variable controls the mask= ing of this out- >> =A0 =A0 =A0 =A0 =A0 =A0put. >> >> =A0 =A0 =A01 =A0 =A0 The script has produced some notable information in= its output. >> =A0 =A0 =A0 =A0 =A0 =A0The _show_info variable controls the mas= king of this out- >> =A0 =A0 =A0 =A0 =A0 =A0put. >> >> =A0 =A0 =A02 =A0 =A0 The script has produced some warnings due to invali= d configuration >> =A0 =A0 =A0 =A0 =A0 =A0settings. =A0The _show_badconfig variabl= e controls the mask- >> =A0 =A0 =A0 =A0 =A0 =A0ing of this output. >> >> =A0 =A0 =A0>2 =A0 =A0The script has produced output that must not be mas= ked. >> >> >> Could it even be that if setting the correct "*_show_*" config option >> could do the right thing for me already? =A0I have no clue how that "mas= king" is >> done and in which category "has not produced any output but the heading" >> would fall into and if other things would possibly be hidden as well? > > I'm not sure which problem you're trying to solve. Are you trying to > solve the problem of "scripts that are enabled but don't have any output > other than the header should not output anything at all?" =A0If so, then > yes, then *_show_success=3D"NO" is likely what you're after. > > I assumed from your OP that you were trying to solve a different > problem, but it's starting to seem like I read it wrong. Can you clarify? Looking at the scripts, there are bugs where all of the beforementioned scripts would always be mute (because rc=3D0 is explicitly set at the bottom), unless _show_success was set to YES. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:21:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3BDC0106564A for ; Mon, 2 Jan 2012 23:21:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 40E891558BE; Mon, 2 Jan 2012 23:21:03 +0000 (UTC) Message-ID: <4F023BDE.9090606@FreeBSD.org> Date: Mon, 02 Jan 2012 15:21:02 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Garrett Cooper References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> <4F02390E.4080303@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:21:15 -0000 On 01/02/2012 15:10, Garrett Cooper wrote: > Looking at the scripts, there are bugs where all of the > beforementioned scripts would always be mute (because rc=0 is > explicitly set at the bottom), unless _show_success was set to YES. Take a look at /etc/defaults/periodic.conf -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:26:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B29D106566B; Mon, 2 Jan 2012 23:26:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 348518FC0A; Mon, 2 Jan 2012 23:26:15 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5E5B125D385D; Mon, 2 Jan 2012 23:26:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8CCEDBD8588; Mon, 2 Jan 2012 23:26:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 6eYMOcmS2p5L; Mon, 2 Jan 2012 23:26:12 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2F209BD8587; Mon, 2 Jan 2012 23:26:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F02390E.4080303@FreeBSD.org> Date: Mon, 2 Jan 2012 23:26:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <253A49B1-3711-4B16-8569-E445E234A834@lists.zabbadoz.net> References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> <4F02390E.4080303@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: Garrett Cooper , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:26:15 -0000 On 2. Jan 2012, at 23:09 , Doug Barton wrote: > On 01/02/2012 15:01, Bjoern A. Zeeb wrote: >> Looking at periodic(8) it says: >>=20 >> Each script is required to exit with one of the following values: >>=20 >> 0 The script has produced nothing notable in its output. The >> _show_success variable controls the masking of = this out- >> put. >>=20 >> 1 The script has produced some notable information in its = output. >> The _show_info variable controls the masking of = this out- >> put. >>=20 >> 2 The script has produced some warnings due to invalid = configuration >> settings. The _show_badconfig variable controls = the mask- >> ing of this output. >>=20 >>> 2 The script has produced output that must not be masked. >>=20 >>=20 >> Could it even be that if setting the correct "*_show_*" config option >> could do the right thing for me already? I have no clue how that = "masking" is >> done and in which category "has not produced any output but the = heading" >> would fall into and if other things would possibly be hidden as well? >=20 > I'm not sure which problem you're trying to solve. Are you trying to > solve the problem of "scripts that are enabled but don't have any = output > other than the header should not output anything at all?" If so, then > yes, then *_show_success=3D"NO" is likely what you're after. >=20 > I assumed from your OP that you were trying to solve a different > problem, but it's starting to seem like I read it wrong. Can you = clarify? How did you read it? The follow-up thing is "if the email is empty, don't send it". The problem I have with the description is that "nothing notable" !=3D = "nothing" or "nothing but the header" in my view. I read it as "there was output beyond the heading". /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 00:03:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8D0106566B for ; Tue, 3 Jan 2012 00:03:08 +0000 (UTC) (envelope-from kob6558@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 D73C78FC12 for ; Tue, 3 Jan 2012 00:03:07 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so26926954wgb.31 for ; Mon, 02 Jan 2012 16:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nko5AsP+dUQv2NhQrgHvE9syBCnc6JLmwa3fVDhQ4t8=; b=mYLqD97jtdYitXpL8PUjIsyhMYXhi+FyyF6i9n9dFC7yoE932dgfrw/n113Au47n8L xjvIix2j0cuCDwISWYsrpfbOV/eqZtTSsSGrBwxMPAjVKWrXu005A9vIvGvLaoLfGVvG ayeKSpulIo0nTaWaWEmWri8JqgeS7drGqPAZI= MIME-Version: 1.0 Received: by 10.227.60.78 with SMTP id o14mr49323899wbh.9.1325548986843; Mon, 02 Jan 2012 16:03:06 -0800 (PST) Received: by 10.223.158.129 with HTTP; Mon, 2 Jan 2012 16:03:06 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Jan 2012 16:03:06 -0800 Message-ID: From: Kevin Oberman To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 00:03:08 -0000 On Mon, Jan 2, 2012 at 1:29 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > Hi, > > why do we send all these empty headings for periodic emails or given there > is > no output to this one can we > > 1) suppress the empty sections (to me that sounds a bit like a wrong > return code or something maybe?), and > 2) add an option to suppress "empty" periodic emails entirely? > > Sample: > ------- > Removing stale files from /var/preserve: > > Cleaning out old system announcements: > > Removing stale files from /var/rwho: > > Backup passwd and group files: > > Verifying group file syntax: > /etc/group is fine > > Security check: > (output mailed separately) > > Checking for denied zone transfers (AXFR and IXFR): > > -- End of daily output -- > ------- > > > I'd also like to get the hostname out of the headings of the security > emails > if possible. It's in the Subject:. There's no need to have each section > header > starting differently. I understand that it would be a POLA problem given > a lot > of people parse these emails automatically so adding an option for that > would be > ok with me as well. > > Any takers? > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you do! > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Please don't! The headers with no entries confirm that the check has been run. I really don't care about the hostnames, but the POLA issue makes me seriously question whther it is worth doing. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 01:13:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55FB1106566B for ; Tue, 3 Jan 2012 01:13:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A81F8FC1A for ; Tue, 3 Jan 2012 01:13:07 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so18095341obb.13 for ; Mon, 02 Jan 2012 17:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oPkMKqRd3C6rcuU1cMVjs8YpYrVSRuk/+lDr1SLhxxs=; b=Lu0HR979L4dZNNt2QxljYh4hrtypgGIqNGon+XZazdBGFhlDty12UnET8X7ab5CidU HrmKpVOFt+YJj0caBxONfQ0JldOSdY/7akHXSlXSoJZ6UoNPGUL4A/ZiQNB+5hlEZJaL +VAufW+vLFdh99wRPUqyM7cKjLPRVE4hNk69Y= MIME-Version: 1.0 Received: by 10.182.51.37 with SMTP id h5mr42923649obo.51.1325553186731; Mon, 02 Jan 2012 17:13:06 -0800 (PST) Received: by 10.182.152.6 with HTTP; Mon, 2 Jan 2012 17:13:06 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Jan 2012 17:13:06 -0800 Message-ID: From: Garrett Cooper To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 01:13:08 -0000 On Mon, Jan 2, 2012 at 4:03 PM, Kevin Oberman wrote: > On Mon, Jan 2, 2012 at 1:29 PM, Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> Hi, >> >> why do we send all these empty headings for periodic emails or given the= re >> is >> no output to this one can we >> >> 1) suppress the empty sections (to me that sounds a bit like a wrong >> =A0 return code or something maybe?), and >> 2) add an option to suppress "empty" periodic emails entirely? >> >> Sample: >> ------- >> Removing stale files from /var/preserve: >> >> Cleaning out old system announcements: >> >> Removing stale files from /var/rwho: >> >> Backup passwd and group files: >> >> Verifying group file syntax: >> /etc/group is fine >> >> Security check: >> =A0 (output mailed separately) >> >> Checking for denied zone transfers (AXFR and IXFR): >> >> -- End of daily output -- >> ------- >> >> >> I'd also like to get the hostname out of the headings of the security >> emails >> if possible. =A0It's in the Subject:. =A0There's no need to have each se= ction >> header >> starting differently. =A0I understand that it would be a POLA problem gi= ven >> a lot >> of people parse these emails automatically so adding an option for that >> would be >> ok with me as well. >> >> Any takers? > > Please don't! The headers with no entries confirm that the check has been > run. > > I really don't care about the hostnames, but the POLA issue makes me > seriously question whther it is worth doing. (Based on followup emails) No one's suggesting that the defaults be changed. We're just trying to make sure that things are made more sane if empty. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 01:19:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFBB0106566B; Tue, 3 Jan 2012 01:19:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 639098FC17; Tue, 3 Jan 2012 01:19:13 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so18097721obb.13 for ; Mon, 02 Jan 2012 17:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=olfe6Whu+gFXZDyyxkkYwmt2U0SU8OtjE904x0SSus0=; b=ehA10lGHNZttaUucYUa2NoR+5bBSMaKauaVu4YEq1AVUNWsja6o2eon8dIFa8p7ljf GPPctQjEN2eZetU6fNTRho8sLISdlK9y2Z4YN4tCP0aJmh1CiCBKkKJiZYc2fVRbBg8W LQeXXfaj+ncmyurREieBhzrQKlJSSUR4Yu2qw= MIME-Version: 1.0 Received: by 10.182.1.67 with SMTP id 3mr43351239obk.31.1325553552940; Mon, 02 Jan 2012 17:19:12 -0800 (PST) Received: by 10.182.152.6 with HTTP; Mon, 2 Jan 2012 17:19:12 -0800 (PST) In-Reply-To: <4F02350D.2050500@FreeBSD.org> References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> Date: Mon, 2 Jan 2012 17:19:12 -0800 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: multipart/mixed; boundary=f46d044469e7a75f4e04b5957cd2 Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 01:19:13 -0000 --f46d044469e7a75f4e04b5957cd2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 2, 2012 at 2:51 PM, Doug Barton wrote: > On 01/02/2012 14:49, Garrett Cooper wrote: >> On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton wrote: >>> On 01/02/2012 14:14, Garrett Cooper wrote: >>> >>>> =A0 =A0 How does this look for starters? The attached patch's goal is = to >>>> provide a generic, rc(5)-like infrastructure that would quiet down the >>>> periodic emails for 120.clean-preserve . >>> >>> The periodic scripts are badly in need of attention, so effort in that >>> area is much appreciated. >>> >>> Regarding your patch, rather than copying functions from rc.subr, why >>> not just source it? Yes, you will get more than you need, but I think >>> that the virtue of not having to maintain the same code in 2 places far >>> outweighs that minor drawback. >> >> =A0 =A0 That works too, assuming that rc.subr isn't too rc(5) centric. > > Well of course it's rc-centric, but that's not the point. :) =A0If you're > going to be using the exact same code from rc.subr, you might as well > just source it. The things that you'll get by doing that which are only > relevant to rc you just ignore. > >> Thanks for the feedback! > > Glad to help. Here's a patch (untested apart from sh -n, but I'm going to toss it into a VM to watch the sparks fly), based on stable/9 that makes periodic(5) a bit more like rc(5). Apart from that it resolves some inconsistencies with 800.zfs-scrub (the defaults were in the script and not /etc/defaults/periodic.conf), removes duplicate rc=3D0 declarations, consolidates and generalizes the "catmsgs" function, catches more errors, and some other good stuff. Thanks! -Garrett --f46d044469e7a75f4e04b5957cd2 Content-Type: application/octet-stream; name="periodic-rototill.patch" Content-Disposition: attachment; filename="periodic-rototill.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gwy8c8il0 SW5kZXg6IGV0Yy9wZXJpb2RpYy93ZWVrbHkvMzIwLndoYXRpcwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMv cGVyaW9kaWMvd2Vla2x5LzMyMC53aGF0aXMJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJp b2RpYy93ZWVrbHkvMzIwLndoYXRpcwkod29ya2luZyBjb3B5KQpAQCAtMywyMSArMywxNSBAQAog IyAkRnJlZUJTRCQKICMKIAotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJh dGlvbiBmaWxlLCBzdWNrIGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGlj LmNvbmYgXQotdGhlbgotICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291 cmNlX3BlcmlvZGljX2NvbmZzCi1maQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJHdl ZWtseV93aGF0aXNfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hl Y2t5ZXNubyB3ZWVrbHlfd2hhdGlzX2VuYWJsZTsgdGhlbgogCWVjaG8gIiIKIAllY2hvICJSZWJ1 aWxkaW5nIHdoYXRpcyBkYXRhYmFzZToiCiAKLQlNQU5QQVRIPWAvdXNyL2Jpbi9tYW5wYXRoIC1x YAotCWlmIFsgJD8gPSAwIF0KKwlpZiBNQU5QQVRIPSQoL3Vzci9iaW4vbWFucGF0aCAtcSk7IHRo ZW4KIAl0aGVuCiAJICAgIGlmIFsgLXogIiR7TUFOUEFUSH0iIF0KIAkgICAgdGhlbgpAQCAtMjUs NyArMTksNiBAQAogCQlyYz0zCiAJICAgIGVsc2UKIAkJbWFuX2xvY2FsZXM9YC91c3IvYmluL21h bnBhdGggLXFMYAotCQlyYz0wCiAKIAkgICAgICAgICMgQnVpbGQgd2hhdGlzKDEpIGRhdGFiYXNl KHMpIGZvciBvcmlnaW5hbCwgbm9uLWxvY2FsaXplZAogCQkjICBtYW5wYWdlcy4KQEAgLTQzLDkg KzM2LDcgQEAKIAkgICAgZmkKIAllbHNlCiAJICAgIHJjPTMKLQlmaTs7CisJZmkKK2ZpCiAKLSAg ICAqKSAgcmM9MDs7Ci1lc2FjCi0KIGV4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvd2Vla2x5 Lzk5OS5sb2NhbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvd2Vla2x5Lzk5OS5sb2NhbAko cmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL3dlZWtseS85OTkubG9jYWwJKHdvcmtp bmcgY29weSkKQEAgLTMsMTUgKzMsMTAgQEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUg aXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlm IFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVm YXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0 Yy9wZXJpb2RpYy5zdWJyCiAKIHJjPTAKKwogZm9yIHNjcmlwdCBpbiAkd2Vla2x5X2xvY2FsCiBk bwogICAgIGVjaG8gJycKSW5kZXg6IGV0Yy9wZXJpb2RpYy93ZWVrbHkvNDAwLnN0YXR1cy1wa2cK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL3dlZWtseS80MDAuc3RhdHVzLXBrZwkocmV2aXNp b24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL3dlZWtseS80MDAuc3RhdHVzLXBrZwkod29ya2lu ZyBjb3B5KQpAQCAtMywxNiArMywxMSBAQAogIyAkRnJlZUJTRCQKICMKIAotIyBJZiB0aGVyZSBp cyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNrIGl0IGluLgotIwotaWYg WyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQotdGhlbgotICAgIC4gL2V0Yy9kZWZh dWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2NvbmZzCi1maQorLiAvZXRj L3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJHdlZWtseV9zdGF0dXNfcGtnX2VuYWJsZSIgaW4KLSAg ICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNreWVzbm8gd2Vla2x5X3N0YXR1c19wa2df ZW5hYmxlOyB0aGVuCiAJZWNobyAiIgogCWVjaG8gIkNoZWNrIGZvciBvdXQgb2YgZGF0ZSBwYWNr YWdlczoiCiAKQEAgLTI1LDkgKzIwLDcgQEAKIAkJLWUgJ3MvXlwoW14gXSotW14gXSpcKSAgKj8g Klwob3JwaGFuZWQ6LipcKSQvICBcMSB3YXMgXDIvcCcgfAogCSAgICB0ZWUgL2Rldi9zdGRlcnIg fAogCSAgICB3YyAtbCkKLQlbICRyYyAtZ3QgMSBdICYmIHJjPTE7OworCVsgJHJjIC1ndCAxIF0g JiYgcmM9MQorZmkKIAotICAgICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0 Yy9wZXJpb2RpYy93ZWVrbHkvMzMwLmNhdG1hbgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMv d2Vla2x5LzMzMC5jYXRtYW4JKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy93ZWVr bHkvMzMwLmNhdG1hbgkod29ya2luZyBjb3B5KQpAQCAtMyw1NiArMyw0NCBAQAogIyAkRnJlZUJT RCQKICMKIAotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxl LCBzdWNrIGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQot dGhlbgotICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3Blcmlv ZGljX2NvbmZzCi1maQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJHdlZWtseV9jYXRt YW5fZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5ZXNubyB3 ZWVrbHlfY2F0bWFuX2VuYWJsZTsgdGhlbgogCWlmIFsgISAtZCAvdXNyL3NoYXJlL21hbi9jYXQx IF0KIAl0aGVuCi0JICAgIGVjaG8gJyR3ZWVrbHlfY2F0bWFuX2VuYWJsZSBpcyBzZXQgYnV0IC91 c3Ivc2hhcmUvbWFuL2NhdDEnIFwKKwkgICAgZXJyIDIgJyR3ZWVrbHlfY2F0bWFuX2VuYWJsZSBp cyBzZXQgYnV0IC91c3Ivc2hhcmUvbWFuL2NhdDEnIFwKIAkJImRvZXNuJ3QgZXhpc3QiCi0JICAg IHJjPTIKLQllbHNlCi0JICAgIGVjaG8gIiIKLQkgICAgZWNobyAiUmVmb3JtYXR0aW5nIG1hbnVh bCBwYWdlczoiCisJZmkKKwllY2hvICIiCisJZWNobyAiUmVmb3JtYXR0aW5nIG1hbnVhbCBwYWdl czoiCiAKLQkgICAgTUFOUEFUSD1gL3Vzci9iaW4vbWFucGF0aCAtcWAKLQkgICAgaWYgWyAkPyA9 IDAgXQorCWlmIE1BTlBBVEg9YC91c3IvYmluL21hbnBhdGggLXFgOyB0aGVuCisJdGhlbgorCSAg ICBpZiBbIC16ICIke01BTlBBVEh9IiBdCiAJICAgIHRoZW4KLQkJaWYgWyAteiAiJHtNQU5QQVRI fSIgXQotCQl0aGVuCi0JCSAgICBlY2hvICJtYW5wYXRoIGZhaWxlZCB0byBmaW5kIGFueSBtYW5w YXRoIGRpcmVjdG9yaWVzIgotCQkgICAgcmM9MwotCQllbHNlCi0JCSAgICBtYW5fbG9jYWxlcz1g L3Vzci9iaW4vbWFucGF0aCAtcUxgCi0JCSAgICByYz0wCisJICAgICAgICBlcnIgMyAibWFucGF0 aCBmYWlsZWQgdG8gZmluZCBhbnkgbWFucGF0aCBkaXJlY3RvcmllcyIKKwkgICAgZWxzZQorCSAg ICAgICAgbWFuX2xvY2FsZXM9YC91c3IvYmluL21hbnBhdGggLXFMYAogCi0JCSAgICAjIFByZWZv cm1hdCBvcmlnaW5hbCwgbm9uLWxvY2FsaXplZCBtYW5wYWdlcwotCQkgICAgZWNobyAvdXNyL2xp YmV4ZWMvY2F0bWFuLmxvY2FsIC1yICIkTUFOUEFUSCIgfAotCQkJc3UgLWZtIG1hbiB8fCByYz0z CisJICAgICAgICAjIFByZWZvcm1hdCBvcmlnaW5hbCwgbm9uLWxvY2FsaXplZCBtYW5wYWdlcwor CQllY2hvIC91c3IvbGliZXhlYy9jYXRtYW4ubG9jYWwgLXIgIiRNQU5QQVRIIiB8CisJCSAgICBz dSAtZm0gbWFuIHx8IHJjPTMKIAotCQkgICAgIyBQcmVmb3JtYXQgbG9jYWxpemVkIG1hbnBhZ2Vz LgotCQkgICAgaWYgWyAtbiAiJG1hbl9sb2NhbGVzIiBdCi0JCSAgICB0aGVuCi0JCQlmb3IgaSBp biAkbWFuX2xvY2FsZXMKLQkJCWRvCi0JCQkgICAgZWNobyAvdXNyL2xpYmV4ZWMvY2F0bWFuLmxv Y2FsIC1MciBcCi0JCQkJIiRNQU5QQVRIIiB8IExDX0FMTD0kaSBzdSAtZm0gbWFuIHx8IHJjPTMK LQkJCWRvbmUKLQkJICAgIGZpCisJCSMgUHJlZm9ybWF0IGxvY2FsaXplZCBtYW5wYWdlcy4KKwkJ aWYgWyAtbiAiJG1hbl9sb2NhbGVzIiBdCisJCXRoZW4KKwkJICAgIGZvciBpIGluICRtYW5fbG9j YWxlcworCQkgICAgZG8KKwkJICAgICAgICBlY2hvIC91c3IvbGliZXhlYy9jYXRtYW4ubG9jYWwg LUxyIFwKKwkJCSIkTUFOUEFUSCIgfCBMQ19BTEw9JGkgc3UgLWZtIG1hbiB8fCByYz0zCisJCSAg ICBkb25lCiAJCWZpCi0JICAgIGVsc2UKLQkJcmM9MwogCSAgICBmaQotCWZpOzsKKwllbHNlCisJ ICAgIHJjPTMKKwlmaQorZmkKIAotICAgICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5k ZXg6IGV0Yy9wZXJpb2RpYy93ZWVrbHkvMzEwLmxvY2F0ZQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVy aW9kaWMvd2Vla2x5LzMxMC5sb2NhdGUJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2Rp Yy93ZWVrbHkvMzEwLmxvY2F0ZQkod29ya2luZyBjb3B5KQpAQCAtMywzMCArMywyMyBAQAogIyAk RnJlZUJTRCQKICMKIAotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlv biBmaWxlLCBzdWNrIGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNv bmYgXQotdGhlbgotICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNl X3BlcmlvZGljX2NvbmZzCi1maQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJHdlZWts eV9sb2NhdGVfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5 ZXNubyB3ZWVrbHlfbG9jYXRlX2VuYWJsZTsgdGhlbgogCWVjaG8gIiIKIAllY2hvICJSZWJ1aWxk aW5nIGxvY2F0ZSBkYXRhYmFzZToiCiAKIAlsb2NkYj0vdmFyL2RiL2xvY2F0ZS5kYXRhYmFzZQog Ci0JdG91Y2ggJGxvY2RiICYmIHJjPTAgfHwgcmM9MworCXRvdWNoICRsb2NkYiB8fCByYz0zCiAJ Y2hvd24gbm9ib2R5ICRsb2NkYiB8fCByYz0zCiAJY2htb2QgNjQ0ICRsb2NkYiB8fCByYz0zCiAK IAljZCAvCiAJZWNobyAvdXNyL2xpYmV4ZWMvbG9jYXRlLnVwZGF0ZWRiIHwgbmljZSAtbiA1IHN1 IC1mbSBub2JvZHkgfHwgcmM9MwotCWNobW9kIDQ0NCAkbG9jZGIgfHwgcmM9Mzs7CisJY2htb2Qg NDQ0ICRsb2NkYiB8fCByYz0zCitmaQogCi0gICAgKikgIHJjPTA7OwotZXNhYwotCiBleGl0ICRy YwpJbmRleDogZXRjL3BlcmlvZGljL3dlZWtseS8zNDAubm9pZAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMv cGVyaW9kaWMvd2Vla2x5LzM0MC5ub2lkCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9k aWMvd2Vla2x5LzM0MC5ub2lkCSh3b3JraW5nIGNvcHkpCkBAIC0zLDE2ICszLDExIEBACiAjICRG cmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9u IGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29u ZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2Vf cGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkd2Vla2x5 X25vaWRfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5ZXNu byB3ZWVrbHlfbm9pZF9lbmFibGU7IHRoZW4KIAllY2hvICIiCiAJZWNobyAiQ2hlY2sgZm9yIGZp bGVzIHdpdGggYW4gdW5rbm93biB1c2VyIG9yIGdyb3VwOiIKIApAQCAtMjEsOSArMTYsNiBAQAog CSAgICBcKCAtbm9ncm91cCAtbyAtbm91c2VyIFwpIC1wcmludCB8IHNlZCAncy9eLyAgLycgfAog CSAgICB0ZWUgL2Rldi9zdGRlcnIgfCB3YyAtbCkKIAlbICRyYyAtZ3QgMSBdICYmIHJjPTEKLQk7 OworZmkKIAotICAgICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJp b2RpYy9kYWlseS8zMzAubmV3cwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvMzMw Lm5ld3MJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS8zMzAubmV3cwko d29ya2luZyBjb3B5KQpAQCAtNiwyOSArNiwyMSBAQAogIyAoVGhpcyBpcyBwcmVzZW50IG9ubHkg Zm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB1c3VhbGx5IHRoZSBuZXdzCiAjIHN5c3RlbSBo YW5kbGVzIHRoaXMgb24gaXRzIG93bikuCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVt IGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0 cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29u ZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAK LWNhc2UgIiRkYWlseV9uZXdzX2V4cGlyZV9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQor cmM9MAorCitpZiBjaGVja3llc25vIGRhaWx5X25ld3NfZXhwaXJlX2VuYWJsZTsgdGhlbgogCWlm IFsgISAtZiAvZXRjL25ld3MuZXhwaXJlIF0KIAl0aGVuCi0JICAgIGVjaG8gJyRkYWlseV9uZXdz X2V4cGlyZV9lbmFibGUgaXMgc2V0IGJ1dCAvZXRjL25ld3MuZXhwaXJlJyBcCisJICAgIGVyciAy ICckZGFpbHlfbmV3c19leHBpcmVfZW5hYmxlIGlzIHNldCBidXQgL2V0Yy9uZXdzLmV4cGlyZScg XAogCQkiZG9lc24ndCBleGlzdCIKLQkgICAgcmM9MgogCWVsc2UKIAkgICAgZWNobyAiIgogCSAg ICBlY2hvICJSdW5uaW5nIG5ld3MuZXhwaXJlOiIKIAogCSAgICAvZXRjL25ld3MuZXhwaXJlICYm IHJjPTAgfHwgcmM9MwotCWZpOzsKKwlmaQorZmkKIAotICAgICopICByYz0wOzsKLWVzYWMKLQog ZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9kYWlseS80OTAuc3RhdHVzLXBrZy1jaGFuZ2Vz Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9kYWlseS80OTAuc3RhdHVzLXBrZy1jaGFuZ2Vz CShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvZGFpbHkvNDkwLnN0YXR1cy1wa2ct Y2hhbmdlcwkod29ya2luZyBjb3B5KQpAQCAtMywyMiArMywxNiBAQAogIyAkRnJlZUJTRCQKICMK IAotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNr IGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXTsgdGhlbgot ICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2Nv bmZzCi1maQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJGRhaWx5X3N0YXR1c19wa2df Y2hhbmdlc19lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAorCitpZiBjaGVja3ll c25vIGRhaWx5X3N0YXR1c19wa2dfY2hhbmdlc19lbmFibGU7IHRoZW4KIAlpZiBbICEgLWYgL3Vz ci9zYmluL3BrZ19pbmZvIF07IHRoZW4KLQkgICAgZWNobyAnJGRhaWx5X3N0YXR1c19wa2dfY2hh bmdlc19lbmFibGUgaXMgZW5hYmxlZCBidXQnIFwKKwkgICAgZXJyIDIgJyRkYWlseV9zdGF0dXNf cGtnX2NoYW5nZXNfZW5hYmxlIGlzIGVuYWJsZWQgYnV0JyBcCiAJCSAiL3Vzci9zYmluL3BrZ19p bmZvIGRvZXNuJ3QgZXhpc3QiCi0JICAgIHJjPTIKIAllbHNlCiAJICAgIGJhaz0vdmFyL2JhY2t1 cHMKLQkgICAgcmM9MAogCiAJICAgIGlmIFsgLWYgJGJhay9wa2dfaW5mby5iYWsgXTsgdGhlbgog CSAgICAJbXYgLWYgJGJhay9wa2dfaW5mby5iYWsgJGJhay9wa2dfaW5mby5iYWsyCkBAIC0zMywx MSArMjcsNiBAQAogCQl8IGdyZXAgJ15bLStdW14tK10nIHwgc29ydCAtayAxLjIKIAkgICAgZmkK IAlmaQotCTs7CitmaQogCi0gICAgKikKLQlyYz0wCi0JOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5k ZXg6IGV0Yy9wZXJpb2RpYy9kYWlseS85OTkubG9jYWwKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3Blcmlv ZGljL2RhaWx5Lzk5OS5sb2NhbAkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2Rh aWx5Lzk5OS5sb2NhbAkod29ya2luZyBjb3B5KQpAQCAtNiwxMyArNiw3IEBACiAjIGNvbXBhdGli aWxpdHkgbW9yZSB0aGFuIGFueXRoaW5nIGVsc2UuCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9i YWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0 Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVy aW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2Rp Yy5zdWJyCiAKIHJjPTAKIGZvciBzY3JpcHQgaW4gJGRhaWx5X2xvY2FsCkluZGV4OiBldGMvcGVy aW9kaWMvZGFpbHkvODAwLnNjcnViLXpmcwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFp bHkvODAwLnNjcnViLXpmcwkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2RhaWx5 LzgwMC5zY3J1Yi16ZnMJKHdvcmtpbmcgY29weSkKQEAgLTMsMjIgKzMsMTYgQEAKICMgJEZyZWVC U0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmls ZSwgc3VjayBpdCBpbi4KLSMKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKIG5ld2xpbmU9IgogIiAj IEEgc2luZ2xlIG5ld2xpbmUKIAotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYg XQotdGhlbgotICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3Bl cmlvZGljX2NvbmZzCi1maQorcmM9MAogCiA6ICR7ZGFpbHlfc2NydWJfemZzX2RlZmF1bHRfdGhy ZXNob2xkPTMwfQogCi1jYXNlICIkZGFpbHlfc2NydWJfemZzX2VuYWJsZSIgaW4KLSAgICBbWXld W0VlXVtTc10pCitpZiBjaGVja3llc25vIGRhaWx5X3NjcnViX3pmc19lbmFibGU7IHRoZW4KIAll Y2hvCiAJZWNobyAnU2NydWJiaW5nIG9mIHpmcyBwb29sczonCiAKQEAgLTI2LDcgKzIwLDYgQEAK IAkJZGFpbHlfc2NydWJfemZzX3Bvb2xzPSIkKHpwb29sIGxpc3QgLUggLW8gbmFtZSkiCiAJZmkK IAotCXJjPTAKIAlmb3IgcG9vbCBpbiAke2RhaWx5X3NjcnViX3pmc19wb29sc307IGRvCiAJCSMg c2FuaXR5IGNoZWNrCiAJCV9zdGF0dXM9JCh6cG9vbCBsaXN0ICIke3Bvb2x9IiAyPiAvZGV2L251 bGwpCkBAIC04OCwxMSArODEsNiBAQAogCiAJCWVjaG8gIiAgICAgIGNvbnN1bHQgJ3pwb29sIHN0 YXR1cyAke3Bvb2x9JyBmb3IgdGhlIHJlc3VsdCIKIAlkb25lCi0JOzsKK2ZpCiAKLSAgICAqKQot CXJjPTAKLQk7OwotZXNhYwotCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzQ0 MC5zdGF0dXMtbWFpbHEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL2RhaWx5LzQ0MC5zdGF0 dXMtbWFpbHEJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS80NDAuc3Rh dHVzLW1haWxxCSh3b3JraW5nIGNvcHkpCkBAIC0zLDY0ICszLDUzIEBACiAjICRGcmVlQlNEJAog IwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1 Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVu Ci0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNf Y29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfc3RhdHVzX21h aWxxX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNreWVzbm8g ZGFpbHlfc3RhdHVzX21haWxxX2VuYWJsZTsgdGhlbgogCWlmIFsgISAteCAvdXNyL2Jpbi9tYWls cSBdCiAJdGhlbgotCSAgICBlY2hvICckZGFpbHlfc3RhdHVzX21haWxxX2VuYWJsZSBpcyBzZXQg YnV0IC91c3IvYmluL21haWxxJyBcCisJICAgIGVyciAyICckZGFpbHlfc3RhdHVzX21haWxxX2Vu YWJsZSBpcyBzZXQgYnV0IC91c3IvYmluL21haWxxJyBcCiAJCSJpc24ndCBleGVjdXRhYmxlIgot CSAgICByYz0yCiAJZWxzZQogCSAgICBlY2hvICIiCiAJICAgIGVjaG8gIk1haWwgaW4gbG9jYWwg cXVldWU6IgogCi0JICAgIHJjPSQoY2FzZSAiJGRhaWx5X3N0YXR1c19tYWlscV9zaG9ydGVuIiBp bgotCQlbWXldW0VlXVtTc10pCisJICAgIG49JChpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19t YWlscV9zaG9ydGVuOyB0aGVuCiAJCSAgICBtYWlscSB8CiAJCQllZ3JlcCAtZSAnXltbOnNwYWNl Ol1dK1teWzpzcGFjZTpdXStAJyB8CiAJCQlzb3J0IHwKIAkJCXVuaXEgLWMgfAogCQkJc29ydCAt bnIgfAotCQkJYXdrICckMSA+PSAxIHtwcmludCAkMSwgJDJ9Jzs7Ci0JCSopCi0JCSAgICBtYWls cTs7Ci0JICAgIGVzYWMgfCB0ZWUgL2Rldi9zdGRlcnIgfAorCQkJYXdrICckMSA+PSAxIHtwcmlu dCAkMSwgJDJ9JworCQllbHNlCisJCSAgICBtYWlscQorCSAgICAgICAgZmkgfCB0ZWUgL2Rldi9z dGRlcnIgfAogCSAgICBlZ3JlcCAtdiAnKG1xdWV1ZSBpcyBlbXB0eXxUb3RhbCByZXF1ZXN0cykn IHwgd2MgLWwpCi0JICAgIFsgJHJjIC1ndCAwIF0gJiYgcmM9MSB8fCByYz0wCisJICAgIFsgJG4g LWd0IDAgXSAmJiByYz0xCiAKLQkgICAgY2FzZSAiJGRhaWx5X3N0YXR1c19pbmNsdWRlX3N1Ym1p dF9tYWlscSIgaW4KLQkgICAgW1l5XVtFZV1bU3NdKQorCSAgICBpZiBjaGVja3llc25vIGRhaWx5 X3N0YXR1c19pbmNsdWRlX3N1Ym1pdF9tYWlscTsgdGhlbgogCQlpZiBbIC1mIC9ldGMvbWFpbC9z dWJtaXQuY2YgXQogCQl0aGVuCiAJCSAgICBlY2hvICIiCiAJCSAgICBlY2hvICJNYWlsIGluIHN1 Ym1pdCBxdWV1ZToiCiAKLQkJICAgIHJjX3N1Ym1pdD0kKGNhc2UgIiRkYWlseV9zdGF0dXNfbWFp bHFfc2hvcnRlbiIgaW4KLQkJCVtZeV1bRWVdW1NzXSkKKwkJICAgIG49JChpZiBjaGVja3llc25v IGRhaWx5X3N0YXR1c19tYWlscV9zaG9ydGVuOyB0aGVuCiAJCQkgICAgbWFpbHEgLUFjIHwKIAkJ CQllZ3JlcCAtZSAnXltbOnNwYWNlOl1dK1teWzpzcGFjZTpdXStAJyB8CiAJCQkJc29ydCB8CiAJ CQkJdW5pcSAtYyB8CiAJCQkJc29ydCAtbnIgfAotCQkJCWF3ayAnJDEgPj0gMSB7cHJpbnQgJDEs ICQyfSc7OwotCQkJKikKLQkJCSAgICBtYWlscSAtQWM7OwotCQkgICAgZXNhYyB8IHRlZSAvZGV2 L3N0ZGVyciB8CisJCQkJYXdrICckMSA+PSAxIHtwcmludCAkMSwgJDJ9JworCQkJZWxzZQorCQkJ ICAgIG1haWxxIC1BYworCQkgICAgICAgIGZpIHwgdGVlIC9kZXYvc3RkZXJyIHwKIAkJICAgIGVn cmVwIC12ICcobXF1ZXVlIGlzIGVtcHR5fFRvdGFsIHJlcXVlc3RzKScgfCB3YyAtbCkKLQkJICAg IFsgJHJjX3N1Ym1pdCAtZ3QgMCBdICYmIHJjPTEKLQkJZmk7OwotCSAgICBlc2FjCi0JZmk7Owor CQkgICAgWyAkbiAtZ3QgMCBdICYmIHJjPTEKKwkJZmkKKwkgICAgZmkKKwlmaQorZmkKIAotICAg ICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9kYWlseS8x MzAuY2xlYW4tbXNncwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvMTMwLmNsZWFu LW1zZ3MJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS8xMzAuY2xlYW4t bXNncwkod29ya2luZyBjb3B5KQpAQCAtNSwyMSArNSwxNSBAQAogIyBSZW1vdmUgc3lzdGVtCW1l c3NhZ2VzCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24g ZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25m IF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9w ZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKLWNhc2UgIiRkYWlseV9j bGVhbl9tc2dzX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNr eWVzbm8gZGFpbHlfY2xlYW5fbXNnc19lbmFibGU7IHRoZW4KIAlpZiBbICEgLWQgL3Zhci9tc2dz IF0KIAl0aGVuCi0JICAgIGVjaG8gJyRkYWlseV9jbGVhbl9tc2dzX2VuYWJsZSBpcyBzZXQgYnV0 IC92YXIvbXNncycgXAorCSAgICBlcnIgMiAnJGRhaWx5X2NsZWFuX21zZ3NfZW5hYmxlIGlzIHNl dCBidXQgL3Zhci9tc2dzJyBcCiAJCSJkb2Vzbid0IGV4aXN0IgotCSAgICByYz0yCiAJZWxzZQog CSAgICBlY2hvICIiCiAJICAgIGVjaG8gIkNsZWFuaW5nIG91dCBvbGQgc3lzdGVtIGFubm91bmNl bWVudHM6IgpAQCAtMjcsOSArMjEsNyBAQAogCSAgICBbIC1uICIkZGFpbHlfY2xlYW5fbXNnc19k YXlzIiBdICYmCiAJCWFyZz0tJHtkYWlseV9jbGVhbl9tc2dzX2RheXMjLX0gfHwgYXJnPQogCSAg ICBtc2dzIC1jICRhcmcgJiYgcmM9MCB8fCByYz0zCi0JZmk7OworCWZpCitmaQogCi0gICAgKikg IHJjPTA7OwotZXNhYwotCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzEwMC5j bGVhbi1kaXNrcwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvMTAwLmNsZWFuLWRp c2tzCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvZGFpbHkvMTAwLmNsZWFuLWRp c2tzCSh3b3JraW5nIGNvcHkpCkBAIC01LDUxICs1LDQwIEBACiAjIFJlbW92ZSBnYXJiYWdlIGZp bGVzIG1vcmUgdGhhbiAkZGFpbHlfY2xlYW5fZGlza3NfZGF5cyBkYXlzIG9sZAogIwogCi0jIElm IHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4u Ci0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAv ZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZp CisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfY2xlYW5fZGlza3NfZW5hYmxl IiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5ZXNubyBkYWlseV9jbGVh bl9kaXNrc19lbmFibGU7IHRoZW4KIAlpZiBbIC16ICIkZGFpbHlfY2xlYW5fZGlza3NfZGF5cyIg XQogCXRoZW4KLQkgICAgZWNobyAnJGRhaWx5X2NsZWFuX2Rpc2tzX2VuYWJsZSBpcyBzZXQgYnV0 JyBcCisJICAgIGVyciAyICckZGFpbHlfY2xlYW5fZGlza3NfZW5hYmxlIGlzIHNldCBidXQnIFwK IAkJJyRkYWlseV9jbGVhbl9kaXNrc19kYXlzIGlzIG5vdCcKLQkgICAgcmM9MgogCWVsaWYgWyAt eiAiJGRhaWx5X2NsZWFuX2Rpc2tzX2ZpbGVzIiBdCiAJdGhlbgotCSAgICBlY2hvICckZGFpbHlf Y2xlYW5fZGlza3NfZW5hYmxlIGlzIHNldCBidXQnIFwKKwkgICAgZXJyIDIgJyRkYWlseV9jbGVh bl9kaXNrc19lbmFibGUgaXMgc2V0IGJ1dCcgXAogCQknJGRhaWx5X2NsZWFuX2Rpc2tzX2ZpbGVz IGlzIG5vdCcKLQkgICAgcmM9MgogCWVsc2UKLQkgICAgZWNobyAiIgotCSAgICBlY2hvICJDbGVh bmluZyBkaXNrczoiCisJICAgIGlmIGNoZWNreWVzbm8gZGFpbHlfY2xlYW5fZGlza3NfdmVyYm9z ZTsgdGhlbgorCQllY2hvICIiCisJCWVjaG8gIkNsZWFuaW5nIGRpc2tzOiIKKworCQlwcmludD0t cHJpbnQKKwkgICAgZWxzZQorCQlwcmludD0KKwkgICAgZmkKIAkgICAgc2V0IC1mIG5vZ2xvYgog CSAgICBhcmdzPSItbmFtZSAiYGVjaG8gIiRkYWlseV9jbGVhbl9kaXNrc19maWxlcyIgfAogCQlz ZWQgLWUgJ3MvXlsgCV0qLy8nIFwKIAkJICAgIC1lICdzL1sgCV0qJC8vJyBcCiAJCSAgICAtZSAn cy9bIAldWyAJXSovIC1vIC1uYW1lIC9nJ2AKIAotCSAgICBjYXNlICIkZGFpbHlfY2xlYW5fZGlz a3NfdmVyYm9zZSIgaW4KLQkJW1l5XVtFZV1bU3NdKQotCQkgICAgcHJpbnQ9LXByaW50OzsKLQkJ KikKLQkJICAgIHByaW50PTs7Ci0JICAgIGVzYWMKLQogCSAgICByYz0kKGZpbmQgLyBcKCAhIC1m c3R5cGUgbG9jYWwgLW8gLWZzdHlwZSByZG9ubHkgXCkgLXBydW5lIC1vIFwKIAkJXCggJGFyZ3Mg XCkgLWF0aW1lICskZGFpbHlfY2xlYW5fZGlza3NfZGF5cyBcCiAJCS1leGVjZGlyIHJtIC1kZiB7 fSBcOyAkcHJpbnQgfCB0ZWUgL2Rldi9zdGRlcnIgfCB3YyAtbCkKLQkgICAgWyAteiAiJHByaW50 IiBdICYmIHJjPTAKIAkgICAgWyAkcmMgLWd0IDEgXSAmJiByYz0xCiAJICAgIHNldCAtZiBnbG9i Ci0JZmk7OworCWZpCitmaQogCi0gICAgKikgIHJjPTA7OwotZXNhYwotCiBleGl0ICRyYwpJbmRl eDogZXRjL3BlcmlvZGljL2RhaWx5LzQ1MC5zdGF0dXMtc2VjdXJpdHkKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g ZXRjL3BlcmlvZGljL2RhaWx5LzQ1MC5zdGF0dXMtc2VjdXJpdHkJKHJldmlzaW9uIDIyOTMyMykK KysrIGV0Yy9wZXJpb2RpYy9kYWlseS80NTAuc3RhdHVzLXNlY3VyaXR5CSh3b3JraW5nIGNvcHkp CkBAIC0zLDM5ICszLDMxIEBACiAjICRGcmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xv YmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9l dGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3Bl cmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9k aWMuc3VicgogCi1jYXNlICIkZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2VuYWJsZSIgaW4KLSAgICBb WXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNreWVzbm8gZGFpbHlfc3RhdHVzX3NlY3VyaXR5 X2VuYWJsZTsgdGhlbgogCWVjaG8gIiIKIAllY2hvICJTZWN1cml0eSBjaGVjazoiCiAKLQljYXNl ICIkZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2lubGluZSIgaW4KLQkgICAgW1l5XVtFZV1bU3NdKQor CWlmIGNoZWNreWVzbm8gZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2lubGluZTsgdGhlbgogCQlleHBv cnQgc2VjdXJpdHlfb3V0cHV0PSIiOzsKLQkgICAgKikKKwllbHNlCiAJCWV4cG9ydCBzZWN1cml0 eV9vdXRwdXQ9IiR7ZGFpbHlfc3RhdHVzX3NlY3VyaXR5X291dHB1dH0iCiAJCWNhc2UgIiR7ZGFp bHlfc3RhdHVzX3NlY3VyaXR5X291dHB1dH0iIGluCiAJCSAgICAiIikKIAkJCXJjPTM7OwogCQkg ICAgLyopCiAJCQllY2hvICIgICAgKG91dHB1dCBsb2dnZWQgc2VwYXJhdGVseSkiCi0JCQlyYz0w OzsKKwkJCTs7CiAJCSAgICAqKQogCQkJZWNobyAiICAgIChvdXRwdXQgbWFpbGVkIHNlcGFyYXRl bHkpIgotCQkJcmM9MDs7Ci0JCWVzYWM7OwotCWVzYWMKKwkJCTs7CisJCWVzYWMKKwlmaQogCi0J cGVyaW9kaWMgc2VjdXJpdHkgfHwgcmM9Mzs7CisJcGVyaW9kaWMgc2VjdXJpdHkgfHwgcmM9Mwor ZmkKIAotICAgICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2Rp Yy9kYWlseS8xNDAuY2xlYW4tcndobwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkv MTQwLmNsZWFuLXJ3aG8JKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS8x NDAuY2xlYW4tcndobwkod29ya2luZyBjb3B5KQpAQCAtNSw0OSArNSwzNyBAQAogIyBSZW1vdmUg c3RhbGUgZmlsZXMgaW4gL3Zhci9yd2hvCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lz dGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZh dWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMu Y29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJy CiAKLWNhc2UgIiRkYWlseV9jbGVhbl9yd2hvX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10p CityYz0wCisKK2lmIGNoZWNreWVzbm8gZGFpbHlfY2xlYW5fcndob19lbmFibGU7IHRoZW4KIAlp ZiBbIC16ICIkZGFpbHlfY2xlYW5fcndob19kYXlzIiBdCiAJdGhlbgotCSAgICBlY2hvICckZGFp bHlfY2xlYW5fcndob19lbmFibGUgaXMgZW5hYmxlZCBidXQnIFwKKwkgICAgZXJyIDIgJyRkYWls eV9jbGVhbl9yd2hvX2VuYWJsZSBpcyBlbmFibGVkIGJ1dCcgXAogCQknJGRhaWx5X2NsZWFuX3J3 aG9fZGF5cyBpcyBub3Qgc2V0JwotCSAgICByYz0yCiAJZWxpZiBbICEgLWQgL3Zhci9yd2hvIF0K IAl0aGVuCi0JICAgIGVjaG8gJyRkYWlseV9jbGVhbl9yd2hvX2VuYWJsZSBpcyBlbmFibGVkIGJ1 dCAvdmFyL3J3aG8nIFwKKwkgICAgZXJyIDIgJyRkYWlseV9jbGVhbl9yd2hvX2VuYWJsZSBpcyBl bmFibGVkIGJ1dCAvdmFyL3J3aG8nIFwKIAkJImRvZXNuJ3QgZXhpc3QiCi0JICAgIHJjPTIKIAll bHNlCi0JICAgIGVjaG8gIiIKLQkgICAgZWNobyAiUmVtb3Zpbmcgc3RhbGUgZmlsZXMgZnJvbSAv dmFyL3J3aG86IgorCSAgICBpZiBjaGVja3llc25vIGRhaWx5X2NsZWFuX3J3aG9fdmVyYm9zZTsg dGhlbgorCQllY2hvICIiCisJCWVjaG8gIlJlbW92aW5nIHN0YWxlIGZpbGVzIGZyb20gL3Zhci9y d2hvOiIKIAotCSAgICBjYXNlICIkZGFpbHlfY2xlYW5fcndob192ZXJib3NlIiBpbgotCQlbWXld W0VlXVtTc10pCi0JCSAgICBwcmludD0tcHJpbnQ7OwotCQkqKQotCQkgICAgcHJpbnQ9OzsKLQkg ICAgZXNhYwotCisJCXByaW50PS1wcmludAorCSAgICBlbHNlCisJCXByaW50PQorCSAgICBmaQog CSAgICBpZiBjZCAvdmFyL3J3aG8KIAkgICAgdGhlbgogCQlyYz0kKGZpbmQgLiAhIC1uYW1lIC4g LW10aW1lICskZGFpbHlfY2xlYW5fcndob19kYXlzIFwKIAkJICAgIC1kZWxldGUgJHByaW50IHwg dGVlIC9kZXYvc3RkZXJyIHwgd2MgLWwpCi0JCVsgLXogIiRwcmludCIgXSAmJiByYz0wCiAJCVsg JHJjIC1ndCAxIF0gJiYgcmM9MQogCSAgICBlbHNlCiAJCXJjPTMKIAkgICAgZmkKLQlmaTs7CisJ ZmkKK2ZpCiAKLSAgICAqKSAgcmM9MDs7Ci1lc2FjCi0KIGV4aXQgJHJjCkluZGV4OiBldGMvcGVy aW9kaWMvZGFpbHkvMTEwLmNsZWFuLXRtcHMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL2Rh aWx5LzExMC5jbGVhbi10bXBzCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvZGFp bHkvMTEwLmNsZWFuLXRtcHMJKHdvcmtpbmcgY29weSkKQEAgLTYsMjUgKzYsMjQgQEAKICMgZG9u J3QgZW5kIHVwIHdpdGggZXhjZXNzaXZlbHkgb2xkIGZpbGVzIHRoZXJlLgogIwogCi0jIElmIHRo ZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0j Ci1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRj L2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisu IC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfY2xlYW5fdG1wc19lbmFibGUiIGlu Ci0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAorCitpZiBjaGVja3llc25vIGRhaWx5X2NsZWFuX3Rt cHNfZW5hYmxlOyB0aGVuCiAJaWYgWyAteiAiJGRhaWx5X2NsZWFuX3RtcHNfZGF5cyIgXQogCXRo ZW4KLQkgICAgZWNobyAnJGRhaWx5X2NsZWFuX3RtcHNfZW5hYmxlIGlzIHNldCBidXQnIFwKKwkg ICAgZXJyIDIgJyRkYWlseV9jbGVhbl90bXBzX2VuYWJsZSBpcyBzZXQgYnV0JyBcCiAJCSckZGFp bHlfY2xlYW5fdG1wc19kYXlzIGlzIG5vdCcKLQkgICAgcmM9MgogCWVsc2UKLQkgICAgZWNobyAi IgotCSAgICBlY2hvICJSZW1vdmluZyBvbGQgdGVtcG9yYXJ5IGZpbGVzOiIKKwkgICAgaWYgY2hl Y2t5ZXNubyBkYWlseV9jbGVhbl90bXBzX3ZlcmJvc2U7IHRoZW4KKwkJZWNobyAiIgorCQllY2hv ICJSZW1vdmluZyBvbGQgdGVtcG9yYXJ5IGZpbGVzOiIKIAorCQlwcmludD0tcHJpbnQKKwkgICAg ZWxzZQorCQlwcmludD0KKwkgICAgZmkKIAkgICAgc2V0IC1mIG5vZ2xvYgogCSAgICBhcmdzPSIt YXRpbWUgKyRkYWlseV9jbGVhbl90bXBzX2RheXMgLW10aW1lICskZGFpbHlfY2xlYW5fdG1wc19k YXlzIgogCSAgICBhcmdzPSIke2FyZ3N9IC1jdGltZSArJGRhaWx5X2NsZWFuX3RtcHNfZGF5cyIK QEAgLTM1LDEzICszNCw2IEBACiAJCWRhcmdzPSIkZGFyZ3MgImBlY2hvICIgJHtkYWlseV9jbGVh bl90bXBzX2lnbm9yZSUgfSIgfAogCQkgICAgc2VkICdzL1sgCV1bIAldKi8gISAtbmFtZSAvZydg CiAJICAgIH0KLQkgICAgY2FzZSAiJGRhaWx5X2NsZWFuX3RtcHNfdmVyYm9zZSIgaW4KLQkJW1l5 XVtFZV1bU3NdKQotCQkgICAgcHJpbnQ9LXByaW50OzsKLQkJKikKLQkJICAgIHByaW50PTs7Ci0J ICAgIGVzYWMKLQogCSAgICByYz0kKGZvciBkaXIgaW4gJGRhaWx5X2NsZWFuX3RtcHNfZGlycwog CQlkbwogCQkgICAgWyAuIiR7ZGlyIy99IiAhPSAuIiRkaXIiIC1hIC1kICRkaXIgXSAmJiBjZCAk ZGlyICYmIHsKQEAgLTQ5LDEyICs0MSw5IEBACiAJCQlmaW5kIC1kIC4gISAtbmFtZSAuIC10eXBl IGQgJGRhcmdzIC1kZWxldGUgJHByaW50CiAJCSAgICB9IHwgc2VkICJzLF5cXC4sICAkZGlyLCIK IAkJZG9uZSB8IHRlZSAvZGV2L3N0ZGVyciB8IHdjIC1sKQotCSAgICBbIC16ICIkcHJpbnQiIF0g JiYgcmM9MAogCSAgICBbICRyYyAtZ3QgMSBdICYmIHJjPTEKIAkgICAgc2V0IC1mIGdsb2IKLQlm aTs7CisJZmkKK2ZpCiAKLSAgICAqKSAgcmM9MDs7Ci1lc2FjCi0KIGV4aXQgJHJjCkluZGV4OiBl dGMvcGVyaW9kaWMvZGFpbHkvNDMwLnN0YXR1cy1yd2hvCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJp b2RpYy9kYWlseS80MzAuc3RhdHVzLXJ3aG8JKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJp b2RpYy9kYWlseS80MzAuc3RhdHVzLXJ3aG8JKHdvcmtpbmcgY29weSkKQEAgLTMsMTYgKzMsMTEg QEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZp Z3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJp b2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAg IHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKLWNhc2Ug IiRkYWlseV9zdGF0dXNfcndob19lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAor CitpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19yd2hvX2VuYWJsZTsgdGhlbgogCXJ3aG89JChl Y2hvIC92YXIvcndoby8qKQogICAgICAgICBpZiBbIC1mICIke3J3aG8lJSAqfSIgXQogICAgICAg ICB0aGVuCkBAIC0yNCwxNSArMTksMTMgQEAKIAkgICAgZWNobyAiTG9jYWwgc3lzdGVtIHN0YXR1 czoiCiAJICAgIHByb2c9dXB0aW1lCiAJZmkKLQlyYz0kKCRwcm9nIHwgdGVlIC9kZXYvc3RkZXJy IHwgd2MgLWwpCisJbj0kKCRwcm9nIHwgdGVlIC9kZXYvc3RkZXJyIHwgd2MgLWwpCiAJaWYgWyAk PyAtZXEgMCBdCiAJdGhlbgotCSAgICBbICRyYyAtZ3QgMSBdICYmIHJjPTEKKwkgICAgWyAkbiAt Z3QgMSBdICYmIHJjPTEKIAllbHNlCiAJICAgIHJjPTMKLQlmaTs7CisJZmkKK2ZpCiAKLSAgICAq KSAgcmM9MDs7Ci1lc2FjCi0KIGV4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvZGFpbHkvNDYw LnN0YXR1cy1tYWlsLXJlamVjdHMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL2RhaWx5LzQ2 MC5zdGF0dXMtbWFpbC1yZWplY3RzCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMv ZGFpbHkvNDYwLnN0YXR1cy1tYWlsLXJlamVjdHMJKHdvcmtpbmcgY29weSkKQEAgLTMsMzYgKzMs MjkgQEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNv bmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9w ZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgot ICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcworLiAvZXRjL3BlcmlvZGljLnN1YnIKKworcmM9MAor CitpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19tYWlsX3JlamVjdHNfc2hvcnRlbjsgdGhlbgor CXNob3J0ZW49J2N1dCAtZCIgIiAtZjIsMycKK2Vsc2UKKwlzaG9ydGVuPWNhdAogZmkKIAotY2Fz ZSAiJGRhaWx5X3N0YXR1c19tYWlsX3JlamVjdHNfc2hvcnRlbiIgaW4KLVtZeV1bRWVdW1NzXSkJ c2hvcnRlbj0nY3V0IC1kIiAiIC1mMiwzJzs7Ci0qKQkJc2hvcnRlbj1jYXQ7OwotZXNhYwotCi1j YXNlICIkZGFpbHlfc3RhdHVzX21haWxfcmVqZWN0c19lbmFibGUiIGluCi0gICAgW1l5XVtFZV1b U3NdKQoraWYgY2hlY2t5ZXNubyBkYWlseV9zdGF0dXNfbWFpbF9yZWplY3RzX2VuYWJsZTsgdGhl bgogCWlmIFsgISAtZCAvZXRjL21haWwgXQogCXRoZW4KLQkgICAgZWNobyAnJGRhaWx5X3N0YXR1 c19tYWlsX3JlamVjdHNfZW5hYmxlIGlzIHNldCBidXQgL2V0Yy9tYWlsJyBcCisJICAgIGVyciAy ICckZGFpbHlfc3RhdHVzX21haWxfcmVqZWN0c19lbmFibGUgaXMgc2V0IGJ1dCAvZXRjL21haWwn IFwKIAkJImRvZXNuJ3QgZXhpc3QiCi0JICAgIHJjPTIKIAllbGlmIFsgISAtZiAvdmFyL2xvZy9t YWlsbG9nIF0KIAl0aGVuCi0JICAgIGVjaG8gJyRkYWlseV9zdGF0dXNfbWFpbF9yZWplY3RzX2Vu YWJsZSBpcyBzZXQgYnV0ICcgXAorCSAgICBlcnIgMiAnJGRhaWx5X3N0YXR1c19tYWlsX3JlamVj dHNfZW5hYmxlIGlzIHNldCBidXQgJyBcCiAJCSIvdmFyL2xvZy9tYWlsbG9nIGRvZXNuJ3QgZXhp c3QiCi0JICAgIHJjPTIKIAllbGlmIFsgIiRkYWlseV9zdGF0dXNfbWFpbF9yZWplY3RzX2xvZ3Mi IC1sZSAwIF0KIAl0aGVuCi0JICAgIGVjaG8gJyRkYWlseV9zdGF0dXNfbWFpbF9yZWplY3RzX2Vu YWJsZSBpcyBzZXQgYnV0ICcgXAorCSAgICBlcnIgMiAnJGRhaWx5X3N0YXR1c19tYWlsX3JlamVj dHNfZW5hYmxlIGlzIHNldCBidXQgJyBcCiAJCSckZGFpbHlfc3RhdHVzX21haWxfcmVqZWN0c19s b2dzIGlzIG5vdCBncmVhdGVyIHRoYW4gemVybycKLQkgICAgcmM9MgogCWVsc2UKIAkgICAgZWNo bwogCSAgICBlY2hvIENoZWNraW5nIGZvciByZWplY3RlZCBtYWlsIGhvc3RzOgpAQCAtNjUsOSAr NTgsNyBAQAogCQkgICAgOmVuZAogCQl9JyB8IGV2YWwgJHNob3J0ZW4gfCBzb3J0IC1mIHwgdW5p cSAtaWMgfCBzb3J0IC1mbnIgfCB0ZWUgL2Rldi9zdGRlcnIgfCB3YyAtbCkKIAkgICAgWyAkcmMg LWd0IDAgXSAmJiByYz0xCi0JZmk7OworCWZpCitmaQogCi0gICAgKikgIHJjPTA7OwotZXNhYwot CiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzQwNS5zdGF0dXMtYXRhLXJhaWQK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL2RhaWx5LzQwNS5zdGF0dXMtYXRhLXJhaWQJKHJl dmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS80MDUuc3RhdHVzLWF0YS1yYWlk CSh3b3JraW5nIGNvcHkpCkBAIC0xLDMzICswLDAgQEAKLSMhL2Jpbi9zaAotIwotIyAkRnJlZUJT RCQKLSMKLQotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxl LCBzdWNrIGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQot dGhlbgotICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3Blcmlv ZGljX2NvbmZzCi1maQotCi1jYXNlICIkZGFpbHlfc3RhdHVzX2F0YV9yYWlkX2VuYWJsZSIgaW4K LSAgICBbWXldW0VlXVtTc10pCi0JZWNobwotCWVjaG8gJ0NoZWNraW5nIHN0YXR1cyBvZiBBVEEg cmFpZCBwYXJ0aXRpb25zOicKLQotCXJjPTAKLQlmb3IgcmFpZCBpbiBgZmluZCAvZGV2LyAtbmFt ZSAnYXJbMC05XSonIC10eXBlIGMgfCBlZ3JlcCAnWzAtOV0kJyBcCi0JCXwgZWdyZXAgLXYgJ3Nb MC05XScgfCBjdXQgLWQgLyAtZiAzYAotCSAgICAgZG8KLQkJc3RhdHVzPWAvc2Jpbi9hdGFjb250 cm9sIHN0YXR1cyAkcmFpZGAKLQkJZWNobyAkc3RhdHVzCi0JCXJhaWRfcmM9YGVjaG8gJHN0YXR1 cyB8IGdyZXAgLXYgUkVBRFkgfCB3YyAtbGAKLQkJWyAkcmMgLWVxIDAgXSAmJiBbICRyYWlkX3Jj IC1ndCAwIF0gJiYgcmM9MwotCSAgICAgZG9uZQotCTs7Ci0KLSAgICAqKSAgcmM9MDs7Ci1lc2Fj Ci0KLWV4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvZGFpbHkvNDA5LnN0YXR1cy1nY29uY2F0 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9kYWlseS80MDkuc3RhdHVzLWdjb25jYXQJKHJl dmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS80MDkuc3RhdHVzLWdjb25jYXQJ KHdvcmtpbmcgY29weSkKQEAgLTMsMTYgKzMsMTEgQEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYg dGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4K LSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9l dGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkK Ky4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKLWNhc2UgIiRkYWlseV9zdGF0dXNfZ2NvbmNhdF9lbmFi bGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAorCitpZiBjaGVja3llc25vIGRhaWx5X3N0 YXR1c19nY29uY2F0X2VuYWJsZTsgdGhlbgogCWVjaG8KIAllY2hvICdDaGVja2luZyBzdGF0dXMg b2YgZ2NvbmNhdCg4KSBkZXZpY2VzOicKIApAQCAtMjAsMTUgKzE1LDEwIEBACiAJCWNvbXBvbmVu dHM9IiQoZ2NvbmNhdCBzdGF0dXMgLXMgfCBmZ3JlcCAtdiBVUCkiCiAJCWlmIFsgIiR7Y29tcG9u ZW50c30iIF07IHRoZW4KIAkJCXJjPTMKLQkJZWxzZQotCQkJcmM9MAogCQlmaQogCWVsc2UKIAkJ cmM9MgogCWZpCi0JOzsKK2ZpCiAKLSAgICAqKSAgcmM9MDs7Ci1lc2FjCi0KIGV4aXQgJHJjCklu ZGV4OiBldGMvcGVyaW9kaWMvZGFpbHkvNDA2LnN0YXR1cy1nbWlycm9yCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IGV0Yy9wZXJpb2RpYy9kYWlseS80MDYuc3RhdHVzLWdtaXJyb3IJKHJldmlzaW9uIDIyOTMyMykK KysrIGV0Yy9wZXJpb2RpYy9kYWlseS80MDYuc3RhdHVzLWdtaXJyb3IJKHdvcmtpbmcgY29weSkK QEAgLTMsMTYgKzMsMTEgQEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9i YWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0 Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVy aW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2Rp Yy5zdWJyCiAKLWNhc2UgIiRkYWlseV9zdGF0dXNfZ21pcnJvcl9lbmFibGUiIGluCi0gICAgW1l5 XVtFZV1bU3NdKQorcmM9MAorCitpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19nbWlycm9yX2Vu YWJsZTsgdGhlbgogCWVjaG8KIAllY2hvICdDaGVja2luZyBzdGF0dXMgb2YgZ21pcnJvcig4KSBk ZXZpY2VzOicKIApAQCAtMjAsMTUgKzE1LDEwIEBACiAJCWNvbXBvbmVudHM9IiQoZ21pcnJvciBz dGF0dXMgLXMgfCBmZ3JlcCAtdiBDT01QTEVURSkiCiAJCWlmIFsgIiR7Y29tcG9uZW50c30iIF07 IHRoZW4KIAkJCXJjPTMKLQkJZWxzZQotCQkJcmM9MAogCQlmaQogCWVsc2UKIAkJcmM9MgogCWZp Ci0JOzsKK2ZpCiAKLSAgICAqKSAgcmM9MDs7Ci1lc2FjCi0KIGV4aXQgJHJjCkluZGV4OiBldGMv cGVyaW9kaWMvZGFpbHkvMzAwLmNhbGVuZGFyCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9k YWlseS8zMDAuY2FsZW5kYXIJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWls eS8zMDAuY2FsZW5kYXIJKHdvcmtpbmcgY29weSkKQEAgLTgsMjIgKzgsMTUgQEAKICMgb3IgcnVu IGl0IGZyb20geW91ciB+Ly5wcm9maWxlIG9yIH4vLmxvZ2luLgogIwogCi0jIElmIHRoZXJlIGlz IGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBb IC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1 bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMv cGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfY2FsZW5kYXJfZW5hYmxlIiBpbgotICAgIFtZ eV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5ZXNubyBkYWlseV9jYWxlbmRhcl9lbmFibGU7 IHRoZW4KIAllY2hvICIiCiAJZWNobyAiUnVubmluZyBjYWxlbmRhcjoiCiAKLQljYWxlbmRhciAt YSAmJiByYz0wIHx8IHJjPTM7OworCWNhbGVuZGFyIC1hICYmIHJjPTAgfHwgcmM9MworZmkKIAot ICAgICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9kYWls eS81MDAucXVldWVydW4KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL2RhaWx5LzUwMC5xdWV1 ZXJ1bgkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2RhaWx5LzUwMC5xdWV1ZXJ1 bgkod29ya2luZyBjb3B5KQpAQCAtMywzNCArMywyMiBAQAogIyAkRnJlZUJTRCQKICMKIAotIyBJ ZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNrIGl0IGlu LgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQotdGhlbgotICAgIC4g L2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2NvbmZzCi1m aQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJGRhaWx5X3F1ZXVlcnVuX2VuYWJsZSIg aW4KLSAgICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNreWVzbm8gZGFpbHlfcXVldWVy dW5fZW5hYmxlOyB0aGVuCiAJaWYgWyAhIC14IC91c3Ivc2Jpbi9zZW5kbWFpbCBdCiAJdGhlbgot CSAgICBlY2hvICckZGFpbHlfcXVldWVydW5fZW5hYmxlIGlzIHNldCBidXQgL3Vzci9zYmluL3Nl bmRtYWlsJyBcCisJICAgIGVyciAyICckZGFpbHlfcXVldWVydW5fZW5hYmxlIGlzIHNldCBidXQg L3Vzci9zYmluL3NlbmRtYWlsJyBcCiAJCSJpc24ndCBleGVjdXRhYmxlIgotCSAgICByYz0yCi0J ZWxzZQotCSAgICAvdXNyL3NiaW4vc2VuZG1haWwgLXEgPi9kZXYvbnVsbCAyPiYxICYKLQkgICAg Y2FzZSAiJGRhaWx5X3N1Ym1pdF9xdWV1ZXJ1biIgaW4KLQkgICAgW1l5XVtFZV1bU3NdKQotCQlp ZiBbIC1mIC9ldGMvbWFpbC9zdWJtaXQuY2YgXQotCQl0aGVuCi0JCSAgICAvdXNyL3NiaW4vc2Vu ZG1haWwgLXEgLUFjID4vZGV2L251bGwgMj4mMSAmCi0JCWZpOzsKLQkgICAgZXNhYwotCSAgICBy Yz0wCi0JZmk7OworCWZpCisJL3Vzci9zYmluL3NlbmRtYWlsIC1xID4vZGV2L251bGwgMj4mMSAm CisJaWYgY2hlY2t5ZXNubyBkYWlseV9zdWJtaXRfcXVldWVydW47IHRoZW4KKwkgICAgaWYgWyAt ZiAvZXRjL21haWwvc3VibWl0LmNmIF07IHRoZW4KKwkJL3Vzci9zYmluL3NlbmRtYWlsIC1xIC1B YyA+L2Rldi9udWxsIDI+JjEgJgorCSAgICBmaQorCWZpCitmaQogCi0gICAgKikgIHJjPTA7Owot ZXNhYwotCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzQyMC5zdGF0dXMtbmV0 d29yawo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvNDIwLnN0YXR1cy1uZXR3b3Jr CShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvZGFpbHkvNDIwLnN0YXR1cy1uZXR3 b3JrCSh3b3JraW5nIGNvcHkpCkBAIC0zLDI3ICszLDIwIEBACiAjICRGcmVlQlNEJAogIwogCi0j IElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQg aW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAg LiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMK LWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfc3RhdHVzX25ldHdvcmtf ZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5ZXNubyBkYWls eV9zdGF0dXNfbmV0d29ya19lbmFibGU7IHRoZW4KIAllY2hvICIiCiAJZWNobyAiTmV0d29yayBp bnRlcmZhY2Ugc3RhdHVzOiIKIAotCWNhc2UgIiRkYWlseV9zdGF0dXNfbmV0d29ya191c2VkbnMi IGluCi0JICAgIFtZeV1bRWVdW1NzXSkKLQkJbmV0c3RhdCAtaSAmJiByYz0wIHx8IHJjPTM7Owot CSAgICAqKQotCQluZXRzdGF0IC1pbiAmJiByYz0wIHx8IHJjPTM7OwotCWVzYWM7OworCWlmIGNo ZWNreWVzbm8gZGFpbHlfc3RhdHVzX25ldHdvcmtfdXNlZG5zOyB0aGVuCisJCW5ldHN0YXRfZmxh Z3M9Ii1pIgorCWVsc2UKKwkJbmV0c3RhdF9mbGFncz0iLWluIgorCWZpCisJbmV0c3RhdCAkbmV0 c3RhdF9mbGFncyAmJiByYz0wIHx8IHJjPTMKK2ZpCiAKLSAgICAqKSAgcmM9MDs7Ci1lc2FjCi0K IGV4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvZGFpbHkvNDcwLnN0YXR1cy1uYW1lZAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvNDcwLnN0YXR1cy1uYW1lZAkocmV2aXNpb24g MjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2RhaWx5LzQ3MC5zdGF0dXMtbmFtZWQJKHdvcmtpbmcg Y29weSkKQEAgLTMsNDMgKzMsMjQgQEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMg YSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsg LXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVs dHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9w ZXJpb2RpYy5zdWJyCiAKLWNhdG1zZ3MoKSB7Ci0JZmluZCAvdmFyL2xvZyAtbmFtZSAnbWVzc2Fn ZXMuKicgLW10aW1lIC0yIHwKLQkgICAgc29ydCAtdC4gLXIgLW4gLWsgMiwyIHwKLQkgICAgd2hp bGUgcmVhZCBmCi0JICAgIGRvCi0JCWNhc2UgJGYgaW4KLQkJICAgICouZ3opCXpjYXQgLWYgJGY7 OwotCQkgICAgKi5iejIpCWJ6Y2F0IC1mICRmOzsKLQkJZXNhYwotCSAgICBkb25lCi0JWyAtZiAv dmFyL2xvZy9tZXNzYWdlcyBdICYmIGNhdCAvdmFyL2xvZy9tZXNzYWdlcwotfQorcmM9MAogCi1j YXNlICIkZGFpbHlfc3RhdHVzX25hbWVkX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCitp ZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19uYW1lZF9lbmFibGU7IHRoZW4KIAllY2hvCiAJZWNo byAnQ2hlY2tpbmcgZm9yIGRlbmllZCB6b25lIHRyYW5zZmVycyAoQVhGUiBhbmQgSVhGUik6Jwog CiAJc3RhcnQ9YGRhdGUgLXYtMWQgJyslYiAlZSdgCi0JcmM9JChjYXRtc2dzIHwKKwlyYz0kKGNh dGxvZ3MgIm1lc3NhZ2VzIiAvdmFyL2xvZyB8CiAJICAgIGZncmVwIC1FICJeJHN0YXJ0LipuYW1l ZFxbW1s6ZGlnaXQ6XV0rXF06IHRyYW5zZmVyIG9mIC4qZmFpbGVkIC4qOiBSRUZVU0VEIiB8CiAJ ICAgIHNlZCAtZSAicy8uKnRyYW5zZmVyIG9mIFwnXCguKlwpXC9JTlwnIGZyb20gXCguKlwpI1sw LTldKjogLiovXDEgZnJvbSBcMi8iIHwKIAkgICAgc29ydCAtZiB8IHVuaXEgLWljIHwgKAotCQl1 c2VkbnM9MAotCQljYXNlICIkZGFpbHlfc3RhdHVzX25hbWVkX3VzZWRucyIgaW4KLQkJJycpIDs7 Ci0JCVt5WV1bZUVdW3NTXSkgdXNlZG5zPTEgOzsKLQkJZXNhYwotCisJCWlmIGNoZWNreWVzbm8g ZGFpbHlfc3RhdHVzX25hbWVkX3VzZWRuczsgdGhlbgorCQkJdXNlZG5zPTEKKwkJZWxzZQorCQkJ dXNlZG5zPTAKKwkJZmkKIAkJd2hpbGUgcmVhZCBsaW5lIDtkbwogCQkJaXBhZGRyPWBlY2hvICIk bGluZSIgfCBzZWQgLWUgJ3MvXi4qZnJvbSAvLydgCiAJCQlpZiBbICR1c2VkbnMgLWVxIDEgXTsg dGhlbgpAQCAtNTQsOSArMzUsNiBAQAogCQlkb25lICkgfCBcCiAJCXRlZSAvZGV2L3N0ZGVyciB8 IHdjIC1sKQogCVsgJHJjIC1ndCAwIF0gJiYgcmM9MQotCTs7CitmaQogCi0gICAgKikgIHJjPTA7 OwotZXNhYwotCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzIxMC5iYWNrdXAt YWxpYXNlcwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvMjEwLmJhY2t1cC1hbGlh c2VzCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvZGFpbHkvMjEwLmJhY2t1cC1h bGlhc2VzCSh3b3JraW5nIGNvcHkpCkBAIC0zLDE2ICszLDExIEBACiAjICRGcmVlQlNEJAogIwog Ci0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sg aXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0g ICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29u ZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfYmFja3VwX2FsaWFz ZXNfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5ZXNubyBk YWlseV9iYWNrdXBfYWxpYXNlc19lbmFibGU7IHRoZW4KIAlpZiBbICEgLWYgL2V0Yy9tYWlsL2Fs aWFzZXMgXQogCXRoZW4KIAkgICAgZWNobyAnJGRhaWx5X2JhY2t1cF9hbGlhc2VzX2VuYWJsZSBp cyBlbmFibGVkIGJ1dCcgXApAQCAtMjAsNyArMTUsNiBAQAogCSAgICByYz0yCiAJZWxzZQogCSAg ICBiYWs9L3Zhci9iYWNrdXBzCi0JICAgIHJjPTAKIAogCSAgICBlY2hvICIiCiAJICAgIGVjaG8g IkJhY2tpbmcgdXAgbWFpbCBhbGlhc2VzOiIKQEAgLTMxLDE3ICsyNSwxNCBAQAogCQljcCAtcCAv ZXRjL21haWwvYWxpYXNlcyAkYmFrL2FsaWFzZXMuYmFrIHx8IHJjPTMKIAkgICAgZmkKIAotCSAg ICBpZiAhIGNtcCAtcyAkYmFrL2FsaWFzZXMuYmFrIC9ldGMvbWFpbC9hbGlhc2VzCisJICAgIGlm IFsgJHJjIC1lcSAwIF0gJiYgISBjbXAgLXMgJGJhay9hbGlhc2VzLmJhayAvZXRjL21haWwvYWxp YXNlcwogCSAgICB0aGVuCi0JCVsgJHJjIC1sdCAxIF0gJiYgcmM9MQogCQllY2hvICIkaG9zdCBh bGlhc2VzIGRpZmZzOiIKIAkJZGlmZiAtdSAkYmFrL2FsaWFzZXMuYmFrIC9ldGMvbWFpbC9hbGlh c2VzCiAJCW12ICRiYWsvYWxpYXNlcy5iYWsgJGJhay9hbGlhc2VzLmJhazIKIAkJY3AgLXAgL2V0 Yy9tYWlsL2FsaWFzZXMgJGJhay9hbGlhc2VzLmJhayB8fCByYz0zCiAJICAgIGZpCi0JZmk7Owor CWZpCitmaQogCi0gICAgKikgIHJjPTA7OwotZXNhYwotCiBleGl0ICRyYwpJbmRleDogZXRjL3Bl cmlvZGljL2RhaWx5LzQwNC5zdGF0dXMtemZzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9k YWlseS80MDQuc3RhdHVzLXpmcwkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2Rh aWx5LzQwNC5zdGF0dXMtemZzCSh3b3JraW5nIGNvcHkpCkBAIC0zLDE2ICszLDExIEBACiAjICRG cmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9u IGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29u ZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2Vf cGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlf c3RhdHVzX3pmc19lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAorCitpZiBjaGVj a3llc25vIGRhaWx5X3N0YXR1c196ZnNfZW5hYmxlOyB0aGVuCiAJZWNobwogCWVjaG8gJ0NoZWNr aW5nIHN0YXR1cyBvZiB6ZnMgcG9vbHM6JwogCkBAIC0yNiwxMSArMjEsNiBAQAogCWVsc2UKIAkJ cmM9MQogCWZpCi0JOzsKK2ZpCiAKLSAgICAqKQotCXJjPTAKLQk7OwotZXNhYwotCiBleGl0ICRy YwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzIyMC5iYWNrdXAtcGtnZGIKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gZXRjL3BlcmlvZGljL2RhaWx5LzIyMC5iYWNrdXAtcGtnZGIJKHJldmlzaW9uIDIyOTMyMykK KysrIGV0Yy9wZXJpb2RpYy9kYWlseS8yMjAuYmFja3VwLXBrZ2RiCSh3b3JraW5nIGNvcHkpCkBA IC0zLDE4ICszLDExIEBACiAjICRGcmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFs IHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMv ZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3Blcmlv ZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMu c3VicgogCiByYz0wCiAKLWNhc2UgIiRkYWlseV9iYWNrdXBfcGtnZGJfZW5hYmxlIiBpbgotICAg IFtZeV1bRWVdW1NzXSkKK2lmIGNoZWNreWVzbm8gZGFpbHlfYmFja3VwX3BrZ2RiX2VuYWJsZTsg dGhlbgogCWJhaz0iJHtkYWlseV9iYWNrdXBfcGtnZGJfZGlyOi0vdmFyL2JhY2t1cHN9IgogCWJh a19maWxlPSIke2Jha30vcGtnZGIuYmFrLnRieiIKIApAQCAtMjMsMTAgKzE2LDEwIEBACiAKIAlp ZiBbICEgLWQgIiRiYWsiIF0KIAl0aGVuCi0JICAgIGluc3RhbGwgLWQgLW8gcm9vdCAtZyB3aGVl bCAtbSA3NTAgJGJhayB8fCB7Ci0JCWVjaG8gJyRkYWlseV9iYWNrdXBfcGtnZGJfZW5hYmxlIGlz IGVuYWJsZWQgYnV0JyBcCisJICAgIGlmICEgaW5zdGFsbCAtZCAtbyByb290IC1nIHdoZWVsIC1t IDc1MCAkYmFrOyB0aGVuCisJCWVyciAyICckZGFpbHlfYmFja3VwX3BrZ2RiX2VuYWJsZSBpcyBl bmFibGVkIGJ1dCcgXAogCQkgICAgIiRkYWlseV9iYWNrdXBfcGtnZGJfZGJkaXIgZG9lc24ndCBl eGlzdCIgOwotCQlleGl0IDIgOyB9CisJICAgIGZpCiAJZmkKIAogCWVjaG8gJycKQEAgLTQ1LDcg KzM4LDcgQEAKIAkgICAgbXYgIiR7bmV3X2Jha19maWxlfSIgIiR7YmFrX2ZpbGV9IgogCWVsc2UK IAkgICAgcmM9MwotCWZpIDs7Ci1lc2FjCisJZmkKK2ZpCiAKIGV4aXQgJHJjCkluZGV4OiBldGMv cGVyaW9kaWMvZGFpbHkvMzEwLmFjY291bnRpbmcKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGlj L2RhaWx5LzMxMC5hY2NvdW50aW5nCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMv ZGFpbHkvMzEwLmFjY291bnRpbmcJKHdvcmtpbmcgY29weSkKQEAgLTMsMTYgKzMsMTEgQEAKICMg JEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRp b24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5j b25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJj ZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKLWNhc2UgIiRkYWls eV9hY2NvdW50aW5nX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNo ZWNreWVzbm8gZGFpbHlfYWNjb3VudGluZ19lbmFibGU7IHRoZW4KIAlpZiBbICEgLWYgL3Zhci9h Y2NvdW50L2FjY3QgXQogCXRoZW4KIAkgICAgZWNobyAnJGRhaWx5X2FjY291bnRpbmdfZW5hYmxl IGlzIHNldCBidXQgL3Zhci9hY2NvdW50L2FjY3QnIFwKQEAgLTI4LDcgKzIzLDYgQEAKIAkgICAg ZWNobyAiUm90YXRpbmcgYWNjb3VudGluZyBsb2dzIGFuZCBnYXRoZXJpbmcgc3RhdGlzdGljczoi CiAKIAkgICAgY2QgL3Zhci9hY2NvdW50Ci0JICAgIHJjPTAKIAogCSAgICBuPSQoKCAkZGFpbHlf YWNjb3VudGluZ19zYXZlIC0gMSApKQogCSAgICBmb3IgZiBpbiBhY2N0Lio7IGRvCkBAIC01Mywx MyArNDcsMTAgQEAKIAkgICAgc2EgLXMgJGRhaWx5X2FjY291bnRpbmdfZmxhZ3MgL3Zhci9hY2Nv dW50L2FjY3QubWVyZ2UgfHwgcmM9MwogCSAgICBybSBhY2N0Lm1lcmdlCiAKLQkgICAgY2FzZSAi JGRhaWx5X2FjY291bnRpbmdfY29tcHJlc3MiIGluCi0JCVtZeV1bRWVdW1NzXSkKLQkJICAgIGd6 aXAgLWYgYWNjdC4wIHx8IHJjPTM7OwotCSAgICBlc2FjCi0JZmk7OworCSAgICBpZiBjaGVja3ll c25vIGRhaWx5X2FjY291bnRpbmdfY29tcHJlc3M7IHRoZW4KKwkJZ3ppcCAtZiBhY2N0LjAgfHwg cmM9MworCSAgICBmaQorCWZpCitmaQogCi0gICAgKikgIHJjPTA7OwotZXNhYwotCiBleGl0ICRy YwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzE1MC5jbGVhbi1ob3N0c3RhdAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvMTUwLmNsZWFuLWhvc3RzdGF0CShyZXZpc2lvbiAyMjkz MjMpCisrKyBldGMvcGVyaW9kaWMvZGFpbHkvMTUwLmNsZWFuLWhvc3RzdGF0CSh3b3JraW5nIGNv cHkpCkBAIC01LDI1ICs1LDE4IEBACiAjIFJlbW92ZSBzdGFsZSBwZXJzaXN0ZW50IGhvc3Qgc3Rh dHVzIGZpbGVzCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRp b24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5j b25mIF07IHRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJj ZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKLWNhc2UgIiRkYWls eV9jbGVhbl9ob3N0c3RhdF9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAorCitp ZiBjaGVja3llc25vIGRhaWx5X2NsZWFuX2hvc3RzdGF0X2VuYWJsZTsgdGhlbgogCWlmIFsgLXog IiQoaG9zdHN0YXQgMj4mMSkiIF07IHRoZW4KIAkgICAgcmM9MgogCWVsc2UKIAkgICAgZWNobyAi IgogCSAgICBlY2hvICJSZW1vdmluZyBzdGFsZSBlbnRyaWVzIGZyb20gc2VuZG1haWwgaG9zdCBz dGF0dXMgY2FjaGU6IgotCSAgICByYz0wCiAJICAgIHB1cmdlc3RhdCB8fCByYz0xCi0JZmk7Owor CWZpCitmaQogCi0gICAgKikgIHJjPTA7OwotZXNhYwotCiBleGl0ICRyYwpJbmRleDogZXRjL3Bl cmlvZGljL2RhaWx5LzQ4MC5zdGF0dXMtbnRwZAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMv ZGFpbHkvNDgwLnN0YXR1cy1udHBkCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMv ZGFpbHkvNDgwLnN0YXR1cy1udHBkCSh3b3JraW5nIGNvcHkpCkBAIC0zLDE4ICszLDExIEBACiAj ICRGcmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0 aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMu Y29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3Vy Y2VfcGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCiByYz0wCiAKLWNh c2UgIiRkYWlseV9zdGF0dXNfbnRwZF9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQoraWYg Y2hlY2t5ZXNubyBkYWlseV9zdGF0dXNfbnRwZF9lbmFibGU7IHRoZW4KIAllY2hvICIiCiAJZWNo byAiTlRQIHN0YXR1czoiCiAKQEAgLTIyLDcgKzE1LDYgQEAKIAlpZiBbIC16ICIkc3luY2hyb25p emVkIiBdOyB0aGVuCiAJCXJjPTEKIAlmaQotCTs7Ci1lc2FjCitmaQogCiBleGl0ICRyYwpJbmRl eDogZXRjL3BlcmlvZGljL2RhaWx5LzQwMC5zdGF0dXMtZGlza3MKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRj L3BlcmlvZGljL2RhaWx5LzQwMC5zdGF0dXMtZGlza3MJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0 Yy9wZXJpb2RpYy9kYWlseS80MDAuc3RhdHVzLWRpc2tzCSh3b3JraW5nIGNvcHkpCkBAIC0zLDE2 ICszLDExIEBACiAjICRGcmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3Rl bSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVs dHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNv bmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3Vicgog Ci1jYXNlICIkZGFpbHlfc3RhdHVzX2Rpc2tzX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10p CityYz0wCisKK2lmIGNoZWNreWVzbm8gZGFpbHlfc3RhdHVzX2Rpc2tzX2VuYWJsZTsgdGhlbgog CWVjaG8gIiIKIAllY2hvICJEaXNrIHN0YXR1czoiCiAKQEAgLTI0LDkgKzE5LDcgQEAKIAlmaQog CiAJZWNobyAiIgotCWR1bXAgVyB8fCByYz0zOzsKKwlkdW1wIFcgfHwgcmM9MworZmkKIAotICAg ICopICByYz0wOzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9kYWlseS80 MDcuc3RhdHVzLWdyYWlkMwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvZGFpbHkvNDA3LnN0 YXR1cy1ncmFpZDMJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9kYWlseS80MDcu c3RhdHVzLWdyYWlkMwkod29ya2luZyBjb3B5KQpAQCAtMywxNiArMywxMSBAQAogIyAkRnJlZUJT RCQKICMKIAotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxl LCBzdWNrIGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQot dGhlbgotICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3Blcmlv ZGljX2NvbmZzCi1maQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJGRhaWx5X3N0YXR1 c19ncmFpZDNfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hlY2t5 ZXNubyBkYWlseV9zdGF0dXNfZ3JhaWQzX2VuYWJsZTsgdGhlbgogCWVjaG8KIAllY2hvICdDaGVj a2luZyBzdGF0dXMgb2YgZ3JhaWQzKDgpIGRldmljZXM6JwogCkBAIC0yMCwxNSArMTUsMTAgQEAK IAkJY29tcG9uZW50cz0iJChncmFpZDMgc3RhdHVzIC1zIHwgZmdyZXAgLXYgQ09NUExFVEUpIgog CQlpZiBbICIke2NvbXBvbmVudHN9IiBdOyB0aGVuCiAJCQlyYz0zCi0JCWVsc2UKLQkJCXJjPTAK IAkJZmkKIAllbHNlCiAJCXJjPTIKIAlmaQotCTs7CitmaQogCi0gICAgKikgIHJjPTA7OwotZXNh YwotCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL2RhaWx5LzIwMC5iYWNrdXAtcGFzc3dk Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9kYWlseS8yMDAuYmFja3VwLXBhc3N3ZAkocmV2 aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2RhaWx5LzIwMC5iYWNrdXAtcGFzc3dkCSh3 b3JraW5nIGNvcHkpCkBAIC0zLDE2ICszLDExIEBACiAjICRGcmVlQlNEJAogIwogCi0jIElmIHRo ZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0j Ci1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRj L2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisu IC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfYmFja3VwX3Bhc3N3ZF9lbmFibGUi IGluCi0gICAgW1l5XVtFZV1bU3NdKQorcmM9MAorCitpZiBjaGVja3llc25vIGRhaWx5X2JhY2t1 cF9wYXNzd2RfZW5hYmxlOyB0aGVuCiAJaWYgWyAhIC1mIC9ldGMvbWFzdGVyLnBhc3N3ZCBdCiAJ dGhlbgogCSAgICBlY2hvICckZGFpbHlfYmFja3VwX3Bhc3N3ZF9lbmFibGUiIGlzIHNldCBidXQg L2V0Yy9tYXN0ZXIucGFzc3dkJyBcCkBAIC0yNSw3ICsyMCw2IEBACiAJICAgIHJjPTIKIAllbHNl CiAJICAgIGJhaz0vdmFyL2JhY2t1cHMKLQkgICAgcmM9MAogCiAJICAgIGVjaG8gIiIKIAkgICAg ZWNobyAiQmFja3VwIHBhc3N3ZCBhbmQgZ3JvdXAgZmlsZXM6IgpAQCAtNjksOSArNjMsNyBAQAog CQllY2hvICJWZXJpZnlpbmcgZ3JvdXAgZmlsZSBzeW50YXg6IgogCSAgICAgICAgY2hrZ3JwIC9l dGMvZ3JvdXAgfHwgcmM9MwogCSAgICBmaQotCWZpOzsKKwlmaQorZmkKIAotICAgICopICByYz0w OzsKLWVzYWMKLQogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9kYWlseS80MDguc3RhdHVz LWdzdHJpcGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL2RhaWx5LzQwOC5zdGF0dXMtZ3N0 cmlwZQkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2RhaWx5LzQwOC5zdGF0dXMt Z3N0cmlwZQkod29ya2luZyBjb3B5KQpAQCAtMywxNiArMywxMSBAQAogIyAkRnJlZUJTRCQKICMK IAotIyBJZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNr IGl0IGluLgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQotdGhlbgot ICAgIC4gL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2Nv bmZzCi1maQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJGRhaWx5X3N0YXR1c19nc3Ry aXBlX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNreWVzbm8g ZGFpbHlfc3RhdHVzX2dzdHJpcGVfZW5hYmxlOyB0aGVuCiAJZWNobwogCWVjaG8gJ0NoZWNraW5n IHN0YXR1cyBvZiBnc3RyaXBlKDgpIGRldmljZXM6JwogCkBAIC0yMCwxNSArMTUsMTAgQEAKIAkJ Y29tcG9uZW50cz0iJChnc3RyaXBlIHN0YXR1cyAtcyB8IGZncmVwIC12IFVQKSIKIAkJaWYgWyAi JHtjb21wb25lbnRzfSIgXTsgdGhlbgogCQkJcmM9MwotCQllbHNlCi0JCQlyYz0wCiAJCWZpCiAJ ZWxzZQogCQlyYz0yCiAJZmkKLQk7OworZmkKIAotICAgICopICByYz0wOzsKLWVzYWMKLQogZXhp dCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9kYWlseS8xMjAuY2xlYW4tcHJlc2VydmUKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gZXRjL3BlcmlvZGljL2RhaWx5LzEyMC5jbGVhbi1wcmVzZXJ2ZQkocmV2aXNpb24g MjI5MzIzKQorKysgZXRjL3BlcmlvZGljL2RhaWx5LzEyMC5jbGVhbi1wcmVzZXJ2ZQkod29ya2lu ZyBjb3B5KQpAQCAtNSw0OSArNSwzNyBAQAogIyBSZW1vdmUgc3RhbGUgZmlsZXMgaW4gL3Zhci9w cmVzZXJ2ZQogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9u IGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29u ZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2Vf cGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlf Y2xlYW5fcHJlc2VydmVfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYg Y2hlY2t5ZXNubyBkYWlseV9jbGVhbl9wcmVzZXJ2ZV9lbmFibGU7IHRoZW4KIAlpZiBbIC16ICIk ZGFpbHlfY2xlYW5fcHJlc2VydmVfZGF5cyIgXQogCXRoZW4KLQkgICAgZWNobyAnJGRhaWx5X2Ns ZWFuX3ByZXNlcnZlX2VuYWJsZSBpcyBzZXQgYnV0JyBcCisJICAgIGVyciAyICckZGFpbHlfY2xl YW5fcHJlc2VydmVfZW5hYmxlIGlzIHNldCBidXQnIFwKIAkJJyRkYWlseV9jbGVhbl9wcmVzZXJ2 ZV9kYXlzIGlzIG5vdCcKLQkgICAgcmM9MgogCWVsaWYgWyAhIC1kIC92YXIvcHJlc2VydmUgXQog CXRoZW4KLQkgICAgZWNobyAnJGRhaWx5X2NsZWFuX3ByZXNlcnZlX2VuYWJsZSBpcyBzZXQgYnV0 IC92YXIvcHJlc2VydmUnIFwKKwkgICAgZXJyIDIgJyRkYWlseV9jbGVhbl9wcmVzZXJ2ZV9lbmFi bGUgaXMgc2V0IGJ1dCAvdmFyL3ByZXNlcnZlJyBcCiAJCSJkb2Vzbid0IGV4aXN0IgotCSAgICBy Yz0yCiAJZWxzZQotCSAgICBlY2hvICIiCi0JICAgIGVjaG8gIlJlbW92aW5nIHN0YWxlIGZpbGVz IGZyb20gL3Zhci9wcmVzZXJ2ZToiCisJICAgIGlmIGNoZWNreWVzbm8gZGFpbHlfY2xlYW5fcHJl c2VydmVfdmVyYm9zZTsgdGhlbgorCQllY2hvICIiCisJCWVjaG8gIlJlbW92aW5nIHN0YWxlIGZp bGVzIGZyb20gL3Zhci9wcmVzZXJ2ZToiCiAKKwkJcHJpbnQ9LXByaW50CisJICAgIGVsc2UKKwkJ cHJpbnQ9CisJICAgIGZpCiAJICAgIGlmIGNkIC92YXIvcHJlc2VydmUKIAkgICAgdGhlbgotCQlj YXNlICIkZGFpbHlfY2xlYW5fcHJlc2VydmVfdmVyYm9zZSIgaW4KLQkJICAgIFtZeV1bRWVdW1Nz XSkKLQkJCXByaW50PS1wcmludDs7Ci0JCSAgICAqKQotCQkJcHJpbnQ9OzsKLQkJZXNhYwotCiAJ CXJjPSQoZmluZCAuICEgLW5hbWUgLiAtbXRpbWUgKyRkYWlseV9jbGVhbl9wcmVzZXJ2ZV9kYXlz IFwKIAkJICAgIC1kZWxldGUgJHByaW50IHwgdGVlIC9kZXYvc3RkZXJyIHwgd2MgLWwpCi0JCVsg LXogIiRwcmludCIgXSAmJiByYz0wCiAJCVsgJHJjIC1ndCAxIF0gJiYgcmM9MQogCSAgICBlbHNl CiAJCXJjPTMKIAkgICAgZmkKLQlmaTs7CisJZmkKK2ZpCiAKLSAgICAqKSAgcmM9MDs7Ci1lc2Fj Ci0KIGV4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvc2VjdXJpdHkvNTAwLmlwZndkZW5pZWQK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL3NlY3VyaXR5LzUwMC5pcGZ3ZGVuaWVkCShyZXZp c2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvc2VjdXJpdHkvNTAwLmlwZndkZW5pZWQJKHdv cmtpbmcgY29weSkKQEAgLTI3LDI3ICsyNywyNCBAQAogIyAkRnJlZUJTRCQKICMKIAotIyBJZiB0 aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNrIGl0IGluLgot IwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQotdGhlbgotICAgIC4gL2V0 Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2NvbmZzCi1maQot CisuIC9ldGMvcGVyaW9kaWMuc3VicgogLiAvZXRjL3BlcmlvZGljL3NlY3VyaXR5L3NlY3VyaXR5 LmZ1bmN0aW9ucwogCiByYz0wCiAKLWNhc2UgIiRkYWlseV9zdGF0dXNfc2VjdXJpdHlfaXBmd2Rl bmllZF9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQotCVRNUD1gbWt0ZW1wIC10IHNlY3Vy aXR5YAotCWlmIGlwZncgLWEgbGlzdCAyPi9kZXYvbnVsbCB8IGVncmVwICJkZW55fHJlc2V0fHVu cmVhY2giID4gJHtUTVB9OyB0aGVuCi0JICBjaGVja19kaWZmIG5ld19vbmx5IGlwZncgJHtUTVB9 ICIke2hvc3R9IGlwZncgZGVuaWVkIHBhY2tldHM6IgoraWYgY2hlY2t5ZXNubyBkYWlseV9zdGF0 dXNfc2VjdXJpdHlfaXBmd2RlbmllZF9lbmFibGU7IHRoZW4KKwlpZiBUTVA9JChta3RlbXAgLXQg c2VjdXJpdHkpOyB0aGVuCisJCWlmIGlwZncgLWEgbGlzdCAyPi9kZXYvbnVsbCB8IGVncmVwICJk ZW55fHJlc2V0fHVucmVhY2giID4gJHtUTVB9OyB0aGVuCisJCQljaGVja19kaWZmIG5ld19vbmx5 IGlwZncgJHtUTVB9IFwKKwkJCSAgICAiJHtob3N0fSBpcGZ3IGRlbmllZCBwYWNrZXRzOiIKKwkJ CXJjPSQ/CisJCWVsc2UKKwkJCXJjPTEKKwkJZmkKKwkJcm0gLWYgJHtUTVB9CisJZWxzZQorCQly Yz0zCiAJZmkKLQlyYz0kPwotCXJtIC1mICR7VE1QfTs7Ci0gICAgKikJcmM9MDs7Ci1lc2FjCitm aQogCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL3NlY3VyaXR5LzEwMC5jaGtzZXR1aWQK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL3NlY3VyaXR5LzEwMC5jaGtzZXR1aWQJKHJldmlz aW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS8xMDAuY2hrc2V0dWlkCSh3b3Jr aW5nIGNvcHkpCkBAIC0yNywyMCArMjcsMTIgQEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhl cmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMK LWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMv ZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKLQor LiAvZXRjL3BlcmlvZGljLnN1YnIKIC4gL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS9zZWN1cml0eS5m dW5jdGlvbnMKIAogcmM9MAogCi1jYXNlICIkZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2Noa3NldHVp ZF9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQoraWYgY2hlY2t5ZXNubyBkYWlseV9zdGF0 dXNfc2VjdXJpdHlfY2hrc2V0dWlkX2VuYWJsZTsgdGhlbgogCWVjaG8gIiIKIAllY2hvICdDaGVj a2luZyBzZXR1aWQgZmlsZXMgYW5kIGRldmljZXM6JwogCU1QPWBtb3VudCAtdCB1ZnMsemZzIHwg YXdrICckMCAhfiAvbm8oc3VpZHxleGVjKS8geyBwcmludCAkMyB9J2AKQEAgLTQ5LDEwICs0MSw2 IEBACiAJICAgIFwoIC1wZXJtIC11K3MgLW9yIC1wZXJtIC1nK3MgXCkgLWV4ZWMgbHMgLWxpVGQg XHtcfSBcKyB8CiAJY2hlY2tfZGlmZiBzZXR1aWQgLSAiJHtob3N0fSBzZXR1aWQgZGlmZnM6Igog CXJjPSQ/Ci0JOzsKLSAgICAqKQotCXJjPTAKLQk7OwotZXNhYworZmkKIAogZXhpdCAkcmMKSW5k ZXg6IGV0Yy9wZXJpb2RpYy9zZWN1cml0eS81MjAucGZkZW5pZWQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRj L3BlcmlvZGljL3NlY3VyaXR5LzUyMC5wZmRlbmllZAkocmV2aXNpb24gMjI5MzIzKQorKysgZXRj L3BlcmlvZGljL3NlY3VyaXR5LzUyMC5wZmRlbmllZAkod29ya2luZyBjb3B5KQpAQCAtMjcsMjcg KzI3LDMyIEBACiAjICRGcmVlQlNEJAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3Rl bSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVs dHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNv bmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCi0KKy4gL2V0Yy9wZXJpb2RpYy5zdWJy CiAuIC9ldGMvcGVyaW9kaWMvc2VjdXJpdHkvc2VjdXJpdHkuZnVuY3Rpb25zCiAKIHJjPTAKIAot Y2FzZSAiJGRhaWx5X3N0YXR1c19zZWN1cml0eV9wZmRlbmllZF9lbmFibGUiIGluCi0gICAgW1l5 XVtFZV1bU3NdKQotCVRNUD1gbWt0ZW1wIC10IHNlY3VyaXR5YAotCWlmIHBmY3RsIC1zciAtdiAy Pi9kZXYvbnVsbCB8IG5hd2sgJ3tpZiAoL15ibG9jay8pIHtidWY9JDA7IGdldGxpbmU7IGdzdWIo IiArIiwiICIsJDApOyBwcmludCBidWYkMDt9IH0nID4gJHtUTVB9OyB0aGVuCi0JICBjaGVja19k aWZmIG5ld19vbmx5IHBmICR7VE1QfSAiJHtob3N0fSBwZiBkZW5pZWQgcGFja2V0czoiCitpZiBj aGVja3llc25vIGRhaWx5X3N0YXR1c19zZWN1cml0eV9wZmRlbmllZF9lbmFibGU7IHRoZW4KKwlp ZiBUTVA9JChta3RlbXAgLXQgc2VjdXJpdHkpOyB0aGVuCisJCXBmY3RsIC1zciAtdiAyPi9kZXYv bnVsbCB8IFwKKwkJICAgIG5hd2sgJ3sKKwkJCWlmICgvXmJsb2NrLykgeworCQkJCWJ1Zj0kMDsK KwkJCQlnZXRsaW5lOworCQkJCWdzdWIoIiArIiwiICIsJDApOworCQkJCXByaW50IGJ1ZiQwOwor CQkJfQorCQl9JyA+ICR7VE1QfQorCQlpZiBbICQ/IC1lcSAwIF07IHRoZW4KKwkJCWNoZWNrX2Rp ZmYgbmV3X29ubHkgcGYgJHtUTVB9ICIke2hvc3R9IHBmIGRlbmllZCBwYWNrZXRzOiIKKwkJCXJj PSQ/CisJCWVsc2UKKwkJCXJjPTEKKwkJZmkKKwkJcm0gLWYgJHtUTVB9CisJZWxzZQorCQlyYz0z CiAJZmkKLQlyYz0kPwotCXJtIC1mICR7VE1QfTs7Ci0gICAgKikJcmM9MDs7Ci1lc2FjCitmaQog CiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL3NlY3VyaXR5LzMwMC5jaGt1aWQwCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS8zMDAuY2hrdWlkMAkocmV2aXNpb24gMjI5 MzIzKQorKysgZXRjL3BlcmlvZGljL3NlY3VyaXR5LzMwMC5jaGt1aWQwCSh3b3JraW5nIGNvcHkp CkBAIC0yNywyNSArMjcsMTggQEAKICMgJEZyZWVCU0QkCiAjCiAKKy4gL2V0Yy9wZXJpb2RpYy5z dWJyCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmlsZSwg c3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0KLXRo ZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJpb2Rp Y19jb25mcwotZmkKK3JjPTAKIAotY2FzZSAiJGRhaWx5X3N0YXR1c19zZWN1cml0eV9jaGt1aWQw X2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCitpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1 c19zZWN1cml0eV9jaGt1aWQwX2VuYWJsZTsgdGhlbgogCWVjaG8gIiIKIAllY2hvICdDaGVja2lu ZyBmb3IgdWlkcyBvZiAwOicKIAluPSQoYXdrIC1GOiAnL14jLyB7bmV4dH0gJDM9PTAge3ByaW50 ICQxLCQzfScgL2V0Yy9tYXN0ZXIucGFzc3dkIHwKIAl0ZWUgL2Rldi9zdGRlcnIgfAogCXNlZCAt ZSAnL15yb290IDAkL2QnIC1lICcvXnRvb3IgMCQvZCcgfAogCXdjIC1sKQotCVsgJG4gLWd0IDAg XSAmJiByYz0xIHx8IHJjPTA7OwotICAgICopCXJjPTA7OwotZXNhYworCVsgJG4gLWd0IDAgXSAm JiByYz0xCitmaQogCi1leGl0ICIkcmMiCitleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL3Nl Y3VyaXR5LzcwMC5rZXJuZWxtc2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL3NlY3VyaXR5 LzcwMC5rZXJuZWxtc2cJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1cml0 eS83MDAua2VybmVsbXNnCSh3b3JraW5nIGNvcHkpCkBAIC0zMCwyNCArMzAsMTUgQEAKICMgU2hv dyBrZXJuZWwgbG9nIG1lc3NhZ2VzCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVt IGNvbmZpZ3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0 cy9wZXJpb2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29u ZgotICAgIHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKLQorLiAvZXRjL3BlcmlvZGljLnN1YnIK IC4gL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS9zZWN1cml0eS5mdW5jdGlvbnMKIAogcmM9MAogCi1j YXNlICIkZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2tlcm5lbG1zZ19lbmFibGUiIGluCi0gICAgW1l5 XVtFZV1bU3NdKQoraWYgY2hlY2t5ZXNubyBkYWlseV9zdGF0dXNfc2VjdXJpdHlfa2VybmVsbXNn X2VuYWJsZTsgdGhlbgogCWRtZXNnIDI+L2Rldi9udWxsIHwKIAkgICAgY2hlY2tfZGlmZiBuZXdf b25seSBkbWVzZyAtICIke2hvc3R9IGtlcm5lbCBsb2cgbWVzc2FnZXM6IgotCXJjPSQ/OzsKLSAg ICAqKQlyYz0wOzsKLWVzYWMKKwlyYz0kPworZmkKIAogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJp b2RpYy9zZWN1cml0eS80NjAuY2hrcG9ydHN1bQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMv c2VjdXJpdHkvNDYwLmNoa3BvcnRzdW0JKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2Rp Yy9zZWN1cml0eS80NjAuY2hrcG9ydHN1bQkod29ya2luZyBjb3B5KQpAQCAtMjcsNDIgKzI3LDQw IEBACiAjICRGcmVlQlNEJAogIwogCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29u ZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2Vf cGVyaW9kaWNfY29uZnMKLWZpCi0KKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAuIC9ldGMvcGVyaW9k aWMvc2VjdXJpdHkvc2VjdXJpdHkuZnVuY3Rpb25zCiAKIHJjPTAKIAotZWNobyAiIgotZWNobyAn Q2hlY2tpbmcgZm9yIHBvcnRzIHdpdGggbWlzbWF0Y2hlZCBjaGVja3N1bXM6JwotCi1jYXNlICIk e2RhaWx5X3N0YXR1c19zZWN1cml0eV9jaGtwb3J0c3VtX2VuYWJsZX0iIGluCi0JW1l5XVtFZV1b U3NdKQotCXNldCAtZgotCXBrZ19pbmZvIC1nYSAyPi9kZXYvbnVsbCB8IFwKLQl3aGlsZSBJRlM9 IHJlYWQgLXIgbGluZTsgZG8KLQkJc2V0IC0tICRsaW5lCi0JCWNhc2UgJDEgaW4KK2lmIGNoZWNr eWVzbm8gZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2Noa3BvcnRzdW1fZW5hYmxlOyB0aGVuCisJaWYg VE1QPSQobWt0ZW1wIC10IGNoa3BvcnRzdW0pOyB0aGVuCisJCWVjaG8gIiIKKwkJZWNobyAnQ2hl Y2tpbmcgZm9yIHBvcnRzIHdpdGggbWlzbWF0Y2hlZCBjaGVja3N1bXM6JworCQlzZXQgLWYKKwkJ cGtnX2luZm8gLWdhIDI+L2Rldi9udWxsIHwgXAorCQl3aGlsZSBJRlM9IHJlYWQgLXIgbGluZTsg ZG8KKwkJCXNldCAtLSAkbGluZQorCQkJY2FzZSAkMSBpbgogCQkJSW5mb3JtYXRpb24pCi0JCQlj YXNlICQyIGluCisJCQkJY2FzZSAkMiBpbgogCQkJCWZvcikgbmFtZT0iJHszJSU6fSIgOzsKIAkJ CQkqKSBuYW1lPSc/PycgOzsKLQkJCWVzYWMKLQkJCTs7CisJCQkJZXNhYworCQkJCTs7CiAJCQlN aXNtYXRjaGVkfCcnKSA7OwogCQkJKikgWyAtbiAiJHtuYW1lfSIgXSAmJgogCQkJCWVjaG8gIiR7 bmFtZX06ICR7bGluZSUlIGZhaWxzIHRoZSBvcmlnaW5hbCBNRDUgY2hlY2tzdW19IgotCQkJOzsK LQkJZXNhYwotCWRvbmUKLQk7OwotCSopCi0JcmM9MAotCTs7Ci1lc2FjCisJCQkJOzsKKwkJCWVz YWMKKwkJZG9uZSA+ICRUTVAKKwkJaWYgWyAkKHdjIC1sICRUTVApIC1ndCAwIF07IHRoZW4KKwkJ CWNhdCAkVE1QCisJCQlyYz0xCisJCWZpCisJCXJtIC1mICRUTVAKKwllbHNlCisJCXJjPTMKKwlm aQorZmkKIAogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9zZWN1cml0eS80MTAubG9naW5j aGVjawo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvc2VjdXJpdHkvNDEwLmxvZ2luY2hlY2sJ KHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS80MTAubG9naW5jaGVj awkod29ya2luZyBjb3B5KQpAQCAtMjcsMjYgKzI3LDE2IEBACiAjICRGcmVlQlNEJAogIwogCi0j IElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQg aW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAg LiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMK LWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCi1jYXNlICIkZGFpbHlfc3RhdHVzX3NlY3VyaXR5 X2xvZ2luY2hlY2tfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK3JjPTAKKworaWYgY2hl Y2t5ZXNubyBkYWlseV9zdGF0dXNfc2VjdXJpdHlfbG9naW5jaGVja19lbmFibGU7IHRoZW4KIAll Y2hvICIiCiAJZWNobyAnQ2hlY2tpbmcgbG9naW4uY29uZiBwZXJtaXNzaW9uczonCi0JaWYgWyAt RyAvZXRjL2xvZ2luLmNvbmYgLWEgLU8gL2V0Yy9sb2dpbi5jb25mIF07IHRoZW4KLQkgICAgbj0w Ci0JZWxzZQotCSAgICBlY2hvICJCYWQgb3duZXJzaGlwIG9mIC9ldGMvbG9naW4uY29uZiIKLQkg ICAgbj0xCisJaWYgISBbIC1HIC9ldGMvbG9naW4uY29uZiAtYSAtTyAvZXRjL2xvZ2luLmNvbmYg XTsgdGhlbgorCQllcnIgMSAiQmFkIG93bmVyc2hpcCBvZiAvZXRjL2xvZ2luLmNvbmYiCiAJZmkK LQlbICRuIC1ndCAwIF0gJiYgcmM9MSB8fCByYz0wOzsKLSAgICAqKQlyYz0wOzsKLWVzYWMKK2Zp CiAKLWV4aXQgIiRyYyIKK2V4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvc2VjdXJpdHkvODAw LmxvZ2luZmFpbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvc2VjdXJpdHkvODAwLmxvZ2lu ZmFpbAkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL3NlY3VyaXR5LzgwMC5sb2dp bmZhaWwJKHdvcmtpbmcgY29weSkKQEAgLTMwLDM5ICszMCwyMCBAQAogIyBTaG93IGxvZ2luIGZh aWx1cmVzCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24g ZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25m IF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9w ZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKIExPRz0iJHtkYWlseV9z dGF0dXNfc2VjdXJpdHlfbG9nZGlyfSIKIAorcmM9MAorCiB5ZXN0ZXJkYXk9YGRhdGUgLXYtMWQg IislYiAlZSAiYAogCi1jYXRtc2dzKCkgewotCWZpbmQgJHtMT0d9IC1uYW1lICdhdXRoLmxvZy4q JyAtbXRpbWUgLTIgfAotCSAgICBzb3J0IC10LiAtciAtbiAtayAyLDIgfAotCSAgICB3aGlsZSBy ZWFkIGYKLQkgICAgZG8KLQkJY2FzZSAkZiBpbgotCQkgICAgKi5neikJemNhdCAtZiAkZjs7Ci0J CSAgICAqLmJ6MikJYnpjYXQgLWYgJGY7OwotCQllc2FjCi0JICAgIGRvbmUKLQlbIC1mICR7TE9H fS9hdXRoLmxvZyBdICYmIGNhdCAkTE9HL2F1dGgubG9nCi19Ci0KLWNhc2UgIiRkYWlseV9zdGF0 dXNfc2VjdXJpdHlfbG9naW5mYWlsX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCitpZiBj aGVja3llc25vIGRhaWx5X3N0YXR1c19zZWN1cml0eV9sb2dpbmZhaWxfZW5hYmxlOyB0aGVuCiAJ ZWNobyAiIgogCWVjaG8gIiR7aG9zdH0gbG9naW4gZmFpbHVyZXM6IgotCW49JChjYXRtc2dzIHwg ZWdyZXAgLWlhICJeJHllc3RlcmRheS4qOiAuKihmYWlsfGludmFsaWR8YmFkfGlsbGVnYWwpIiB8 CisJbj0kKGNhdGxvZ3MgJExPRyBhdXRoIHwgZWdyZXAgLWlhICJeJHllc3RlcmRheS4qOiAuKihm YWlsfGludmFsaWR8YmFkfGlsbGVnYWwpIiB8CiAJICAgIHRlZSAvZGV2L3N0ZGVyciB8IHdjIC1s KQotCVsgJG4gLWd0IDAgXSAmJiByYz0xIHx8IHJjPTA7OwotICAgICopCXJjPTA7OwotZXNhYwor CVsgJG4gLWd0IDAgXSAmJiByYz0xCitmaQogCiBleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGlj L3NlY3VyaXR5LzIwMC5jaGttb3VudHMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL3NlY3Vy aXR5LzIwMC5jaGttb3VudHMJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1 cml0eS8yMDAuY2hrbW91bnRzCSh3b3JraW5nIGNvcHkpCkBAIC0zMCwzMyArMzAsMjcgQEAKICMg U2hvdyBjaGFuZ2VzIGluIHRoZSB3YXkgZmlsZXN5c3RlbXMgYXJlIG1vdW50ZWQKICMKIAotIyBJ ZiB0aGVyZSBpcyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNrIGl0IGlu LgotIwotaWYgWyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQotdGhlbgotICAgIC4g L2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2NvbmZzCi1m aQotCisuIC9ldGMvcGVyaW9kaWMuc3VicgogLiAvZXRjL3BlcmlvZGljL3NlY3VyaXR5L3NlY3Vy aXR5LmZ1bmN0aW9ucwogCiBpZ25vcmU9IiR7ZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2Noa21vdW50 c19pZ25vcmV9IgorCiByYz0wCiAKLWNhc2UgIiRkYWlseV9zdGF0dXNfc2VjdXJpdHlfY2hrbW91 bnRzX2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCi0JY2FzZSAiJGRhaWx5X3N0YXR1c19z ZWN1cml0eV9ub2FtZCIgaW4KLQkgICAgW1l5XVtFZV1bU3NdKQoraWYgY2hlY2t5ZXNubyBkYWls eV9zdGF0dXNfc2VjdXJpdHlfY2hrbW91bnRzX2VuYWJsZTsgdGhlbgorCWlmIGNoZWNreWVzbm8g ZGFpbHlfc3RhdHVzX3NlY3VyaXR5X25vYW1kOyB0aGVuCiAJCWlnbm9yZT0iJHtpZ25vcmV9fF5h bWQ6IgotCWVzYWMKLQlbIC1uICIkaWdub3JlIiBdICYmIGNtZD0iZWdyZXAgLXYgJHtpZ25vcmUj fH0iIHx8IGNtZD1jYXQKLQlpZiAhIFsgLWYgL2V0Yy9mc3RhYiBdOyB0aGVuCisJZmkKKwlpZiBb IC1uICIkaWdub3JlIiBdOyB0aGVuCisJCWNtZD0iZWdyZXAgLXYgJHtpZ25vcmUjfH0iCisJZWxz ZQorCQljbWQ9Y2F0CisJZmkKKwlpZiBbICEgLWYgL2V0Yy9mc3RhYiBdOyB0aGVuCiAJCWV4cG9y dCBQQVRIX0ZTVEFCPS9kZXYvbnVsbAogCWZpCiAJbW91bnQgLXAgfCBzb3J0IHwgJHtjbWR9IHwK IAkgIGNoZWNrX2RpZmYgbW91bnQgLSAiJHtob3N0fSBjaGFuZ2VzIGluIG1vdW50ZWQgZmlsZXN5 c3RlbXM6IgotCXJjPSQ/OzsKLSAgICAqKQlyYz0wOzsKLWVzYWMKLQotZXhpdCAiJHJjIgorCXJj PSQ/CitmaQorZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9zZWN1cml0eS81NTAuaXBmd2xp bWl0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS81NTAuaXBmd2xpbWl0CShy ZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvc2VjdXJpdHkvNTUwLmlwZndsaW1pdAko d29ya2luZyBjb3B5KQpAQCAtMzAsMzkgKzMwLDMzIEBACiAjIFNob3cgaXBmdyBydWxlcyB3aGlj aCBoYXZlIHJlYWNoZWQgdGhlIGxvZyBsaW1pdAogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFs IHN5c3RlbSBjb25maWd1cmF0aW9uIGZpbGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMv ZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBdCi10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3Blcmlv ZGljLmNvbmYKLSAgICBzb3VyY2VfcGVyaW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMu c3VicgogCiByYz0wCiAKLWNhc2UgIiRkYWlseV9zdGF0dXNfc2VjdXJpdHlfaXBmd2xpbWl0X2Vu YWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCitpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19z ZWN1cml0eV9pcGZ3bGltaXRfZW5hYmxlOyB0aGVuCiAJSVBGV19WRVJCT1NFPWBzeXNjdGwgLW4g bmV0LmluZXQuaXAuZncudmVyYm9zZSAyPiAvZGV2L251bGxgCi0JaWYgWyAkPyAtbmUgMCBdIHx8 IFsgIiRJUEZXX1ZFUkJPU0UiIC1lcSAwIF07IHRoZW4KKwlpZiBbICQ/IC1uZSAwIC1vICIkSVBG V19WRVJCT1NFIiAtZXEgMCBdOyB0aGVuCiAJCWV4aXQgMAogCWZpCi0JVE1QPWBta3RlbXAgLXQg c2VjdXJpdHlgCi0JaXBmdyAtYSBsaXN0IHwgZ3JlcCAiIGxvZyAiIHwgXAotCWdyZXAgJ15bWzpk aWdpdDpdXVwrW1s6c3BhY2U6XV1cK1tbOmRpZ2l0Ol1dXCsnIHwgXAotCWF3ayBcCi0JCSd7aWYg KCQ2ID09ICJsb2dhbW91bnQiKSB7Ci0JCQlpZiAoJDIgPiAkNykKLQkJCQl7cHJpbnQgJDB9fQot CQl9JyA+ICR7VE1QfQorCWlmIFRNUD1gbWt0ZW1wIC10IHNlY3VyaXR5YDsgdGhlbgorCQlpcGZ3 IC1hIGxpc3QgfCBncmVwICIgbG9nICIgfCBcCisJCWdyZXAgJ15bWzpkaWdpdDpdXVwrW1s6c3Bh Y2U6XV1cK1tbOmRpZ2l0Ol1dXCsnIHwgXAorCQlhd2sgXAorCQkJJ3tpZiAoJDYgPT0gImxvZ2Ft b3VudCIpIHsKKwkJCQlpZiAoJDIgPiAkNykKKwkJCQkJe3ByaW50ICQwfX0KKwkJCX0nID4gJHtU TVB9CiAKLQlpZiBbIC1zICIke1RNUH0iIF07IHRoZW4KLQkJcmM9MQotCQllY2hvICIiCi0JCWVj aG8gJ2lwZncgbG9nIGxpbWl0IHJlYWNoZWQ6JwotCQljYXQgJHtUTVB9CisJCWlmIFsgLXMgIiR7 VE1QfSIgXTsgdGhlbgorCQkJcmM9MQorCQkJZWNobyAiIgorCQkJZWNobyAnaXBmdyBsb2cgbGlt aXQgcmVhY2hlZDonCisJCQljYXQgJHtUTVB9CisJCWZpCisJCXJtIC1mICR7VE1QfQorCWVsc2UK KwkJcmM9MwogCWZpCi0Jcm0gLWYgJHtUTVB9OzsKLSAgICAqKQlyYz0wOzsKLWVzYWMKLQorZmkK IGV4aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvc2VjdXJpdHkvc2VjdXJpdHkuZnVuY3Rpb25z Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS9zZWN1cml0eS5mdW5jdGlvbnMJ KHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS9zZWN1cml0eS5mdW5j dGlvbnMJKHdvcmtpbmcgY29weSkKQEAgLTczLDYgKzczLDUgQEAKICAgICBtdiAke3RtcGZ9ICR7 TE9HfS8ke2xhYmVsfS50b2RheSB8fCByYz0zCiAgIGZpCiAKLSAgcm0gLWYgJHt0bXBmfQotICBl eGl0ICR7cmN9CisgIHJldHVybiAke3JjfQogfQpJbmRleDogZXRjL3BlcmlvZGljL3NlY3VyaXR5 LzYxMC5pcGY2ZGVuaWVkCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS82MTAu aXBmNmRlbmllZAkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL3NlY3VyaXR5LzYx MC5pcGY2ZGVuaWVkCSh3b3JraW5nIGNvcHkpCkBAIC0yNywyNyArMjcsMjMgQEAKICMgJEZyZWVC U0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmls ZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0K LXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJp b2RpY19jb25mcwotZmkKLQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIC4gL2V0Yy9wZXJpb2RpYy9z ZWN1cml0eS9zZWN1cml0eS5mdW5jdGlvbnMKIAogcmM9MAogCi1jYXNlICIkZGFpbHlfc3RhdHVz X3NlY3VyaXR5X2lwZjZkZW5pZWRfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKLQlUTVA9 YG1rdGVtcCAke1RNUERJUjotL3RtcH0vc2VjdXJpdHkuWFhYWFhYWFhYWGAKLQlpZiBpcGZzdGF0 IC1uaGlvNiAyPi9kZXYvbnVsbCB8IGdyZXAgYmxvY2sgPiAke1RNUH07IHRoZW4KLQkgY2hlY2tf ZGlmZiBuZXdfb25seSBpcGY2ICR7VE1QfSAiJHtob3N0fSBpcGY2IGRlbmllZCBwYWNrZXRzOiIK K2lmIGNoZWNreWVzbm8gZGFpbHlfc3RhdHVzX3NlY3VyaXR5X2lwZjZkZW5pZWRfZW5hYmxlOyB0 aGVuCisJaWYgVE1QPSQobWt0ZW1wIC10IHNlY3VyaXR5KTsgdGhlbgorCQlpZiBpcGZzdGF0IC1u aGlvNiAyPi9kZXYvbnVsbCB8IGdyZXAgYmxvY2sgPiAke1RNUH07IHRoZW4KKwkJCWNoZWNrX2Rp ZmYgbmV3X29ubHkgaXBmNiAke1RNUH0gIiR7aG9zdH0gaXBmNiBkZW5pZWQgcGFja2V0czoiCisJ CQlyYz0kPworCQllbHNlCisJCQlyYz0xCisJCWZpCisJCXJtIC1mICR7VE1QfQorCWVsc2UKKwkJ cmM9MwogCWZpCi0JcmM9JD8KLQlybSAtZiAke1RNUH07OwotICAgICopCXJjPTA7OwotZXNhYwor ZmkKIAogZXhpdCAkcmMKSW5kZXg6IGV0Yy9wZXJpb2RpYy9zZWN1cml0eS85MDAudGNwd3JhcAo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvc2VjdXJpdHkvOTAwLnRjcHdyYXAJKHJldmlzaW9u IDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS85MDAudGNwd3JhcAkod29ya2luZyBj b3B5KQpAQCAtMzAsMzkgKzMwLDIwIEBACiAjIFNob3cgdGNwX3dyYXBwZXIgd2FybmluZyBtZXNz YWdlcwogIwogCi0jIElmIHRoZXJlIGlzIGEgZ2xvYmFsIHN5c3RlbSBjb25maWd1cmF0aW9uIGZp bGUsIHN1Y2sgaXQgaW4uCi0jCi1pZiBbIC1yIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZiBd Ci10aGVuCi0gICAgLiAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYKLSAgICBzb3VyY2VfcGVy aW9kaWNfY29uZnMKLWZpCisuIC9ldGMvcGVyaW9kaWMuc3VicgogCiBMT0c9IiR7ZGFpbHlfc3Rh dHVzX3NlY3VyaXR5X2xvZ2Rpcn0iCiAKK3JjPTAKKwogeWVzdGVyZGF5PWBkYXRlIC12LTFkICIr JWIgJWUgImAKIAotY2F0bXNncygpIHsKLQlmaW5kICR7TE9HfSAtbmFtZSAnbWVzc2FnZXMuKicg LW10aW1lIC0yIHwKLQkgICAgc29ydCAtdC4gLXIgLW4gLWsgMiwyIHwKLQkgICAgd2hpbGUgcmVh ZCBmCi0JICAgIGRvCi0JCWNhc2UgJGYgaW4KLQkJICAgICouZ3opCXpjYXQgLWYgJGY7OwotCQkg ICAgKi5iejIpCWJ6Y2F0IC1mICRmOzsKLQkJZXNhYwotCSAgICBkb25lCi0JWyAtZiAke0xPR30v bWVzc2FnZXMgXSAmJiBjYXQgJExPRy9tZXNzYWdlcwotfQotCi1jYXNlICIkZGFpbHlfc3RhdHVz X3NlY3VyaXR5X3RjcHdyYXBfZW5hYmxlIiBpbgotICAgIFtZeV1bRWVdW1NzXSkKK2lmIGNoZWNr eWVzbm8gZGFpbHlfc3RhdHVzX3NlY3VyaXR5X3RjcHdyYXBfZW5hYmxlOyB0aGVuCiAJZWNobyAi IgogCWVjaG8gIiR7aG9zdH0gcmVmdXNlZCBjb25uZWN0aW9uczoiCi0Jbj0kKGNhdG1zZ3MgfCBn cmVwIC1pICJeJHllc3RlcmRheS4qcmVmdXNlZCBjb25uZWN0IiB8CisJbj0kKGNhdGxvZ3MgJExP RyBtZXNzYWdlcyB8IGdyZXAgLWkgIl4keWVzdGVyZGF5LipyZWZ1c2VkIGNvbm5lY3QiIHwKIAkg ICAgdGVlIC9kZXYvc3RkZXJyIHwgd2MgLWwpCi0JWyAkbiAtZ3QgMCBdICYmIHJjPTEgfHwgcmM9 MDs7Ci0gICAgKikJcmM9MDs7Ci1lc2FjCisJWyAkbiAtZ3QgMCBdICYmIHJjPTEKK2ZpCiAKIGV4 aXQgJHJjCkluZGV4OiBldGMvcGVyaW9kaWMvc2VjdXJpdHkvNDAwLnBhc3N3ZGxlc3MKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gZXRjL3BlcmlvZGljL3NlY3VyaXR5LzQwMC5wYXNzd2RsZXNzCShyZXZpc2lvbiAy MjkzMjMpCisrKyBldGMvcGVyaW9kaWMvc2VjdXJpdHkvNDAwLnBhc3N3ZGxlc3MJKHdvcmtpbmcg Y29weSkKQEAgLTI3LDIyICsyNywxNiBAQAogIyAkRnJlZUJTRCQKICMKIAotIyBJZiB0aGVyZSBp cyBhIGdsb2JhbCBzeXN0ZW0gY29uZmlndXJhdGlvbiBmaWxlLCBzdWNrIGl0IGluLgotIwotaWYg WyAtciAvZXRjL2RlZmF1bHRzL3BlcmlvZGljLmNvbmYgXQotdGhlbgotICAgIC4gL2V0Yy9kZWZh dWx0cy9wZXJpb2RpYy5jb25mCi0gICAgc291cmNlX3BlcmlvZGljX2NvbmZzCi1maQorLiAvZXRj L3BlcmlvZGljLnN1YnIKIAotY2FzZSAiJGRhaWx5X3N0YXR1c19zZWN1cml0eV9wYXNzd2RsZXNz X2VuYWJsZSIgaW4KLSAgICBbWXldW0VlXVtTc10pCityYz0wCisKK2lmIGNoZWNreWVzbm8gZGFp bHlfc3RhdHVzX3NlY3VyaXR5X3Bhc3N3ZGxlc3NfZW5hYmxlOyB0aGVuCiAJZWNobyAiIgogCWVj aG8gJ0NoZWNraW5nIGZvciBwYXNzd29yZGxlc3MgYWNjb3VudHM6JwogCW49JChhd2sgLUY6ICdO RiA+IDEgJiYgJDEgIX4gL15bIystXS8gJiYgJDI9PSIiIHtwcmludCAkMH0nIC9ldGMvbWFzdGVy LnBhc3N3ZCB8CiAJICAgIHRlZSAvZGV2L3N0ZGVyciB8IHdjIC1sKQotCVsgJG4gLWd0IDAgXSAm JiByYz0xIHx8IHJjPTA7OwotICAgICopCXJjPTA7OwotZXNhYworCVsgJG4gLWd0IDAgXSAmJiBy Yz0xCitmaQogCi1leGl0ICIkcmMiCitleGl0ICRyYwpJbmRleDogZXRjL3BlcmlvZGljL3NlY3Vy aXR5LzUxMC5pcGZkZW5pZWQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGljL3NlY3VyaXR5LzUx MC5pcGZkZW5pZWQJKHJldmlzaW9uIDIyOTMyMykKKysrIGV0Yy9wZXJpb2RpYy9zZWN1cml0eS81 MTAuaXBmZGVuaWVkCSh3b3JraW5nIGNvcHkpCkBAIC0yNywyNyArMjcsMjMgQEAKICMgJEZyZWVC U0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmls ZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0K LXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJp b2RpY19jb25mcwotZmkKLQorLiAvZXRjL3BlcmlvZGljLnN1YnIKIC4gL2V0Yy9wZXJpb2RpYy9z ZWN1cml0eS9zZWN1cml0eS5mdW5jdGlvbnMKIAogcmM9MAogCi1jYXNlICIkZGFpbHlfc3RhdHVz X3NlY3VyaXR5X2lwZmRlbmllZF9lbmFibGUiIGluCi0gICAgW1l5XVtFZV1bU3NdKQotCVRNUD1g bWt0ZW1wIC10IHNlY3VyaXR5YAotCWlmIGlwZnN0YXQgLW5oaW8gMj4vZGV2L251bGwgfCBncmVw IGJsb2NrID4gJHtUTVB9OyB0aGVuCi0JICBjaGVja19kaWZmIG5ld19vbmx5IGlwZiAke1RNUH0g IiR7aG9zdH0gaXBmIGRlbmllZCBwYWNrZXRzOiIKK2lmIGNoZWNreWVzbm8gZGFpbHlfc3RhdHVz X3NlY3VyaXR5X2lwZmRlbmllZF9lbmFibGU7IHRoZW4KKwlpZiBUTVA9JChta3RlbXAgLXQgc2Vj dXJpdHkpOyB0aGVuCisJCWlmIGlwZnN0YXQgLW5oaW8gMj4vZGV2L251bGwgfCBncmVwIGJsb2Nr ID4gJHtUTVB9OyB0aGVuCisJCQljaGVja19kaWZmIG5ld19vbmx5IGlwZiAke1RNUH0gIiR7aG9z dH0gaXBmIGRlbmllZCBwYWNrZXRzOiIKKwkJCXJjPSQ/CisJCWVsc2UKKwkJCXJjPTEKKwkJZmkK KwkJcm0gLWYgJHtUTVB9CisJZWxzZQorCQlyYz0zCiAJZmkKLQlyYz0kPwotCXJtIC1mICR7VE1Q fTs7Ci0gICAgKikJcmM9MDs7Ci1lc2FjCitmaQogCiBleGl0ICRyYwpJbmRleDogZXRjL3Blcmlv ZGljL3NlY3VyaXR5LzExMC5uZWdncnBwZXJtCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9wZXJpb2RpYy9z ZWN1cml0eS8xMTAubmVnZ3JwcGVybQkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGlj L3NlY3VyaXR5LzExMC5uZWdncnBwZXJtCSh3b3JraW5nIGNvcHkpCkBAIC0yNywxOCArMjcsMTEg QEAKICMgJEZyZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZp Z3VyYXRpb24gZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJp b2RpYy5jb25mIF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAg IHNvdXJjZV9wZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5zdWJyCiAKIHJjPTAK IAotY2FzZSAiJGRhaWx5X3N0YXR1c19zZWN1cml0eV9uZWdncnBwZXJtX2VuYWJsZSIgaW4KLSAg ICBbWXldW0VlXVtTc10pCitpZiBjaGVja3llc25vIGRhaWx5X3N0YXR1c19zZWN1cml0eV9uZWdn cnBwZXJtX2VuYWJsZTsgdGhlbgogCWVjaG8gIiIKIAllY2hvICdDaGVja2luZyBuZWdhdGl2ZSBn cm91cCBwZXJtaXNzaW9uczonCiAJTVA9YG1vdW50IC10IHVmcyx6ZnMgfCBhd2sgJyQwICF+IC9u byhzdWlkfGV4ZWMpLyB7IHByaW50ICQzIH0nYApAQCAtNDcsOCArNDAsNyBAQAogCSAgICBcKCAh IC1wZXJtICswMjAgLWFuZCAtcGVybSArMDAyIFwpIC1vciBcCiAJICAgIFwoICEgLXBlcm0gKzA0 MCAtYW5kIC1wZXJtICswMDQgXCkgXCkgXAogCSAgICAtZXhlYyBscyAtbGlUZCBce1x9IFwrIHwg dGVlIC9kZXYvc3RkZXJyIHwgd2MgLWwpCi0JWyAkbiAtZ3QgMCBdICYmIHJjPTEgfHwgcmM9MAot CTs7Ci1lc2FjCisJWyAkbiAtZ3QgMCBdICYmIHJjPTEKK2ZpCiAKIGV4aXQgJHJjCkluZGV4OiBl dGMvcGVyaW9kaWMvbW9udGhseS85OTkubG9jYWwKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3BlcmlvZGlj L21vbnRobHkvOTk5LmxvY2FsCShyZXZpc2lvbiAyMjkzMjMpCisrKyBldGMvcGVyaW9kaWMvbW9u dGhseS85OTkubG9jYWwJKHdvcmtpbmcgY29weSkKQEAgLTMsMTUgKzMsMTAgQEAKICMgJEZyZWVC U0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZmls ZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25mIF0K LXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9wZXJp b2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5jb25mCiAKIHJjPTAKKwogZm9yIHNjcmlw dCBpbiAkbW9udGhseV9sb2NhbAogZG8KICAgICBlY2hvICcnCkluZGV4OiBldGMvcGVyaW9kaWMv bW9udGhseS8yMDAuYWNjb3VudGluZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcGVyaW9kaWMvbW9udGhs eS8yMDAuYWNjb3VudGluZwkocmV2aXNpb24gMjI5MzIzKQorKysgZXRjL3BlcmlvZGljL21vbnRo bHkvMjAwLmFjY291bnRpbmcJKHdvcmtpbmcgY29weSkKQEAgLTMsMjAgKzMsMTMgQEAKICMgJEZy ZWVCU0QkCiAjCiAKLSMgSWYgdGhlcmUgaXMgYSBnbG9iYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24g ZmlsZSwgc3VjayBpdCBpbi4KLSMKLWlmIFsgLXIgL2V0Yy9kZWZhdWx0cy9wZXJpb2RpYy5jb25m IF0KLXRoZW4KLSAgICAuIC9ldGMvZGVmYXVsdHMvcGVyaW9kaWMuY29uZgotICAgIHNvdXJjZV9w ZXJpb2RpY19jb25mcwotZmkKKy4gL2V0Yy9wZXJpb2RpYy5jb25mCiAKLW9sZG1hc2s9JCh1bWFz aykKK3JjPTAKKwogdW1hc2sgMDY2Ci1jYXNlICIkbW9udGhseV9hY2NvdW50aW5nX2VuYWJsZSIg aW4KLSAgICBbWXldW0VlXVtTc10pCitpZiBjaGVja3llc25vIG1vbnRobHlfYWNjb3VudGluZ19l bmFibGU7IHRoZW4KIAlXPS92YXIvbG9nL3V0eC5sb2cKLQlyYz0wCiAJcmVtb3ZlPU5PCiAJaWYg WyAhIC1mICRXLjAgXQogCXRoZW4KQEAgLTI5LDIzICsyMiwyMCBAQAogCQlyZW1vdmU9WUVTCiAJ CWJ6Y2F0ICRXLjAuYnoyID4gJFcuMCB8fCByYz0xCiAJICAgIGVsc2UKLQkJZWNobyAnJG1vbnRo bHlfYWNjb3VudGluZ19lbmFibGUgaXMgc2V0IGJ1dCcgXAorCQllcnIgMiAnJG1vbnRobHlfYWNj b3VudGluZ19lbmFibGUgaXMgc2V0IGJ1dCcgXAogCQkgICAgIiRXLjAgZG9lc24ndCBleGlzdCIK LQkJcmM9MgogCSAgICBmaQogCWZpCiAJaWYgWyAkcmMgLWVxIDAgXQogCXRoZW4KLQkgICAgZWNo byAiIgotCSAgICBlY2hvICJEb2luZyBsb2dpbiBhY2NvdW50aW5nOiIKLQorCSAgICBpZiBjaGVj a3llc25vIG1vbnRobHlfYWNjb3VudGluZ192ZXJib3NlOyB0aGVuCisJCWVjaG8gIiIKKwkJZWNo byAiRG9pbmcgbG9naW4gYWNjb3VudGluZzoiCisJICAgIGZpCiAJICAgIHJjPSQoYWMgLXAgLXcg JFcuMCB8IHNvcnQgLW5yIC1rIDIgfCB0ZWUgL2Rldi9zdGRlcnIgfCB3YyAtbCkKIAkgICAgWyAk cmMgLWd0IDAgXSAmJiByYz0xCiAJZmkKLQlbICRyZW1vdmUgPSBZRVMgXSAmJiBybSAtZiAkVy4w OzsKKwlbICRyZW1vdmUgPSBZRVMgXSAmJiBybSAtZiAkVy4wCitmaQogCi0gICAgKikgIHJjPTA7 OwotZXNhYwotCi11bWFzayAkb2xkbWFzawogZXhpdCAkcmMK --f46d044469e7a75f4e04b5957cd2-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 02:35:46 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9AF4106564A; Tue, 3 Jan 2012 02:35:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 87BCB8FC12; Tue, 3 Jan 2012 02:35:46 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q032ZY4V006462; Mon, 2 Jan 2012 18:35:38 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201030235.q032ZY4V006462@gw.catspoiler.org> Date: Mon, 2 Jan 2012 18:35:33 -0800 (PST) From: Don Lewis To: flo@FreeBSD.org In-Reply-To: <201201022047.q02Kl3IM005792@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: mckusick@mckusick.com, current@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, kib@FreeBSD.org, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 02:35:46 -0000 On 2 Jan, Don Lewis wrote: > On 2 Jan, Florian Smeets wrote: >> This does not make a difference. I tried on 32K/4K with/without journal >> and on 16K/2K all exhibit the same problem. At some point during the >> cvs2svn conversion the sycer starts to use 100% CPU. The whole process >> hangs at that point sometimes for hours, from time to time it does >> continue doing some work, but really really slow. It's usually between >> revision 210000 and 220000, when the resulting svn file gets bigger than >> about 11-12Gb. At that point an ls in the target dir hangs in state ufs. >> >> I broke into ddb and ran all commands which i thought could be useful. >> The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt > > Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000 > cpustop_handler() at cpustop_handler+0x2b > ipi_nmi_handler() at ipi_nmi_handler+0x50 > trap() at trap+0x1a8 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0xffffffff8082ba43, rsp = 0xffffff8000270fe0, rbp = 0xffffff88c97829a0 --- > _mtx_assert() at _mtx_assert+0x13 > pmap_remove_write() at pmap_remove_write+0x38 > vm_object_page_remove_write() at vm_object_page_remove_write+0x1f > vm_object_page_clean() at vm_object_page_clean+0x14d > vfs_msync() at vfs_msync+0xf1 > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x135 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff88c9782d00, rbp = 0 --- > > I thinks this explains why the r228838 patch seems to help the problem. > Instead of an application call to msync(), you're getting bitten by the > syncer doing the equivalent. I don't know why the syncer is CPU bound, > though. From my understanding of the patch it only optimizes the I/O. > Without the patch, I would expect that the syncer would just spend a lot > of time waiting on I/O. My guess is that this is actually a vm problem. > There are nested loops in vm_object_page_clean() and > vm_object_page_remove_write(), so you could be doing something that's > causing lots of looping in that code. Does the machine recover if you suspend cvs2svn? I think what is happening is that cvs2svn is continuing to dirty pages while the syncer is trying to sync the file. From my limited understanding of this code, it looks to me like every time cvs2svn dirties a page, it will trigger a call to vm_object_set_writeable_dirty(), which will increment object->generation. Whenever vm_object_page_clean() detects a change in the generation count, it restarts its scan of the pages associated with the object. This is probably not optimal ... From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 04:39:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9531065672 for ; Tue, 3 Jan 2012 04:39:13 +0000 (UTC) (envelope-from aconnolly08@yahoo.co.jp) Received: from web100405.mail.kks.yahoo.co.jp (web100405.mail.kks.yahoo.co.jp [183.79.28.107]) by mx1.freebsd.org (Postfix) with SMTP id BF0368FC12 for ; Tue, 3 Jan 2012 04:39:12 +0000 (UTC) Received: (qmail 91046 invoked by uid 60001); 3 Jan 2012 04:39:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1325565550; bh=3+tsHc1Uf9JpdyLghgP/Pj2VSmXSLYl5r810Tw1tQzo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=StSl86KSI2IeSk1uHyaFUuWUhHTGAI6Dg9joaTMQUFTd+Bp+n72DQz9EXxiawXFFUNoL8zShnSyT5xCsab+OJHolsylXSuNeijRPeI58Ob0LOoZEbO7x4o/ElGUVNbqLDEf047hRftl2KgK2SDnLZVGs/sc5cqubW8Cj1CH0YJM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=vGBoDkGBbCzcZPzDJEoHM/e+KjsUzr77pqpqKivVNowcjeIQy21m7S3NSSjIw5bPlfACa5Xdm3KbK0kZstPfDeZQbiHLmICq2NEyakr0c6ZfEowZiQIqaAwaYgdxWTbzApqM8S14UB9YPTfAj3uS0NLbyCCzMum+EgUIeGWZF6k=; Message-ID: <863081.90627.qm@web100405.mail.kks.yahoo.co.jp> X-YMail-OSG: qq2baeMVM1nMpgU_p81sf14BLNZmDTIoWp5i2l35GsuKtvbZ6gspBCTo_kHsd0INCgZb0t2ADhwPcNckY5TNTD2pEiwIALg9rJJ0SMhdK7oKVHFDfYshIC6KdoUUZJSJGHkD.yBQHNBhLDqSThwjCqqArz6t19zO2s65PyA9jV5PCq_IAj9nYrnp4mB1i0aunNCwtT7rnHMpk68N3olI4F9gGl.NZvPfEmlh7arY7rtg.cfq7ARMjacu1jwA7vmx_EPT7DNj1WyL2XBSW.CiBzvH Received: from [119.104.145.117] by web100405.mail.kks.yahoo.co.jp via HTTP; Tue, 03 Jan 2012 13:39:10 JST X-Mailer: YahooMailClassic/6.0.19_42 YahooMailWebService/0.7.289.12_42 Date: Tue, 3 Jan 2012 13:39:10 +0900 (JST) From: To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: atkbc not loaded with ACPI enabled in 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 04:39:13 -0000 I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of th= e functionality I want with one major exception, when I enable ACPI my inte= grated keyboard drivers aren't loaded. Without ACPI I can use my keyboard a= s atkbdc and atkbd get loaded, (not psm though), but I have problems with s= hutdown, time settings, power settings and usb controllers. I have tried various ways of tackling this including: 1. including "nooptions NEW_PCIB" in kernel configuration, rebuilding and i= nstalling >> no effect 2a. including "debug.acpi.disabled=3D"pci" " >> can't mount file system2b. = including "debug.acpi.disabled=3D"bus" " >> can't mount file system 2c. inc= luding "debug.acpi.disabled=3D"children" " >> can't mount file system2d. in= cluding "debug.acpi.disabled=3D"hostres" " >> no effect 3. making the edit in r228961, rebuilding the kernel and installing >> no e= ffect I have the latest bios (v3.x), but it features very few changeable options. Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's t= he output of my devinfo -ur Any suggestions would be greatly appreciated. Best regards,Adrian Connolly From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 04:59:23 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08265106564A for ; Tue, 3 Jan 2012 04:59:23 +0000 (UTC) (envelope-from aconnolly08@yahoo.co.jp) Received: from web100411.mail.kks.yahoo.co.jp (web100411.mail.kks.yahoo.co.jp [183.79.28.113]) by mx1.freebsd.org (Postfix) with SMTP id 7B8B58FC13 for ; Tue, 3 Jan 2012 04:59:22 +0000 (UTC) Received: (qmail 62032 invoked by uid 60001); 3 Jan 2012 04:32:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1325565160; bh=4ZvJVLkCnmPujI9RFzZekkK6zA6RkT/Qni7rVdDNOEk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=eycTyHcm6M6hzVxK1FPQmTt/aQ4irqiSLVElCBzcZMOlThhGfYSrusqXTgfI5Wk+zpO7VDtforoPHmPJfMWY4os2AzBFEf5Bgldjrv/NpUEz+D3rLEfXOSanSK4/na2QAraQvrvcpsQMZ6hNHY0XbDMqvYxraT7OYwaWMXzeWvY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=VCOSdggSUfeX/mx3KUxyOMWrqwpd2mXwxDjtwaI3nDW4UbSpv1Ctvoy0zFeWKz8lsBipenBzkb1Ej/92gL2rYNpcZeja3u8t9jYIVvuVNuAZAN4Taxdpz1OtqUK0+0kh9timA/j5kt5NaDSW99ZYekxVtdZzUu3iUMEw5LkSIJs=; Message-ID: <126202.61703.qm@web100411.mail.kks.yahoo.co.jp> X-YMail-OSG: a1GNEbIVM1kwhv4MoL92NICdIYXoRRUyoqVWq26CUcCKt8XWntrSFnCcs6JTLVN53Swp6VjpEzsGA2WGQ2Y7FuhoOTuuCRJAduSy1biZQI2oqchcM3bEjGYM0kmQLjG2zIcm1RWAxM9YEa_DOmG0NxRbe_ZM5ZFhGec7stV3wSpmbN7zTmzfBZhtueJ._lvi6WAFR9hGFmgxCUyIPE4xLjEUrlseCuidQCVGqkmynzyo82s2gtec4utRGBQ2yPL1atUePhcMQamlbyJHCIHEBc.m2SKxQlEO2p0FZ7D.axeV.IfxA7QCH2KOVdekyYVyyPEBKty1Yaeo Received: from [119.104.145.117] by web100411.mail.kks.yahoo.co.jp via HTTP; Tue, 03 Jan 2012 13:32:39 JST X-Mailer: YahooMailClassic/6.0.19_42 YahooMailWebService/0.7.289.12_42 Date: Tue, 3 Jan 2012 13:32:39 +0900 (JST) From: To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: atkbc not loaded with ACPI enabled in 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 04:59:23 -0000 I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of th= e functionality I want with one major exception, when I enable ACPI my inte= grated keyboard drivers aren't loaded. Without ACPI I can use my keyboard a= s atkbdc and atkbd get loaded, (not psm though), but I have problems with s= hutdown, time settings, power settings and usb controllers. I have tried various ways of tackling this including: 1. including "nooptions NEW_PCIB" in kernel configuration, rebuilding and i= nstalling >> no effect 2a. including "debug.acpi.disabled=3D"pci" " >> can't mount file system2b. = including "debug.acpi.disabled=3D"bus" " >> can't mount file system 2c. inc= luding "debug.acpi.disabled=3D"children" " >> can't mount file system2d. in= cluding "debug.acpi.disabled=3D"hostres" " >> no effect 3. making the edit in r228961, rebuilding the kernel and installing >> no e= ffect I have the latest bios (v3.x), but it features very few changeable options. Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's t= he output of my devinfo -ur Any suggestions would be greatly appreciated. Best regards,Adrian Connolly From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 05:27:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B470106564A for ; Tue, 3 Jan 2012 05:27:59 +0000 (UTC) (envelope-from bryce@bryce.net) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C9EDD8FC13 for ; Tue, 3 Jan 2012 05:27:58 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so27097782wgb.31 for ; Mon, 02 Jan 2012 21:27:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.208.133 with SMTP id gc5mr49724358wbb.25.1325568477518; Mon, 02 Jan 2012 21:27:57 -0800 (PST) Received: by 10.216.159.135 with HTTP; Mon, 2 Jan 2012 21:27:57 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Jan 2012 23:27:57 -0600 Message-ID: From: Bryce Edwards To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: FS hang when creating snapshots on a UFS SU+J setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 05:27:59 -0000 I have a RELENG_9 machine that hangs when a snapshot is created on the root fs (UFS, with SU+J). =A0More accurately, all the processes show a state of "suspfs" (with ^T) and no fs activity is completed from then on. =A0A hard reboot (power cycle) was the only way to proceed. Here's some reference info - let me know what else I should provide. $uname -a FreeBSD xxx.xxx.net 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec 25 05:04:37 UTC 2011 =A0 =A0 root@xxx.xxx.net:/usr/obj/usr/src/sys/GENERIC amd64 csup was run just before build[world|kernel] so you have reference on the version information. $mount /dev/gpt/root on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) linprocfs on /compat/linux/proc (linprocfs, local) { zfs info removed } $df -h Filesystem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Size =A0 =A0Used =A0 Avail Ca= pacity =A0Mounted on /dev/gpt/root =A0 =A0 =A0 =A0 =A0 =A0 =A0 454G =A0 =A09.1G =A0 =A0409G =A0 = =A0 2% =A0 =A0/ devfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1.0k =A0 =A01.0k =A0 =A0 = =A00B =A0 100% =A0 =A0/dev linprocfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.0k =A0 =A04.0k =A0 =A0 =A00= B =A0 100% =A0 =A0/compat/linux/proc { zfs info removed } After the hard reset, there was a snapshot file listed in /.snap and it was ~465 GB, iirc. =A0Unfortunately, I needed to get things going again so I was not able to debug or diagnose further. =A0I may be able to schedule a time that I could recreate the issue and diagnose better, but I wanted to get your input on what data points and/or command you would be interested in. Thanks in advance, Bryce From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 08:02:35 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA564106564A; Tue, 3 Jan 2012 08:02:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB038FC0C; Tue, 3 Jan 2012 08:02:35 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q0382M5a006876; Tue, 3 Jan 2012 00:02:26 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201030802.q0382M5a006876@gw.catspoiler.org> Date: Tue, 3 Jan 2012 00:02:22 -0800 (PST) From: Don Lewis To: flo@FreeBSD.org In-Reply-To: <201201030235.q032ZY4V006462@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: attilio@FreeBSD.org, current@FreeBSD.org, mckusick@mckusick.com, phk@phk.freebsd.dk, kib@FreeBSD.org, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:02:35 -0000 On 2 Jan, Don Lewis wrote: > On 2 Jan, Don Lewis wrote: >> On 2 Jan, Florian Smeets wrote: > >>> This does not make a difference. I tried on 32K/4K with/without journal >>> and on 16K/2K all exhibit the same problem. At some point during the >>> cvs2svn conversion the sycer starts to use 100% CPU. The whole process >>> hangs at that point sometimes for hours, from time to time it does >>> continue doing some work, but really really slow. It's usually between >>> revision 210000 and 220000, when the resulting svn file gets bigger than >>> about 11-12Gb. At that point an ls in the target dir hangs in state ufs. >>> >>> I broke into ddb and ran all commands which i thought could be useful. >>> The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt >> >> Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000 >> cpustop_handler() at cpustop_handler+0x2b >> ipi_nmi_handler() at ipi_nmi_handler+0x50 >> trap() at trap+0x1a8 >> nmi_calltrap() at nmi_calltrap+0x8 >> --- trap 0x13, rip = 0xffffffff8082ba43, rsp = 0xffffff8000270fe0, rbp = 0xffffff88c97829a0 --- >> _mtx_assert() at _mtx_assert+0x13 >> pmap_remove_write() at pmap_remove_write+0x38 >> vm_object_page_remove_write() at vm_object_page_remove_write+0x1f >> vm_object_page_clean() at vm_object_page_clean+0x14d >> vfs_msync() at vfs_msync+0xf1 >> sync_fsync() at sync_fsync+0x12a >> sync_vnode() at sync_vnode+0x157 >> sched_sync() at sched_sync+0x1d1 >> fork_exit() at fork_exit+0x135 >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff88c9782d00, rbp = 0 --- >> >> I thinks this explains why the r228838 patch seems to help the problem. >> Instead of an application call to msync(), you're getting bitten by the >> syncer doing the equivalent. I don't know why the syncer is CPU bound, >> though. From my understanding of the patch it only optimizes the I/O. >> Without the patch, I would expect that the syncer would just spend a lot >> of time waiting on I/O. My guess is that this is actually a vm problem. >> There are nested loops in vm_object_page_clean() and >> vm_object_page_remove_write(), so you could be doing something that's >> causing lots of looping in that code. > > Does the machine recover if you suspend cvs2svn? I think what is > happening is that cvs2svn is continuing to dirty pages while the syncer > is trying to sync the file. From my limited understanding of this code, > it looks to me like every time cvs2svn dirties a page, it will trigger a > call to vm_object_set_writeable_dirty(), which will increment > object->generation. Whenever vm_object_page_clean() detects a change in > the generation count, it restarts its scan of the pages associated with > the object. This is probably not optimal ... Since the syncer is only trying to flush out pages that have been dirty for the last 30 seconds, I think that vm_object_set_writeable_dirty() should just make one pass through the object, ignoring generation, and then return when it is called from the syncer. That should keep vm_object_set_writeable_dirty() from looping over the object again and again if another process is actively dirtying the object. From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 09:18:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A573C106566C; Tue, 3 Jan 2012 09:18:25 +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 3970B8FC15; Tue, 3 Jan 2012 09:18:24 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q039IKpH027506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 11:18:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id q039IKxe041825; Tue, 3 Jan 2012 11:18:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id q039IKOj041824; Tue, 3 Jan 2012 11:18:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Jan 2012 11:18:20 +0200 From: Kostik Belousov To: Don Lewis Message-ID: <20120103091819.GN50300@deviant.kiev.zoral.com.ua> References: <201201030235.q032ZY4V006462@gw.catspoiler.org> <201201030802.q0382M5a006876@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5aGRU2U96A10TQH2" Content-Disposition: inline In-Reply-To: <201201030802.q0382M5a006876@gw.catspoiler.org> 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=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: attilio@freebsd.org, flo@freebsd.org, current@freebsd.org, mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:18:25 -0000 --5aGRU2U96A10TQH2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 03, 2012 at 12:02:22AM -0800, Don Lewis wrote: > On 2 Jan, Don Lewis wrote: > > On 2 Jan, Don Lewis wrote: > >> On 2 Jan, Florian Smeets wrote: > >=20 > >>> This does not make a difference. I tried on 32K/4K with/without journ= al > >>> and on 16K/2K all exhibit the same problem. At some point during the > >>> cvs2svn conversion the sycer starts to use 100% CPU. The whole process > >>> hangs at that point sometimes for hours, from time to time it does > >>> continue doing some work, but really really slow. It's usually between > >>> revision 210000 and 220000, when the resulting svn file gets bigger t= han > >>> about 11-12Gb. At that point an ls in the target dir hangs in state u= fs. > >>>=20 > >>> I broke into ddb and ran all commands which i thought could be useful. > >>> The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt > >>=20 > >> Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000 > >> cpustop_handler() at cpustop_handler+0x2b > >> ipi_nmi_handler() at ipi_nmi_handler+0x50 > >> trap() at trap+0x1a8 > >> nmi_calltrap() at nmi_calltrap+0x8 > >> --- trap 0x13, rip =3D 0xffffffff8082ba43, rsp =3D 0xffffff8000270fe0,= rbp =3D 0xffffff88c97829a0 --- > >> _mtx_assert() at _mtx_assert+0x13 > >> pmap_remove_write() at pmap_remove_write+0x38 > >> vm_object_page_remove_write() at vm_object_page_remove_write+0x1f > >> vm_object_page_clean() at vm_object_page_clean+0x14d > >> vfs_msync() at vfs_msync+0xf1 > >> sync_fsync() at sync_fsync+0x12a > >> sync_vnode() at sync_vnode+0x157 > >> sched_sync() at sched_sync+0x1d1 > >> fork_exit() at fork_exit+0x135 > >> fork_trampoline() at fork_trampoline+0xe > >> --- trap 0, rip =3D 0, rsp =3D 0xffffff88c9782d00, rbp =3D 0 --- > >>=20 > >> I thinks this explains why the r228838 patch seems to help the problem. > >> Instead of an application call to msync(), you're getting bitten by the > >> syncer doing the equivalent. I don't know why the syncer is CPU bound, > >> though. From my understanding of the patch it only optimizes the I/O. > >> Without the patch, I would expect that the syncer would just spend a l= ot > >> of time waiting on I/O. My guess is that this is actually a vm proble= m. > >> There are nested loops in vm_object_page_clean() and > >> vm_object_page_remove_write(), so you could be doing something that's > >> causing lots of looping in that code. > >=20 > > Does the machine recover if you suspend cvs2svn? I think what is > > happening is that cvs2svn is continuing to dirty pages while the syncer > > is trying to sync the file. From my limited understanding of this code, > > it looks to me like every time cvs2svn dirties a page, it will trigger a > > call to vm_object_set_writeable_dirty(), which will increment > > object->generation. Whenever vm_object_page_clean() detects a change in > > the generation count, it restarts its scan of the pages associated with > > the object. This is probably not optimal ... >=20 > Since the syncer is only trying to flush out pages that have been dirty > for the last 30 seconds, I think that vm_object_set_writeable_dirty() > should just make one pass through the object, ignoring generation, and > then return when it is called from the syncer. That should keep > vm_object_set_writeable_dirty() from looping over the object again and > again if another process is actively dirtying the object. >=20 This sounds very plausible. I think that there is no sense in restarting the scan if it is requested in async mode at all. See below. Would be thrilled if this finally solves the svn2cvs issues. commit 41aaafe5e3be5387949f303b8766da64ee4a521f Author: Kostik Belousov Date: Tue Jan 3 11:16:30 2012 +0200 Do not restart the scan in vm_object_page_clean() if requested mode is async. =20 Proposed by: truckman diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 716916f..52fc08b 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -841,7 +841,8 @@ rescan: if (p->valid =3D=3D 0) continue; if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { - if (object->generation !=3D curgeneration) + if ((flags & OBJPC_SYNC) !=3D 0 && + object->generation !=3D curgeneration) goto rescan; np =3D vm_page_find_least(object, pi); continue; @@ -851,7 +852,8 @@ rescan: =20 n =3D vm_object_page_collect_flush(object, p, pagerflags, flags, &clearobjflags); - if (object->generation !=3D curgeneration) + if ((flags & OBJPC_SYNC) !=3D 0 && + object->generation !=3D curgeneration) goto rescan; =20 /* --5aGRU2U96A10TQH2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8Cx9sACgkQC3+MBN1Mb4hv5QCcCQb98Dj1kc6VYVON8Vz+D1Kg L7EAnA2ob/Gdyz7rJJUnIX6OC8agoZLl =3Cla -----END PGP SIGNATURE----- --5aGRU2U96A10TQH2-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 09:26:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1534C1065670 for ; Tue, 3 Jan 2012 09:26:26 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id A1DC58FC0C for ; Tue, 3 Jan 2012 09:26:25 +0000 (UTC) Received: from maka.home.yamagi.org (p5DC91CA8.dip.t-dialin.net [93.201.28.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 728591666334; Tue, 3 Jan 2012 10:26:23 +0100 (CET) Date: Tue, 3 Jan 2012 10:26:30 +0100 From: Yamagi Burmeister To: freebsd-current@freebsd.org Message-Id: <20120103102630.1d331316.lists@yamagi.org> In-Reply-To: References: X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Tue__3_Jan_2012_10_26_30_+0100_PqOZ27LfnIsxQuLw" Cc: bryce@bryce.net Subject: Re: FS hang when creating snapshots on a UFS SU+J setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:26:26 -0000 --Signature=_Tue__3_Jan_2012_10_26_30_+0100_PqOZ27LfnIsxQuLw Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've seen this too (and other problems with SU+J and snapshots) and was able to reproduce it fairly easy. I wrote a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163310=20 Never received any feedback until now... On Mon, 2 Jan 2012 23:27:57 -0600 Bryce Edwards wrote: > I have a RELENG_9 machine that hangs when a snapshot is created on the > root fs (UFS, with SU+J). =A0More accurately, all the processes show a > state of "suspfs" (with ^T) and no fs activity is completed from then > on. =A0A hard reboot (power cycle) was the only way to proceed. >=20 > Here's some reference info - let me know what else I should provide. >=20 > $uname -a > FreeBSD xxx.xxx.net 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec > 25 05:04:37 UTC 2011 =A0 =A0 root@xxx.xxx.net:/usr/obj/usr/src/sys/GENERIC > amd64 >=20 > csup was run just before build[world|kernel] so you have reference on > the version information. >=20 > $mount > /dev/gpt/root on / (ufs, local, journaled soft-updates) > devfs on /dev (devfs, local, multilabel) > linprocfs on /compat/linux/proc (linprocfs, local) > { zfs info removed } >=20 > $df -h > Filesystem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Size =A0 =A0Used =A0 Avail = Capacity =A0Mounted on > /dev/gpt/root =A0 =A0 =A0 =A0 =A0 =A0 =A0 454G =A0 =A09.1G =A0 =A0409G = =A0 =A0 2% =A0 =A0/ > devfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1.0k =A0 =A01.0k =A0 = =A0 =A00B =A0 100% =A0 =A0/dev > linprocfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.0k =A0 =A04.0k =A0 =A0 = =A00B =A0 100% =A0 =A0/compat/linux/proc > { zfs info removed } >=20 > After the hard reset, there was a snapshot file listed in /.snap and > it was ~465 GB, iirc. =A0Unfortunately, I needed to get things going > again so I was not able to debug or diagnose further. =A0I may be able > to schedule a time that I could recreate the issue and diagnose > better, but I wanted to get your input on what data points and/or > command you would be interested in. >=20 > Thanks in advance, >=20 > Bryce > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >=20 --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Tue__3_Jan_2012_10_26_30_+0100_PqOZ27LfnIsxQuLw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8CycsACgkQWTjlg++8y8t+lACgx9akfHcYQD9FkJE3KErJgKru 6J8An2J4BYGtFahwLeiYRDAWUywZ3lHy =9ISe -----END PGP SIGNATURE----- --Signature=_Tue__3_Jan_2012_10_26_30_+0100_PqOZ27LfnIsxQuLw-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 09:45:40 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434EF1065670; Tue, 3 Jan 2012 09:45:40 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 24CD08FC08; Tue, 3 Jan 2012 09:45:39 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q039jQ4j007027; Tue, 3 Jan 2012 01:45:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201030945.q039jQ4j007027@gw.catspoiler.org> Date: Tue, 3 Jan 2012 01:45:26 -0800 (PST) From: Don Lewis To: kostikbel@gmail.com In-Reply-To: <20120103091819.GN50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: attilio@FreeBSD.org, flo@FreeBSD.org, current@FreeBSD.org, mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:45:40 -0000 On 3 Jan, Kostik Belousov wrote: > This sounds very plausible. I think that there is no sense in restarting > the scan if it is requested in async mode at all. See below. > > Would be thrilled if this finally solves the svn2cvs issues. > > commit 41aaafe5e3be5387949f303b8766da64ee4a521f > Author: Kostik Belousov > Date: Tue Jan 3 11:16:30 2012 +0200 > > Do not restart the scan in vm_object_page_clean() if requested > mode is async. > > Proposed by: truckman > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 716916f..52fc08b 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -841,7 +841,8 @@ rescan: > if (p->valid == 0) > continue; > if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { > - if (object->generation != curgeneration) > + if ((flags & OBJPC_SYNC) != 0 && > + object->generation != curgeneration) > goto rescan; > np = vm_page_find_least(object, pi); > continue; I wonder if it would make more sense to just skip the busy pages in async mode instead of sleeping ... From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 10:26:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF48D1065670; Tue, 3 Jan 2012 10:26:41 +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 0F2EC8FC15; Tue, 3 Jan 2012 10:26:40 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q03AQ8jT040541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 12:26:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id q03AQ7Km042092; Tue, 3 Jan 2012 12:26:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id q03AQ7GN042091; Tue, 3 Jan 2012 12:26:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Jan 2012 12:26:07 +0200 From: Kostik Belousov To: Don Lewis Message-ID: <20120103102607.GO50300@deviant.kiev.zoral.com.ua> References: <20120103091819.GN50300@deviant.kiev.zoral.com.ua> <201201030945.q039jQ4j007027@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kg9bXG3rqf9MxIZW" Content-Disposition: inline In-Reply-To: <201201030945.q039jQ4j007027@gw.catspoiler.org> 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=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: attilio@freebsd.org, flo@freebsd.org, current@freebsd.org, mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 10:26:41 -0000 --Kg9bXG3rqf9MxIZW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 03, 2012 at 01:45:26AM -0800, Don Lewis wrote: > On 3 Jan, Kostik Belousov wrote: >=20 > > This sounds very plausible. I think that there is no sense in restarting > > the scan if it is requested in async mode at all. See below. > >=20 > > Would be thrilled if this finally solves the svn2cvs issues. > >=20 > > commit 41aaafe5e3be5387949f303b8766da64ee4a521f > > Author: Kostik Belousov > > Date: Tue Jan 3 11:16:30 2012 +0200 > >=20 > > Do not restart the scan in vm_object_page_clean() if requested > > mode is async. > > =20 > > Proposed by: truckman > >=20 > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > > index 716916f..52fc08b 100644 > > --- a/sys/vm/vm_object.c > > +++ b/sys/vm/vm_object.c > > @@ -841,7 +841,8 @@ rescan: > > if (p->valid =3D=3D 0) > > continue; > > if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { > > - if (object->generation !=3D curgeneration) > > + if ((flags & OBJPC_SYNC) !=3D 0 && > > + object->generation !=3D curgeneration) > > goto rescan; > > np =3D vm_page_find_least(object, pi); > > continue; >=20 > I wonder if it would make more sense to just skip the busy pages in > async mode instead of sleeping ... >=20 It would be too much weakening the guarantee of the vfs_msync(MNT_NOWAIT) to not write such pages, IMO. Busy state indeed means that the page most likely undergoing the i/o, but in case it is not, we would not write it at all. Lets see whether the change alone helps. Do you agree ? --Kg9bXG3rqf9MxIZW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8C178ACgkQC3+MBN1Mb4hHgACdE/rxPa1jc/HtDf0e5lllCt1F 5oMAn0w8LJtV/gHa1ogbWvGypHTkxiAF =f+AK -----END PGP SIGNATURE----- --Kg9bXG3rqf9MxIZW-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 10:57:32 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1A3D106566C; Tue, 3 Jan 2012 10:57:32 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 658238FC18; Tue, 3 Jan 2012 10:57:31 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q03AvHur007141; Tue, 3 Jan 2012 02:57:21 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201031057.q03AvHur007141@gw.catspoiler.org> Date: Tue, 3 Jan 2012 02:57:17 -0800 (PST) From: Don Lewis To: kostikbel@gmail.com In-Reply-To: <20120103102607.GO50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: attilio@FreeBSD.org, flo@FreeBSD.org, current@FreeBSD.org, mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 10:57:32 -0000 On 3 Jan, Kostik Belousov wrote: > On Tue, Jan 03, 2012 at 01:45:26AM -0800, Don Lewis wrote: >> On 3 Jan, Kostik Belousov wrote: >> >> > This sounds very plausible. I think that there is no sense in restarting >> > the scan if it is requested in async mode at all. See below. >> > >> > Would be thrilled if this finally solves the svn2cvs issues. >> > >> > commit 41aaafe5e3be5387949f303b8766da64ee4a521f >> > Author: Kostik Belousov >> > Date: Tue Jan 3 11:16:30 2012 +0200 >> > >> > Do not restart the scan in vm_object_page_clean() if requested >> > mode is async. >> > >> > Proposed by: truckman >> > >> > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >> > index 716916f..52fc08b 100644 >> > --- a/sys/vm/vm_object.c >> > +++ b/sys/vm/vm_object.c >> > @@ -841,7 +841,8 @@ rescan: >> > if (p->valid == 0) >> > continue; >> > if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { >> > - if (object->generation != curgeneration) >> > + if ((flags & OBJPC_SYNC) != 0 && >> > + object->generation != curgeneration) >> > goto rescan; >> > np = vm_page_find_least(object, pi); >> > continue; >> >> I wonder if it would make more sense to just skip the busy pages in >> async mode instead of sleeping ... >> > It would be too much weakening the guarantee of the vfs_msync(MNT_NOWAIT) > to not write such pages, IMO. Busy state indeed means that the page most > likely undergoing the i/o, but in case it is not, we would not write it > at all. If the original code detects a busy page, it sleeps and then continues with the next page if generation hasn't changed. If generation has changed, then it restarts the scan. With your change above, the code will skip the busy page after sleeping if it is running in async mode. It won't make another attempt to write this page because it no longer attempts to rescan. My suggestion just omits the sleep in this particular case. The syncer should write the page the next time it runs, unless we're particularly unlucky ... > Lets see whether the change alone helps. Do you agree ? Your patch is definitely worth trying as-is. My latest suggestion is probably a minor additional optimization. From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 11:16:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E395F1065670; Tue, 3 Jan 2012 11:16:33 +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 76C048FC12; Tue, 3 Jan 2012 11:16:32 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q03BGJDM050029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 13:16:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id q03BGJ3I042271; Tue, 3 Jan 2012 13:16:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id q03BGIXf042270; Tue, 3 Jan 2012 13:16:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Jan 2012 13:16:18 +0200 From: Kostik Belousov To: Don Lewis Message-ID: <20120103111618.GP50300@deviant.kiev.zoral.com.ua> References: <20120103102607.GO50300@deviant.kiev.zoral.com.ua> <201201031057.q03AvHur007141@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GGOD4F4C0+BqRx9L" Content-Disposition: inline In-Reply-To: <201201031057.q03AvHur007141@gw.catspoiler.org> 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=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: attilio@freebsd.org, flo@freebsd.org, current@freebsd.org, mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 11:16:34 -0000 --GGOD4F4C0+BqRx9L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 03, 2012 at 02:57:17AM -0800, Don Lewis wrote: > On 3 Jan, Kostik Belousov wrote: > > On Tue, Jan 03, 2012 at 01:45:26AM -0800, Don Lewis wrote: > >> On 3 Jan, Kostik Belousov wrote: > >>=20 > >> > This sounds very plausible. I think that there is no sense in restar= ting > >> > the scan if it is requested in async mode at all. See below. > >> >=20 > >> > Would be thrilled if this finally solves the svn2cvs issues. > >> >=20 > >> > commit 41aaafe5e3be5387949f303b8766da64ee4a521f > >> > Author: Kostik Belousov > >> > Date: Tue Jan 3 11:16:30 2012 +0200 > >> >=20 > >> > Do not restart the scan in vm_object_page_clean() if requested > >> > mode is async. > >> > =20 > >> > Proposed by: truckman > >> >=20 > >> > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > >> > index 716916f..52fc08b 100644 > >> > --- a/sys/vm/vm_object.c > >> > +++ b/sys/vm/vm_object.c > >> > @@ -841,7 +841,8 @@ rescan: > >> > if (p->valid =3D=3D 0) > >> > continue; > >> > if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { > >> > - if (object->generation !=3D curgeneration) > >> > + if ((flags & OBJPC_SYNC) !=3D 0 && > >> > + object->generation !=3D curgeneration) > >> > goto rescan; > >> > np =3D vm_page_find_least(object, pi); > >> > continue; > >>=20 > >> I wonder if it would make more sense to just skip the busy pages in > >> async mode instead of sleeping ... > >>=20 > > It would be too much weakening the guarantee of the vfs_msync(MNT_NOWAI= T) > > to not write such pages, IMO. Busy state indeed means that the page most > > likely undergoing the i/o, but in case it is not, we would not write it > > at all. >=20 > If the original code detects a busy page, it sleeps and then continues > with the next page if generation hasn't changed. If generation has > changed, then it restarts the scan. >=20 > With your change above, the code will skip the busy page after sleeping > if it is running in async mode. It won't make another attempt to write > this page because it no longer attempts to rescan. Why would it skip it ? Please note the call to vm_page_find_least() with the pindex of the busy page right after the check for generation. If a page with the pindex is still present in the object, vm_page_find_least() should return it, and vm_object_page_clean() should make another attempt at processing it. Am I missing something ? >=20 > My suggestion just omits the sleep in this particular case. >=20 > The syncer should write the page the next time it runs, unless we're > particularly unlucky ... >=20 > > Lets see whether the change alone helps. Do you agree ? >=20 > Your patch is definitely worth trying as-is. My latest suggestion is > probably a minor additional optimization. --GGOD4F4C0+BqRx9L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8C44IACgkQC3+MBN1Mb4i75wCfbri2O2weq/4g56l4Ax4aFfuF kAIAn0tUmudAn/xURv02cu/wPxeLLnw0 =q8Ep -----END PGP SIGNATURE----- --GGOD4F4C0+BqRx9L-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 11:35:48 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACC02106564A; Tue, 3 Jan 2012 11:35:48 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 763EE8FC18; Tue, 3 Jan 2012 11:35:48 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q03BZZ4I007532; Tue, 3 Jan 2012 03:35:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201031135.q03BZZ4I007532@gw.catspoiler.org> Date: Tue, 3 Jan 2012 03:35:35 -0800 (PST) From: Don Lewis To: kostikbel@gmail.com In-Reply-To: <20120103111618.GP50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: attilio@FreeBSD.org, flo@FreeBSD.org, current@FreeBSD.org, mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 11:35:48 -0000 On 3 Jan, Kostik Belousov wrote: >> With your change above, the code will skip the busy page after sleeping >> if it is running in async mode. It won't make another attempt to write >> this page because it no longer attempts to rescan. > Why would it skip it ? Please note the call to vm_page_find_least() > with the pindex of the busy page right after the check for > generation. If a page with the pindex is still present in the object, > vm_page_find_least() should return it, and vm_object_page_clean() should > make another attempt at processing it. > > Am I missing something ? Nope, I was missing something ... From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 12:46:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1542F1065670; Tue, 3 Jan 2012 12:46:33 +0000 (UTC) (envelope-from flo@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F2E308FC08; Tue, 3 Jan 2012 12:46:32 +0000 (UTC) Received: from bender.solomo.local (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q03CkUDR066503; Tue, 3 Jan 2012 12:46:30 GMT (envelope-from flo@freebsd.org) Message-ID: <4F02F8A6.2000802@freebsd.org> Date: Tue, 03 Jan 2012 13:46:30 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: Kostik Belousov References: <201201030235.q032ZY4V006462@gw.catspoiler.org> <201201030802.q0382M5a006876@gw.catspoiler.org> <20120103091819.GN50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20120103091819.GN50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, current@freebsd.org, Don Lewis , mckusick@mckusick.com, phk@phk.freebsd.dk, seanbru@yahoo-inc.com Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 12:46:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.01.2012 10:18, Kostik Belousov wrote: > On Tue, Jan 03, 2012 at 12:02:22AM -0800, Don Lewis wrote: >> On 2 Jan, Don Lewis wrote: >>> On 2 Jan, Don Lewis wrote: >>>> On 2 Jan, Florian Smeets wrote: >>> >>>>> This does not make a difference. I tried on 32K/4K >>>>> with/without journal and on 16K/2K all exhibit the same >>>>> problem. At some point during the cvs2svn conversion the >>>>> sycer starts to use 100% CPU. The whole process hangs at >>>>> that point sometimes for hours, from time to time it does >>>>> continue doing some work, but really really slow. It's >>>>> usually between revision 210000 and 220000, when the >>>>> resulting svn file gets bigger than about 11-12Gb. At that >>>>> point an ls in the target dir hangs in state ufs. >>>>> >>>>> I broke into ddb and ran all commands which i thought >>>>> could be useful. The output is at >>>>> http://tb.smeets.im/~flo/giant-ape_syncer.txt >>>> >>>> Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000 >>>> cpustop_handler() at cpustop_handler+0x2b ipi_nmi_handler() >>>> at ipi_nmi_handler+0x50 trap() at trap+0x1a8 nmi_calltrap() >>>> at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8082ba43, >>>> rsp = 0xffffff8000270fe0, rbp = 0xffffff88c97829a0 --- >>>> _mtx_assert() at _mtx_assert+0x13 pmap_remove_write() at >>>> pmap_remove_write+0x38 vm_object_page_remove_write() at >>>> vm_object_page_remove_write+0x1f vm_object_page_clean() at >>>> vm_object_page_clean+0x14d vfs_msync() at vfs_msync+0xf1 >>>> sync_fsync() at sync_fsync+0x12a sync_vnode() at >>>> sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 >>>> fork_exit() at fork_exit+0x135 fork_trampoline() at >>>> fork_trampoline+0xe --- trap 0, rip = 0, rsp = >>>> 0xffffff88c9782d00, rbp = 0 --- >>>> >>>> I thinks this explains why the r228838 patch seems to help >>>> the problem. Instead of an application call to msync(), >>>> you're getting bitten by the syncer doing the equivalent. I >>>> don't know why the syncer is CPU bound, though. From my >>>> understanding of the patch it only optimizes the I/O. >>>> Without the patch, I would expect that the syncer would just >>>> spend a lot of time waiting on I/O. My guess is that this >>>> is actually a vm problem. There are nested loops in >>>> vm_object_page_clean() and vm_object_page_remove_write(), so >>>> you could be doing something that's causing lots of looping >>>> in that code. >>> >>> Does the machine recover if you suspend cvs2svn? I think what >>> is happening is that cvs2svn is continuing to dirty pages >>> while the syncer is trying to sync the file. From my limited >>> understanding of this code, it looks to me like every time >>> cvs2svn dirties a page, it will trigger a call to >>> vm_object_set_writeable_dirty(), which will increment >>> object->generation. Whenever vm_object_page_clean() detects a >>> change in the generation count, it restarts its scan of the >>> pages associated with the object. This is probably not >>> optimal ... >> >> Since the syncer is only trying to flush out pages that have >> been dirty for the last 30 seconds, I think that >> vm_object_set_writeable_dirty() should just make one pass >> through the object, ignoring generation, and then return when it >> is called from the syncer. That should keep >> vm_object_set_writeable_dirty() from looping over the object >> again and again if another process is actively dirtying the >> object. >> > This sounds very plausible. I think that there is no sense in > restarting the scan if it is requested in async mode at all. See > below. > > Would be thrilled if this finally solves the svn2cvs issues. > > commit 41aaafe5e3be5387949f303b8766da64ee4a521f Author: Kostik > Belousov Date: Tue Jan 3 11:16:30 2012 +0200 > > Do not restart the scan in vm_object_page_clean() if requested > mode is async. > > Proposed by: truckman > > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index > 716916f..52fc08b 100644 --- a/sys/vm/vm_object.c +++ > b/sys/vm/vm_object.c @@ -841,7 +841,8 @@ rescan: if (p->valid == 0) > continue; if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { - if > (object->generation != curgeneration) + if ((flags & OBJPC_SYNC) > != 0 && + object->generation != curgeneration) goto rescan; > np = vm_page_find_least(object, pi); continue; @@ -851,7 +852,8 @@ > rescan: > > n = vm_object_page_collect_flush(object, p, pagerflags, flags, > &clearobjflags); - if (object->generation != curgeneration) + if > ((flags & OBJPC_SYNC) != 0 && + object->generation != > curgeneration) goto rescan; > > /* Yes, the patch fixes the problem. The cvs2svn run completed this time. 9132.25 real 8387.05 user 403.86 sys I did not see any significant syncer activity in top -S anymore. Thanks a lot. Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8C+KYACgkQapo8P8lCvwkc+QCeLY8+OkEQo1/wB3J2TyjfXyc0 b0IAn1OJo1XUlBYPZRoU5NFSO5dnNbne =IGEW -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 13:00:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501F61065678 for ; Tue, 3 Jan 2012 13:00:12 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C358F8FC17 for ; Tue, 3 Jan 2012 13:00:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ri3yL-0006NM-7H for freebsd-current@freebsd.org; Tue, 03 Jan 2012 14:00:09 +0100 Received: from heu75-3-78-192-34-210.fbxo.proxad.net ([78.192.34.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2012 14:00:09 +0100 Received: from alain by heu75-3-78-192-34-210.fbxo.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2012 14:00:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Alain BRAUNER Date: Tue, 3 Jan 2012 12:55:36 +0000 (UTC) Lines: 107 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 78.192.34.210 (Opera/9.80 (X11; FreeBSD 9.0-PRERELEASE amd64; U; en) Presto/2.10.229 Version/11.60) Subject: Re: FS hang when creating snapshots on a UFS SU+J setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 13:00:12 -0000 Bryce Edwards bryce.net> writes: > > I have a RELENG_9 machine that hangs when a snapshot is created on the > root fs (UFS, with SU+J).  More accurately, all the processes show a > state of "suspfs" (with ^T) and no fs activity is completed from then > on.  A hard reboot (power cycle) was the only way to proceed. > > Here's some reference info - let me know what else I should provide. > > $uname -a > FreeBSD xxx.xxx.net 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec > 25 05:04:37 UTC 2011     root xxx.xxx.net:/usr/obj/usr/src/sys/GENERIC > amd64 > > csup was run just before build[world|kernel] so you have reference on > the version information. > > $mount > /dev/gpt/root on / (ufs, local, journaled soft-updates) > devfs on /dev (devfs, local, multilabel) > linprocfs on /compat/linux/proc (linprocfs, local) > { zfs info removed } > > $df -h > Filesystem                  Size    Used   Avail Capacity  Mounted on > /dev/gpt/root               454G    9.1G    409G     2%    / > devfs                       1.0k    1.0k      0B   100%    /dev > linprocfs                   4.0k    4.0k      0B   100%    /compat/linux/proc > { zfs info removed } > > After the hard reset, there was a snapshot file listed in /.snap and > it was ~465 GB, iirc.  Unfortunately, I needed to get things going > again so I was not able to debug or diagnose further.  I may be able > to schedule a time that I could recreate the issue and diagnose > better, but I wanted to get your input on what data points and/or > command you would be interested in. > > Thanks in advance, > > Bryce > _______________________________________________ > freebsd-current freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe freebsd.org" > > Hi, May be i overlooked something but i can confirm the two precedents reports and PR kern/163310, i have the same freeze when trying to issue snapshot on the root fs when SUJ is ON. With 9-PRERELEASE and 10-CURRENT There was an old closed PR (may be or not) related to this PB: http://www.freebsd.org/cgi/query-pr.cgi?pr=160662 I never be able to create a snapshot when SUJ is activated. I use the STOCK GENERIC KERNEL ( System build form OFFICIAL RC ISO or from make world / no special make.conf) This PB occurs on several hardware and also in VM under VBox4 After the freeze i need to halt the system by pressing 5 seconds the power switch. Sometimes, the SUJ recovery is not enough, i have a PANIC with DUP ALLOC when i issue a full fsck -yf in single user, i got some files reconnected in lost+found and some rare recovery messages. To reproduce: Prior doing snapshot, i have fully checked with FSCK the integrity of the fs in single user mode. And just issue : mksnap_ffs /.snap/backup ( dump -L may also suffer from this ) My setup: ( NO ZFS / 4 GB / CORE 2 DUO / SATA 7.2k in ahci mode) FreeBSD test.test.test 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Jan 1 13:35:33 CET 2012 root@test.test.test:/usr/obj/usr/src/sys/GENERIC amd64 /dev/ufs/ROOTFS on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) fdescfs on /dev/fd (fdescfs) procfs on /proc (procfs, local) Notice that nearly no fs activity occurring while doing this snapshot. Also no problems when SUJ is disable. Anyway, thanks so much for your wonderful and heavy work. It will be great to merge SUJ on 8.3 RELEASE when things got stable. Best wishes of happiness and success for this new year ! Alain from Paris. In love with FreeBSD since 386BSD 0.1 :-) From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 16:23:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A5B106566C for ; Tue, 3 Jan 2012 16:23:51 +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 102388FC18 for ; Tue, 3 Jan 2012 16:23:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id BCD7B46B1A; Tue, 3 Jan 2012 11:23:50 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07C1DB944; Tue, 3 Jan 2012 11:23:50 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 3 Jan 2012 10:36:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031036.50837.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 11:23:50 -0500 (EST) Cc: "Bjoern A. Zeeb" Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:23:51 -0000 On Monday, January 02, 2012 4:29:18 pm Bjoern A. Zeeb wrote: > Hi, > > why do we send all these empty headings for periodic emails or given there is > no output to this one can we > > 1) suppress the empty sections (to me that sounds a bit like a wrong > return code or something maybe?), and > 2) add an option to suppress "empty" periodic emails entirely? Have you tried 'daily_show_success="NO"' in /etc/periodic.conf? (Also security_show_success, weekly_show_success, and monthly_show_success?) Those certainly have fixed both 1) and 2) for me. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 16:23:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E773106564A for ; Tue, 3 Jan 2012 16:23:52 +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 658608FC19 for ; Tue, 3 Jan 2012 16:23:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 1E84046B32; Tue, 3 Jan 2012 11:23:52 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A96CB95D; Tue, 3 Jan 2012 11:23:51 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 3 Jan 2012 10:37:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <863081.90627.qm@web100405.mail.kks.yahoo.co.jp> In-Reply-To: <863081.90627.qm@web100405.mail.kks.yahoo.co.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201201031037.36965.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 11:23:51 -0500 (EST) Cc: aconnolly08@yahoo.co.jp Subject: Re: atkbc not loaded with ACPI enabled in 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:23:52 -0000 On Monday, January 02, 2012 11:39:10 pm aconnolly08@yahoo.co.jp wrote: > I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the functionality I want with one major exception, when I enable ACPI my integrated keyboard drivers aren't loaded. Without ACPI I can use my keyboard as atkbdc and atkbd get loaded, (not psm though), but I have problems with shutdown, time settings, power settings and usb controllers. > I have tried various ways of tackling this including: > 1. including "nooptions NEW_PCIB" in kernel configuration, rebuilding and installing >> no effect > 2a. including "debug.acpi.disabled="pci" " >> can't mount file system2b. including "debug.acpi.disabled="bus" " >> can't mount file system 2c. including "debug.acpi.disabled="children" " >> can't mount file system2d. including "debug.acpi.disabled="hostres" " > >> no effect > 3. making the edit in r228961, rebuilding the kernel and installing >> no effect > I have the latest bios (v3.x), but it features very few changeable options. > Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's the output of my devinfo -ur > Any suggestions would be greatly appreciated. > Best regards,Adrian Connolly Hmm, none of your attachments made it to the list. Can you post them at a URL? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 17:18:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACF621065670; Tue, 3 Jan 2012 17:18:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAA28FC0C; Tue, 3 Jan 2012 17:18:01 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 224216442; Tue, 03 Jan 2012 18:17:58 +0100 From: Hans Petter Selasky To: Bartosz Fabianowski Date: Tue, 3 Jan 2012 18:15:32 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EF9D06C.9060501@chillt.de> <201201031726.03885.hselasky@c2i.net> <4F03317D.6080702@chillt.de> In-Reply-To: <4F03317D.6080702@chillt.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201201031815.32624.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: umass regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:18:02 -0000 On Tuesday 03 January 2012 17:49:01 Bartosz Fabianowski wrote: > > Is it possible that you could run usbdump to capture the traffic on the > > bus where the USB device is connected? > > Absolutely. I uploaded the dump at [1]. This dump covers 30 seconds from > plugging in. > > - Bartosz > > [1] http://www.fabianowski.eu/garmin_dakota_20_attach.usbdump Hi, 1) The following transaction shows that the device supports two luns. I suspect that there is a miscommunication between UMASS and CAM layer. frame[0] WRITE 8 bytes 0000 A1 FE 00 00 00 00 01 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 1 bytes 0000 01 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |. | Does anyone @ current know how this should be properly done? 2) The 31-byte messages is a UMASS header containing the SCSI command: http://fxr.watson.org/fxr/source/dev/usb/storage/umass.c#L249 18:42:08.572437 usbus1.8 SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=32,IVAL=0 frame[0] WRITE 31 bytes 0000 55 53 42 43 02 00 00 00 10 00 00 00 80 00 0C A0 |USBC............| ^^ LUN ^^ LEN + SCSI command 0010 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 -- |............... | --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 22:14:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E23B2106564A; Tue, 3 Jan 2012 22:14:42 +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 B92678FC1E; Tue, 3 Jan 2012 22:14:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6F4AE46B2D; Tue, 3 Jan 2012 17:14:42 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C87E6B96B; Tue, 3 Jan 2012 17:14:41 -0500 (EST) From: John Baldwin To: Doug Barton Date: Tue, 3 Jan 2012 17:14:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4E23EE49.5040801@FreeBSD.org> <201108021806.04759.jhb@freebsd.org> <4E38FEE5.4080300@FreeBSD.org> In-Reply-To: <4E38FEE5.4080300@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031714.40777.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 17:14:41 -0500 (EST) Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:14:43 -0000 On Wednesday, August 03, 2011 3:55:17 am Doug Barton wrote: > On 08/02/2011 15:06, John Baldwin wrote: > > On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: > >> on 19/07/2011 18:16 John Baldwin said the following: > >>> Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? > >>> You might be able to just build the kernel with 'nooptions NEW_PCIB'. > >> > >> I believe that I've got a similar problem with amdsbwd(4). > >> It needs some resources (I/O ports) that belong to ACPI. > >> The problem is that the driver attaches to isa bus which is under > >> isab->pci->pcib and those particular resources are not assigned to the Host-PCI > >> bridge. > >> > >> I think that you already made a suggestion that perhaps isa bus should directly > >> attach to acpi bus when acpi is available. Not sure if there are any > >> alternative approaches. > > > > Can you try this: > > Not so much. :) the first and last patches I can apply to HEAD by hand, > but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not > even sure where to start. > > Any chance you could diff against HEAD? I believe this should be fixed (well, worked-around) by my most recent commit to sys/dev/acpica/acpi_pcib_acpi.c in HEAD. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 23:34:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FBD4106564A for ; Tue, 3 Jan 2012 23:34:06 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8E58FC1D for ; Tue, 3 Jan 2012 23:34:05 +0000 (UTC) Received: by lahl5 with SMTP id l5so8924392lah.13 for ; Tue, 03 Jan 2012 15:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=FRutf9+ACbztcVpv2YJyHsq9zA15Hb2vfuFfeKTLJwY=; b=ovxDHIJCgH0LZz0j7vmF06ePeFl1MG3WxCVkGTfror1idiBdaPR1LWp69i+A9404/A Y8zg+yt4EfupGzN03BhE5bIEc+QuBbXTuPIHaJSRH/vnPPszUivP9WFtRqGgAMaKy/vk y+d8bD/sMd2chid0cjGhipYAl218WGj5U7wzE= Received: by 10.152.103.71 with SMTP id fu7mr43167653lab.31.1325633644197; Tue, 03 Jan 2012 15:34:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.129.8 with HTTP; Tue, 3 Jan 2012 15:33:33 -0800 (PST) From: Eitan Adler Date: Tue, 3 Jan 2012 18:33:33 -0500 Message-ID: To: freebsd-current Current , freebsd-sysinstall@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: sysinstall as a post-install tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:34:06 -0000 Hi, In the the recent sysinstall thread there seems to be general agreement that having a post-install configuration tool is a good thing. Until such a tool is written I think it would be a good idea to use sysinstall for this purpose. I am willing to do the work to restore sysinstall and maintain it as a post-install tool until a new one is written. My plan would be to: - Restore sysinstall and libodialog - Statically link libodialog and make it specific to sysinstall A rewrite of sysinstall to use libdialog is not worth it. It would be better to just write a new configuration tool at that point. - Remove front end non-configure facing features (ie "upgrade" and installation options) - Remove scripting support from sysinstall Additionally I would agree to - Ensure that sysinstall continues to function as time goes on - Review and test patches to sysinstall What I am not agreeing to: - Rewrite sysinstall - Make a new tool Please follow up to freebsd-sysinstall@ -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 23:49:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119E4106566B; Tue, 3 Jan 2012 23:49:27 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id C12008FC0A; Tue, 3 Jan 2012 23:49:26 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q03NnCji094506; Tue, 3 Jan 2012 15:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1325634553; bh=Lfqvp6BCMg2ZRl0fLxPtT1rexgGARaJ0I5vLXO5kKgg=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version; b=X7ecqoTfGGtNFlzoonpOjYqK0jQ3xdVAtIwuRBQDXMgjJ7NzvbmiNKbMEBZfBr0BE PipK0T/NoCg/JhiHDNs6jf4xMK6vFoUSNirdwWR03VJhC5GoQK9NUkJlijE48kN/d9 Fyo5QN1kPq7pxBDWgAUPWWrf1j7SARFcncBj+J5k= From: Sean Bruno To: Florian Smeets In-Reply-To: <4F02F8A6.2000802@freebsd.org> References: <201201030235.q032ZY4V006462@gw.catspoiler.org> <201201030802.q0382M5a006876@gw.catspoiler.org> <20120103091819.GN50300@deviant.kiev.zoral.com.ua> <4F02F8A6.2000802@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SKRSm0uSuBrWz1Pq7M8e" Date: Tue, 03 Jan 2012 15:49:12 -0800 Message-ID: <1325634552.17931.2.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Cc: "mckusick@mckusick.com" , Don, "current@freebsd.org" , Lewis , "attilio@freebsd.org" , "phk@phk.freebsd.dk" , Kostik Belousov Subject: Re: dogfooding over in clusteradm land X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:49:27 -0000 --=-SKRSm0uSuBrWz1Pq7M8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-01-03 at 04:46 -0800, Florian Smeets wrote: > Yes, the patch fixes the problem. The cvs2svn run completed this time. >=20 > 9132.25 real 8387.05 user 403.86 sys >=20 > I did not see any significant syncer activity in top -S anymore. >=20 > Thanks a lot. > Florian=20 Currently running stable-9 + this patch on crush.freebsd.org. First run was successful and took about 4 hours start to finish. Nicely done folks. diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 716916f..52fc08b 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -841,7 +841,8 @@ rescan: if (p->valid =3D=3D 0) continue; if (vm_page_sleep_if_busy(p, TRUE, "vpcwai")) { - if (object->generation !=3D curgeneration) + if ((flags & OBJPC_SYNC) !=3D 0 && + object->generation !=3D curgeneration) goto rescan; np =3D vm_page_find_least(object, pi); continue; @@ -851,7 +852,8 @@ rescan: n =3D vm_object_page_collect_flush(object, p, pagerflags, flags, &clearobjflags); - if (object->generation !=3D curgeneration) + if ((flags & OBJPC_SYNC) !=3D 0 && + object->generation !=3D curgeneration) goto rescan; /*=20 --=-SKRSm0uSuBrWz1Pq7M8e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJPA5PqAAoJEL2UHwafTLtO3GoH/2Rh21mDAxx5TNjmTdqXehoy vzNw8G8UqepX/7dxH7zA4YEuW9MLVOBxKSlvBPC+ceKi+e60AHhJ8IKBntGACp/v JUu2CQVrKk8MMqASgVxYpvrnMWm9RG1CGdNdZaAG0Sg7X6c5UEs2qaIFwEp2hmvz QWFpo87PFN+BhZBFJTBN9EsNl/AOjFEknTFd1nFKq/sEnSpyAhbvZfuXZOdwG1K+ eZ/3KkRLZSijiKgNgq9M3/RiKNV2lLDmJO5Rn4/uIDbq98hM220NHuQt5LRznuzt VZHs6j/iFlnaBGu24O/JxCexJ6LOzCUyT5mlDDlhR5/h7pWXT306eo4237S90Zw= =aMec -----END PGP SIGNATURE----- --=-SKRSm0uSuBrWz1Pq7M8e-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 23:54:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16EEE1065670; Tue, 3 Jan 2012 23:54:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF9C78FC13; Tue, 3 Jan 2012 23:54:17 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so22179660vcb.13 for ; Tue, 03 Jan 2012 15:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b+etYx9y8Sv/m4OPzT2a8wYke9OhAql0PwFVHHx5K88=; b=H+GZWgWi95s5wus3amps3h6Go61VIZEZ8oqU1QY1PjPOdSmmqIOn2xw+1FoRIX0qFH 5K4l8EtIPsmkQQVyuUGKgQmM83nb2EPZQ02HhfpkVyautqrcXX9IUISlPq2sIg9LqTA+ i7CClqvJZI3jo/FJ+PrJlzYadbtdKXe9YvSaM= MIME-Version: 1.0 Received: by 10.220.156.81 with SMTP id v17mr25478107vcw.68.1325634856859; Tue, 03 Jan 2012 15:54:16 -0800 (PST) Received: by 10.220.194.131 with HTTP; Tue, 3 Jan 2012 15:54:16 -0800 (PST) In-Reply-To: <4EF904F2.4020109@FreeBSD.org> References: <4EF904F2.4020109@FreeBSD.org> Date: Tue, 3 Jan 2012 15:54:16 -0800 Message-ID: From: Freddie Cash To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Subject: Re: Removal of sysinstall from HEAD and lack of a post-install configuration tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:54:18 -0000 Not directed to Doug in particular, just selected the first message to reply to, to keep the depth of the thread from exploding. :) On Mon, Dec 26, 2011 at 3:36 PM, Doug Barton wrote: > The story so far ... > > sysinstall was removed from HEAD in October. I (and others) objected on > the basis that at this time there is no replacement for the post-install > configuration role that sysinstall played. More sysinstall components > were then removed. Then the old version of libdialog (which sysinstall > used) was removed. Thus at this point it's not possible to easily > restore sysinstall. > > So my question is, how much do you care? Is lack of that functionality > in HEAD something that we care about? Unless someone is willing to put in the time and effort to fix sysinstall such that it doesn't just spam settings to the end of the rc.conf file, it should remain dead, gone, buried, expunged, etc. While it may be nice for some users to have a pretty TUI to browse through packages, or configure networking, or whatever, sysinstall should not be it. The number of times new users have screwed up their systems by using sysinstall as a post-install configuration tool is too numerous to count. As a moderator on forums.freebsd.org, the first thing I tell new users is to forget sysinstall even exists once the OS is installed. JUST DON'T USE IT AS A POST-INSTALL CONFIGURATION TOOL! It's not worth the headaches it will cause down the line. And some of those headaches are large indeed. Plus, it doesn't support even half of the network configuration features that rc.conf support. Let alone the rest of stuff that can go into rc.conf. And it has no concept of rc.conf.local (which is very useful for configuring multiple systems that share an rc.conf). Instead of resurrecting this horrible tool, perhaps we should look at Devin Teska's host-setup tool. Or better documenting the standalone parts of sysinstall like SADE. Or even just improving the first-login fortune entry to point to a couple of useful man pages to get people started. Or even writing a new "things to do once the OS is installed" man page (similar to what OpenBSD has). sysinstall has served its purpose; and long out-lived its usefulness. It's time to let it out to pasture. Please, let's leave it in the attic where it belongs. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 00:32:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A5B106566B for ; Wed, 4 Jan 2012 00:32:11 +0000 (UTC) (envelope-from aconnolly08@yahoo.co.jp) Received: from applesmtp510.mail.kks.yahoo.co.jp (applesmtp510.mail.kks.yahoo.co.jp [183.79.29.90]) by mx1.freebsd.org (Postfix) with SMTP id 94A528FC12 for ; Wed, 4 Jan 2012 00:32:10 +0000 (UTC) Received: (qmail 98529 invoked by alias); 4 Jan 2012 00:32:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1325637129; bh=lk123p7u0o5RMnlZnsVMOV19zFvs0p852SQg7lHdaIo=; h=Received:X-Apparently-From:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=guP+/kRplisYsiU4b+QScIgN3TTv2CJJ/CknWOt5EX79aBGNe2edmOsozrQeYVcJg3LJ3rNbM6rniyKKjmhiB9/f4ExLZ1UL+A2yRtPLJZwUl9OIW5q0fJjS2gUzAO8lQWHJroRwP5LmsVztXNmL5JgCsqpkFys0aI6FIYse2xs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Received:X-Apparently-From:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=oTecB7rvm6wmUdtIUaGoyW8+/1wGqVwBxC7Vm4kilGgWWsm78JoDYOQzkmyx6B8wv40g/sLhS9cbdEy3o0CbwWJiPxsKf2EgVKODpm8GdJDGXOiT2jNB9cX4PjSW5aNAHrnMVfeA+8O1mt1x+GpBJqw6lp3SDz+xJvFMNOj4n0E= ; Received: from unknown (HELO ?126.160.68.154?) (126.160.68.154 with plain) by applesmtp510.mail.kks.yahoo.co.jp with SMTP; 4 Jan 2012 00:32:09 -0000 X-Apparently-From: References: <863081.90627.qm@web100405.mail.kks.yahoo.co.jp> <201201031037.36965.jhb@freebsd.org> In-Reply-To: <201201031037.36965.jhb@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8C148a) Message-Id: <76ED7D95-63D6-4328-B689-BBBA5C9F24A0@yahoo.co.jp> X-Mailer: iPhone Mail (8C148a) From: Adrian Connolly Date: Wed, 4 Jan 2012 09:31:59 +0900 To: John Baldwin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" Subject: Re: atkbc not loaded with ACPI enabled in 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:32:11 -0000 On 2012/01/04, at 0:37, John Baldwin wrote: > On Monday, January 02, 2012 11:39:10 pm aconnolly08@yahoo.co.jp wrote: >> I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of t= he=20 > functionality I want with one major exception, when I enable ACPI my=20 > integrated keyboard drivers aren't loaded. Without ACPI I can use my keybo= ard=20 > as atkbdc and atkbd get loaded, (not psm though), but I have problems with= =20 > shutdown, time settings, power settings and usb controllers. >> I have tried various ways of tackling this including: >> 1. including "nooptions NEW_PCIB" in kernel configuration, rebuilding and= =20 > installing >> no effect >> 2a. including "debug.acpi.disabled=3D"pci" " >> can't mount file system2b= .=20 > including "debug.acpi.disabled=3D"bus" " >> can't mount file system 2c.=20= > including "debug.acpi.disabled=3D"children" " >> can't mount file system2d= .=20 > including "debug.acpi.disabled=3D"hostres" " >>>> no effect >> 3. making the edit in r228961, rebuilding the kernel and installing >> no= =20 > effect >> I have the latest bios (v3.x), but it features very few changeable option= s. >> Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's= =20 > the output of my devinfo -ur >> Any suggestions would be greatly appreciated. >> Best regards,Adrian Connolly >=20 > Hmm, none of your attachments made it to the list. Can you post them at a= =20 > URL? >=20 > --=20 > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= My apologies, here are the URLs of the output, dmesg -a http://pastebin.com/rJhddt4A devinfo -vr http://pastebin.com/MYd8wS7F devinfo -ur http://pastebin.com/iBr62epv Thanks again. Adrian= From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 00:49:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137FD1065673; Wed, 4 Jan 2012 00:49:40 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id AB7FE8FC17; Wed, 4 Jan 2012 00:49:39 +0000 (UTC) Received: from sa-nc-cs-216.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q040R9mJ079360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 16:27:17 -0800 (PST) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: Date: Tue, 3 Jan 2012 16:27:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eitan Adler X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current Current , freebsd-sysinstall@freebsd.org Subject: Re: sysinstall as a post-install tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:49:40 -0000 On Jan 3, 2012, at 3:33 PM, Eitan Adler wrote: > Hi, >=20 > In the the recent sysinstall thread there seems to be general = agreement that > having a post-install configuration tool is a good thing. Until such a > tool is written I think it would be a good idea to use sysinstall for > this purpose. I am willing to do the work to restore sysinstall and > maintain it as a post-install tool until a new one is written. I though sade was created for that purpose, because sysinstall was too much tied to the installation process. If sysinstall comes back, sade definitely has to go: ------------------------------------------------------------------------ r161060 | netchild | 2006-08-07 16:35:49 -0700 (Mon, 07 Aug 2006) | 9 = lines Say welcome to 'sade', the SysAdmins Disk Editor. It's the fdisk and = disklabel part of sysinstall. So sysinstall may retire now, we have the important = non-install part of it covered. ATM it doesn't understand GEOM stuff (like mirror, stripe, raid, ...), = but patches to change this and to clean it up internally are more than welcome. Submitted by: mami@nyitolap.hu ------------------------------------------------------------------------ In general I think it's a bad idea to revive sysinstall. It doesn't function appropriately on most architectures that FreeBSD supports and it's definitely the opposite of what we've been working towards for at least the last 5 years. FYI, --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 00:55:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBA3D1065670; Wed, 4 Jan 2012 00:55:08 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 65BE18FC12; Wed, 4 Jan 2012 00:55:08 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 02360E622B; Wed, 4 Jan 2012 00:55:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=kveQcqzDnxbW HYstXoK6flTLskw=; b=bi8L8ZhoFr9QCcbajbZodtk+DqMdm+XjMNg+5tvfSOd2 UeK0nPRu0WBlnx72bYSmGbDjKy1YEZPrgB3aiOZkcnrfB0zrUigQ5TMPAf9KmwgC lenQurXqX/n+Si01/bdfbuCUM2WIaVe8geCAeNqHwuuxk117LYnPww2BjQm67FM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=VGK0OP aglAFHJzBrI6CPL+n+A6ijUefh3ko58JJIw0Ox6A2of1CffYrC3pgsAjm7ipzlgb LJQS0MtvPifri8umlZ6+dF7hPvitWAyuDuCQAk10/wqd3vOA/OIaPU0o40ZwynyB hFbB3EAlmVId4ys2wDLxm6DkBX1lj4X5NVsDg= Received: from [192.168.1.66] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id CE29CE620E; Wed, 4 Jan 2012 00:55:06 +0000 (GMT) Message-ID: <4F03A366.5030601@cran.org.uk> Date: Wed, 04 Jan 2012 00:55:02 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eitan Adler , freebsd-current Current , freebsd-sysinstall@freebsd.org Subject: Re: sysinstall as a post-install tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:55:08 -0000 On 04/01/2012 00:27, Marcel Moolenaar wrote: > ATM it doesn't understand GEOM stuff (like mirror, stripe, raid, ...), but patches > to change this and to clean it up internally are more than welcome. There's a rewrite almost ready to go that supports ZFS etc. at http://butcher.heavennet.ru/sade/ - I'm hoping to find some time to finish it off and import it. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 03:39:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66808106566B for ; Wed, 4 Jan 2012 03:39:06 +0000 (UTC) (envelope-from crodr001@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 BFA128FC12 for ; Wed, 4 Jan 2012 03:39:05 +0000 (UTC) Received: by eaaf13 with SMTP id f13so21717174eaa.13 for ; Tue, 03 Jan 2012 19:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wb6dFNtV34OLxIQ28a74jLdkGANYhWl1ZZW+ZNmSjNE=; b=rrk3mxJr3l4gAoAN142Hu7sdUjSPAXHD+06XfPNhu5cBf44PTrv0wWlAdp0g01WaYA 3a7kv8mK3B/H7MDnDiWJMREO+ZBE8bD02p8e+kG5ho+6tilwANJ4UqGs884LA9PPTuKA eVImWqDbJEcEf1Y6+FWaBOIARKv5IQj2u9PHk= MIME-Version: 1.0 Received: by 10.205.129.3 with SMTP id hg3mr12639726bkc.20.1325648344640; Tue, 03 Jan 2012 19:39:04 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.205.115.138 with HTTP; Tue, 3 Jan 2012 19:39:04 -0800 (PST) In-Reply-To: <4F03A366.5030601@cran.org.uk> References: <4F03A366.5030601@cran.org.uk> Date: Tue, 3 Jan 2012 19:39:04 -0800 X-Google-Sender-Auth: 5ho492aD8Y3UXHOq0wM_ndBiIkU Message-ID: From: Craig Rodrigues To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: Eitan Adler , freebsd-current Current , freebsd-sysinstall@freebsd.org, Marcel Moolenaar Subject: Re: sysinstall as a post-install tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:39:06 -0000 On Tue, Jan 3, 2012 at 4:55 PM, Bruce Cran wrote: > There's a rewrite almost ready to go that supports ZFS etc. at > http://butcher.heavennet.ru/sade/ - I'm hoping to find some time to finish > it off and import it. > > -- > Bruce Cran > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Bruce, Where is the code for this? Would committing your sade additions now to a project branch in Subversion be appropriate? That way folks could check it out from SVN, and provide comments and patches, and help push things along faster. When your code is complete, it could be merged to HEAD. While I understand some of the concerns about removing sysinstall in HEAD, I think that sysinstall is so far behind the curve in usefulness, that I think that putting a bullet in its head now and forcing a mini-crisis to implement something better is not a bad idea, even though it may violate POLA. Many thanks to Nathan for all his latest work on the installer. The state of sysinstall today is worse than some of the installers I used in various Linux distributions about 15 years ago, and makes FreeBSD look silly for new users trying to set it up. I think we can do better. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 07:37:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 840E5106564A; Wed, 4 Jan 2012 07:37:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 94DE51501FC; Wed, 4 Jan 2012 07:37:56 +0000 (UTC) Message-ID: <4F0401D3.9040903@FreeBSD.org> Date: Tue, 03 Jan 2012 23:37:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: John Baldwin References: <4E23EE49.5040801@FreeBSD.org> <201108021806.04759.jhb@freebsd.org> <4E38FEE5.4080300@FreeBSD.org> <201201031714.40777.jhb@freebsd.org> In-Reply-To: <201201031714.40777.jhb@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 07:37:57 -0000 On 01/03/2012 14:14, John Baldwin wrote: > On Wednesday, August 03, 2011 3:55:17 am Doug Barton wrote: >> On 08/02/2011 15:06, John Baldwin wrote: >>> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: >>>> on 19/07/2011 18:16 John Baldwin said the following: >>>>> Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? >>>>> You might be able to just build the kernel with 'nooptions NEW_PCIB'. >>>> >>>> I believe that I've got a similar problem with amdsbwd(4). >>>> It needs some resources (I/O ports) that belong to ACPI. >>>> The problem is that the driver attaches to isa bus which is under >>>> isab->pci->pcib and those particular resources are not assigned to the Host-PCI >>>> bridge. >>>> >>>> I think that you already made a suggestion that perhaps isa bus should directly >>>> attach to acpi bus when acpi is available. Not sure if there are any >>>> alternative approaches. >>> >>> Can you try this: >> >> Not so much. :) the first and last patches I can apply to HEAD by hand, >> but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not >> even sure where to start. >> >> Any chance you could diff against HEAD? > > I believe this should be fixed (well, worked-around) by my most recent commit > to sys/dev/acpica/acpi_pcib_acpi.c in HEAD. Funny you should ask. :) I saw that, and took a look. I'm getting the following error, from a verbose dmesg: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 That's different than the error message I got before, but watchdogd still fails. I didn't have a chance to check the BIOS settings until today, and there is no entry for anything even closely resembling this. The only things I actually have disabled are the parallel port, and the "Dell Trusted Platform Module," neither of which I can imagine would be relevant. I'm happy to provide more info. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 08:29:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95DB51065670; Wed, 4 Jan 2012 08:29:42 +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 466588FC0A; Wed, 4 Jan 2012 08:29:42 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 57364E3F07A; Wed, 4 Jan 2012 09:11:56 +0100 (CET) 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 yFZ9GaZkoOU3; Wed, 4 Jan 2012 09:11:53 +0100 (CET) Received: from goofy01.vnodelab.local (unknown [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 6C1B0E3F079; Wed, 4 Jan 2012 09:11:53 +0100 (CET) Date: Wed, 4 Jan 2012 09:11:51 +0100 From: Joel Dahl To: Eitan Adler Message-ID: <20120104081151.GC61584@goofy01.vnodelab.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Current , freebsd-sysinstall@freebsd.org Subject: Re: sysinstall as a post-install tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:29:44 -0000 On 03-01-2012 18:33, Eitan Adler wrote: > Hi, > > In the the recent sysinstall thread there seems to be general agreement that > having a post-install configuration tool is a good thing. Until such a > tool is written I think it would be a good idea to use sysinstall for > this purpose. I am willing to do the work to restore sysinstall and > maintain it as a post-install tool until a new one is written. > > My plan would be to: > > - Restore sysinstall and libodialog You should read the following post by Freddie Cash to current@, in case you haven't seen it: http://lists.freebsd.org/pipermail/freebsd-current/2012-January/030954.html I agree with all his points. -- Joel From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 08:52:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48BAC10656B0; Wed, 4 Jan 2012 08:52:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C244F8FC16; Wed, 4 Jan 2012 08:52:55 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id B26B1E622D; Wed, 4 Jan 2012 08:52:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=HAc34GAI6XNq aQqzcNs0+H9n/+Q=; b=X/Zr6MjhIXGgXqKcsfQFUwjnyrl3nyATirpyNITkB6LL sHfiUS6NJ02MimH+Sixe6qBuQ/Voa7HHCVpxd3P5U1LXNQWdhYLUGioEp3WE+uyK agX5VHsYg+KfUOFxTUj7FZJjfqQvRRRiQan6AifBdAszo09sg4NLd2ogYFKAC4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=Y+UN/i 4yTHWM6tBu9wlK8HC9SEtxuMYcixOjaCBIUvHslppSZ4MoJlsvXrorDTkIDom6NM 6vy5ITAwyD/L6jUoqzY5587qW/5pMFrjfnJPZXkW7enSUi0+nRmqzWMACvn81CZ5 qpeT1PEuhUo4sW9DyIyGI/Kt+3oMm1agETZ8A= Received: from [192.168.1.66] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 7A2F8E6219; Wed, 4 Jan 2012 08:52:54 +0000 (GMT) Message-ID: <4F041361.7000802@cran.org.uk> Date: Wed, 04 Jan 2012 08:52:49 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <4F03A366.5030601@cran.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eitan Adler , freebsd-current Current , freebsd-sysinstall@freebsd.org, Marcel Moolenaar Subject: Re: sysinstall as a post-install tool X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:52:56 -0000 On 04/01/2012 03:39, Craig Rodrigues wrote: > Where is the code for this? Would committing your sade additions now > to a project branch in Subversion > be appropriate? That way folks could check it out from SVN, and > provide comments and patches, > and help push things along faster. > When your code is complete, it could be merged to HEAD. I didn't do the work, it was Andrey Elsukov (ae@) - the code's at http://svnweb.freebsd.org/base/user/ae/usr.sbin/sade/ . > While I understand some of the concerns about removing sysinstall in HEAD, > I think that sysinstall is so far behind the curve in usefulness, that I think > that putting a bullet in its head now and forcing a mini-crisis to > implement something better is not a bad idea, > even though it may violate POLA. I can see that people prefer bsdinstall so I'll stop trying to keep sysinstall going. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 11:57:55 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46610106566C; Wed, 4 Jan 2012 11:57:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B8A568FC0C; Wed, 4 Jan 2012 11:57:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q04BvrfN051450; Wed, 4 Jan 2012 15:57:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q04Bvr8N051449; Wed, 4 Jan 2012 15:57:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Jan 2012 15:57:53 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20120104115753.GF34721@FreeBSD.org> References: <201201031036.50837.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201201031036.50837.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:57:55 -0000 On Tue, Jan 03, 2012 at 10:36:50AM -0500, John Baldwin wrote: J> > why do we send all these empty headings for periodic emails or given there is J> > no output to this one can we J> > J> > 1) suppress the empty sections (to me that sounds a bit like a wrong J> > return code or something maybe?), and J> > 2) add an option to suppress "empty" periodic emails entirely? J> J> Have you tried 'daily_show_success="NO"' in /etc/periodic.conf? J> J> (Also security_show_success, weekly_show_success, and monthly_show_success?) J> J> Those certainly have fixed both 1) and 2) for me. Does security_show_success="YES" suppress the security report entirely (no mail sent), if no security related issues found? When I once tried OpenBSD, I loved that security report mail isn't generated at all if not issues found. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 12:14:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2FF71065673 for ; Wed, 4 Jan 2012 12:14:45 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 53AD68FC1C for ; Wed, 4 Jan 2012 12:14:44 +0000 (UTC) Received: by eekc50 with SMTP id c50so19750675eek.13 for ; Wed, 04 Jan 2012 04:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BnqohyQzBs9KbZOBZESLk1k2GhC5z9V1Q5811//iwjg=; b=raheHObS9khJd8uU/LxLedFPHO0FS16a+s4cRgcD8IhEXkqoIvucwM1H9w0O+bTWmm qXe4GjQf2Xst5OZmfIxoGLRmFVPTnME/2R4Z1wnOyHLfQfLJ5DVqIDvijMumERVVFXq6 Buws506gIj5XDRRz5cRBh3vFd95R01j/jnqPs= Received: by 10.14.3.200 with SMTP id 48mr22247987eeh.94.1325679283785; Wed, 04 Jan 2012 04:14:43 -0800 (PST) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id e12sm68045300eea.5.2012.01.04.04.14.41 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 04:14:42 -0800 (PST) Message-ID: <4F0442B0.6020707@gmail.com> Date: Wed, 04 Jan 2012 14:14:40 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111223 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <201201031036.50837.jhb@freebsd.org> <20120104115753.GF34721@FreeBSD.org> In-Reply-To: <20120104115753.GF34721@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, John Baldwin Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:14:45 -0000 04.01.2012 13:57, Gleb Smirnoff wrote: > Does security_show_success="YES" suppress the security report entirely > (no mail sent), if no security related issues found? Yes. PS: I also prefer setting *_show_badconfig to 'yes' in case something is just not working right. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 13:14:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E91106566B; Wed, 4 Jan 2012 13:14:09 +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 AC7C48FC15; Wed, 4 Jan 2012 13:14:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 65EDC46B0C; Wed, 4 Jan 2012 08:14:09 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CA288B949; Wed, 4 Jan 2012 08:14:08 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Wed, 4 Jan 2012 08:11:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201201031036.50837.jhb@freebsd.org> <20120104115753.GF34721@FreeBSD.org> In-Reply-To: <20120104115753.GF34721@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201201040811.15793.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jan 2012 08:14:08 -0500 (EST) Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:14:09 -0000 On Wednesday, January 04, 2012 6:57:53 am Gleb Smirnoff wrote: > On Tue, Jan 03, 2012 at 10:36:50AM -0500, John Baldwin wrote: > J> > why do we send all these empty headings for periodic emails or given there is > J> > no output to this one can we > J> > > J> > 1) suppress the empty sections (to me that sounds a bit like a wrong > J> > return code or something maybe?), and > J> > 2) add an option to suppress "empty" periodic emails entirely? > J> > J> Have you tried 'daily_show_success="NO"' in /etc/periodic.conf? > J> > J> (Also security_show_success, weekly_show_success, and monthly_show_success?) > J> > J> Those certainly have fixed both 1) and 2) for me. > > Does security_show_success="YES" suppress the security report entirely > (no mail sent), if no security related issues found? > > When I once tried OpenBSD, I loved that security report mail isn't > generated at all if not issues found. Yes. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 13:32:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64451065678 for ; Wed, 4 Jan 2012 13:32:53 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 92E3F8FC19 for ; Wed, 4 Jan 2012 13:32:53 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RiQg8-0004xW-0t for freebsd-current@freebsd.org; Wed, 04 Jan 2012 05:14:52 -0800 Date: Wed, 4 Jan 2012 05:14:52 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1325682892011-5119548.post@n5.nabble.com> In-Reply-To: <1325682607290-5119535.post@n5.nabble.com> References: <1325682607290-5119535.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:32:53 -0000 Is vidfont invoked during installation at all? -- View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5119548.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 13:32:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF61106566C for ; Wed, 4 Jan 2012 13:32:54 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 297DD8FC1A for ; Wed, 4 Jan 2012 13:32:54 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RiQbX-0004Om-9b for freebsd-current@freebsd.org; Wed, 04 Jan 2012 05:10:07 -0800 Date: Wed, 4 Jan 2012 05:10:07 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1325682607290-5119535.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:32:54 -0000 Is it working correctly? e.g. Choosing "Polish ISO-8859-2" results in just keymap="pl_PL.ISO8859-2.kbd" added to rc.conf, while to have fully working polish fonts you need font8x14=iso02-8x14 font8x16=iso02-8x16 font8x8=iso02-8x8 keymap=pl_PL.ISO8859-2 -- View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5119535.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 13:46:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6388E106566C; Wed, 4 Jan 2012 13:46:48 +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 2E4C28FC08; Wed, 4 Jan 2012 13:46:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q04DkliM033464; Wed, 4 Jan 2012 08:46:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q04DkkxC033455; Wed, 4 Jan 2012 13:46:46 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 4 Jan 2012 13:46:46 GMT Message-Id: <201201041346.q04DkkxC033455@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: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:46:48 -0000 TB --- 2012-01-04 12:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-04 12:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-01-04 12:50:00 - cleaning the object tree TB --- 2012-01-04 12:50:59 - cvsupping the source tree TB --- 2012-01-04 12:50:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-01-04 12:51:11 - building world TB --- 2012-01-04 12:51:11 - CROSS_BUILD_TESTING=YES TB --- 2012-01-04 12:51:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-04 12:51:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-04 12:51:11 - SRCCONF=/dev/null TB --- 2012-01-04 12:51:11 - TARGET=amd64 TB --- 2012-01-04 12:51:11 - TARGET_ARCH=amd64 TB --- 2012-01-04 12:51:11 - TZ=UTC TB --- 2012-01-04 12:51:11 - __MAKE_CONF=/dev/null TB --- 2012-01-04 12:51:11 - cd /src TB --- 2012-01-04 12:51:11 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 4 12:51:12 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaCast.cpp c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaChecking.cpp c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaCodeComplete.cpp /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaCodeComplete.cpp: In function 'void AddOrdinaryNameResults(clang::Sema::ParserCompletionContext, clang::Scope*, clang::Sema&, ::ResultBuilder&)': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaCodeComplete.cpp:1383: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libclangsema. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-04 13:46:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-04 13:46:46 - ERROR: failed to build world TB --- 2012-01-04 13:46:46 - 2632.35 user 540.32 system 3405.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 19:27:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54C71065670 for ; Wed, 4 Jan 2012 19:27:06 +0000 (UTC) (envelope-from edwinlculp@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 6F7BE8FC13 for ; Wed, 4 Jan 2012 19:27:05 +0000 (UTC) Received: by eaaf13 with SMTP id f13so22462326eaa.13 for ; Wed, 04 Jan 2012 11:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8B170Cu7EJ9/a5jTZ67NGQvVX2P9Tmc9UT9uCJJ9gGE=; b=CUL7siNhDlTNdjD7Y8UzVm8XXiizZtvECBgb2O+LBNMWQ0gNAXNn7Ywh/yolTrLbHW wOSxgqLTKr8d3h1FB8klRijdHYZuqG8t1fMd/7Tewqj9hBckkvB1bitFi5f8FCTE2JGa OmVf0I6z3RQJWxOXwrLdADw3cuBQY+LvoaTvw= MIME-Version: 1.0 Received: by 10.204.141.4 with SMTP id k4mr3713624bku.95.1325703690010; Wed, 04 Jan 2012 11:01:30 -0800 (PST) Received: by 10.205.81.202 with HTTP; Wed, 4 Jan 2012 11:01:29 -0800 (PST) In-Reply-To: <1325682892011-5119548.post@n5.nabble.com> References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> Date: Wed, 4 Jan 2012 13:01:29 -0600 Message-ID: From: "Edwin L. Culp W." To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:27:06 -0000 On Wed, Jan 4, 2012 at 7:14 AM, Jakub Lach wrote: > Is vidfont invoked during installation at all? > > > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5119548.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Last night I suped, built and installed a new world with all the trimmings and then updated ports with portmaster -a. I saw that hal was updated. When I ran startx I was supprised that my keymap value was ignored. I now have an english keyboard only in X but my consoles work correctly and work in Spanish as configured in rc.conf. That really has me confused. Yestarday, all was well. My guess is that something changed in the last 36 hours that caused the change but I haven't be able to make heads or tails of it. Any suggestions appreciated, ed From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:18:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E771B106564A for ; Wed, 4 Jan 2012 20:18:13 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id C286E8FC1B for ; Wed, 4 Jan 2012 20:18:13 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RiXHo-0007tf-M0 for freebsd-current@freebsd.org; Wed, 04 Jan 2012 12:18:12 -0800 Date: Wed, 4 Jan 2012 12:18:12 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1325708292675-5120710.post@n5.nabble.com> In-Reply-To: References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:18:14 -0000 That's not related at all. For X you need something like " Option "XkbLayout" "es"" in xorg.conf, and I complained about syscons settings after installation. -- View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5120710.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:22:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1FB9106564A for ; Wed, 4 Jan 2012 20:22:57 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2978FC12 for ; Wed, 4 Jan 2012 20:22:57 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id DA278119C79; Wed, 4 Jan 2012 14:22:56 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325708576; bh=awMeN3QRXmsKm6PHHf1kCliVjTNu1KujWYnW9YgisDc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=kzHyEfDVIWSlafB5B/nNLgGo3+JPFkiZ0T6hMwrOhnfyGUrGq7+fQlHMU8ovO2IX0 eVScJsUAxiNjeLX5EiJYbDI5E3bdUhPKb4HtUzBpM/hXzh+0XjrQj2QhVAOj1FWM6X U7ono+Tto4hP01ieDdpwZ8O4Bg32lxElPxOCwTy0= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id D98A0119C6F for ; Wed, 4 Jan 2012 14:22:56 -0600 (CST) Date: Wed, 4 Jan 2012 14:22:56 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:22:57 -0000 sunsaturn:~# sysctl -w kern.ipc.somaxconn=200000 kern.ipc.somaxconn: 4096 sysctl: kern.ipc.somaxconn: Invalid argument sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536 kern.ipc.somaxconn: 4096 sysctl: kern.ipc.somaxconn: Invalid argument sunsaturn:~# sysctl -w kern.ipc.somaxconn=65535 kern.ipc.somaxconn: 4096 -> 65535 sunsaturn:~# Trying to stress test a framework here that tosses 100k of connections into a listen queue before doing anything, I realize I'll have to use multiple local IPs get get around port limitations, but why is this backlog using a limit? Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:28:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CCBC1065676 for ; Wed, 4 Jan 2012 20:28:36 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7743C8FC0C for ; Wed, 4 Jan 2012 20:28:36 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RiXRr-0000Yn-TK for freebsd-current@freebsd.org; Wed, 04 Jan 2012 12:28:35 -0800 Date: Wed, 4 Jan 2012 12:28:35 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1325708915902-5120743.post@n5.nabble.com> In-Reply-To: <1325708292675-5120710.post@n5.nabble.com> References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:28:36 -0000 Or you could use x11/setxkbmap each time you login. -- View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5120743.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:44:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F7C71065670 for ; Wed, 4 Jan 2012 20:44:02 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 076218FC15 for ; Wed, 4 Jan 2012 20:44:01 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 74DCA119C79; Wed, 4 Jan 2012 14:44:01 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325709841; bh=fPbsAAQzN3B13zrwY/lDdjJJgTxqTVfapJhloGrqokw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=I+gF6L95UsAazGWz8T6UyK02ttBK8wUbEFtbIM55d+hqg8v4S0p/5sWau+vUejFmd DA6tj1uUdob7IyBQme9jAkWav5yt8zoQrdd0WuLdMK3mlqHpFZgK7oARarc+Wo+RnN do7eqmhSXFEceOhFM5yyVqG+HOoitWnhU/Lf3/hc= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 6F87D119C6E; Wed, 4 Jan 2012 14:44:01 -0600 (CST) Date: Wed, 4 Jan 2012 14:44:01 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:44:02 -0000 On Wed, 4 Jan 2012, Chuck Swiger wrote: > On Jan 4, 2012, at 12:22 PM, Dan The Man wrote: >> Trying to stress test a framework here that tosses 100k of connections into a listen queue before doing anything, I realize I'll have to use multiple local IPs get get around port limitations, but why is this backlog using a limit? > > Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog is big enough that plenty of clients (I'm thinking web-browsers here in particular) will have given up and maybe retried rather than waiting for 60+ seconds just to exchange data. > For web browsers makes sense, but if your coding your own server application its only a matter of increasing the read and write timeouts to fill queue that high and still process them. Of course wouldn't need anything that high, but for benchmarking how much can toss in that listen queue then write something to socket on each one after connection established to see how fast application can finish them all, I think its relevant. This linux box I have no issues: cappy:~# /sbin/sysctl -w net.core.somaxconn=200000 net.core.somaxconn = 200000 cappy:~# sysctl -w net.ipv4.tcp_max_syn_backlog=20000 net.ipv4.tcp_max_syn_backlog = 200000 cappy:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:51:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 591DB106564A for ; Wed, 4 Jan 2012 20:51:39 +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 3DF158FC12 for ; Wed, 4 Jan 2012 20:51:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA001EUKLQ8H40@asmtp026.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 12:51:26 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_07:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040220 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 12:51:25 -0800 Message-id: <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:51:39 -0000 On Jan 4, 2012, at 12:44 PM, Dan The Man wrote: >> Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog is big enough that plenty of clients (I'm thinking web-browsers here in particular) will have given up and maybe retried rather than waiting for 60+ seconds just to exchange data. > > For web browsers makes sense, but if your coding your own server application its only a matter of increasing the read and write timeouts > to fill queue that high and still process them. Sure, agreed. > Of course wouldn't need anything that high, but for benchmarking how much can toss in that listen queue then write something to socket on each one after connection established to see how fast application can finish them all, I think its relevant. > > This linux box I have no issues: > cappy:~# /sbin/sysctl -w net.core.somaxconn=200000 > net.core.somaxconn = 200000 > cappy:~# sysctl -w net.ipv4.tcp_max_syn_backlog=20000 > net.ipv4.tcp_max_syn_backlog = 200000 > cappy:~# However, I'm not convinced that it is useful to do this. At some point, you are better off timing out and retrying via exponential backoff than you are queuing hundreds of thousands of connections in the hopes that they will eventually be serviced by something sometime considerably later. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:59:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87255106564A for ; Wed, 4 Jan 2012 20:59:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 353108FC08 for ; Wed, 4 Jan 2012 20:59:06 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q04KuUhY024179 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 4 Jan 2012 13:56:32 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4EFCD252.7080209@cran.org.uk> Date: Wed, 4 Jan 2012 13:56:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EFC1260.1060503@luddite.com.au> <4EFCD252.7080209@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 04 Jan 2012 13:56:36 -0700 (MST) Cc: Renato Botelho , freebsd-current@freebsd.org, "Peter J. Cherny" Subject: Re: Apropos Removal of sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:59:06 -0000 On Dec 29, 2011, at 1:49 PM, Bruce Cran wrote: > On 29/12/2011 18:39, Renato Botelho wrote: >> IIRC, PCBSD installer can install a regular FreeBSD on ZFS.=20 >=20 > It can do, but you're left with a /very/ basic installation - the = hostname, network interfaces etc. aren't configured, which could be a = problem for some people. >=20 > If I thought there would be any support for it, I'd try and find time = to plug in the sade(4) rewrite into sysinstall - it has a rather nice UI = and supports ZFS. The base of the PC-BSD installer is in the system as pc-sysinstall... = There were plans to merge bsdinstall with it that never came to = fruition. pc-sysinstall handles the hard part of the system install on = a huge number of combinations. Just FYI. Warner From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:03:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CF6C1065670 for ; Wed, 4 Jan 2012 21:03:30 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 433988FC1E for ; Wed, 4 Jan 2012 21:03:30 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id D54A8119C6E; Wed, 4 Jan 2012 15:03:29 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325711009; bh=hPNaYyxSqq5Gz5dD4C1KOBUJTYNyxizZ2eSAQ6MYDYc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=pThKlcwAapt7SOQGvPUNrkiyAZJlXKkut7uquOnLYSkkqFSjkF3FeB0UKAH8s+H3/ WBYpTfElwiI2oXmTAZwap/55nGqiO8KHp6D15D8INIrGZJCQ1+G3a7tDZ33Ly1E9xr 5O5g0RQFusM6UhPXtPE2XjhlWXbl5zlYdoJWnD7E= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id CF732119C56; Wed, 4 Jan 2012 15:03:29 -0600 (CST) Date: Wed, 4 Jan 2012 15:03:29 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:03:30 -0000 On Wed, 4 Jan 2012, Chuck Swiger wrote: > On Jan 4, 2012, at 12:44 PM, Dan The Man wrote: >>> Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog is big enough that plenty of clients (I'm thinking web-browsers here in particular) will have given up and maybe retried rather than waiting for 60+ seconds just to exchange data. >> >> For web browsers makes sense, but if your coding your own server application its only a matter of increasing the read and write timeouts >> to fill queue that high and still process them. > > Sure, agreed. > >> Of course wouldn't need anything that high, but for benchmarking how much can toss in that listen queue then write something to socket on each one after connection established to see how fast application can finish them all, I think its relevant. >> >> This linux box I have no issues: >> cappy:~# /sbin/sysctl -w net.core.somaxconn=200000 >> net.core.somaxconn = 200000 >> cappy:~# sysctl -w net.ipv4.tcp_max_syn_backlog=20000 >> net.ipv4.tcp_max_syn_backlog = 200000 >> cappy:~# > > However, I'm not convinced that it is useful to do this. At some point, you are better off timing out and retrying via exponential backoff than you are queuing hundreds of thousands of connections in the hopes that they will eventually be serviced by something sometime considerably later. > I agree completely, in practical application this makes sense, but why should the OS dictate not being able to temporarily set that setting higher in order to fully benchmark the application at 100k+ in the listen queue if the developer so chooses? I think that alone should be a good reason, to make freebsd developer friendly. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:15:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B80FB1065672 for ; Wed, 4 Jan 2012 21:15:11 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB798FC18 for ; Wed, 4 Jan 2012 21:15:11 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 37B29119C6E; Wed, 4 Jan 2012 15:15:11 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325711711; bh=DfSR2yN8pQuu+xSQQiOh4SxVjLuGMO/TyUE6tJVKgqI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=bi09YccRPjbjw2taEIQt8TksUZdC8bSOEXd9s8rMueLOaWoZPuY3TOKwo3m09zn2N VN9NBfrjofgGXrcVs9ZkT12LRF+ZIyWi7lUXXTvFuZfbj6ZjfLhc2DRs0PzYPWyYGD uoYzAyPU1lF0npRgZ2RTYEKBI78OuJpgEKO0VpbQ= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 369CF119C56; Wed, 4 Jan 2012 15:15:11 -0600 (CST) Date: Wed, 4 Jan 2012 15:15:11 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:15:11 -0000 On Wed, 4 Jan 2012, Dan The Man wrote: > > On Wed, 4 Jan 2012, Chuck Swiger wrote: > >> On Jan 4, 2012, at 12:44 PM, Dan The Man wrote: >>>> Even a backlog of a 1000 is large compared to the default listen queue >>>> size of around 50 or 128. And if you can drain 1000 connections per >>>> second, a 65K backlog is big enough that plenty of clients (I'm thinking >>>> web-browsers here in particular) will have given up and maybe retried >>>> rather than waiting for 60+ seconds just to exchange data. >>> >>> For web browsers makes sense, but if your coding your own server >>> application its only a matter of increasing the read and write timeouts >>> to fill queue that high and still process them. >> >> Sure, agreed. >> >>> Of course wouldn't need anything that high, but for benchmarking how much >>> can toss in that listen queue then write something to socket on each one >>> after connection established to see how fast application can finish them >>> all, I think its relevant. >>> >>> This linux box I have no issues: >>> cappy:~# /sbin/sysctl -w net.core.somaxconn=200000 >>> net.core.somaxconn = 200000 >>> cappy:~# sysctl -w net.ipv4.tcp_max_syn_backlog=20000 >>> net.ipv4.tcp_max_syn_backlog = 200000 >>> cappy:~# >> >> However, I'm not convinced that it is useful to do this. At some point, >> you are better off timing out and retrying via exponential backoff than you >> are queuing hundreds of thousands of connections in the hopes that they >> will eventually be serviced by something sometime considerably later. >> > > I agree completely, in practical application this makes sense, but why should > the OS dictate not being able to temporarily set that setting higher in order > to fully benchmark the application at 100k+ in the listen queue if the > developer so chooses? I think that alone should be a good reason, to make > freebsd developer friendly. Anyways its not a big deal I can live with a 60k or so benchmark, I just really wanted to see how freebsd's kqueue would perform processing that many connections right out of the listen queue. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:35:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B289106564A for ; Wed, 4 Jan 2012 21:35:24 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 3341F8FC08 for ; Wed, 4 Jan 2012 21:35:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp020.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA009X4JUXRA80@asmtp020.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 20:35:21 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_07:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040215 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 12:35:20 -0800 Message-id: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> References: To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:35:24 -0000 On Jan 4, 2012, at 12:22 PM, Dan The Man wrote: > Trying to stress test a framework here that tosses 100k of connections into a listen queue before doing anything, I realize I'll have to use multiple local IPs get get around port limitations, but why is this backlog using a limit? Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog is big enough that plenty of clients (I'm thinking web-browsers here in particular) will have given up and maybe retried rather than waiting for 60+ seconds just to exchange data. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:42:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6C87106566B for ; Wed, 4 Jan 2012 21:42:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id B9DDF8FC15 for ; Wed, 4 Jan 2012 21:42:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp021.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA00ENUMZBVS20@asmtp021.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 21:42:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_08:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040240 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 13:42:47 -0800 Message-id: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:42:48 -0000 On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >> However, I'm not convinced that it is useful to do this. At some point, you are better off timing out and retrying via exponential backoff than you are queuing hundreds of thousands of connections in the hopes that they will eventually be serviced by something sometime considerably later. > > I agree completely, in practical application this makes sense, but why should the OS dictate not being able to temporarily set that setting higher in order to fully benchmark the application at 100k+ in the listen queue if the developer so chooses? I think that alone should be a good reason, to make freebsd developer friendly. The job of the OS is to manage resources on behalf of the users and processes using the system. Some developers feel that VM means that the system should always claim have more memory available, but always saying "yes" isn't "managing resources". I'd rather have the OS return a null pointer and set ENOMEM when someone tries to malloc() more memory than the system (including swap, VM overcommit, etc) has, and I expect developers to code well enough to handle malloc() failures. Setting the listen queue to an arbitrarily high value isn't useful, and developers would be better advised to pay attention to best practices in the face of a massive connection backlog. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:49:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6C21065670 for ; Wed, 4 Jan 2012 21:49:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2EAAE8FC15 for ; Wed, 4 Jan 2012 21:49:51 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so17556004wib.13 for ; Wed, 04 Jan 2012 13:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WsjSD5SKUsAmk5BtDWRmUH5H9HKqEFfqFzPIcK+Z08k=; b=BBIWFO/GrSYpgNZhIWEalkH9sPPLnVyVhEb7si1mlMM3Wgz5Jkba4PB5KQXPi+pqB4 7QAYsRxujfODM+50QrYwn1q6CQxLc7ySbGXqemAR5QN67Mm1FIYesQQS3tqK2dqFLDIq W7k37M7IN4v+Oc2Lcvn2RgguheqgJuzKGHaRw= MIME-Version: 1.0 Received: by 10.180.106.165 with SMTP id gv5mr125603198wib.18.1325713791066; Wed, 04 Jan 2012 13:49:51 -0800 (PST) Received: by 10.216.178.204 with HTTP; Wed, 4 Jan 2012 13:49:50 -0800 (PST) In-Reply-To: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> Date: Wed, 4 Jan 2012 16:49:50 -0500 Message-ID: From: Arnaud Lacombe To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:49:52 -0000 Hi, On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: > On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >>> However, I'm not convinced that it is useful to do this. =A0At some poi= nt, you are better off timing out and retrying via exponential backoff than= you are queuing hundreds of thousands of connections in the hopes that the= y will eventually be serviced by something sometime considerably later. >> >> I agree completely, in practical application this makes sense, but why s= hould the OS dictate not being able to temporarily set that setting higher = in order to fully benchmark the application at 100k+ in the listen queue if= the developer so chooses? I think that alone should be a good reason, to m= ake freebsd developer friendly. > > The job of the OS is to manage resources on behalf of the users and proce= sses using the system. > No. The job of the OS is to service the user with the resource available, not constrict the user within some arbitrary predefined wall when there is still plenty of room available. If resource become scarce, then take action. > Some developers feel that VM means that the system should always claim ha= ve more memory available, but always saying "yes" isn't "managing resources= ". =A0I'd rather have the OS return a null pointer and set ENOMEM when some= one tries to malloc() more memory than the system (including swap, VM overc= ommit, etc) has, and I expect developers to code well enough to handle mall= oc() failures. > this is merely a policy issue, not yours to impose. > Setting the listen queue to an arbitrarily high value isn't useful, and d= evelopers would be better advised to pay attention to best practices in the= face of a massive connection backlog. > Stress-testing isn't about "best practice". It is about shaking enough the system to highlight weak point. - Arnaud > Regards, > -- > -Chuck > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:06:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC8E1106566C for ; Wed, 4 Jan 2012 22:06:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 84F1C8FC19 for ; Wed, 4 Jan 2012 22:06:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DE87F7300A; Wed, 4 Jan 2012 23:23:15 +0100 (CET) Date: Wed, 4 Jan 2012 23:23:15 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20120104222315.GA73613@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:06:25 -0000 Hi, in doing cross-builds of picobsd, i found i need a cross-version of "ldd" so i can run it on the host to detect which shared libraries are used by binaries on the target architecture (for amd64->i386 there is a partial workaround, but don't know if it works in other cases) Is there any concern in adding usr.bin/ldd to the list of cross-tools in Makefile.inc1 ? It is a small program and should not increase the build time in any significant way. Otherwise, does anyone know the magic to build a cross-arch version of a program in the FreeBSD source tree ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:10:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C12BA106566C for ; Wed, 4 Jan 2012 22:10:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F01B8FC19 for ; Wed, 4 Jan 2012 22:10:37 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so21089887obb.13 for ; Wed, 04 Jan 2012 14:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JCYNzAWeLcR+//ldgHQnZawW5yb/sxYqCT6ATYerlp0=; b=E4MAIkTjvps8lESffXBa9VeZApbxTH95EtU4oo/FnJP3QUPabTMsXyCqZlaBlL1XNx XpGv8B5Nmyzw6RGQx99hXO9oqXI/Ubd8qXE5U7hzQ4S2/82qgSElftovXEgm7E0Sutrq lkzEmRv1GsltnFVF8wPG6Qf3gu5RflcpOmcNI= MIME-Version: 1.0 Received: by 10.182.1.8 with SMTP id 8mr49324678obi.11.1325715036972; Wed, 04 Jan 2012 14:10:36 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 4 Jan 2012 14:10:36 -0800 (PST) In-Reply-To: <20120104222315.GA73613@onelab2.iet.unipi.it> References: <20120104222315.GA73613@onelab2.iet.unipi.it> Date: Wed, 4 Jan 2012 14:10:36 -0800 Message-ID: From: Garrett Cooper To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:10:37 -0000 On Wed, Jan 4, 2012 at 2:23 PM, Luigi Rizzo wrote: > Hi, > in doing cross-builds of picobsd, i found i need a cross-version > of "ldd" so i can run it on the host to detect which shared libraries > are used by binaries on the target architecture > (for amd64->i386 there is a partial workaround, but don't know > if it works in other cases) > > Is there any concern in adding usr.bin/ldd to the list of cross-tools > in Makefile.inc1 ? It is a small program and should not increase > the build time in any significant way. > > Otherwise, does anyone know the magic to build a cross-arch > version of a program in the FreeBSD source tree ? objdump IMO is a lot easier to parse and it's already built via cross-tools: $ objdump -x `which tar` | awk '$1 == "NEEDED" { print $2 }' libarchive.so.5 libbz2.so.4 libz.so.6 liblzma.so.5 libbsdxml.so.4 libcrypto.so.6 libc.so.7 Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:10:50 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F941065673; Wed, 4 Jan 2012 22:10:50 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFED8FC0A; Wed, 4 Jan 2012 22:10:50 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id DDC5F9DAF0; Wed, 4 Jan 2012 22:55:08 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id CjgLgB5Artu3; Wed, 4 Jan 2012 22:55:06 +0100 (CET) Received: from danger-mbp.local (adsl-dyn163.78-98-251.t-com.sk [78.98.251.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 4A7599DADE; Wed, 4 Jan 2012 22:55:06 +0100 (CET) Message-ID: <4F04CABE.1050301@FreeBSD.org> Date: Wed, 04 Jan 2012 22:55:10 +0100 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.25pre) Gecko/20111115 Lanikai/3.1.17pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: REMAINDER: Call for FreeBSD Status Reports - 4Q/2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:10:50 -0000 Hello everybody, I'd like to remind you that only ca. 10 days have left to the status report submission deadline. Note that we have only received 4 entries so far. I guess most of the people's holidays have finished by now so I hope we will receive much more than that by January 15, 2012. Thanks in advance! PS: Happy New Year 2012! -------- Original Message -------- Subject: REMAINDER: Call for FreeBSD Status Reports - 4Q/2011 Date: Wed, 21 Dec 2011 12:20:01 +0100 From: Daniel Gerzo Organization: The FreeBSD Project To: , , Dear all, I would like to remind you that the next round of status reports covering the fourth quarter of 2011 are due on January 15th, 2012. As this initiative is very popular among our users, I would like to ask you to submit your status reports as sooner than later (holidays are quickly approaching), so that we can compile the report in a timely fashion. Do not hesitate and write a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome as well. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:11:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A770B1065675 for ; Wed, 4 Jan 2012 22:11:12 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 885998FC1C for ; Wed, 4 Jan 2012 22:11:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp019.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA0045POAJO000@asmtp019.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 22:11:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_08:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040251 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 14:11:06 -0800 Message-id: <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org, Dan The Man Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:11:12 -0000 On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: >> On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >>>> However, I'm not convinced that it is useful to do this. At some point, you are better off timing out and retrying via exponential backoff than you are queuing hundreds of thousands of connections in the hopes that they will eventually be serviced by something sometime considerably later. >>> >>> I agree completely, in practical application this makes sense, but why should the OS dictate not being able to temporarily set that setting higher in order to fully benchmark the application at 100k+ in the listen queue if the developer so chooses? I think that alone should be a good reason, to make freebsd developer friendly. >> >> The job of the OS is to manage resources on behalf of the users and processes using the system. > > No. The job of the OS is to service the user with the resource > available, not constrict the user within some arbitrary predefined > wall when there is still plenty of room available. If resource become > scarce, then take action. It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if needed and appropriate. The fact that a system might have 50,000 file descriptors globally available does not mean that it would be OK for any random process to consume half of them, even if there is still adequate room left for other tasks. It's common for "ulimit -n" to be set to 256 or 1024. >> Some developers feel that VM means that the system should always claim have more memory available, but always saying "yes" isn't "managing resources". I'd rather have the OS return a null pointer and set ENOMEM when someone tries to malloc() more memory than the system (including swap, VM overcommit, etc) has, and I expect developers to code well enough to handle malloc() failures. > > this is merely a policy issue, not yours to impose. If we're speaking of machines which I administer, it is a policy issue that would be mine to impose. If we're speaking of someone else's machines, then they can set their own policies as they please. >> Setting the listen queue to an arbitrarily high value isn't useful, and developers would be better advised to pay attention to best practices in the face of a massive connection backlog. > > Stress-testing isn't about "best practice". It is about shaking enough > the system to highlight weak point. Yes. If the system doesn't handle connectivity problems via something like exponential backoff, then the weak point is poor software design and not FreeBSD being unwilling to set the socket listen queue to a value in the hundreds of thousands. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:13:04 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DC7106566C for ; Wed, 4 Jan 2012 22:13:04 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 992E98FC22 for ; Wed, 4 Jan 2012 22:13:04 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 60F487300A; Wed, 4 Jan 2012 23:29:55 +0100 (CET) Date: Wed, 4 Jan 2012 23:29:55 +0100 From: Luigi Rizzo To: Garrett Cooper Message-ID: <20120104222955.GA73868@onelab2.iet.unipi.it> References: <20120104222315.GA73613@onelab2.iet.unipi.it> 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: current@freebsd.org Subject: Re: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:13:04 -0000 On Wed, Jan 04, 2012 at 02:10:36PM -0800, Garrett Cooper wrote: > On Wed, Jan 4, 2012 at 2:23 PM, Luigi Rizzo wrote: > > Hi, > > in doing cross-builds of picobsd, i found i need a cross-version > > of "ldd" so i can run it on the host to detect which shared libraries > > are used by binaries on the target architecture > > (for amd64->i386 there is a partial workaround, but don't know > > if it works in other cases) > > > > Is there any concern in adding usr.bin/ldd to the list of cross-tools > > in Makefile.inc1 ? It is a small program and should not increase > > the build time in any significant way. > > > > Otherwise, does anyone know the magic to build a cross-arch > > version of a program in the FreeBSD source tree ? > > objdump IMO is a lot easier to parse and it's already built via cross-tools: > > $ objdump -x `which tar` | awk '$1 == "NEEDED" { print $2 }' > libarchive.so.5 > libbz2.so.4 > libz.so.6 > liblzma.so.5 > libbsdxml.so.4 > libcrypto.so.6 > libc.so.7 wonderful, thanks! cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:23:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEFE9106566B for ; Wed, 4 Jan 2012 22:23:58 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7180F8FC0A for ; Wed, 4 Jan 2012 22:23:58 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id C797A119C77; Wed, 4 Jan 2012 16:23:57 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325715837; bh=cqh/tYtudxt/HBCcCKh5DIA/IX8biMiNiX04VIDTkuw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=YIjXMvYLAcg+x1QNrQ1A7Mx0uP91uRTEZd1hEY+np2F8Ftw+ckF6OOzmpUX6u4r1a as8ll5SZCR3U4J02kpFcfVq6+RFDkV9E6ob+ItqJ2P5bqjbgd5Gac1T95p86kDVRJW VIttj+n2TwrCBPU1zNdkunkTro7DDwngFdvz13CY= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id C1E75119C62; Wed, 4 Jan 2012 16:23:57 -0600 (CST) Date: Wed, 4 Jan 2012 16:23:57 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:23:58 -0000 On Wed, 4 Jan 2012, Chuck Swiger wrote: > On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: >>> On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >>>>> However, I'm not convinced that it is useful to do this. At some point, you are better off timing out and retrying via exponential backoff than you are queuing hundreds of thousands of connections in the hopes that they will eventually be serviced by something sometime considerably later. >>>> >>>> I agree completely, in practical application this makes sense, but why should the OS dictate not being able to temporarily set that setting higher in order to fully benchmark the application at 100k+ in the listen queue if the developer so chooses? I think that alone should be a good reason, to make freebsd developer friendly. >>> >>> The job of the OS is to manage resources on behalf of the users and processes using the system. >> >> No. The job of the OS is to service the user with the resource >> available, not constrict the user within some arbitrary predefined >> wall when there is still plenty of room available. If resource become >> scarce, then take action. > > It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if needed and appropriate. The fact that a system might have 50,000 file descriptors globally available does not mean that it would be OK for any random process to consume half of them, even if there is still adequate room left for other tasks. It's common for "ulimit -n" to be set to 256 or 1024. Sensibly limits means a sensible stock default, not imposing an OS limit on what admin/developer can set on his own hardware. With the new IBM developments underway of 16 core atom processors and hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or what about the future of 500 core systems with a terrabyte of memory, 100k listen queue could be processed instantly. > >>> Some developers feel that VM means that the system should always claim have more memory available, but always saying "yes" isn't "managing resources". I'd rather have the OS return a null pointer and set ENOMEM when someone tries to malloc() more memory than the system (including swap, VM overcommit, etc) has, and I expect developers to code well enough to handle malloc() failures. >> >> this is merely a policy issue, not yours to impose. > > If we're speaking of machines which I administer, it is a policy issue that would be mine to impose. > If we're speaking of someone else's machines, then they can set their own policies as they please. > >>> Setting the listen queue to an arbitrarily high value isn't useful, and developers would be better advised to pay attention to best practices in the face of a massive connection backlog. >> >> Stress-testing isn't about "best practice". It is about shaking enough >> the system to highlight weak point. > > Yes. If the system doesn't handle connectivity problems via something like exponential backoff, then the weak point is poor software design and not FreeBSD being unwilling to set the socket listen queue to a value in the hundreds of thousands. > I think what me and Arnaud are trying to say here, is let freebsd use a sensible default value, but let the admin dictate the actual policy if he so chooses to change it for stress testing, future proofing or anything else. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:30:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B193A106564A for ; Wed, 4 Jan 2012 22:30:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8E08FC15 for ; Wed, 4 Jan 2012 22:30:27 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so21116603obb.13 for ; Wed, 04 Jan 2012 14:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ntukfB7EeSya/pqQ77XdKrckSg1yqGssMB6oJRIBPG0=; b=xz8pi3YONE8KLBuUISc8FgsyfTZ8M946trnFtLU6Bww2jxwt1BvGrCs/LVD77A8hBy AMTW0FoGkcvuYZRhLNcvAPZZn/B44oiy/c4yeMtNoWDNKW4FeMqIaqyIkG6MOedAlK98 9OuNFZHNe3qi8x7ts4ac2TtJ/bEciGj0ocW8U= MIME-Version: 1.0 Received: by 10.182.193.99 with SMTP id hn3mr49280003obc.61.1325716227045; Wed, 04 Jan 2012 14:30:27 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 4 Jan 2012 14:30:27 -0800 (PST) In-Reply-To: <20120104222955.GA73868@onelab2.iet.unipi.it> References: <20120104222315.GA73613@onelab2.iet.unipi.it> <20120104222955.GA73868@onelab2.iet.unipi.it> Date: Wed, 4 Jan 2012 14:30:27 -0800 Message-ID: From: Garrett Cooper To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:30:27 -0000 On Wed, Jan 4, 2012 at 2:29 PM, Luigi Rizzo wrote: > On Wed, Jan 04, 2012 at 02:10:36PM -0800, Garrett Cooper wrote: >> On Wed, Jan 4, 2012 at 2:23 PM, Luigi Rizzo wrote: >> > Hi, >> > in doing cross-builds of picobsd, i found i need a cross-version >> > of "ldd" so i can run it on the host to detect which shared libraries >> > are used by binaries on the target architecture >> > (for amd64->i386 there is a partial workaround, but don't know >> > if it works in other cases) >> > >> > Is there any concern in adding usr.bin/ldd to the list of cross-tools >> > in Makefile.inc1 ? It is a small program and should not increase >> > the build time in any significant way. >> > >> > Otherwise, does anyone know the magic to build a cross-arch >> > version of a program in the FreeBSD source tree ? >> >> objdump IMO is a lot easier to parse and it's already built via cross-tools: >> >> $ objdump -x `which tar` | awk '$1 == "NEEDED" { print $2 }' >> libarchive.so.5 >> libbz2.so.4 >> libz.so.6 >> liblzma.so.5 >> libbsdxml.so.4 >> libcrypto.so.6 >> libc.so.7 > > wonderful, thanks! Np! The only gap with both of these tools is that you have to watch out for dl_open'ed binaries as they won't show up in ldd/objdump -x. If I could figure out how to detect these with a command line tool, I would be set for life :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:34:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F27D21065672 for ; Wed, 4 Jan 2012 22:34:24 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3838FC14 for ; Wed, 4 Jan 2012 22:34:24 +0000 (UTC) Received: by wibhr1 with SMTP id hr1so17589154wib.13 for ; Wed, 04 Jan 2012 14:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zIxHpDBt2y854d9Vjd1pszZcRKAsHaLwETAmII3kiFk=; b=ESCXdRU/eVIrtuUKSKq/5QcMvg2KDV4qCEZQIknpsuxo5zzzzl3MkWT5kWB5d03mRP jRrOcMr1ndAyh0luuX6yuZXGBjEF34ei326ceQPMCBO5/mVreOj1ALP3MgHRum8jc85W cFI9DvT2UCIkrokJZ0yfsUl32HcECvHNN3x2I= MIME-Version: 1.0 Received: by 10.180.106.165 with SMTP id gv5mr125843273wib.18.1325716462707; Wed, 04 Jan 2012 14:34:22 -0800 (PST) Received: by 10.216.178.204 with HTTP; Wed, 4 Jan 2012 14:34:22 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Jan 2012 17:34:22 -0500 Message-ID: From: Arnaud Lacombe To: Dan The Man Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:34:25 -0000 Hi, On Wed, Jan 4, 2012 at 3:22 PM, Dan The Man wrote: > > > sunsaturn:~# sysctl -w kern.ipc.somaxconn=200000 > kern.ipc.somaxconn: 4096 > sysctl: kern.ipc.somaxconn: Invalid argument > sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536 > kern.ipc.somaxconn: 4096 > sysctl: kern.ipc.somaxconn: Invalid argument > sunsaturn:~# sysctl -w kern.ipc.somaxconn=65535 > kern.ipc.somaxconn: 4096 -> 65535 > sunsaturn:~# > > Trying to stress test a framework here that tosses 100k of connections into > a listen queue before doing anything, I realize I'll have to use multiple > local IPs get get around port limitations, but why is this backlog using a > limit? > This is an arbitrary implementation limitation. A bit of code archaeology reveals that the explicit limitation was introduced in 1,226 of kern/uipc_socket.c[0]. Quoting the commit log: glebus@ << - Convert so_qlen, so_incqlen, so_qlimit fields of struct socket from short to unsigned short. - Add SYSCTL_PROC() around somaxconn, not accepting values < 1 or > U_SHRTMAX. Before this change setting somaxconn to smth above 32767 and calling listen(fd, -1) lead to a socket, which doesn't accept connections at all. Reviewed by: rwatson Reported by: Igor Sysoev >> so the limited width of some `struct socket' fields enforces this limitation. Now, the reason for `so_qlen', `so_incqlen', `so_qlimit' to be so limited might be lost in the arcane of time. After all "640K ought to be enough for anyone", doesn't it ? - Arnaud [0]: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c#rev1.226 > > Dan. > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:58:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75EE106566C; Wed, 4 Jan 2012 21:58:30 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCC328FC0C; Wed, 4 Jan 2012 21:58:29 +0000 (UTC) Received: by werb13 with SMTP id b13so15664963wer.13 for ; Wed, 04 Jan 2012 13:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6XEMeBte3msHnx3roQDC91QmbOtPNieE6mOxFDdWWoY=; b=u7K0sXTxjsX9ufdSpSwmxwnfC3tIap1qhVMswDIwcOrNjxdij2yGdZlOuHFKYdCXYO m5ETSJcKwAd/jkg20Dcg8dk/gi/5Ro/ve57Lkl43lmnnEph+MZYljPgqTMvFIe87yIj8 lGUEw5j2CzDBgeKgQBmR7V3PBJabBBYw8LsSE= MIME-Version: 1.0 Received: by 10.216.131.90 with SMTP id l68mr37657293wei.36.1325714308629; Wed, 04 Jan 2012 13:58:28 -0800 (PST) Received: by 10.216.178.204 with HTTP; Wed, 4 Jan 2012 13:58:28 -0800 (PST) In-Reply-To: <4eeb7cf9.43bfec0a.3e38.ffff9d19SMTPIN_ADDED@mx.google.com> References: <4eeb7cf9.43bfec0a.3e38.ffff9d19SMTPIN_ADDED@mx.google.com> Date: Wed, 4 Jan 2012 16:58:28 -0500 Message-ID: From: Arnaud Lacombe To: matthew@phoronix.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Jan 2012 22:34:43 +0000 Cc: Adrian Chadd , FreeBSD Stable Mailing List , Current FreeBSD , Joe Holden , Michael Larabel , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:58:31 -0000 Hi, On Fri, Dec 16, 2011 at 12:16 PM, wrote: > Thanks. > > My request for the person documenting the tunings also runs the benchmark= to > ensure expected behaviour. > Why should you have to tune anything ? Did you tune the Oracle Server install ? If not, you should not have to tune the FreeBSD install, that wouldn't be fair. If you tune FreeBSD, you should tune the Oracle Server install too. It is pretty easy to win at least 30% in performance for certain workload by choosing the right kernel configuration. - Arnaud > The installation, execution and comparison against the benchmarks in the > article is fairly simple. > > Note that some tuning may not be relevant or recommended (ie: some of the= fs > benchmarks are sensitive to barriers and other synchronous operations). = =A0I'd > recommend bowing out of a benchmark with a 'we're going to be slower sinc= e > the default configuration is this way for the following reason' if this i= s > the case. > > Thanks 'someone'. > > Matthew > > > =A0Dec 16, 2011 8:46 AM, Adrian Chadd wrote: > > Can someone please write up a nice, concise blog post somewhere > outlining all of this? > > Extra bonus points if it's a blog that is picked up by > blogs.freebsdish.org and/or some of the other BSD sites. > > Guys/girls/fuzzy things - this is 2011; people look at shiny blog > sites with graphs rather than mailing lists. Sorry, we lost that > battle. :) > > > > Adrian > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:41:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70BA6106567A for ; Wed, 4 Jan 2012 22:41:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 32CFB8FC1B for ; Wed, 4 Jan 2012 22:41:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EF2E77300A; Wed, 4 Jan 2012 23:58:15 +0100 (CET) Date: Wed, 4 Jan 2012 23:58:15 +0100 From: Luigi Rizzo To: Garrett Cooper Message-ID: <20120104225815.GA73964@onelab2.iet.unipi.it> References: <20120104222315.GA73613@onelab2.iet.unipi.it> <20120104222955.GA73868@onelab2.iet.unipi.it> 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: current@freebsd.org Subject: Re: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:41:25 -0000 On Wed, Jan 04, 2012 at 02:30:27PM -0800, Garrett Cooper wrote: > On Wed, Jan 4, 2012 at 2:29 PM, Luigi Rizzo wrote: ... > >> $ objdump -x `which tar` | awk '$1 == "NEEDED" { print $2 }' > >> libarchive.so.5 > >> libbz2.so.4 > >> libz.so.6 > >> liblzma.so.5 > >> libbsdxml.so.4 > >> libcrypto.so.6 > >> libc.so.7 > > > > wonderful, thanks! > > Np! The only gap with both of these tools is that you have to > watch out for dl_open'ed binaries as they won't show up in ldd/objdump > -x. If I could figure out how to detect these with a command line > tool, I would be set for life :). and the other thing, i just realized, is that once you locate the libraries you should run objdump recursively to find out further dependencies. Perhaps ldd sorts this out by itself ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:50:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D9FB106567A for ; Wed, 4 Jan 2012 22:50:05 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFC68FC28 for ; Wed, 4 Jan 2012 22:50:05 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id C5EE8119C79; Wed, 4 Jan 2012 16:50:04 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325717404; bh=V2v7J4LG+fR6nrbdjyMOApz21hpdyZJsCBKiGfkr08M=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=CLkef9w6vR3ypwyXCkcw9/Gu+lW5U4qn2HyZdRNDaXgUa9zcfilyrRR0ML/sQGn2k uYqRmPmLN/qpLV0uhR5XS274db3lYTjgIJkT4mHSTQzW/Rjcd04RJD9nXkg/gIDp7h LYKNV50HyjGo4C9hOPy480exQuw6/GsR4jnZiCXQ= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id C50AB119C77; Wed, 4 Jan 2012 16:50:04 -0600 (CST) Date: Wed, 4 Jan 2012 16:50:04 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:50:05 -0000 On Wed, 4 Jan 2012, Dan The Man wrote: > > On Wed, 4 Jan 2012, Chuck Swiger wrote: > >> On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: >>>> On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >>>>>> However, I'm not convinced that it is useful to do this. At some >>>>>> point, you are better off timing out and retrying via exponential >>>>>> backoff than you are queuing hundreds of thousands of connections in >>>>>> the hopes that they will eventually be serviced by something sometime >>>>>> considerably later. >>>>> >>>>> I agree completely, in practical application this makes sense, but why >>>>> should the OS dictate not being able to temporarily set that setting >>>>> higher in order to fully benchmark the application at 100k+ in the >>>>> listen queue if the developer so chooses? I think that alone should be a >>>>> good reason, to make freebsd developer friendly. >>>> >>>> The job of the OS is to manage resources on behalf of the users and >>>> processes using the system. >>> >>> No. The job of the OS is to service the user with the resource >>> available, not constrict the user within some arbitrary predefined >>> wall when there is still plenty of room available. If resource become >>> scarce, then take action. >> >> It is not arbitrary. Systems ought to provide sensible limits, which can >> be adjusted if needed and appropriate. The fact that a system might have >> 50,000 file descriptors globally available does not mean that it would be >> OK for any random process to consume half of them, even if there is still >> adequate room left for other tasks. It's common for "ulimit -n" to be set >> to 256 or 1024. > > Sensibly limits means a sensible stock default, not imposing an OS limit on > what admin/developer can set on his own hardware. > > With the new IBM developments underway of 16 core atom processors and > hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or > what about the future of 500 core systems with a terrabyte of memory, 100k > listen queue could be processed instantly. > >> >>>> Some developers feel that VM means that the system should always claim >>>> have more memory available, but always saying "yes" isn't "managing >>>> resources". I'd rather have the OS return a null pointer and set ENOMEM >>>> when someone tries to malloc() more memory than the system (including >>>> swap, VM overcommit, etc) has, and I expect developers to code well >>>> enough to handle malloc() failures. >>> >>> this is merely a policy issue, not yours to impose. >> >> If we're speaking of machines which I administer, it is a policy issue that >> would be mine to impose. >> If we're speaking of someone else's machines, then they can set their own >> policies as they please. >> >>>> Setting the listen queue to an arbitrarily high value isn't useful, and >>>> developers would be better advised to pay attention to best practices in >>>> the face of a massive connection backlog. >>> >>> Stress-testing isn't about "best practice". It is about shaking enough >>> the system to highlight weak point. >> >> Yes. If the system doesn't handle connectivity problems via something like >> exponential backoff, then the weak point is poor software design and not >> FreeBSD being unwilling to set the socket listen queue to a value in the >> hundreds of thousands. >> > > I think what me and Arnaud are trying to say here, is let freebsd use a > sensible default value, but let the admin dictate the actual policy if he so > chooses to change it for stress testing, future proofing or anything else. > How about a sensible solution? I think everyone has been making valid points here, about sensible limits for all programs on system and per application limit changes. How about changing the hard limit high, and an application can make the soft limit higher as it sees fit, its a win win, like ulimit does with openfiles and such. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:01:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BA61065670; Wed, 4 Jan 2012 23:01:58 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 142E58FC1F; Wed, 4 Jan 2012 23:01:57 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so21155898obb.13 for ; Wed, 04 Jan 2012 15:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7FnC6DjnzHaYHGN3a9vewKqdNZylj+Q4DiHE657GST8=; b=oJpwDDL5qv8AGoUjvj8aDMcupq9yDl6ozjMkNfs8YfU4n/FIkx4gfz/cz5UXjbnbEJ zKwlS6hHzYP/YtciSMxbaRQQ7vMrTzl5xypuYwWdGtvr2+vQ9EAywVgXRcaJzVwXsJ01 vDKpLBwUp8LzZOH6e5NBVMFfQ9UNXA6bN870M= MIME-Version: 1.0 Received: by 10.182.78.165 with SMTP id c5mr49880719obx.60.1325718117399; Wed, 04 Jan 2012 15:01:57 -0800 (PST) Received: by 10.182.67.163 with HTTP; Wed, 4 Jan 2012 15:01:57 -0800 (PST) In-Reply-To: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> Date: Wed, 4 Jan 2012 15:01:57 -0800 Message-ID: From: Xin LI To: Dan The Man Content-Type: text/plain; charset=UTF-8 Cc: Robert Watson , Gleb Smirnoff , Arnaud Lacombe , freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:02:00 -0000 Hi, On Wed, Jan 4, 2012 at 2:50 PM, Dan The Man wrote: [...] > How about a sensible solution? I think everyone has been making valid points > here, about sensible limits for all programs on system and per application > limit changes. > > How about changing the hard limit high, and an application can make the soft > limit higher as it sees fit, its a win win, like ulimit does with openfiles > and such. Looking at the code, it seems that there is no reason we can't make this u_short be u_int and just change the limit to U_INTMAX. The biggest problem that one would hit here is that changes the binary interface of both struct xsocket and struct socket consumers. Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 22:31:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911B11065678; Wed, 4 Jan 2012 22:31:58 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF0C8FC14; Wed, 4 Jan 2012 22:31:58 +0000 (UTC) Received: from mobile-166-205-136-164.mycingular.net ([166.205.136.164] helo=www.palm.com) by phx1.phoronix.com with esmtpa (Exim 4.69) (envelope-from ) id 1RiZNC-0007LN-Oy; Wed, 04 Jan 2012 16:31:56 -0600 Date: Wed, 04 Jan 2012 14:31:55 -0800 From: To: "Arnaud Lacombe" In-Reply-To: X-Mailer: Palm webOS X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com Message-Id: <20120104223158.911B11065678@hub.freebsd.org> X-Mailman-Approved-At: Wed, 04 Jan 2012 23:13:36 +0000 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adrian Chadd , FreeBSD Stable Mailing List , Current FreeBSD , Joe Holden , Michael Larabel , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:31:58 -0000 Thanks for the comment Arnaud. For comparative benchmarking on = [1]Phoronix.com, Michael inva= riable leaves it in the default configuration 'in the way the developers or= vendor wanted it for production'. This is by rule. However, i= nvariable the community or vendor for platforms that post poor scores on be= nchmark cry foul about using the default config. 'it should be tuned,= no-one deploys an untuned system' or 'the system is configured for a diffe= rent workload'. The response from us to this comes in two forms. &nb= sp; 1) If it is the wrong workload for the platform, do a public pos= t explaining and analysing the results. Highlighting the rationale fo= r the concious reduction in performance (ie: journaling filesystems with ba= rriers suffer in some write benchmarks for the sake of filesystem integrity= =2E 2) If tuning can have a material impact on the results, post a t= uning guide with step by step and rationale. Ie: educate the communit= y and users. Michael and I have had many discussions with vendors an= d communities on this. In almost all cases, the vendor has either cha= nged the default configuration or accepted the results as valid. As = a service to the community or vendor that publishes the tuning guide, Micha= el is more than willing to redo a tuned vs untuned comparison. To dat= e, the communities have never taken us up on that offer. In part, thi= s affects [2]Phoronix.com's perception in the public, but that is more of a result of a one sided d= iscussion by a party external to a particular community (with a healthy tou= ch of journalisticly pumped compare & contrast). For the FreeBSD = community, who else outside of the FreeBSD community actually runs public c= omparisons of FreeBSD against anything? Matthew -- Sent from my HP Pre3 _________________________________________________________________ On Jan 4, 2012 1:58 PM, Arnaud Lacombe wrote:=0D > Thanks.=0D >=0D &= gt; My request for the person documenting the tunings also runs the benchma= rk to=0D > ensure expected behaviour.=0D >=0D Why should you= have to tune anything ? Did you tune the Oracle Server=0D install ? If = not, you should not have to tune the FreeBSD install,=0D that wouldn't b= e fair. If you tune FreeBSD, you should tune the Oracle=0D Server instal= l too. It is pretty easy to win at least 30% in=0D performance for certa= in workload by choosing the right kernel=0D configuration.=0D =0D = - Arnaud=0D =0D > The installation, execution and comparison agai= nst the benchmarks in the=0D > article is fairly simple.=0D >= =0D > Note that some tuning may not be relevant or recommended (ie: s= ome of the fs=0D > benchmarks are sensitive to barriers and other syn= chronous operations). =C2=A0I'd=0D > recommend bowing out of a benchm= ark with a 'we're going to be slower since=0D > the default configura= tion is this way for the following reason' if this is=0D > the case.= =0D >=0D > Thanks 'someone'.=0D >=0D > Matthew=0D>=0D >=0D > =C2=A0Dec 16, 2011 8:46 AM, Adrian Chadd wrote:=0D >=0D > Can someone please write= up a nice, concise blog post somewhere=0D > outlining all of this?= =0D >=0D > Extra bonus points if it's a blog that is picked up = by=0D > blogs.freebsdish.org and/or some of the other BSD sites.=0D>=0D > Guys/girls/fuzzy things - this is 2011; people look at sh= iny blog=0D > sites with graphs rather than mailing lists. Sorry, we = lost that=0D > battle. :)=0D >=0D >=0D >=0D >= Adrian=0D > _______________________________________________=0D &g= t; freebsd-performance@freebsd.org mailing list=0D > http://lists.fre= ebsd.org/mailman/listinfo/freebsd-performance=0D > To unsubscribe, se= nd any mail to=0D > "freebsd-performance-unsubscribe@freebsd.org"=0D<= br> References 1. 3D"http://Phoronix.com"/ 2. 3D"http://Phoronix.com"/ From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:24:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0556106566B for ; Wed, 4 Jan 2012 23:24:47 +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 455BD8FC14 for ; Wed, 4 Jan 2012 23:24:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA00763ROTL200@asmtp026.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 15:24:30 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_09:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040276 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 15:24:28 -0800 Message-id: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:24:47 -0000 Hi-- On Jan 4, 2012, at 2:23 PM, Dan The Man wrote: >> It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if needed and appropriate. The fact that a system might have 50,000 file descriptors globally available does not mean that it would be OK for any random process to consume half of them, even if there is still adequate room left for other tasks. It's common for "ulimit -n" to be set to 256 or 1024. > > Sensibly limits means a sensible stock default, not imposing an OS limit on what admin/developer can set on his own hardware. In point of fact, protocols like TCP/IP impose limits on what is possible. It is in fact the job of the OS to say "no" when a developer asks for a TTL of a million via setsockopt(), because RFC-791 limits the maximum value of the "time to live" field to 255. > With the new IBM developments underway of 16 core atom processors and hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or what about the future of 500 core systems with a terrabyte of memory, 100k listen queue could be processed instantly. Um. I gather you don't have much background in operating system design or massively parallelized systems? Due to locking constraints imposed by whatever synchronization mechanism and communications topology is employed between cores, you simply cannot just add more processors to a system and expect it to go faster in a linear fashion. Having 500 cores contending over a single queue is almost certain to result in horrible performance. Even though the problem of a bunch of independent requests is "embarrassingly parallelizeable", you do that by partitioning the queue into multiple pieces that are fed to different groups or pools of processors to minimize contention over a single data structure. >> Yes. If the system doesn't handle connectivity problems via something like exponential backoff, then the weak point is poor software design and not FreeBSD being unwilling to set the socket listen queue to a value in the hundreds of thousands. > > I think what me and Arnaud are trying to say here, is let freebsd use a sensible default value, but let the admin dictate the actual policy if he so chooses to change it for stress testing, future proofing or anything else. FreeBSD does provide a sensible default value for the listen queue size. It's tunable to a factor of about 1000 times larger, and is a value which is sufficiently large to hold a backlog of several minutes worth of connections, assuming you can process the requests at a very high rate to keep draining the queue. There probably isn't a reasonable use-case for queuing unprocessed requests for longer than MAXTTL, which is about 4 minutes. So, it's conceivable in theory for a high-volume server to want to set the listen queue to, say 1000 req/s * 255 (ie, MAXTTL), but I manage high volume servers for a living, and practical experience including measurements of latency and service performance suggests that tuning the listen queue up to on the order of a thousand or so is the inflection point after which it is better/necessary for the software to recognize and start doing overload mitigation then it is for the OS to blindly queue more requests. Put more simply, there comes a point where saying "no", ie, dropping the connection with a reset, works better. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:28:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AB10106566B for ; Wed, 4 Jan 2012 23:28:48 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 251528FC08 for ; Wed, 4 Jan 2012 23:28:47 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1RiZgd-000A7a-Ls for freebsd-current@freebsd.org; Wed, 04 Jan 2012 14:52:02 -0800 Message-ID: <4F04D810.60304@freebsd.org> Date: Wed, 04 Jan 2012 14:52:00 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20120104222315.GA73613@onelab2.iet.unipi.it> In-Reply-To: <20120104222315.GA73613@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 04/01/2012 2:23 PM, Luigi Rizzo wrote: > Hi, > in doing cross-builds of picobsd, i found i need a cross-version > of "ldd" so i can run it on the host to detect which shared libraries > are used by binaries on the target architecture > (for amd64->i386 there is a partial workaround, but don't know > if it works in other cases) > > Is there any concern in adding usr.bin/ldd to the list of cross-tools > in Makefile.inc1 ? It is a small program and should not increase > the build time in any significant way. > > Otherwise, does anyone know the magic to build a cross-arch > version of a program in the FreeBSD source tree ? [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Subject: Re: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:28:48 -0000 On 04/01/2012 2:23 PM, Luigi Rizzo wrote: > Hi, > in doing cross-builds of picobsd, i found i need a cross-version > of "ldd" so i can run it on the host to detect which shared libraries > are used by binaries on the target architecture > (for amd64->i386 there is a partial workaround, but don't know > if it works in other cases) > > Is there any concern in adding usr.bin/ldd to the list of cross-tools > in Makefile.inc1 ? It is a small program and should not increase > the build time in any significant way. > > Otherwise, does anyone know the magic to build a cross-arch > version of a program in the FreeBSD source tree ? AFAIK ldd can't be used as a cross-tool. It sets some env variables for loader (e.g. ld-elf.so), calls execve or dlopen and relies on ld.so to print all the required data. You might get away with it on amd64/i386 host-target pair but it's not going to work for i386/arm or i386/mips pair. From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:30:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A68C61065675 for ; Wed, 4 Jan 2012 23:30:16 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECF78FC1D for ; Wed, 4 Jan 2012 23:30:16 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 8DE0B359356; Thu, 5 Jan 2012 00:30:15 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 657B728468; Thu, 5 Jan 2012 00:30:15 +0100 (CET) Date: Thu, 5 Jan 2012 00:30:15 +0100 From: Jilles Tjoelker To: Luigi Rizzo Message-ID: <20120104233015.GA51906@stack.nl> References: <20120104222315.GA73613@onelab2.iet.unipi.it> <20120104222955.GA73868@onelab2.iet.unipi.it> <20120104225815.GA73964@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120104225815.GA73964@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , current@freebsd.org Subject: Re: add 'ldd' to cross-tools ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:30:16 -0000 On Wed, Jan 04, 2012 at 11:58:15PM +0100, Luigi Rizzo wrote: > On Wed, Jan 04, 2012 at 02:30:27PM -0800, Garrett Cooper wrote: > > On Wed, Jan 4, 2012 at 2:29 PM, Luigi Rizzo wrote: > ... > > >> $ objdump -x `which tar` | awk '$1 == "NEEDED" { print $2 }' > > >> libarchive.so.5 > > >> libbz2.so.4 > > >> libz.so.6 > > >> liblzma.so.5 > > >> libbsdxml.so.4 > > >> libcrypto.so.6 > > >> libc.so.7 > > > wonderful, thanks! > > Np! The only gap with both of these tools is that you have to > > watch out for dl_open'ed binaries as they won't show up in ldd/objdump > > -x. If I could figure out how to detect these with a command line > > tool, I would be set for life :). > and the other thing, i just realized, is that once you locate > the libraries you should run objdump recursively to find > out further dependencies. Perhaps ldd sorts this out by itself ? ldd basically sets LD_TRACE_LOADED_OBJECTS=yes and runs the program (after having checked it is a dynamic executable). This means it will not work as a cross tool. Upsides are that it is simple and it shows exactly what rtld would do (because it is rtld), handling things like /var/run/ld-elf.so.hints, LD_LIBRARY_PATH and pathnames hardcoded into objects. You will have to run objdump (or readelf) recursively. (Note that there are also use cases where just the non-recursive NEEDED tags are appropriate, not all objects that happen to be loaded.) -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:49:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11F321065670 for ; Wed, 4 Jan 2012 23:49:18 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7AE08FC18 for ; Wed, 4 Jan 2012 23:49:17 +0000 (UTC) Received: by qcse13 with SMTP id e13so15478541qcs.13 for ; Wed, 04 Jan 2012 15:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=beDoKEUIk0zBuBQW+rbWGI8gjx7JujE5SihTXoewDKE=; b=eKFG+FcpGlE/JOUMCX8Ly87VJO19/uDVi7GcM4vTY5tpaF+Lme1WLgMqJUSqDPUrAB Y2X4k/9kzyZXmJojc7MP/k7mRJTbwCgilBW8m93GWT+sVfpO6k7vBh8XgpEZFxADZ9t2 v5oNDYEcL9r/g6xunxrs8jvL78Nia/xeyHvHc= Received: by 10.229.135.149 with SMTP id n21mr21720325qct.53.1325720956731; Wed, 04 Jan 2012 15:49:16 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id h6sm28236244qap.2.2012.01.04.15.49.15 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 15:49:16 -0800 (PST) Date: Wed, 4 Jan 2012 18:49:10 -0500 From: Alexander Kabaev To: Message-ID: <20120104184910.0d604240@kan.dyndns.org> In-Reply-To: <20120104223158.911B11065678@hub.freebsd.org> References: <20120104223158.911B11065678@hub.freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/E950_Ap3Vq1E8qCyz2buUn_"; protocol="application/pgp-signature" Cc: Adrian Chadd , FreeBSD Stable Mailing List , Michael, Joe Holden , Larabel , Current FreeBSD , Arnaud Lacombe Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:49:18 -0000 --Sig_/E950_Ap3Vq1E8qCyz2buUn_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 04 Jan 2012 14:31:55 -0800 wrote: > Thanks for the comment Arnaud. For comparative benchmarking > on [1]Phoronix.com, Michael inva configuration 'in the way the > developers or production'. This is by rule. However, i poor > scores on be 'it should be tuned, is configured for a diffe The > response from us to this comes in two forms. &nb 1) If it is the > wrong workload for the platform, do a public pos explaining and > analysing the results. Highlighting the rationale fo r the > concious reduction in performance (ie: journaling filesystems with > ba filesystem integrity 2) If tuning can have a material impact > on the results, post a t uning guide with step by step and > rationale. Ie: educate the communit Michael and I have had many > discussions with vendors an on this. In almost all cases, the > vendor has either cha default configuration or accepted the results > as valid. As guide, Micha comparison. To dat offer. In part, > thi public, but that is more of a result of a one sided d party > external to a particular community (with a healthy tou > journalisticly pumped compare & contrast). For the FreeBSD > community, who else outside of the FreeBSD community actually runs > public c Matthew Not really related to the discussion on hand, but the above about the most unreadable email I am yet to read on the public mailing list. --=20 Alexander Kabaev --Sig_/E950_Ap3Vq1E8qCyz2buUn_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPBOV6Q6z1jMm+XZYRAn7AAKDDqfIxM5+mvV3YaP5WyZ7e0ed09QCgzKBU P1N6ba6nwNiQNjP2lDWmJQI= =05rk -----END PGP SIGNATURE----- --Sig_/E950_Ap3Vq1E8qCyz2buUn_-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:52:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F327106566C; Wed, 4 Jan 2012 23:52:10 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 58A9D8FC13; Wed, 4 Jan 2012 23:52:10 +0000 (UTC) Received: from palm-64-28-152-131.palm.com ([64.28.152.131] helo=LT740055CZ0L1.palm1.palmone.com) by phx1.phoronix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Riacr-0006BB-Bb; Wed, 04 Jan 2012 17:52:09 -0600 Message-ID: <4F04E626.5040406@phoronix.com> Date: Wed, 04 Jan 2012 15:52:06 -0800 From: Matthew Tippett User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20111222 Thunderbird/10.0 MIME-Version: 1.0 To: Alexander Kabaev References: <20120104223158.911B11065678@hub.freebsd.org> <20120104184910.0d604240@kan.dyndns.org> In-Reply-To: <20120104184910.0d604240@kan.dyndns.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com X-Mailman-Approved-At: Wed, 04 Jan 2012 23:55:31 +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: Adrian Chadd , FreeBSD Stable Mailing List , Joe Holden , Michael Larabel , Current FreeBSD , Arnaud Lacombe Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:52:10 -0000 Hmm... No sure what happened there again. What I sent (pulled from my "Sent" folder... === Thanks for the comment Arnaud. For comparative benchmarking on Phoronix.com , Michael invariable leaves it in the default configuration 'in the way the developers or vendor wanted it for production'. This is by rule. However, invariable the community or vendor for platforms that post poor scores on benchmark cry foul about using the default config. 'it should be tuned, no-one deploys an untuned system' or 'the system is configured for a different workload'. The response from us to this comes in two forms. 1) If it is the wrong workload for the platform, do a public post explaining and analysing the results. Highlighting the rationale for the concious reduction in performance (ie: journaling filesystems with barriers suffer in some write benchmarks for the sake of filesystem integrity. 2) If tuning can have a material impact on the results, post a tuning guide with step by step and rationale. Ie: educate the community and users. Michael and I have had many discussions with vendors and communities on this. In almost all cases, the vendor has either changed the default configuration or accepted the results as valid. As a service to the community or vendor that publishes the tuning guide, Michael is more than willing to redo a tuned vs untuned comparison. To date, the communities have never taken us up on that offer. In part, this affects Phoronix.com 's perception in the public, but that is more of a result of a one sided discussion by a party external to a particular community (with a healthy touch of journalisticly pumped compare & contrast). For the FreeBSD community, who else outside of the FreeBSD community actually runs public comparisons of FreeBSD against anything? Matthew === On 01/04/2012 03:49 PM, Alexander Kabaev wrote: > On Wed, 04 Jan 2012 14:31:55 -0800 > wrote: > >> Thanks for the comment Arnaud. For comparative benchmarking >> on [1]Phoronix.com, Michael inva configuration 'in the way the >> developers or production'. This is by rule. However, i poor >> scores on be 'it should be tuned, is configured for a diffe The >> response from us to this comes in two forms.&nb 1) If it is the >> wrong workload for the platform, do a public pos explaining and >> analysing the results. Highlighting the rationale fo r the >> concious reduction in performance (ie: journaling filesystems with >> ba filesystem integrity 2) If tuning can have a material impact >> on the results, post a t uning guide with step by step and >> rationale. Ie: educate the communit Michael and I have had many >> discussions with vendors an on this. In almost all cases, the >> vendor has either cha default configuration or accepted the results >> as valid. As guide, Micha comparison. To dat offer. In part, >> thi public, but that is more of a result of a one sided d party >> external to a particular community (with a healthy tou >> journalisticly pumped compare& contrast). For the FreeBSD >> community, who else outside of the FreeBSD community actually runs >> public c Matthew > Not really related to the discussion on hand, but the above about the > most unreadable email I am yet to read on the public mailing list. > From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 00:09:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A2210656B3 for ; Thu, 5 Jan 2012 00:09:45 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 498ED8FC0A for ; Thu, 5 Jan 2012 00:09:45 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id D14F3119C6F; Wed, 4 Jan 2012 18:09:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325722184; bh=Z45rv/Edx1rzMvgJMrw+YLtS1kmKVNKOwIWzufNWAGY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=hO7y3gqQKeVtLQ6oo5xDckPT3ffp8VaN/r+WDDwqLVqyWDNja7KGE0rfhKaPPd7Rf sSeQE2Wz7Bywe8aDq4DkDwDpn/HitQlDFbhLRL8/xHzr94KyzLxk9VCvHPadyI7Dte /404DzGfmjrPUzyDIJftjV6HvwYvP83fNf88unNk= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id CB6DB119C62; Wed, 4 Jan 2012 18:09:44 -0600 (CST) Date: Wed, 4 Jan 2012 18:09:44 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:09:45 -0000 On Wed, 4 Jan 2012, Chuck Swiger wrote: > Hi-- > > On Jan 4, 2012, at 2:23 PM, Dan The Man wrote: >>> It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if needed and appropriate. The fact that a system might have 50,000 file descriptors globally available does not mean that it would be OK for any random process to consume half of them, even if there is still adequate room left for other tasks. It's common for "ulimit -n" to be set to 256 or 1024. >> >> Sensibly limits means a sensible stock default, not imposing an OS limit on what admin/developer can set on his own hardware. > > In point of fact, protocols like TCP/IP impose limits on what is possible. It is in fact the job of the OS to say "no" when a developer asks for a TTL of a million via setsockopt(), because RFC-791 limits the maximum value of the "time to live" field to 255. > >> With the new IBM developments underway of 16 core atom processors and hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or what about the future of 500 core systems with a terrabyte of memory, 100k listen queue could be processed instantly. > > Um. I gather you don't have much background in operating system design or massively parallelized systems? > > Due to locking constraints imposed by whatever synchronization mechanism and communications topology is employed between cores, you simply cannot just add more processors to a system and expect it to go faster in a linear fashion. Having 500 cores contending over a single queue is almost certain to result in horrible performance. Even though the problem of a bunch of independent requests is "embarrassingly parallelizeable", you do that by partitioning the queue into multiple pieces that are fed to different groups or pools of processors to minimize contention over a single data structure. > I guess your calling me out to talk about what I'm doing based on that statement: First framework I was working on a few weeks back just had a parent bind socket, then spawn a certain amount of children to do the accept on the socket, so parent could just focus on dealing with SIGCHLD and what not. I had issues with this design for some reason, all the sockets were set to non-blocking etc, and using kqueue to monitor the socket, but randomly I would have a 1-2 second delay at times from a child doing an accept, I was horrified and changed design quickly. New design, parent does all the accepts and passes blocking work to children via socketpairs it created when forking. Now you talk about scaling on multiple cores, well each child could have its own core to do its blocking I/O on and each have its own processor time, which isn't parallism , but I never said it was doing that. The better part of this design is you have 1 process utilizing a processor efficiently instead of paging the system with useless processes. Also could could have other machines connect in to parent and it could do same thing it does with children via a socket, so in my opinion its more scalable and can centralize everything in one spot. Obviously some cons to this design, you are passing data via socket pairs instead of child writing directly to client. To stress test this new design I simply wrote an asycronouse client counterpart to create 100k of connections to parents listen queue, then it would go off writing to each socket, of course soon as I reached 60k or so client would get numerous failures due to OS limits. So my intention was to see how long it would take children to process request and send response back to client, starting from listen queue with 100k of fd's ready to go I thought would have been really nice test not only for testing applications speed but also testing cpu usage, I/O usage etc with parent processing a client trying to talk to it 100k times at once to really see how kqueue does. Without being able to increase simple limits like these how ever going to find where we can burn down the system and make it outperform epoll() one day. What it so bad to see how many fd's I could toss at kqueue before it croaked? @60k was still handling like a champ with about 50 children getting handed work in my tests. >>> Yes. If the system doesn't handle connectivity problems via something like exponential backoff, then the weak point is poor software design and not FreeBSD being unwilling to set the socket listen queue to a value in the hundreds of thousands. >> >> I think what me and Arnaud are trying to say here, is let freebsd use a sensible default value, but let the admin dictate the actual policy if he so chooses to change it for stress testing, future proofing or anything else. > > FreeBSD does provide a sensible default value for the listen queue size. It's tunable to a factor of about 1000 times larger, and is a value which is sufficiently large to hold a backlog of several minutes worth of connections, assuming you can process the requests at a very high rate to keep draining the queue. > > There probably isn't a reasonable use-case for queuing unprocessed requests for longer than MAXTTL, which is about 4 minutes. So, it's conceivable in theory for a high-volume server to want to set the listen queue to, say 1000 req/s * 255 (ie, MAXTTL), but I manage high volume servers for a living, and practical experience including measurements of latency and service performance suggests that tuning the listen queue up to on the order of a thousand or so is the inflection point after which it is better/necessary for the software to recognize and start doing overload mitigation then it is for the OS to blindly queue more requests. > > Put more simply, there comes a point where saying "no", ie, dropping the connection with a reset, works better. I agree, listen queue of course will go to something reasonable when i was done with testing. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 00:09:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A87106566C; Thu, 5 Jan 2012 00:09:01 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB448FC1C; Thu, 5 Jan 2012 00:09:01 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so21226709obb.13 for ; Wed, 04 Jan 2012 16:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XbdItQKYiYomCveqZYxYJ+LUwLQyfgERPDjPndldPFk=; b=cELNsjMMEMFMmHw6np5h5sHVkIfqFFkE20+dUbkkCnnX/oJzZ901KT3nE+phbwargC 5my6IDplur3bPgiqW8xs5gy8zxHHYeTXte31U4LcXSGTeQIFTVKWfGBJHAbifNSS1/hW yZ+th9THjZv11CzWZwitcMJuHLWsrGoRYBPDc= MIME-Version: 1.0 Received: by 10.182.159.70 with SMTP id xa6mr49957557obb.1.1325722140669; Wed, 04 Jan 2012 16:09:00 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 4 Jan 2012 16:08:59 -0800 (PST) In-Reply-To: References: <4eeb7cf9.43bfec0a.3e38.ffff9d19SMTPIN_ADDED@mx.google.com> Date: Wed, 4 Jan 2012 16:08:59 -0800 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 05 Jan 2012 00:16:12 +0000 Cc: Adrian Chadd , FreeBSD Stable Mailing List , "O. Hartmann" , Joe Holden , Michael Larabel , Current FreeBSD , freebsd-performance@freebsd.org, matthew@phoronix.com, Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:09:01 -0000 On Wed, Jan 4, 2012 at 1:58 PM, Arnaud Lacombe wrote: > Hi, > > On Fri, Dec 16, 2011 at 12:16 PM, =A0 wrote: >> Thanks. >> >> My request for the person documenting the tunings also runs the benchmar= k to >> ensure expected behaviour. >> > Why should you have to tune anything ? Did you tune the Oracle Server > install ? If not, you should not have to tune the FreeBSD install, > that wouldn't be fair. If you tune FreeBSD, you should tune the Oracle > Server install too. It is pretty easy to win at least 30% in > performance for certain workload by choosing the right kernel > configuration. This assumes that Oracle doesn't do secret sauce tuning... the Vanilla CentOS/RHEL base is probably a better comparison than the Oracle custom distro. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 00:58:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97638106566B for ; Thu, 5 Jan 2012 00:58:25 +0000 (UTC) (envelope-from edwinlculp@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 2A8AC8FC15 for ; Thu, 5 Jan 2012 00:58:24 +0000 (UTC) Received: by eaaf13 with SMTP id f13so13433eaa.13 for ; Wed, 04 Jan 2012 16:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YvT7p8Hnlit5o7F9ZlUd71vfey3+aNOChuhlSSrPQFU=; b=XEKcP1GpDkc2Q16cbQqfAKOjNcHl+iE+cF4OizN+4mmOj4TYrthhkj+VwCmE46mwBf XDKAfx5D7MCwlQoM9WTVkK8gdASXLWvOyH0dwj+wkPdfDmxqE9AWtbeF3TsREq5Oq5R/ O8cATD+3ImzEmLF3Y9R1s5xX2rzHur7VV7zrs= MIME-Version: 1.0 Received: by 10.205.122.68 with SMTP id gf4mr14342214bkc.5.1325725099852; Wed, 04 Jan 2012 16:58:19 -0800 (PST) Received: by 10.205.81.202 with HTTP; Wed, 4 Jan 2012 16:58:19 -0800 (PST) In-Reply-To: <1325708915902-5120743.post@n5.nabble.com> References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> <1325708915902-5120743.post@n5.nabble.com> Date: Wed, 4 Jan 2012 18:58:19 -0600 Message-ID: From: "Edwin L. Culp W." To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:58:25 -0000 On Wed, Jan 4, 2012 at 2:28 PM, Jakub Lach wrote: > Or you could use x11/setxkbmap each time you login. > > > > > > > > > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5120743.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I really appreciate your help but I am having a hard time understanding because this has been working perfectly on FreeBSD 9.0 since new. ( 4 months ago ) Just incase it is important. # uname -a FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed Jan 4 05:03:08 CST 2012 root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 My rc.conf has keymap="spanish.iso.acc.kbd" I have no /etc/X11 configuration file and haven't ever needed one. The mouse has never had a problem until I reset the server this morning. Does that sound logical to you? I'm probably missing something obvious. Thanks again for your help and patience. ed From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 01:19:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6D2E106564A for ; Thu, 5 Jan 2012 01:19:29 +0000 (UTC) (envelope-from edwinlculp@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 4C8A18FC17 for ; Thu, 5 Jan 2012 01:19:28 +0000 (UTC) Received: by eaaf13 with SMTP id f13so23586eaa.13 for ; Wed, 04 Jan 2012 17:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=So0vH3fCxuHaFqguib5gdT5bctQuDywYd3QaSj0ad68=; b=kejU7duOO1Tnd7+ZxdKXgHEw8cDPCy9d34m0unIxhRJQwZvkaxwkeTQY92n0Z5mLMl CsZF0n8Z5Ds3nN0IUFSf4AblZkQu6Cy1hpIfSr9sNasRJUkbZaunC+VLMobCkL3QJogo BjOw1HjbrER1cfrx9sSTLFme1IcyZZCKR70CM= MIME-Version: 1.0 Received: by 10.204.141.4 with SMTP id k4mr4096677bku.95.1325726368106; Wed, 04 Jan 2012 17:19:28 -0800 (PST) Received: by 10.205.81.202 with HTTP; Wed, 4 Jan 2012 17:19:28 -0800 (PST) In-Reply-To: References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> <1325708915902-5120743.post@n5.nabble.com> Date: Wed, 4 Jan 2012 19:19:28 -0600 Message-ID: From: "Edwin L. Culp W." To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:19:29 -0000 On Wed, Jan 4, 2012 at 6:58 PM, Edwin L. Culp W. wro= te: > On Wed, Jan 4, 2012 at 2:28 PM, Jakub Lach wrote= : >> Or you could use x11/setxkbmap each time you login. >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: http://freebsd.1045724.n5.nabble.com/bsdin= stall-kbdmap-tp5119535p5120743.html >> Sent from the freebsd-current mailing list archive at Nabble.com. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > I really appreciate your help but I am having a hard time > understanding because this has been working perfectly on FreeBSD 9.0 > since new. ( 4 months ago ) > > Just incase it is important. > > # uname -a > =A0FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed > Jan =A04 05:03:08 CST 2012 > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO =A0amd64 > > My rc.conf has > > keymap=3D"spanish.iso.acc.kbd" > > I have no /etc/X11 configuration file and haven't ever needed one. > The mouse has never had a problem until I reset the server this > morning. > > Does that sound logical to you? =A0I'm probably missing something obvious= . > > Thanks again for your help and patience. > > ed Just as a test I created an X11/xorg.conf with only the following: Section "InputDevice" Identifier "Keyboard1" Driver "kbd" option "XkbLayout" "es" EndSection I expected an error but got none but also still have the same English layou= t. Thanks, ed From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 01:31:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5431E106564A for ; Thu, 5 Jan 2012 01:31:45 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 305A78FC0A for ; Thu, 5 Jan 2012 01:31:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp029.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA006CYXKWJG10@asmtp029.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 17:31:44 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-05_01:2012-01-04, 2012-01-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040317 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 17:31:43 -0800 Message-id: <5D58353F-E4D2-4E01-8B83-350E0E080B3B@mac.com> References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: FreeBSD current Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:31:45 -0000 On Jan 4, 2012, at 4:09 PM, Dan The Man wrote: >>> With the new IBM developments underway of 16 core atom processors and hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or what about the future of 500 core systems with a terrabyte of memory, 100k listen queue could be processed instantly. >> >> Um. I gather you don't have much background in operating system design or massively parallelized systems? >> >> Due to locking constraints imposed by whatever synchronization mechanism and communications topology is employed between cores, you simply cannot just add more processors to a system and expect it to go faster in a linear fashion. Having 500 cores contending over a single queue is almost certain to result in horrible performance. Even though the problem of a bunch of independent requests is "embarrassingly parallelizeable", you do that by partitioning the queue into multiple pieces that are fed to different groups or pools of processors to minimize contention over a single data structure. >> > > I guess your calling me out to talk about what I'm doing based on that statement: "calling you out" is the wrong notion-- I don't see much purpose in arguing about opinions. On the other hand, I do criticize the notion that simply adding more cores will mean something goes faster. If you're going to design or work on parallel systems, you've got to understand at least a little about synchronization overhead and communication latency, and the fact that there will come a point where adding more processors just results in more overhead rather than in more work being completed. > First framework I was working on a few weeks back just had a parent bind socket, then spawn a certain amount of children to do the accept on the socket, so parent could just focus on dealing with SIGCHLD and what not. I had issues with this design for some reason, all the sockets were set to non-blocking etc, and using kqueue to monitor the socket, but randomly I would have a 1-2 second delay at times from a child doing an accept, I was horrified and changed design quickly. Non-blocking? You aren't/weren't sitting and spinning in the children, are you? > New design, parent does all the accepts and passes blocking work to children via socketpairs it created when forking. Now you talk about scaling on multiple cores, well each child could have its own core to do its blocking I/O on and each have its own processor time, which isn't parallism , but I never said it was doing that. Um. You're the one who brought up the notion of "500 core systems". The preforking worker pool model is a classic example from parallel computing. > The better part of this design is you have 1 process utilizing a processor efficiently instead of paging the system with useless processes. Also could could have other machines connect in to parent and it could do same thing it does with children via a socket, so in my opinion its more scalable and can centralize everything in one spot. Obviously some cons to this design, you are passing data via socket pairs instead of child writing directly to client. Typical worker pools (ie, Apache httpd's) tend to block on resources like disk I/O for static resources, or talking to a database or some other service over the network for dynamic responses (mod_perl, mod_php, etc). It's very common to run hundreds of httpd children on a machine that might not have even two cores. If you have worker processes that tend to be CPU-bound, limiting the size of your worker pool to one process per available CPU might be reasonable. > To stress test this new design I simply wrote an asycronouse client counterpart to create 100k of connections to parents listen queue, then it would go off writing to each socket, of course soon as I reached 60k or so client would get numerous failures due to OS limits. So my intention was to see how long it would take children to process request and send response back to client, starting from listen queue with 100k of fd's ready to go I thought would have been really nice test not only for testing applications speed but also testing cpu usage, I/O usage etc with parent processing a client trying to talk to it 100k times at once to really see how kqueue does. > > Without being able to increase simple limits like these how ever going to find where we can burn down the system and make it outperform epoll() one day. I'm having difficulty parsing some of that. If you want to understand the performance of the system, benchmarking it under normal conditions and any expected abnormal conditions makes sense. But you were attempting to test with a massive backlog load scenario which isn't even possible with FreeBSD at the present time, as you discovered. A useful benchmark would look at maximum throughput under load, and service time, and such, and you could readily compare the performance you see on FreeBSD versus whatever your epoll() implementation runs on. > What it so bad to see how many fd's I could toss at kqueue before it croaked? @60k was still handling like a champ with about 50 children getting handed work in my tests. Figure out the request capacity for your system. Take a look at the service SLA. Multiply them. The result is the largest listen queue value that makes sense to use. If you have a system which can do 100 requests per second, and it needs to return an answer to a given request in ten seconds, then setting the listen queue size to anything over 1000 is not just pointless, but counterproductive, because the answers will come too late to meet the SLA. If the system faces a backlog that will take longer than 10 seconds to answer, then it needs to start dropping requests rather than continue to queue up more requests than it can handle in a sufficiently timely fashion. *And* the side making requests really ought to recognize the overload condition, and mitigate against it. See RFC 2914. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 01:32:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2921D106568A for ; Thu, 5 Jan 2012 01:32:48 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 01CFA8FC1C for ; Thu, 5 Jan 2012 01:32:48 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A19A017D63; Wed, 4 Jan 2012 17:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1325727167; bh=Px2ldbrBFqViTC9k1zBfy8jJc2VHzwGLqqRTCd4XG1A=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=xuMT4pRk+2U/3OeJ+HsKayjO1o+3SvWBasdxtB8sI4TPJPzFvLJuSDFtvoHWYRmkG h8ai/yjvDe3NXO4CVcaEBNw03C3X6QQPlsLFHR0048oJHzJ93PVmWhMqraz/QRiDAn MYW1iiosSOmPkjiP0da6wPHqo12vwsHImalIpTg0= Message-ID: <4F04FDBE.5060801@delphij.net> Date: Wed, 04 Jan 2012 17:32:46 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Dan The Man References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/mixed; boundary="------------060809050308090305070008" Cc: d@delphij.net, Arnaud Lacombe , freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:32:48 -0000 This is a multi-part message in MIME format. --------------060809050308090305070008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/12 16:09, Dan The Man wrote: > > On Wed, 4 Jan 2012, Chuck Swiger wrote: > >> Hi-- >> >> On Jan 4, 2012, at 2:23 PM, Dan The Man wrote: >>>> It is not arbitrary. Systems ought to provide sensible >>>> limits, which can be adjusted if needed and appropriate. The >>>> fact that a system might have 50,000 file descriptors >>>> globally available does not mean that it would be OK for any >>>> random process to consume half of them, even if there is >>>> still adequate room left for other tasks. It's common for >>>> "ulimit -n" to be set to 256 or 1024. >>> >>> Sensibly limits means a sensible stock default, not imposing an >>> OS limit on what admin/developer can set on his own hardware. >> >> In point of fact, protocols like TCP/IP impose limits on what is >> possible. It is in fact the job of the OS to say "no" when a >> developer asks for a TTL of a million via setsockopt(), because >> RFC-791 limits the maximum value of the "time to live" field to >> 255. >> >>> With the new IBM developments underway of 16 core atom >>> processors and hundreds of gigabytes of memory, surely a >>> backlog of 100k is manageable. Or what about the future of 500 >>> core systems with a terrabyte of memory, 100k listen queue >>> could be processed instantly. >> >> Um. I gather you don't have much background in operating system >> design or massively parallelized systems? >> >> Due to locking constraints imposed by whatever synchronization >> mechanism and communications topology is employed between cores, >> you simply cannot just add more processors to a system and expect >> it to go faster in a linear fashion. Having 500 cores contending >> over a single queue is almost certain to result in horrible >> performance. Even though the problem of a bunch of independent >> requests is "embarrassingly parallelizeable", you do that by >> partitioning the queue into multiple pieces that are fed to >> different groups or pools of processors to minimize contention >> over a single data structure. >> > > I guess your calling me out to talk about what I'm doing based on > that statement: > > First framework I was working on a few weeks back just had a parent > bind socket, then spawn a certain amount of children to do the > accept on the socket, so parent could just focus on dealing with > SIGCHLD and what not. I had issues with this design for some > reason, all the sockets were set to non-blocking etc, and using > kqueue to monitor the socket, but randomly I would have a 1-2 > second delay at times from a child doing an accept, I was horrified > and changed design quickly. > > New design, parent does all the accepts and passes blocking work > to children via socketpairs it created when forking. Now you talk > about scaling on multiple cores, well each child could have its own > core to do its blocking I/O on and each have its own processor > time, which isn't parallism , but I never said it was doing that. > > The better part of this design is you have 1 process utilizing a > processor efficiently instead of paging the system with useless > processes. Also could could have other machines connect in to > parent and it could do same thing it does with children via a > socket, so in my opinion its more scalable and can centralize > everything in one spot. Obviously some cons to this design, you are > passing data via socket pairs instead of child writing directly to > client. > > To stress test this new design I simply wrote an asycronouse > client counterpart to create 100k of connections to parents listen > queue, then it would go off writing to each socket, of course soon > as I reached 60k or so client would get numerous failures due to OS > limits. So my intention was to see how long it would take children > to process request and send response back to client, starting from > listen queue with 100k of fd's ready to go I thought would have > been really nice test not only for testing applications speed but > also testing cpu usage, I/O usage etc with parent processing a > client trying to talk to it 100k times at once to really see how > kqueue does. > > Without being able to increase simple limits like these how ever > going to find where we can burn down the system and make it > outperform epoll() one day. > > What it so bad to see how many fd's I could toss at kqueue before > it croaked? @60k was still handling like a champ with about 50 > children getting handed work in my tests. > > >>>> Yes. If the system doesn't handle connectivity problems via >>>> something like exponential backoff, then the weak point is >>>> poor software design and not FreeBSD being unwilling to set >>>> the socket listen queue to a value in the hundreds of >>>> thousands. >>> >>> I think what me and Arnaud are trying to say here, is let >>> freebsd use a sensible default value, but let the admin dictate >>> the actual policy if he so chooses to change it for stress >>> testing, future proofing or anything else. >> >> FreeBSD does provide a sensible default value for the listen >> queue size. It's tunable to a factor of about 1000 times larger, >> and is a value which is sufficiently large to hold a backlog of >> several minutes worth of connections, assuming you can process >> the requests at a very high rate to keep draining the queue. >> >> There probably isn't a reasonable use-case for queuing >> unprocessed requests for longer than MAXTTL, which is about 4 >> minutes. So, it's conceivable in theory for a high-volume server >> to want to set the listen queue to, say 1000 req/s * 255 (ie, >> MAXTTL), but I manage high volume servers for a living, and >> practical experience including measurements of latency and >> service performance suggests that tuning the listen queue up to >> on the order of a thousand or so is the inflection point after >> which it is better/necessary for the software to recognize and >> start doing overload mitigation then it is for the OS to blindly >> queue more requests. >> >> Put more simply, there comes a point where saying "no", ie, >> dropping the connection with a reset, works better. > > I agree, listen queue of course will go to something reasonable > when i was done with testing. Here is a patch which I have not tested, just compiled to validate, which changes the u_short's to u_int's. I am personally quite convinced that FreeBSD should make such change though -- having more than 64K of outstanding and unhandled connections does not sound a great idea (i.e. it's not a connection limit after all, but the pending handle connection. If my math were right, 64K connections would require about 1Gbps bandwidth in and out if they happen in the same second.) But I agree this would be a good stress test, which might expose some bugs we don't know today. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8E/b4ACgkQOfuToMruuMBgEQCdF3qVnKsvTXexQmJXEn4wenZA ujQAnjRpBEMW1AR0hIXaae2P8jJ/5PvE =nGgG -----END PGP SIGNATURE----- --------------060809050308090305070008 Content-Type: text/plain; name="sockq.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sockq.diff" diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c index 2a1bf7f..5977428 100644 --- a/sys/kern/uipc_socket.c +++ b/sys/kern/uipc_socket.c @@ -187,7 +187,6 @@ MALLOC_DEFINE(M_PCB, "pcb", "protocol control block"); static int somaxconn = SOMAXCONN; static int sysctl_somaxconn(SYSCTL_HANDLER_ARGS); -/* XXX: we dont have SYSCTL_USHORT */ SYSCTL_PROC(_kern_ipc, KIPC_SOMAXCONN, somaxconn, CTLTYPE_UINT | CTLFLAG_RW, 0, sizeof(int), sysctl_somaxconn, "I", "Maximum pending socket connection " "queue size"); @@ -3280,7 +3279,7 @@ sysctl_somaxconn(SYSCTL_HANDLER_ARGS) if (error || !req->newptr ) return (error); - if (val < 1 || val > USHRT_MAX) + if (val < 1 || val > UINT_MAX) return (EINVAL); somaxconn = val; diff --git a/sys/sys/socketvar.h b/sys/sys/socketvar.h index 94c3b24..51c1c5d 100644 --- a/sys/sys/socketvar.h +++ b/sys/sys/socketvar.h @@ -93,10 +93,10 @@ struct socket { TAILQ_HEAD(, socket) so_incomp; /* (e) queue of partial unaccepted connections */ TAILQ_HEAD(, socket) so_comp; /* (e) queue of complete unaccepted connections */ TAILQ_ENTRY(socket) so_list; /* (e) list of unaccepted connections */ - u_short so_qlen; /* (e) number of unaccepted connections */ - u_short so_incqlen; /* (e) number of unaccepted incomplete + u_int so_qlen; /* (e) number of unaccepted connections */ + u_int so_incqlen; /* (e) number of unaccepted incomplete connections */ - u_short so_qlimit; /* (e) max number queued connections */ + u_int so_qlimit; /* (e) max number queued connections */ short so_timeo; /* (g) connection timeout */ u_short so_error; /* (f) error affecting connection */ struct sigio *so_sigio; /* [sg] information for async I/O or @@ -169,9 +169,9 @@ struct xsocket { caddr_t so_pcb; /* another convenient handle */ int xso_protocol; int xso_family; - u_short so_qlen; - u_short so_incqlen; - u_short so_qlimit; + u_int so_qlen; + u_int so_incqlen; + u_int so_qlimit; short so_timeo; u_short so_error; pid_t so_pgid; --------------060809050308090305070008-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 01:49:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7D31065670 for ; Thu, 5 Jan 2012 01:49:50 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 57E2B8FC1B for ; Thu, 5 Jan 2012 01:49:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp021.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA00089YF1YK00@asmtp021.mac.com> for freebsd-current@freebsd.org; Thu, 05 Jan 2012 01:49:49 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-05_01:2012-01-04, 2012-01-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040323 From: Chuck Swiger In-reply-to: <4F04FDBE.5060801@delphij.net> Date: Wed, 04 Jan 2012 17:49:48 -0800 Message-id: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> <4F04FDBE.5060801@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1084) Cc: FreeBSD current , Dan The Man Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:49:50 -0000 Hi, Xin-- On Jan 4, 2012, at 5:32 PM, Xin Li wrote: > I am personally quite convinced that FreeBSD should make such change > though -- having more than 64K of outstanding and unhandled > connections does not sound a great idea (i.e. it's not a connection > limit after all, but the pending handle connection. If my math were > right, 64K connections would require about 1Gbps bandwidth in and out > if they happen in the same second.) But I agree this would be a good > stress test, which might expose some bugs we don't know today. I think I agree with the change from a correctness standpoint-- listen(2) accepts an int backlog argument. I'm not convinced that there are many scenarios where needing to exceed a listen queue backlog of 64K would be beneficial to a real-world system, and I am sure there are many scenarios where it would be counterproductive, but folks can adjust kern.ipc.somaxconn as they see fit and perhaps Dan or others would gain some value from it. Regards -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 02:06:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14619106564A for ; Thu, 5 Jan 2012 02:06:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id E3ECE8FC15 for ; Thu, 5 Jan 2012 02:06:18 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id ACC4817F5F; Wed, 4 Jan 2012 18:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1325729178; bh=0WvJllfIFKHjmxUXNJemwJV62wn0At5+CH8nulmzUb4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=1mcHB5cfIsj2PQ1blMdkJ2ItmgiIc9iVW6wyz/Ahby4Olqy0EK3g2RzQP7JC68Z6/ zvbJrfFQHYSXCNwn1XqDS6xgbcrp7sQ/cTlLpsSddU2HPdzdfoWu8GTO/BtGyXIbm2 TarxJn/hdn23gWx2PsYzmWdE8qg5qeKZ6ExX7k3w= Message-ID: <4F050599.8060000@delphij.net> Date: Wed, 04 Jan 2012 18:06:17 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Chuck Swiger References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> <4F04FDBE.5060801@delphij.net> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , d@delphij.net, Dan The Man Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 02:06:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/12 17:49, Chuck Swiger wrote: > Hi, Xin-- > > On Jan 4, 2012, at 5:32 PM, Xin Li wrote: >> I am personally quite convinced that FreeBSD should make such >> change though -- having more than 64K of outstanding and >> unhandled connections does not sound a great idea (i.e. it's not >> a connection limit after all, but the pending handle connection. >> If my math were right, 64K connections would require about 1Gbps >> bandwidth in and out if they happen in the same second.) But I >> agree this would be a good stress test, which might expose some >> bugs we don't know today. > > I think I agree with the change from a correctness standpoint-- > listen(2) accepts an int backlog argument. > > I'm not convinced that there are many scenarios where needing to > exceed a listen queue backlog of 64K would be beneficial to a > real-world system, and I am sure there are many scenarios where it > would be counterproductive, but folks can adjust kern.ipc.somaxconn > as they see fit and perhaps Dan or others would gain some value > from it. Ah sorry that should read something like "I'm not quite convinced" and as you see I were explaining why in detail but apparently I missed to check the spellings... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8FBZkACgkQOfuToMruuMDQqQCfWPenaWKpC41i8CXJeuFPlAzg y/cAnR2zTBCa1qG3/0G/nP/vDbQ5Z3vp =lGcl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 04:53:12 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F35106564A; Thu, 5 Jan 2012 04:53:12 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id DB6838FC08; Thu, 5 Jan 2012 04:53:11 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q054rBMk040397; Wed, 4 Jan 2012 21:53:11 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q054rBeJ040396; Wed, 4 Jan 2012 21:53:11 -0700 (MST) (envelope-from ken) Date: Wed, 4 Jan 2012 21:53:11 -0700 From: "Kenneth D. Merry" To: current@FreeBSD.org, scsi@FreeBSD.org Message-ID: <20120105045311.GA40378@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: CAM Target Layer available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 04:53:12 -0000 The CAM Target Layer (CTL) is now available for testing. I am planning to commit it to to head next week, barring any major objections. CTL is a disk and processor device emulation subsystem originally written for Copan Systems under Linux starting in 2003. It has been shipping in Copan (now SGI) products since 2005. It was ported to FreeBSD in 2008, and thanks to an agreement between SGI (who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is available under a BSD-style license. The intent behind the agreement was that Spectra would work to get CTL into the FreeBSD tree. The patches are against FreeBSD/head as of SVN change 229516 and are located here: http://people.freebsd.org/~ken/ctl/ctl_diffs.20120104.4.txt.gz The code is not "perfect" (few pieces of software are), but is in good shape from a functional standpoint. My intent is to get it out there for other folks to use, and perhaps help with improvements. There are a few other CAM changes included with these diffs, some of which will be committed separately from CTL, some concurrently. This is a quick summary: - Fix a panic in the da(4) driver when a drive disappears on boot. - Fix locking in the CAM EDT traversal code. - Add an optional sysctl/tunable (disabled by default) to suppress "duplicate" devices. This most frequently shows up with dual ported SAS drives. - Add some very basic error injection into the da(4) driver. - Bump the length field in the SCSI INQUIRY CDB to 2 bytes to line up with more recent SCSI specs. CTL Features: ============ - Disk and processor device emulation. - Tagged queueing - SCSI task attribute support (ordered, head of queue, simple tags) - SCSI implicit command ordering support. (e.g. if a read follows a mode select, the read will be blocked until the mode select completes.) - Full task management support (abort, LUN reset, target reset, etc.) - Support for multiple ports - Support for multiple simultaneous initiators - Support for multiple simultaneous backing stores - Persistent reservation support - Mode sense/select support - Error injection support - High Availability support (1) - All I/O handled in-kernel, no userland context switch overhead. (1) HA Support is just an API stub, and needs much more to be fully functional. See the to-do list below. Configuring and Running CTL: =========================== - After applying the CTL patchset to your tree, build world and install it on your target system. - Add 'device ctl' to your kernel configuration file. - If you're running with a 8Gb or 4Gb Qlogic FC board, add 'options ISP_TARGET_MODE' to your kernel config file. 'device ispfw' or loading the ispfw module is also recommended. - Rebuild and install a new kernel. - Reboot with the new kernel. - To add a LUN with the RAM disk backend: ctladm create -b ramdisk -s 10485760000000000000 ctladm port -o on - You should now see the CTL disk LUN through camcontrol devlist: scbus6 on ctl2cam0 bus 0: at scbus6 target 1 lun 0 (da24,pass32) <> at scbus6 target -1 lun -1 () This is visible through the CTL CAM SIM. This allows using CTL without any physical hardware. You should be able to issue any normal SCSI commands to the device via the pass(4)/da(4) devices. If any target-capable HBAs are in the system (e.g. isp(4)), and have target mode enabled, you should now also be able to see the CTL LUNs via that target interface. Note that all CTL LUNs are presented to all frontends. There is no LUN masking, or separate, per-port configuration. - Note that the ramdisk backend is a "fake" ramdisk. That is, it is backed by a small amount of RAM that is used for all I/O requests. This is useful for performance testing, but not for any data integrity tests. - To add a LUN with the block/file backend: truncate -s +1T myfile ctladm create -b block -o file=myfile ctladm port -o on - You can also see a list of LUNs and their backends like this: # ctladm devlist LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 2147483648 512 MYSERIAL 0 MYDEVID 0 1 block 2147483648 512 MYSERIAL 1 MYDEVID 1 2 block 2147483648 512 MYSERIAL 2 MYDEVID 2 3 block 2147483648 512 MYSERIAL 3 MYDEVID 3 4 block 2147483648 512 MYSERIAL 4 MYDEVID 4 5 block 2147483648 512 MYSERIAL 5 MYDEVID 5 6 block 2147483648 512 MYSERIAL 6 MYDEVID 6 7 block 2147483648 512 MYSERIAL 7 MYDEVID 7 8 block 2147483648 512 MYSERIAL 8 MYDEVID 8 9 block 2147483648 512 MYSERIAL 9 MYDEVID 9 10 block 2147483648 512 MYSERIAL 10 MYDEVID 10 11 block 2147483648 512 MYSERIAL 11 MYDEVID 11 - You can see the LUN type and backing store for block/file backend LUNs like this: # ctladm devlist -v LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 2147483648 512 MYSERIAL 0 MYDEVID 0 lun_type=0 num_threads=14 file=testdisk0 1 block 2147483648 512 MYSERIAL 1 MYDEVID 1 lun_type=0 num_threads=14 file=testdisk1 2 block 2147483648 512 MYSERIAL 2 MYDEVID 2 lun_type=0 num_threads=14 file=testdisk2 3 block 2147483648 512 MYSERIAL 3 MYDEVID 3 lun_type=0 num_threads=14 file=testdisk3 4 block 2147483648 512 MYSERIAL 4 MYDEVID 4 lun_type=0 num_threads=14 file=testdisk4 5 block 2147483648 512 MYSERIAL 5 MYDEVID 5 lun_type=0 num_threads=14 file=testdisk5 6 block 2147483648 512 MYSERIAL 6 MYDEVID 6 lun_type=0 num_threads=14 file=testdisk6 7 block 2147483648 512 MYSERIAL 7 MYDEVID 7 lun_type=0 num_threads=14 file=testdisk7 8 block 2147483648 512 MYSERIAL 8 MYDEVID 8 lun_type=0 num_threads=14 file=testdisk8 9 block 2147483648 512 MYSERIAL 9 MYDEVID 9 lun_type=0 num_threads=14 file=testdisk9 10 ramdisk 0 0 MYSERIAL 0 MYDEVID 0 lun_type=3 11 ramdisk 204800000000000 512 MYSERIAL 1 MYDEVID 1 lun_type=0 - To see system throughput, use ctlstat(8): # ctlstat -t System Read System Write System Total ms KB/t tps MB/s ms KB/t tps MB/s ms KB/t tps MB/s 1.71 50.64 0 0.00 1.24 512.00 0 0.03 2.05 245.20 0 0.03 1.0% 0.00 0.00 0 0.00 1.12 512.00 564 282.00 1.12 512.00 564 282.00 8.4% 0.00 0.00 0 0.00 1.27 512.00 536 268.00 1.27 512.00 536 268.00 10.0% 0.00 0.00 0 0.00 1.27 512.00 535 267.50 1.27 512.00 535 267.50 7.6% 0.00 0.00 0 0.00 1.12 512.00 520 260.00 1.12 512.00 520 260.00 10.9% 0.00 0.00 0 0.00 1.02 512.00 538 269.00 1.02 512.00 538 269.00 10.9% 0.00 0.00 0 0.00 1.10 512.00 557 278.50 1.10 512.00 557 278.50 9.6% 0.00 0.00 0 0.00 1.12 512.00 561 280.50 1.12 512.00 561 280.50 10.4% 0.00 0.00 0 0.00 1.14 512.00 502 251.00 1.14 512.00 502 251.00 6.5% 0.00 0.00 0 0.00 1.31 512.00 527 263.50 1.31 512.00 527 263.50 10.5% 0.00 0.00 0 0.00 1.07 512.00 560 280.00 1.07 512.00 560 280.00 10.3% CTL To Do List: ============== - Use devstat(9) for CTL's statistics collection. CTL uses a home-grown statistics collection system that is similar to devstat(9). ctlstat should be retired in favor of iostat, etc., once aggregation modes are available in iostat to match the behavior of ctlstat -t and dump modes are available to match the behavior of ctlstat -d/ctlstat -J. - ZFS ARC backend for CTL. Since ZFS copies all I/O into the ARC (Adaptive Replacement Cache), running the block/file backend on top of a ZFS-backed zdev or file will involve an extra set of copies. The optimal solution for backing targets served by CTL with ZFS would be to allocate buffers out of the ARC directly, and DMA to/from them directly. That would eliminate an extra data buffer allocation and copy. - Switch CTL over to using CAM CCBs instead of its own union ctl_io. This will likely require a significant amount of work, but will eliminate another data structure in the stack, more memory allocations, etc. This will also require changes to the CAM CCB structure to support CTL. - Full-featured High Availability support. The HA API that is in ctl_ha.h is essentially a renamed version of Copan's HA API. There is no substance to it, but it remains in CTL to show what needs to be done to implement active/active HA from a CTL standpoint. The things that would need to be done include: - A kernel level software API for message passing as well as DMA between at least two nodes. - Hardware support and drivers for inter-node communication. This could be as simples as ethernet hardware and drivers. - A "supervisor", or startup framework to control and coordinate HA startup, failover (going from active/active to single mode), and failback (going from single mode to active/active). - HA support in other components of the stack. The goal behind HA is that one node can fail and another node can seamlessly take over handling I/O requests. This requires support from pretty much every component in the storage stack, from top to bottom. CTL is one piece of it, but you also need support in the RAID stack/filesystem/backing store. You also need full configuration mirroring, and all peer nodes need to be able to talk to the underlying storage hardware. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 04:51:03 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FAC5106564A; Thu, 5 Jan 2012 04:51:03 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id CB0058FC16; Thu, 5 Jan 2012 04:50:59 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q054dYnQ039136; Wed, 4 Jan 2012 21:39:34 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q054dYRP039135; Wed, 4 Jan 2012 21:39:34 -0700 (MST) (envelope-from ken) Date: Wed, 4 Jan 2012 21:39:34 -0700 From: "Kenneth D. Merry" To: current@FreeBSD.org, scsi@FreeBSD.org Message-ID: <20120105043934.GA37322@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Mailman-Approved-At: Thu, 05 Jan 2012 05:00:34 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: CAM Target Layer available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 04:51:03 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The CAM Target Layer (CTL) is now available for testing. I am planning to commit it to to head next week, barring any major objections. CTL is a disk and processor device emulation subsystem originally written for Copan Systems under Linux starting in 2003. It has been shipping in Copan (now SGI) products since 2005. It was ported to FreeBSD in 2008, and thanks to an agreement between SGI (who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is available under a BSD-style license. The intent behind the agreement was that Spectra would work to get CTL into the FreeBSD tree. The attached patches are against FreeBSD/head as of SVN change 229516. They are also located here: http://people.freebsd.org/~ken/ctl/ctl_diffs.20120104.4.txt.gz The code is not "perfect" (few pieces of software are), but is in good shape from a functional standpoint. My intent is to get it out there for other folks to use, and perhaps help with improvements. There are a few other CAM changes included with these diffs, some of which will be committed separately from CTL, some concurrently. This is a quick summary: - Fix a panic in the da(4) driver when a drive disappears on boot. - Fix locking in the CAM EDT traversal code. - Add an optional sysctl/tunable (disabled by default) to suppress "duplicate" devices. This most frequently shows up with dual ported SAS drives. - Add some very basic error injection into the da(4) driver. - Bump the length field in the SCSI INQUIRY CDB to 2 bytes to line up with more recent SCSI specs. CTL Features: ============ - Disk and processor device emulation. - Tagged queueing - SCSI task attribute support (ordered, head of queue, simple tags) - SCSI implicit command ordering support. (e.g. if a read follows a mode select, the read will be blocked until the mode select completes.) - Full task management support (abort, LUN reset, target reset, etc.) - Support for multiple ports - Support for multiple simultaneous initiators - Support for multiple simultaneous backing stores - Persistent reservation support - Mode sense/select support - Error injection support - High Availability support (1) - All I/O handled in-kernel, no userland context switch overhead. (1) HA Support is just an API stub, and needs much more to be fully functional. See the to-do list below. Configuring and Running CTL: =========================== - After applying the CTL patchset to your tree, build world and install it on your target system. - Add 'device ctl' to your kernel configuration file. - If you're running with a 8Gb or 4Gb Qlogic FC board, add 'options ISP_TARGET_MODE' to your kernel config file. 'device ispfw' or loading the ispfw module is also recommended. - Rebuild and install a new kernel. - Reboot with the new kernel. - To add a LUN with the RAM disk backend: ctladm create -b ramdisk -s 10485760000000000000 ctladm port -o on - You should now see the CTL disk LUN through camcontrol devlist: scbus6 on ctl2cam0 bus 0: at scbus6 target 1 lun 0 (da24,pass32) <> at scbus6 target -1 lun -1 () This is visible through the CTL CAM SIM. This allows using CTL without any physical hardware. You should be able to issue any normal SCSI commands to the device via the pass(4)/da(4) devices. If any target-capable HBAs are in the system (e.g. isp(4)), and have target mode enabled, you should now also be able to see the CTL LUNs via that target interface. Note that all CTL LUNs are presented to all frontends. There is no LUN masking, or separate, per-port configuration. - Note that the ramdisk backend is a "fake" ramdisk. That is, it is backed by a small amount of RAM that is used for all I/O requests. This is useful for performance testing, but not for any data integrity tests. - To add a LUN with the block/file backend: truncate -s +1T myfile ctladm create -b block -o file=myfile ctladm port -o on - You can also see a list of LUNs and their backends like this: # ctladm devlist LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 2147483648 512 MYSERIAL 0 MYDEVID 0 1 block 2147483648 512 MYSERIAL 1 MYDEVID 1 2 block 2147483648 512 MYSERIAL 2 MYDEVID 2 3 block 2147483648 512 MYSERIAL 3 MYDEVID 3 4 block 2147483648 512 MYSERIAL 4 MYDEVID 4 5 block 2147483648 512 MYSERIAL 5 MYDEVID 5 6 block 2147483648 512 MYSERIAL 6 MYDEVID 6 7 block 2147483648 512 MYSERIAL 7 MYDEVID 7 8 block 2147483648 512 MYSERIAL 8 MYDEVID 8 9 block 2147483648 512 MYSERIAL 9 MYDEVID 9 10 block 2147483648 512 MYSERIAL 10 MYDEVID 10 11 block 2147483648 512 MYSERIAL 11 MYDEVID 11 - You can see the LUN type and backing store for block/file backend LUNs like this: # ctladm devlist -v LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 2147483648 512 MYSERIAL 0 MYDEVID 0 lun_type=0 num_threads=14 file=testdisk0 1 block 2147483648 512 MYSERIAL 1 MYDEVID 1 lun_type=0 num_threads=14 file=testdisk1 2 block 2147483648 512 MYSERIAL 2 MYDEVID 2 lun_type=0 num_threads=14 file=testdisk2 3 block 2147483648 512 MYSERIAL 3 MYDEVID 3 lun_type=0 num_threads=14 file=testdisk3 4 block 2147483648 512 MYSERIAL 4 MYDEVID 4 lun_type=0 num_threads=14 file=testdisk4 5 block 2147483648 512 MYSERIAL 5 MYDEVID 5 lun_type=0 num_threads=14 file=testdisk5 6 block 2147483648 512 MYSERIAL 6 MYDEVID 6 lun_type=0 num_threads=14 file=testdisk6 7 block 2147483648 512 MYSERIAL 7 MYDEVID 7 lun_type=0 num_threads=14 file=testdisk7 8 block 2147483648 512 MYSERIAL 8 MYDEVID 8 lun_type=0 num_threads=14 file=testdisk8 9 block 2147483648 512 MYSERIAL 9 MYDEVID 9 lun_type=0 num_threads=14 file=testdisk9 10 ramdisk 0 0 MYSERIAL 0 MYDEVID 0 lun_type=3 11 ramdisk 204800000000000 512 MYSERIAL 1 MYDEVID 1 lun_type=0 - To see system throughput, use ctlstat(8): # ctlstat -t System Read System Write System Total ms KB/t tps MB/s ms KB/t tps MB/s ms KB/t tps MB/s 1.71 50.64 0 0.00 1.24 512.00 0 0.03 2.05 245.20 0 0.03 1.0% 0.00 0.00 0 0.00 1.12 512.00 564 282.00 1.12 512.00 564 282.00 8.4% 0.00 0.00 0 0.00 1.27 512.00 536 268.00 1.27 512.00 536 268.00 10.0% 0.00 0.00 0 0.00 1.27 512.00 535 267.50 1.27 512.00 535 267.50 7.6% 0.00 0.00 0 0.00 1.12 512.00 520 260.00 1.12 512.00 520 260.00 10.9% 0.00 0.00 0 0.00 1.02 512.00 538 269.00 1.02 512.00 538 269.00 10.9% 0.00 0.00 0 0.00 1.10 512.00 557 278.50 1.10 512.00 557 278.50 9.6% 0.00 0.00 0 0.00 1.12 512.00 561 280.50 1.12 512.00 561 280.50 10.4% 0.00 0.00 0 0.00 1.14 512.00 502 251.00 1.14 512.00 502 251.00 6.5% 0.00 0.00 0 0.00 1.31 512.00 527 263.50 1.31 512.00 527 263.50 10.5% 0.00 0.00 0 0.00 1.07 512.00 560 280.00 1.07 512.00 560 280.00 10.3% CTL To Do List: ============== - Use devstat(9) for CTL's statistics collection. CTL uses a home-grown statistics collection system that is similar to devstat(9). ctlstat should be retired in favor of iostat, etc., once aggregation modes are available in iostat to match the behavior of ctlstat -t and dump modes are available to match the behavior of ctlstat -d/ctlstat -J. - ZFS ARC backend for CTL. Since ZFS copies all I/O into the ARC (Adaptive Replacement Cache), running the block/file backend on top of a ZFS-backed zdev or file will involve an extra set of copies. The optimal solution for backing targets served by CTL with ZFS would be to allocate buffers out of the ARC directly, and DMA to/from them directly. That would eliminate an extra data buffer allocation and copy. - Switch CTL over to using CAM CCBs instead of its own union ctl_io. This will likely require a significant amount of work, but will eliminate another data structure in the stack, more memory allocations, etc. This will also require changes to the CAM CCB structure to support CTL. - Full-featured High Availability support. The HA API that is in ctl_ha.h is essentially a renamed version of Copan's HA API. There is no substance to it, but it remains in CTL to show what needs to be done to implement active/active HA from a CTL standpoint. The things that would need to be done include: - A kernel level software API for message passing as well as DMA between at least two nodes. - Hardware support and drivers for inter-node communication. This could be as simples as ethernet hardware and drivers. - A "supervisor", or startup framework to control and coordinate HA startup, failover (going from active/active to single mode), and failback (going from single mode to active/active). - HA support in other components of the stack. The goal behind HA is that one node can fail and another node can seamlessly take over handling I/O requests. This requires support from pretty much every component in the storage stack, from top to bottom. CTL is one piece of it, but you also need support in the RAID stack/filesystem/backing store. You also need full configuration mirroring, and all peer nodes need to be able to talk to the underlying storage hardware. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 05:19:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E05B81065672 for ; Thu, 5 Jan 2012 05:19:17 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 963998FC18 for ; Thu, 5 Jan 2012 05:19:17 +0000 (UTC) Received: by qadb17 with SMTP id b17so197773qad.13 for ; Wed, 04 Jan 2012 21:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kg5I0mJm4+jaYUEHnd1qMQRu20xeCsb4q2M0qvx4wq8=; b=VRZH9x8ZLccRWj6r2Fz/R0dPkn0kVnGgEQJCWk0/FQZZhbrUI5H6dGdvqlMKaJ56Z5 Bew6bohK+7IIcCdjZkBQwwNhZMvcT1/Hf6X1ujfyY45xiaa/bNgpo6lzZE7wDjNWxRDe 6NoLQEB4/qUxUdZolE5wICTZBCFZMQ5QhG2Hw= MIME-Version: 1.0 Received: by 10.224.216.74 with SMTP id hh10mr1230281qab.45.1325739239160; Wed, 04 Jan 2012 20:53:59 -0800 (PST) Received: by 10.229.120.207 with HTTP; Wed, 4 Jan 2012 20:53:58 -0800 (PST) In-Reply-To: <4EF5915E.1030202@gmail.com> References: <20111219224545.GA22631@onelab2.iet.unipi.it> <4EF5915E.1030202@gmail.com> Date: Thu, 5 Jan 2012 06:53:58 +0200 Message-ID: From: Jacques Fourie To: current@freebsd.org Content-Type: multipart/mixed; boundary=20cf300514a26a3d3e04b5c0b8e6 Cc: rizzo@iet.unipi.it Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 05:19:18 -0000 --20cf300514a26a3d3e04b5c0b8e6 Content-Type: text/plain; charset=ISO-8859-1 I've posted a diff to -arm about 2 years ago that I used to cross-build arm picobsd images for a gumstix platform on a i386 host. I don't know if the diff will apply cleanly anymore but here it is in anyway. --20cf300514a26a3d3e04b5c0b8e6 Content-Type: text/plain; charset=US-ASCII; name="diffs.txt" Content-Disposition: attachment; filename="diffs.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gx1av2c70 LS0tIGEvcmVsZWFzZS9waWNvYnNkL2J1aWxkL01ha2VmaWxlLmNvbmYKKysrIGIvcmVsZWFzZS9w aWNvYnNkL2J1aWxkL01ha2VmaWxlLmNvbmYKQEAgLTIxLDcgKzIxLDggQEAgTU9EVUxFUz89LURO T19NT0RVTEVTCSMgZG8gbm90IGJ1aWxkIHRoZW0gYXMgYSBkZWZhdWx0CiAjIElmIGNvbmZpZyB3 ZXJlIHNtYXJ0IGVub3VnaCwgd2UgY291bGQgcGxhY2UgdGhlIGNvbmZpZwogIyBmaWxlIGluIHNv bWUgb3RoZXIgcGxhY2UgdGhhbiAke1NSQ30vc3lzL2kzODYvY29uZiwgYnV0CiAjIGF0IHRoZSBt b21lbnQgKE9jdC4yMDAxKSB0aGlzIGlzIG5vdCBwb3NzaWJsZSB5ZXQuCi1DT05GPSR7U1JDfS9z eXMvaTM4Ni9jb25mCisjQ09ORj0ke1NSQ30vc3lzL2kzODYvY29uZgorQ09ORj0ke1NSQ30vc3lz LyR7VEFSR0VUX0FSQ0h9L2NvbmYKICNDT05GPSR7QlVJTERESVJ9L2NvbmYgICAgICAgICAjIFhY WCBkb2VzIG5vdCB3b3JrIHlldAogQ09ORkZJTEU9UElDT0JTRC0ke25hbWV9CiAKQEAgLTM5LDEw ICs0MCwxOSBAQCAke0JVSUxERElSfS9rZXJuZWw6ICR7S0VSTkZJTEV9CiAke0tFUk5GSUxFfTog JHtDT01QSUxFfSBkb19hX21ha2VfaW5fdGhlX2tlcm5lbF9kaXJlY3RvcnlfYW55d2F5cwogCiBk b19hX21ha2VfaW5fdGhlX2tlcm5lbF9kaXJlY3RvcnlfYW55d2F5czoKKwl1bnNldCBUQVJHRVRf Q1BVVFlQRQorCXVuc2V0IFRBUkdFVF9CSUdfRU5ESUFOCiAJKGNkICR7Q09NUElMRX07ICR7QklO TUFLRX0gS0VSTkVMPWtlcm5lbCAke01PRFVMRVN9ICkKIAordHJhbXBvbGluZToKKwl1bnNldCBU QVJHRVRfQ1BVVFlQRQorCXVuc2V0IFRBUkdFVF9CSUdfRU5ESUFOCisJKGNkICR7Q09NUElMRX07 ICR7QklOTUFLRX0gS0VSTkVMPWtlcm5lbCAke01PRFVMRVN9IHRyYW1wb2xpbmUgKQorCiAke0NP TVBJTEV9OiAke0NPTkZ9LyR7Q09ORkZJTEV9Ci0JKGNkICR7Q09ORn07ICR7Q09ORklHfSAtZCAk e0NPTVBJTEV9ICR7Q09ORkZJTEV9OyBcCisJdW5zZXQgVEFSR0VUX0NQVVRZUEUKKwl1bnNldCBU QVJHRVRfQklHX0VORElBTgorCShjZCAke0NPTkZ9OyBQQVRIPSR7VE1QUEFUSH0gJHtDT05GSUd9 IC1kICR7Q09NUElMRX0gJHtDT05GRklMRX07IFwKIAljZCAke0NPTVBJTEV9OyAke0JJTk1BS0V9 IEtFUk5FTD1rZXJuZWwgJHtNT0RVTEVTfSBkZXBlbmQgKQogCiAke0NPTkZ9LyR7Q09ORkZJTEV9 OiBQSUNPQlNECi0tLSAvZGV2L251bGwKKysrIGIvcmVsZWFzZS9waWNvYnNkL2J1aWxkL2J1aWxk LnNoCkBAIC0wLDAgKzEgQEAKKy4vcGljb2JzZCAtLXRhcmdldF9hcmNoIGFybSAtLXRhcmdldF9j cHV0eXBlIHhzY2FsZSAtLXNyYyAvaG9tZS9qYWNxdWVzL2d1bXN0aXggLW4gLXYgZ3Vtc3RpeCAK ZGlmZiAtLWdpdCBhL3JlbGVhc2UvcGljb2JzZC9idWlsZC9waWNvYnNkIGIvcmVsZWFzZS9waWNv YnNkL2J1aWxkL3BpY29ic2QKaW5kZXggYTNiM2NmNS4uMTQyMzVmZiAxMDA3NTUKLS0tIGEvcmVs ZWFzZS9waWNvYnNkL2J1aWxkL3BpY29ic2QKKysrIGIvcmVsZWFzZS9waWNvYnNkL2J1aWxkL3Bp Y29ic2QKQEAgLTIxLDYgKzIxLDcgQEAKICMgICBNYWtlZmlsZS5jb25mCU1ha2VmaWxlIHVzZWQg dG8gYnVpbGQgdGhlIGtlcm5lbAogIyAgIGNvbmZpZwkJc2hlbGwgdmFyaWFibGVzLCBzb3VyY2Vk IGhlcmUuCiAjICAgbWZzLm10cmVlCQltdHJlZSBjb25maWcgZmlsZQorIwogIyAgIGZsb3BweS50 cmVlLwlmaWxlcyB3aGljaCBnbyBvbiB0aGUgZmxvcHB5CiAjICAgbWZzX3RyZWUvCQlmaWxlcyB3 aGljaCBnbyBvbnRvIHRoZSBtZnMKICMKQEAgLTI4LDEzICsyOSwxMCBAQAogIyAgIFBJQ09CU0QJ CWtlcm5lbCBjb25maWcgZmlsZQogIyAgIGNvbmZpZwkJc2hlbGwgdmFyaWFibGVzLCBzb3VyY2Vk IGhlcmUuCiAjICAgY3J1bmNoLmNvbmYJCWNydW5jaGdlbiBjb25maWd1cmF0aW9uCi0jICAgbWZz Lm10cmVlCQlvdmVycmlkZXMgJHtQSUNPX1RSRUV9L21mcy5tdHJlZQogIyAgIGZsb3BweS50cmVl LmV4Y2x1ZGUJZmlsZXMgZnJvbSBmbG9wcHkudHJlZS8gd2hpY2ggd2UgZG8gbm90IG5lZWQgaGVy ZS4KLSMgICBmbG9wcHkudHJlZS8JbG9jYWwgYWRkaXRpb25zIHRvICR7UElDT19UUkVFfS9tZnNf ZnJlZQorIyAgIGZsb3BweS50cmVlLwlsb2NhbCBhZGRpdGlvbnMgdG8gdGhlIGZsb3BweS50cmVl CiAjICAgZmxvcHB5LnRyZWUuJHtzaXRlfS8gc2FtZSBhcyBhYm92ZSwgc2l0ZSBzcGVjaWZpYy4K ICMgICBtZnNfdHJlZS8JCWxvY2FsIGFkZGl0aW9ucyB0byB0aGUgbWZzX2ZyZWUKLSMgICBidWls ZHRyZWUubWsJb3B0aW9uYWwgbWFrZWZpbGUgdG8gYnVpbGQgYW4gZXh0ZW5zaW9uIGZvciBmbG9w cHkgdHJlZQotIwkJCShnZW5lcmF0ZWQgaW4gYnVpbGR0cmVlLyApCiAKICMKICMtLS0gVGhlIG1h aW4gZW50cnkgcG9pbnQgaXMgYXQgdGhlIGVuZC4KQEAgLTEwMCw3ICs5OCw3IEBAIHNldF9kZWZh dWx0cygpIHsKICAgICBFRElUT1I9JHtFRElUT1I6LXZpfQogICAgIGZkX3NpemU9JHtmZF9zaXpl Oi0xNDQwfQogCi0gICAgb191c2VfbG9hZGVyPSJ5ZXMiCQkjIHVzZSAvYm9vdC9sb2FkZXIKKyAg ICBvX3RhcmdldF9hcmNoPSJpMzg2IgogICAgIG9fYWxsX2luX21mcz0ieWVzIgkJIyBwdXQgYWxs IGZpbGVzIGluIG1mcyBzbyB5b3UgY2FuIGJvb3QgYW5kIHJ1bgogCQkJCSMgdGhlIGltYWdlIHZp YSBkaXNrbGVzcyBib290LgogICAgIG9fY2xlYW49IiIJCQkjIGRvIG5vdCBjbGVhbgpAQCAtMTA5 LDcgKzEwNyw3IEBAIHNldF9kZWZhdWx0cygpIHsKICAgICBvX3RhcnY9IiIJCQkjIHRhciB2ZXJi b3NlIGZsYWcsICIiIG9yICJ2IgogICAgIG9faW5pdF9zcmM9IiIJCSMgbm9uICIiIGlmIHdlIG5l ZWQgdG8gaW5pdCBsaWJzIGFuZCBpbmNsdWRlcy4KICAgICBvX21ha2VvcHRzPSR7TUFLRU9QVFM6 LS1zfQkjIG1ha2Ugb3B0aW9ucywgYmUgc2lsZW50IGJ5IGRlZmF1bHQKLSAgICBvX25vX2RldmZz PXllcwkJIyB3ZSBkbyBub3Qgd2FudCBkZXZmcworICAgIG9fbm9fZGV2ZnM9IiIJCSMgd2UgZG8g bm90IHdhbnQgZGV2ZnMKICAgICBvX2RvX21vZHVsZXM9IiIJCSMgZG8gbm90IGJ1aWxkIG1vZHVs ZXMKIAogICAgIFNSQz0iL3Vzci9zcmMiCQkjIGRlZmF1bHQgbG9jYXRpb24gZm9yIHNvdXJjZXMK QEAgLTEzMCw3ICsxMjgsNiBAQCBzZXRfZGVmYXVsdHMoKSB7CiAgICAgCQkJCSMgbW91bnRwb2lu dCB1c2VkIHRvIGJ1aWxkIG1lbW9yeSBmaWxlc3lzdGVtcwogICAgIGNfZnM9ZnMuUElDT0JTRAkJ IyBmaWxlbmFtZSB1c2VkIGZvciB0aGUgbWVtb3J5IGZpbGVzeXN0ZW0KICAgICBjX2ltZz1waWNv YnNkLmJpbgkJIyBmaWxlbmFtZSB1c2VkIGZvciB0aGUgcGljb2JzZCBpbWFnZQotICAgIGdlbmVy YXRlX2lzbz0iTk8iCQkjIGRvbid0IGdlbmVyYXRlIHRoZSBpc28gaW1hZ2UKIAogICAgICMgc2Vs ZWN0IHRoZSByaWdodCBtZW1vcnkgZGlzayBuYW1lCiAgICAgY2FzZSBgdW5hbWUgLXJgIGluCkBA IC0xNTAsNyArMTQ3LDYgQEAgc2V0X2RlZmF1bHRzKCkgewogICAgIHRyYXAgZmFpbCAxNQogfQog Ci0jIHVzZSB0aGUgbmV3IGJ1aWxkIGluZnJhc3RydWN0dXJlCiBjcmVhdGVfaW5jbHVkZXNfYW5k X2xpYnJhcmllczIoKSB7CiAgICAgbG9jYWwgbm8KICAgICBsb2cgImNyZWF0ZV9pbmNsdWRlc19h bmRfbGlicmFyaWVzMigpIGZvciAke1NSQ30iCkBAIC0xNjMsNyArMTU5LDcgQEAgY3JlYXRlX2lu Y2x1ZGVzX2FuZF9saWJyYXJpZXMyKCkgewogICAgIGV4cG9ydCBNQUtFT0JKRElSUFJFRklYCiAg ICAgKCBjZCAke1NSQ307CiAgICAgIyBtYWtlIC1ETk9DTEVBTiAtRE5PUFJPRklMRSAtRE5PR0FN RVMgLUROT0xJQkNfUiAtRFBJQ09CU0QgYnVpbGR3b3JsZAotICAgIG1ha2UgXytfPSAkbm8gdG9v bGNoYWluIF9pbmNsdWRlcyBfbGlicmFyaWVzCisgICAgbWFrZSBfK189ICRubyB0b29sY2hhaW4K ICAgICApCiB9CiAKQEAgLTIxMiw3ICsyMDgsNyBAQCBjcmVhdGVfaW5jbHVkZXNfYW5kX2xpYnJh cmllcygpIHsKIAogIyBzZXRfdHlwZSA8dHlwZT4gbG9va3MgaW4gdXNlciBvciBzeXN0ZW0gZGly ZWN0b3JpZXMgZm9yIHRoZSBmbG9wcHkgdHlwZQogIyBzcGVjaWZpZWQgYXMgZmlyc3QgYXJndW1l bnQsIGFuZCBzZXRzIHZhcmlhYmxlcyBhY2NvcmRpbmcgdG8gdGhlIGNvbmZpZy4KLSMgZmlsZS4g QWxzbyBzZXRzIE1ZX1RSRUUgYW5kIEJVSUxERElSIGFuZCBTSVRFCisjIGZpbGUuIFNldHMgVEhF VFlQRSwgU0lURSwgbmFtZSwgTVlfVFJFRSBhbmQgQlVJTERESVIKIAogc2V0X3R5cGUoKSB7CiAg ICAgbG9jYWwgYSBpCkBAIC0yNjAsMTMgKzI1Niw2IEBAIHNldF9tc2dzKCkgewkJIyBPSwogXHQz LiAgU2l0ZS1pbmZvOiAke1NJVEV9XG5cdDQuICBGdWxsLXBhdGg6ICR7TVlfVFJFRX1cbiIKIH0K IAotIyBidWlsZCB0aGUgaXNvIGltYWdlCi1idWlsZF9pc29faW1hZ2UoKSB7Ci0gICAgbG9nICJi dWlsZF9pc29faW1hZ2UoKSIKLSAgICBjbGVhcgotICAgIHNldF9tc2dzCi0gICAgcHJpbnRmICIk e01TR30tLS0+IEJ1aWxkIHRoZSBpc28gaW1hZ2Ugbm90IHJlYWR5IHlldFxuXG4iCi19CiAKICMg TWFpbiBidWlsZCBwcm9jZWR1cmUuCiBidWlsZF9pbWFnZSgpIHsKQEAgLTI5MiwxNCArMjgxLDE4 IEBAIGJ1aWxkX2ltYWdlKCkgewogICAgIGlmIFsgJHtPU1ZFUlNJT059IC1nZSA1MDAwMzUgXSA7 IHRoZW4KIAlleHBvcnQgTUFLRU9CSkRJUlBSRUZJWD0ke2xfb2JqdHJlZX0KIAlldmFsICJleHBv cnQgQklOTUFLRT1cImBjZCAke1NSQ307IG1ha2UgLWYgTWFrZWZpbGUgLVYgQklOTUFLRWBcIiIK KwlldmFsICJleHBvcnQgVE1QUEFUSD1cImBjZCAke1NSQ307IG1ha2UgLWYgTWFrZWZpbGUuaW5j MSAtViBUTVBQQVRIYFwiIgogCWV2YWwgZXhwb3J0IGBjZCAke1NSQ307ICR7QklOTUFLRX0gLWYg TWFrZWZpbGUuaW5jMSAtViBXTUFLRUVOVmAKICAgICBmaQorICAgIGVjaG8gJHtQQVRIfQogICAg ICMgY3JlYXRlIGJ1aWxkIGRpcmVjdG9yeSBhbmQgc3VidHJlZQogICAgIG1rZGlyIC1wICR7QlVJ TERESVJ9L2NydW5jaAogICAgICMgcmVtb3ZlIGFueSBvbGQgc3R1ZmYKICAgICBybSAtZiAke0JV SUxERElSfS9rZXJuZWwuZ3ogJHtCVUlMRERJUn0vJHtjX2ZzfQogICAgICMgaW52b2tlIGNvbW1h bmRzIHRvIGJ1aWxkIGEga2VybmVsCiAgICAgZG9fa2VybmVsCisKKyAgICBleHBvcnQgVEFSR0VU X0NQVVRZUEUJCQogICAgICMgZmlsbCBhIHN1YmRpcmVjdG9yeSB3aXRoIHRoaW5ncyB0aGF0IGdv IGludG8gdGhlIGZsb3BweQogICAgICMgKG1vc3RseSAvZXRjIGFuZCBzaW1pbGFyIHN0dWZmKQog ICAgIHBvcHVsYXRlX2Zsb3BweV9mcwpAQCAtMzE5LDYgKzMxMiwxMCBAQCBidWlsZF9wYWNrYWdl KCkgewogICAgIGVjaG8gIiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMiID4+YnVpbGQuc3RhdHVzCiAgICAgZm9yIHogaW4gYnJpZGdlIGRpYWwgcm91dGVyIG5l dCBpc3AgOyBkbwogCXNldF90eXBlICR7en0KKyAgICAgICAgaWYgWyAiJHtuYW1lfSIgPSAiIiBd IDsgdGhlbgorCSAgICBlY2hvICIqKiogVFlQRT0ke3p9IG5vdCBmb3VuZCIgPj5idWlsZC5zdGF0 dXMKKwkgICAgY29udGludWUKKwlmaQogCWVjaG8gIi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSI+PmJ1aWxkLnN0YXR1cwogCWVjaG8gIkJ1aWxkaW5nIFRZUEU9 JHt6fSwgU0laRT0ke01GU19TSVpFfSIgPj5idWlsZC5zdGF0dXMKIAltc2c9IihvaykiCSMgZXJy b3IgbWVzc2FnZQpAQCAtNDM1LDkgKzQzMiwxNCBAQCB0aGlzIGFzIHNtYWxsIGFzIHBvc3NpYmxl LiAiIDEwIDcwIDI+ICR7Y19yZXBseX0gXAogZG9faW5zdGFsbCgpIHsKICAgICBsb2cgImRvX2lu c3RhbGwoKSIKIAorICAgIGlmIFsgIiR7b190YXJnZXRfYXJjaH0iID0gImFybSIgXSA7IHRoZW4K KwllY2hvICJCb290YWJsZSBBUk0gdHJhbXBvbGluZSBpcyBpbgorCSR7QlVJTERESVJ9L1BJQ09C U0QtJHtuYW1lfS9rZXJuZWwuZ3oudHJhbXAiCisgICAgZmkKKwogICAgIGlmIFsgIiR7b19pbnRl cmFjdGl2ZX0iID0gIk5PIiBdIDsgdGhlbgogCWVjaG8gIisrKyBCdWlsZCBjb21wbGV0ZWQgKysr IgotCWNhdCAuYnVpbGQucmVwbHkgfHwgdHJ1ZQorI2NhdCAuYnVpbGQucmVwbHkgfHwgdHJ1ZQog CXJldHVybgogICAgIGZpCiAgICAgZGlhbG9nIC0tdGl0bGUgIkJ1aWxkICR7VEhFVFlQRX0gY29t cGxldGVkIiAtLWlucHV0Ym94IFwKQEAgLTQ3NCw2ICs0NzYsMTMgQEAgZG9fa2VybmVsKCkgewkJ IyBPSwogCWZhaWwgJD8gbWlzc2luZ19rZXJuZWwKIH0KIAorcmVidWlsZF90cmFtcG9saW5lKCkg eworICAgIGxvZyAicmVidWlsZF90cmFtcG9saW5lKCkgUmUtYnVpbGRpbmcga2VybmVsIHRyYW1w b2xpbmUgXCIkbmFtZVwiIGluICRNWV9UUkVFIgorICAgIChjZCAkTVlfVFJFRTsgZXhwb3J0IG5h bWUgU1JDIEJVSUxERElSICMgdXNlZCBpbiB0aGlzIG1ha2VmaWxlIDsKKyAgICAJJHtCSU5NQUtF fSAtdiAtZiAke1BJQ09fVFJFRX0vYnVpbGQvTWFrZWZpbGUuY29uZiB0cmFtcG9saW5lICkgfHwg XAorCWZhaWwgJD8gbWlzc2luZ19rZXJuZWwKK30KKwogIyBQb3B1bGF0ZSB0aGUgdmFyaWFibGUg cGFydCBvZiB0aGUgZmxvcHB5IGZpbGVzeXN0ZW0uIE11c3QgYmUgZG9uZSBiZWZvcmUKICMgdGhl IE1GUyBiZWNhdXNlIGl0cyBjb250ZW50IG1pZ2h0IG5lZWQgdG8gYmUgY29waWVkIHRoZXJlIGFz IHdlbGwuCiAjCkBAIC00OTIsMTAgKzUwMSwxMCBAQCBwb3B1bGF0ZV9mbG9wcHlfZnMoKSB7CQkj IE9LCiAgICAgZHN0PSR7QlVJTERESVJ9L2Zsb3BweS50cmVlCiAgICAgbG9nICJwd2Q9YHB3ZGAg UG9wdWxhdGluZyBmbG9wcHkgZmlsZXN5c3RlbS4uLiIKIAotICAgIHJtIC1yZiAke2RzdH0gfHwg dHJ1ZQkjIGNsZWFuIHJlbGljcyBmcm9tIG9sZCBjb21waWxhdGlvbnMuCi0gICAgbWtkaXIgJHtk c3R9CQkjIGNyZWF0ZSBhIGNsZWFuIHRyZWUKKyAgICAjIGNsZWFuIHJlbGljcyBmcm9tIG9sZCBj b21waWxhdGlvbnMuCisgICAgcm0gLXJmICR7ZHN0fSB8fCB0cnVlCisgICAgbWtkaXIgJHtkc3R9 CiAKLSAgICAjIGNvbXB1dGUgZXhjbHVkZSBsaXN0IGZvciBnZW5lcmljIHRyZWUKICAgICBleGNs PSR7TVlfVFJFRX0vZmxvcHB5LnRyZWUuZXhjbHVkZQogICAgIGlmIFsgLWYgJHtleGNsfSBdIDsg dGhlbgogCWxvZyAiRmlsZXMgZXhjbHVkZWQgZnJvbSBnZW5lcmljIHRyZWU6IGBlY2hvO2NhdCAk e2V4Y2x9YCIKQEAgLTUwMywyNiArNTEyLDI5IEBAIHBvcHVsYXRlX2Zsb3BweV9mcygpIHsJCSMg T0sKICAgICBlbHNlCiAJZXhjbD0iIgogICAgIGZpCi0gICAgIyBjb3B5IGZyb20gdGhlIGZsb3Bw eSB0cmVlcyBpbnRvIHRoZSBkZXN0aW5hdGlvbgotICAgIGZvciBGTE9QUFlfVFJFRSBpbiAke1BJ Q09fVFJFRX0vZmxvcHB5LnRyZWUgJHtNWV9UUkVFfS9mbG9wcHkudHJlZSBcCi0JCSR7TVlfVFJF RX0vZmxvcHB5LnRyZWUuJHtTSVRFfSA7IGRvCi0JaWYgWyAtZCAke0ZMT1BQWV9UUkVFfSBdIDsg dGhlbgotCSAgICAoY2QgJHtGTE9QUFlfVFJFRX0gOyB0YXIgLWNmIC0gLS1leGNsdWRlIENWUyBc Ci0JCSAgICAtLWV4Y2x1ZGUgLnN2biAke2V4Y2x9IC4gKSB8IFwKKyAgICAoY2QgJHtQSUNPX1RS RUV9L2Zsb3BweS50cmVlIDsgdGFyIC1jZiAtIC0tZXhjbHVkZSBDVlMgLS1leGNsdWRlIC5zdm4g XAorICAgIAkJJHtleGNsfSAuICkgfCBcCiAJCShjZCAke2RzdH0gOyB0YXIgeCR7b190YXJ2fWYg LSApCi0JICAgIGxvZyAiQ29waWVkIGZyb20gJHtGTE9QUFlfVFJFRX0iCi0JZmkKLQlleGNsPSIi ICMgcmVzZXQgdGhlIGV4Y2x1ZGUgbGlzdC4KLSAgICBkb25lCi0KLSAgICAjIGFkZCBsb2NhbCBt YW5pcHVsYXRpb24KLSAgICBpZiBbIC1mICR7TVlfVFJFRX0vYnVpbGR0cmVlLm1rIF0gOyB0aGVu Ci0JbG9nICJidWlsZGluZyBsb2NhbCBmbG9wcHkgdHJlZSIKLQkke0JJTk1BS0V9IC1DICR7ZHN0 fSAtZiAke01ZX1RSRUV9L2J1aWxkdHJlZS5tayBmbG9wcHkudHJlZQorICAgIGxvZyAiQ29waWVk IGZyb20gZ2VuZXJpYyBmbG9wcHktdHJlZSBgZWNobzsgbHMgLWxhUiAke2RzdH1gIgorCisgICAg c3JjZGlyPSR7TVlfVFJFRX0vZmxvcHB5LnRyZWUKKyAgICBpZiBbIC1kICR7c3JjZGlyfSBdIDsg dGhlbgorCWxvZyAidXBkYXRlIHdpdGggdHlwZS1zcGVjaWZpYyBmaWxlczoiCisJKGNkICR7c3Jj ZGlyfSA7IHRhciAtY2YgLSAtLWV4Y2x1ZGUgQ1ZTIC0tZXhjbHVkZSAuc3ZuIC4gKSB8IFwKKwkg ICAgKGNkICR7ZHN0fSA7IHRhciB4JHtvX3RhcnZ9ZiAtICkKKwlsb2cgIkNvcGllZCBmcm9tIHR5 cGUgZmxvcHB5LXRyZWUgYGVjaG87IGxzIC1sYVIgJHtkc3R9YCIKKyAgICBlbHNlCisJbG9nICJO byB0eXBlLXNwZWNpZmljIGZsb3BweS10cmVlIgogICAgIGZpCi0gCi0gICAgIyBjb21wcmVzcyB0 aGUgZmlsZXMgaW4gZXRjLywganVzdCBpbiBjYXNlCi0gICAgIyBYWFggdGhpcyBzaG91bGQgYmUg ZG9uZSBpbiB0aGUgbWFrZWZpbGUuCisgICAgaWYgWyAtZCAke3NyY2Rpcn0uJHtTSVRFfSBdIDsg dGhlbgorCWxvZyAiVXBkYXRlIHdpdGggc2l0ZS1zcGVjaWZpYyAoJHtTSVRFfSkgZmlsZXM6Igor CShjZCAke3NyY2Rpcn0uJHtTSVRFfSA7IHRhciAtY2YgLSAtLWV4Y2x1ZGUgQ1ZTIC0tZXhjbHVk ZSAuc3ZuIC4gKSB8IFwKKwkgICAgKGNkICR7ZHN0fSA7IHRhciB4JHtvX3RhcnZ9ZiAtICkKKwls b2cgIkNvcGllZCBmcm9tIHNpdGUgZmxvcHB5LXRyZWUgYGVjaG87IGxzIC1sYVIgJHtkc3R9YCIK KyAgICBlbHNlCisJbG9nICJObyBzaXRlLXNwZWNpZmljIGZsb3BweS10cmVlIgorICAgIGZpCisK ICAgICAjIGd6aXAgcmV0dXJucyBhbiBlcnJvciBpZiBpdCBmYWlscyB0byBjb21wcmVzcyBzb21l IGZpbGUKICAgICAoY2QgJGRzdCA7IGd6aXAgLTkgZXRjLyoKIAkgICAgbG9nICJDb21wcmVzc2Vk IGZpbGVzIGluIGV0Yy8gYGVjaG87IGxzIC1sIGV0Y2AiCkBAIC01MzcsMTIgKzU0OSwxMyBAQCBw b3B1bGF0ZV9mbG9wcHlfZnMoKSB7CQkjIE9LCiAjIEZpbmFsbHksIGlmIHJlcXVpcmVkLCBtYWtl IGEgY29weSBvZiB0aGUgZmxvcHB5LnRyZWUgb250byAvZmQKIAogcG9wdWxhdGVfbWZzX3RyZWUo KSB7Ci0gICAgbG9jYWwgYSBkc3QgTUZTX1RSRUUKKyAgICBsb2NhbCBhIGRzdAogCiAgICAgbG9n ICJwb3B1bGF0ZV9tZnNfdHJlZSgpIgogICAgIGRzdD0ke0JVSUxERElSfS9tZnMudHJlZQotICAg IHJtIC1yZiAke2RzdH0gfHwgdHJ1ZQkjIGNsZWFuIHJlbGljcyBmcm9tIG9sZCBjb21waWxhdGlv bnMuCi0gICAgbWtkaXIgJHtkc3R9CQkjIGNyZWF0ZSBhIGZyZXNoIHRyZWUKKyAgICAjIGNsZWFu IHJlbGljcyBmcm9tIG9sZCBjb21waWxhdGlvbnMuCisgICAgcm0gLXJmICR7ZHN0fSB8fCB0cnVl CisgICAgbWtkaXIgJHtkc3R9CiAKICAgICBsb2cgInB3ZD1gcHdkYCwgUG9wdWxhdGluZyBNRlMg dHJlZS4uLiIKIApAQCAtNTU5LDcgKzU3Miw3IEBAIHBvcHVsYXRlX21mc190cmVlKCkgewogICAg IGxuIC1zIC9kZXYvbnVsbCAke2RzdH0vdmFyL3J1bi9sb2cKICAgICBsbiAtcyAvZXRjL3Rlcm1j YXAgJHtkc3R9L3Vzci9zaGFyZS9taXNjL3Rlcm1jYXAKIAotICAgICMjIyBub3cgYnVpbGQgdGhl IGNydW5jaGVkIGJpbmFyaWVzICMjIworCiAgICAgKAogICAgIGNkICR7QlVJTERESVJ9L2NydW5j aAogICAgIGxvZyAiTWFraW5nIGFuZCBpbnN0YWxsaW5nIGNydW5jaDEgZnJvbSBgcHdkYCBzcmMg JHtTUkN9Li4uIgpAQCAtNjAzLDE4ICs2MTYsMTIgQEAgcG9wdWxhdGVfbWZzX3RyZWUoKSB7CiAJ ZmkKICAgICBkb25lCiAKLSAgICBpZiBbIC1mICR7TVlfVFJFRX0vYnVpbGR0cmVlLm1rIF0gOyB0 aGVuCi0JbG9nICJidWlsZGluZyBsb2NhbCBmbG9wcHkgdHJlZSIKLQkke0JJTk1BS0V9IC1DICR7 ZHN0fSAtZiAke01ZX1RSRUV9L2J1aWxkdHJlZS5tayBtZnMudHJlZQotICAgIGZpCi0KICAgICBp ZiBbICIke29fYWxsX2luX21mc30iID0gInllcyIgXTsgdGhlbgogCWxvZyAiQ29weSBnZW5lcmlj IGZsb3BweV90cmVlIGludG8gTUZTLi4uIgotCSMgaWdub3JlIGZhaWx1cmUgaW4gY2FzZSB0aGUg ZmxvcHB5IGlzIGVtcHR5CisJIyB0aGlzIG1heSBmYWlsIGluIGNhc2UgdGhlIGZsb3BweSBpcyBl bXB0eQogCWNwIC1ScCAke0JVSUxERElSfS9mbG9wcHkudHJlZS8qICR7ZHN0fS9mZCB8fCB0cnVl CiAgICAgZmkKIAotICAgICMgNC54IGNvbXBhdGliaWxpdHkgLSBjcmVhdGUgZGV2aWNlIG5vZGVz CiAgICAgaWYgWyAiJHtvX25vX2RldmZzfSIgIT0gIiIgXSA7IHRoZW4KIAkjIGNyZWF0ZSBkZXZp Y2UgZW50cmllcyB1c2luZyBNQUtFREVWCiAJKGNkICR7ZHN0fS9kZXYKQEAgLTYzMywyMSArNjQw LDE5IEBAIHBvcHVsYXRlX21mc190cmVlKCkgewogCWxvZyAiaW1wb3J0aW5nICR7aW1wb3J0X2Zp bGVzfSBpbnRvIG1mcyIKIAkjIFdlIGRvIGl0IGluIGEgY2hyb290IGVudmlyb25tZW50IG9uIHRo ZSB0YXJnZXQgc28KIAkjIHN5bWxpbmtzIGFyZSBmb2xsb3dlZCBjb3JyZWN0bHkuCi0JIyBNYWtl IHN1cmUgd2UgaGF2ZSBhIHN0YXRpY2FsbHkgbGlua2VkIHRhciB0aGVyZS4KLQlta2RpciAtcCAk e2RzdH0vcmVzY3VlCi0JY3AgL3Jlc2N1ZS90YXIgJHtkc3R9L3Jlc2N1ZQorCWNwIGB3aGljaCB0 YXJgICR7ZHN0fS9teV9jb3B5X29mX3RhcgogCShjZCAke2xfdXNydHJlZX0vLi4gOyB0YXIgY2Yg LSAke2ltcG9ydF9maWxlc30gKSB8IFwKLQkgICAgKGNocm9vdCAke2RzdH0gL3Jlc2N1ZS90YXIg eFBmIC0gKQotCXJtIC1yZiAke2RzdH0vcmVzY3VlCisJICAgIChjaHJvb3QgJHtkc3R9IC9teV9j b3B5X29mX3RhciB4ZiAtICkKKwlybSAke2RzdH0vbXlfY29weV9vZl90YXIKICAgICBmaQogCiAg ICAgKGNkICR7QlVJTERESVJ9CiAJIyBvdmVycmlkZSB0aGUgb3duZXIKIAllY2hvICIvc2V0IHVp ZD0wIGdpZD0wIiA+IG10cmVlLm91dAotCW10cmVlIC1pYyAtcCAke2RzdH0gLWsgIiIgPj4gbXRy ZWUub3V0CisJbXRyZWUgLWMgLXAgJHtkc3R9IC1rICIiID4+IG10cmVlLm91dAogCWxvZyAibXRy ZS5vdXQgYXQgJHtCVUlMRERJUn0vbXRyZWUub3V0IgogCW1ha2VmcyAtdCBmZnMgLW8gYnNpemU9 NDA5NiAtbyBmc2l6ZT01MTIgXAotCQktcyAke01GU19TSVpFfWsgLWYgMTAwMCAtRiBtdHJlZS5v dXQgJHtjX2ZzfSAke2RzdH0KKwkJLXMgJHtNRlNfU0laRX1rIC1mIDEwMCAtRiBtdHJlZS5vdXQg JHtjX2ZzfSAke2RzdH0KIAlscyAtbCAke2NfZnN9ICkKICAgICBsb2cgImRvbmUgbWZzIGltYWdl IgogfQpAQCAtNzIzLDEwNyArNzI4LDEwNyBAQCBmaWxsX2Zsb3BweV9pbWFnZSgpIHsKIAlibG9j a3M9MTQ3NgogICAgIGZpCiAKLSAgICBsb2cgIkxhYmVsaW5nIGZsb3BweSBpbWFnZSIKLSAgICBi Mj0ke0JVSUxERElSfS9ib290MiAjIG1vZGlmaWVkIGJvb3QyCi0gICAgY3AgLWYgJHtjX2Jvb3Qy fSAke2IyfQotICAgIGNobW9kIDA2NDQgJHtiMn0KKyAgICBpZiBbICIke29fdGFyZ2V0X2FyY2h9 IiAhPSAiYXJtIiBdOyB0aGVuCisJICAgIGxvZyAiTGFiZWxpbmcgZmxvcHB5IGltYWdlIgorCSAg ICBsb2cgInBhdGNoICR7Y19ib290Mn0gdG8gYm9vdCAva2VybmVsIHJpZ2h0IGF3YXkiCisJICAg IGIyPSR7QlVJTERESVJ9L2Jvb3QyICMgbW9kaWZpZWQgYm9vdDIKKwkgICAgY3AgLWYgJHtjX2Jv b3QyfSAke2IyfQorCSAgICBjaG1vZCAwNjQ0ICR7YjJ9CiAKLSAgICBpZiBbICR7b191c2VfbG9h ZGVyfSA9ICJubyIgXSA7IHRoZW4KLQlsb2cgInBhdGNoICR7Y19ib290Mn0gdG8gYm9vdCAva2Vy bmVsIHJpZ2h0IGF3YXkiCi0Jc2V0IGBzdHJpbmdzIC1hdCBkICR7YjJ9IHwgZ3JlcCAiL2Jvb3Qv bG9hZGVyImAKLQllY2hvIC1lICIva2VybmVsXDBcMFwwXDBcMCIgfCBcCisJICAgIHNldCBgc3Ry aW5ncyAtYXQgZCAke2IyfSB8IGdyZXAgIi9ib290L2xvYWRlciJgCisJICAgIGVjaG8gLWUgIi9r ZXJuZWxcMFwwXDBcMFwwIiB8IFwKIAkgICAgZGQgb2Y9JHtiMn0gb2JzPSQxIG9zZWVrPTEgY29u dj1ub3RydW5jIDI+L2Rldi9udWxsCisJICAgIGNobW9kIDA0NDQgJHtiMn0KICAgICBmaQotICAg IGNobW9kIDA0NDQgJHtiMn0KIAogICAgIGRzdD0ke0JVSUxERElSfS9pbWFnZS50cmVlCiAgICAg cm0gLXJmICR7ZHN0fQogICAgIG1rZGlyIC1wICR7ZHN0fQotICAgICgKLSAgICBjZCAke0JVSUxE RElSfQotICAgIHNldCAwIDAgIyByZXNldCB2YXJpYWJsZXMKLSAgICAjICQxIHRha2VzIHRoZSBv ZmZzZXQgb2YgdGhlIE1GUyBmaWxlc3lzdGVtCi0gICAgc2V0IGBzdHJpbmdzIC1hdCBkIGtlcm5l bCB8IGdyZXAgIk1GUyBGaWxlc3lzdGVtIGdvZXMgaGVyZSJgCi0gICAgbWZzX3N0YXJ0PSQxCi0g ICAgc2V0IDAgMCAjIHJlc2V0IHZhcmlhYmxlcwotICAgIHNldCBgc3RyaW5ncyAtYXQgZCBrZXJu ZWwgfCBncmVwICJNRlMgRmlsZXN5c3RlbSBoYWQgYmV0dGVyImAKLSAgICBtZnNfZW5kPSQxCi0g ICAgbWZzX3NpemU9IiQoKCR7bWZzX2VuZH0gLSAke21mc19zdGFydH0pKSIKLSAgICBzZXQgLS0g YGxzIC1sICR7Y19mc31gOyBpbWdzaXplPSIkNSIKLSAgICBpZiBbICR7bWZzX3N0YXJ0fSAtZ3Qg MCAtYSAke21mc19zaXplfSAtZ2UgJHtpbWdzaXplfSBdIDsgdGhlbgotCW1mc19vZnM9JCgoJHtt ZnNfc3RhcnR9ICsgODE5MikpCi0JbG9nICJQcmVsb2FkIGtlcm5lbCB3aXRoIGZpbGUgJHtjX2Zz fSBhdCAke21mc19vZnN9IgotCWxvZ3ZlcmJvc2UgImBscyAtbCAke2NfZnN9YCB0byBmaXQgaW4g JHttZnNfc2l6ZX0iCi0JZGQgaWY9JHtjX2ZzfSBpYnM9ODE5MiBpc2Vlaz0xIG9mPWtlcm5lbCBv YnM9JHttZnNfb2ZzfSBcCi0JICAgIG9zZWVrPTEgY29udj1ub3RydW5jICMgMj4gL2Rldi9udWxs Ci0gICAgZWxzZQotICAgIAlsb2cgIm5vdCBsb2FkaW5nIG1mcywgc2l6ZSAke21mc19zaXplfSBp bWcgJHtpbWdzaXplfSIKLSAgICBmaQotICAgIGxvZyAiQ29tcHJlc3Mgd2l0aCBrZ3ppcCBhbmQg Y29weSB0byBmbG9wcHkgaW1hZ2UiCi0gICAgaWYgWyAke29fdXNlX2xvYWRlcn0gPSAibm8iIF0g OyB0aGVuCi0Ja2d6aXAgLW8ga2VybmVsLmd6IGtlcm5lbAotCWNwIC1wIGtlcm5lbC5neiAke2Rz dH0va2VybmVsIHx8IGZhaWwgJD8gbm9fc3BhY2UgImNvcHlpbmcga2VybmVsIgorICAgIG15a2Vy bj0ke0JVSUxERElSfS9QSUNPQlNELSR7bmFtZX0va2VybmVsLmRlYnVnCisgICAgaWYgWyAiJHtv X3RhcmdldF9hcmNofSIgPSAiYXJtIiBdIDsgdGhlbgorCSAgICAoCisgICAgCSAgICBjZCAke0JV SUxERElSfQorCSAgICBzZXQgMCAwICMgcmVzZXQgdmFyaWFibGVzCisJICAgICMgJDEgdGFrZXMg dGhlIG9mZnNldCBvZiB0aGUgTUZTIGZpbGVzeXN0ZW0KKwkgICAgc2V0IGBzdHJpbmdzIC1hdCBk ICR7bXlrZXJufSB8IGdyZXAgIk1GUyBGaWxlc3lzdGVtIGdvZXMgaGVyZSJgCisJICAgIG1mc19z dGFydD0kMQorCSAgICBzZXQgMCAwICMgcmVzZXQgdmFyaWFibGVzCisJICAgIHNldCBgc3RyaW5n cyAtYXQgZCAke215a2Vybn0gfCBncmVwICJNRlMgRmlsZXN5c3RlbSBoYWQgYmV0dGVyImAKKwkg ICAgbWZzX2VuZD0kMQorCSAgICBtZnNfc2l6ZT0iJCgoJHttZnNfZW5kfSAtICR7bWZzX3N0YXJ0 fSkpIgorCSAgICBzZXQgLS0gYGxzIC1sICR7Y19mc31gOyBpbWdzaXplPSIkNSIKKwkgICAgaWYg WyAke21mc19zdGFydH0gLWd0IDAgLWEgJHttZnNfc2l6ZX0gLWdlICR7aW1nc2l6ZX0gXSA7IHRo ZW4KKwkJbG9nICJQcmVsb2FkIGtlcm5lbCB3aXRoIGZpbGUgJHtjX2ZzfSBhdCAke21mc19zdGFy dH0iCisJCW1mc19vZnM9JCgoJHttZnNfc3RhcnR9ICsgODE5MikpCisJCWRkIGlmPSR7Y19mc30g aWJzPTgxOTIgaXNlZWs9MSBvZj0ke215a2Vybn0gb2JzPSR7bWZzX29mc30gXAorCQkgICAgb3Nl ZWs9MSBjb252PW5vdHJ1bmMgMj4gL2Rldi9udWxsCisJICAgIGVsc2UKKwkJbG9nICJub3QgbG9h ZGluZyBtZnMsIHNpemUgJHttZnNfc2l6ZX0gaW1nICR7aW1nc2l6ZX0iCisJICAgIGZpCisJICAg ICkKKwkgICAgcmVidWlsZF90cmFtcG9saW5lCiAgICAgZWxzZQotICAgICAgICBnemlwIGtlcm5l bAotCW1rZGlyIC1wICAke2RzdH0vYm9vdC9rZXJuZWwKLQllY2hvICJoaW50LmFjcGkuMC5kaXNh YmxlZD1cIjFcIiIgPiAke2RzdH0vYm9vdC9sb2FkZXIuY29uZgotCWVjaG8gImNvbnNvbGU9XCJj b21jb25zb2xlXCIiID4+ICR7ZHN0fS9ib290L2xvYWRlci5jb25mCi0JY3AgLXAgL2Jvb3QvbG9h ZGVyICR7ZHN0fS9ib290L2xvYWRlciB8fCBmYWlsICQ/IG5vX3NwYWNlICJjb3B5aW5nIGJvb3Rs b2FkZXIiCi0JY3AgLXAga2VybmVsLmd6ICR7ZHN0fS9ib290L2tlcm5lbC9rZXJuZWwuZ3ogfHwg ZmFpbCAkPyBub19zcGFjZSAiY29weWluZyBrZXJuZWwiCi0gICAgZmkKLQotICAgICMgbm93IHRy YW5zZmVyIHRoZSBmbG9wcHkgdHJlZS4gSWYgaXQgaXMgYWxyZWFkeSBpbiBtZnMsIGRvbnQgYm90 aGVyLgotICAgIGlmIFsgIiR7b19hbGxfaW5fbWZzfSIgIT0gInllcyIgXSA7IHRoZW4KLQlsb2cg Ik5vdyB0cmFuc2ZlciBmbG9wcHkgdHJlZSBpZiBub3QgYWxyZWFkeSBpbiBNRlMgaW1hZ2UiCi0J Y3AgLVJwIGZsb3BweS50cmVlLyogJHtkc3R9IHx8IFwKLQkJZmFpbCAkPyBub19zcGFjZSAiY29w eWluZyBmbG9wcHkgdHJlZSIKLSAgICBmaQotICAgICkKLQotICAgICMgYWRkIGxvY2FsIG1hbmlw dWxhdGlvbiB0byB0aGUgaW1hZ2UKLSAgICBpZiBbIC1mICR7TVlfVFJFRX0vYnVpbGR0cmVlLm1r IF0gOyB0aGVuCi0JJHtCSU5NQUtFfSAtQyAke2RzdH0gLWYgJHtNWV9UUkVFfS9idWlsZHRyZWUu bWsgaW1hZ2UudHJlZQotICAgIGZpCi0KLSAgICBsb2cgImltYWdlIHVzZWQgYGR1IC1zICR7ZHN0 fWAgb2YgJHtibG9ja3N9ayIKLSAgICAoY2QgJHtCVUlMRERJUn0KLSAgICBtYWtlZnMgLXQgZmZz IC1vIGJzaXplPTQwOTYgLW8gZnNpemU9NTEyIFwKLQktcyAke2Jsb2Nrc31rIC1mIDUwICR7Y19p bWd9ICR7ZHN0fQotICAgICMgJHtsX2xhYmVsfSAtZiBgcHdkYC8ke2NfaW1nfQotICAgICR7bF9s YWJlbH0gLXcgLWYgYHB3ZGAvJHtjX2ltZ30gYXV0byAjIHdyaXRlIGluIGEgbGFiZWwKLSAgICAj IGNvcHkgcGFydGl0aW9uIGM6IGludG8gYTogd2l0aCBzb21lIHNlZCBtYWdpYwotICAgICR7bF9s YWJlbH0gLWYgYHB3ZGAvJHtjX2ltZ30gfCBzZWQgLWUgJy8gIGM6L3twO3MvYzovYTovO30nIHwg XAotCSR7bF9sYWJlbH0gLVIgLWYgYHB3ZGAvJHtjX2ltZ30gL2Rldi9zdGRpbgotICAgICR7bF9s YWJlbH0gLWYgYHB3ZGAvJHtjX2ltZ30KLQotICAgIGxzIC1sICR7Y19pbWd9Ci0gICAgJHtsX2xh YmVsfSAtZiBgcHdkYC8ke2NfaW1nfQotICAgIGxvZ3ZlcmJvc2UgImFmdGVyIGRpc2tsYWJlbCIK LSAgICApCi0KLSAgICBlY2hvICJCVUlMRERJUiAke0JVSUxERElSfSIKLSAgICBpZiBbICIke2dl bmVyYXRlX2lzb30iID0gIllFUyIgXTsgdGhlbgotCWVjaG8gImdlbmVyYXRlX2lzbyAke2dlbmVy YXRlX2lzb30iCi0JI2J1aWxkX2lzb19pbWFnZSgpCi0JZXhpdCAxCisJICAgICgKKwkgICAgY2Qg JHtCVUlMRERJUn0KKwkgICAgc2V0IDAgMCAjIHJlc2V0IHZhcmlhYmxlcworCSAgICAjICQxIHRh a2VzIHRoZSBvZmZzZXQgb2YgdGhlIE1GUyBmaWxlc3lzdGVtCisJICAgIHNldCBgc3RyaW5ncyAt YXQgZCBrZXJuZWwgfCBncmVwICJNRlMgRmlsZXN5c3RlbSBnb2VzIGhlcmUiYAorCSAgICBtZnNf c3RhcnQ9JDEKKwkgICAgc2V0IDAgMCAjIHJlc2V0IHZhcmlhYmxlcworCSAgICBzZXQgYHN0cmlu Z3MgLWF0IGQga2VybmVsIHwgZ3JlcCAiTUZTIEZpbGVzeXN0ZW0gaGFkIGJldHRlciJgCisJICAg IG1mc19lbmQ9JDEKKwkgICAgbWZzX3NpemU9IiQoKCR7bWZzX2VuZH0gLSAke21mc19zdGFydH0p KSIKKwkgICAgc2V0IC0tIGBscyAtbCAke2NfZnN9YDsgaW1nc2l6ZT0iJDUiCisJICAgIGlmIFsg JHttZnNfc3RhcnR9IC1ndCAwIC1hICR7bWZzX3NpemV9IC1nZSAke2ltZ3NpemV9IF0gOyB0aGVu CisJCW1mc19vZnM9JCgoJHttZnNfc3RhcnR9ICsgODE5MikpCisJCWxvZyAiUHJlbG9hZCBrZXJu ZWwgd2l0aCBmaWxlICR7Y19mc30gYXQgJHttZnNfb2ZzfSIKKwkJZGQgaWY9JHtjX2ZzfSBpYnM9 ODE5MiBpc2Vlaz0xIG9mPWtlcm5lbCBvYnM9JHttZnNfb2ZzfSBcCisJCSAgICBvc2Vlaz0xIGNv bnY9bm90cnVuYyAyPiAvZGV2L251bGwKKwkgICAgZWxzZQorCQlsb2cgIm5vdCBsb2FkaW5nIG1m cywgc2l6ZSAke21mc19zaXplfSBpbWcgJHtpbWdzaXplfSIKKwkgICAgZmkKKwkgICAgbG9nICJD b21wcmVzcyB3aXRoIGtnemlwIGFuZCBjb3B5IHRvIGZsb3BweSBpbWFnZSIKKwkgICAga2d6aXAg LW8ga2VybmVsLmd6IGtlcm5lbAorCSAgICBjcCAtcCBrZXJuZWwuZ3ogJHtkc3R9L2tlcm5lbCB8 fCBmYWlsICQ/IG5vX3NwYWNlICJjb3B5aW5nIGtlcm5lbCIKKworCSAgICBsb2cgIk5vdyB0cmFu c2ZlciBmbG9wcHkgdHJlZSBpZiBub3QgYWxyZWFkeSBpbiBNRlMgaW1hZ2UiCisJICAgICMgbm93 IHRyYW5zZmVyIHRoZSBmbG9wcHkgdHJlZS4gSWYgaXQgaXMgYWxyZWFkeSBpbiBtZnMsIGRvbnQg Ym90aGVyLgorCSAgICBpZiBbICIke29fYWxsX2luX21mc30iICE9ICJ5ZXMiIF0gOyB0aGVuCisJ CWNwIC1ScCBmbG9wcHkudHJlZS8qICR7ZHN0fSB8fCBcCisJCQlmYWlsICQ/IG5vX3NwYWNlICJj b3B5aW5nIGZsb3BweSB0cmVlIgorCSAgICBmaQorCSAgICApCisgICAgZmkJCSAgICAKKworICAg IGlmIFsgIiR7b190YXJnZXRfYXJjaH0iICE9ICJhcm0iIF0gOyB0aGVuCisJICAgIChjZCAke0JV SUxERElSfQorCSAgICBtYWtlZnMgLXQgZmZzIC1vIGJzaXplPTQwOTYgLW8gZnNpemU9NTEyIFwK KwkJLXMgJHtibG9ja3N9ayAtZiA1MCAke2NfaW1nfSAke2RzdH0KKwkgICAgIyAke2xfbGFiZWx9 IC1mIGBwd2RgLyR7Y19pbWd9CisJICAgICR7bF9sYWJlbH0gLXcgLWYgYHB3ZGAvJHtjX2ltZ30g YXV0byAjIHdyaXRlIGluIGEgbGFiZWwKKwkgICAgIyBjb3B5IHBhcnRpdGlvbiBjOiBpbnRvIGE6 IHdpdGggc29tZSBzZWQgbWFnaWMKKwkgICAgJHtsX2xhYmVsfSAtZiBgcHdkYC8ke2NfaW1nfSB8 IHNlZCAtZSAnLyAgYzove3A7cy9jOi9hOi87fScgfCBcCisJCSR7bF9sYWJlbH0gLVIgLWYgYHB3 ZGAvJHtjX2ltZ30gL2Rldi9zdGRpbgorCSAgICAke2xfbGFiZWx9IC1mIGBwd2RgLyR7Y19pbWd9 CisJICAgIGxzIC1sICR7Y19pbWd9CisJCWxvZ3ZlcmJvc2UgImFmdGVyIGRpc2tsYWJlbCIKKwkJ ICkKKwkgICAgIyBkdW1wIHRoZSBwcmltYXJ5IGFuZCBzZWNvbmRhcnkgYm9vdAorCSAgICAjIFhY WCBwcmltYXJ5IGlzIDUxMiBieXRlcworCSAgICBkZCBpZj0ke2NfYm9vdDF9IG9mPSR7QlVJTERE SVJ9LyR7Y19pbWd9IGNvbnY9bm90cnVuYyAyPi9kZXYvbnVsbAorCSAgICAjIFhYWCBzZWNvbmRh cnkgc3RhcnRzIGFmdGVyIHRoZSAweDExNCA9IGRlYyAyNzYgYnl0ZXMgb2YgdGhlIGxhYmVsCisJ ICAgICMgc28gd2Ugc2tpcCAyNzYgZnJvbSB0aGUgc291cmNlLCBhbmQgMjc2KzUxMj03ODggZnJv bSBkc3QKKwkgICAgIyB0aGUgb2xkIHN0eWxlIGJsb2NrcyB1c2VkIDUxMiBhbmQgMTAyNCByZXNw ZWN0aXZlbHkKKworCSAgICBkZCBpZj0ke2IyfSBpc2Vlaz0xIGlicz0yNzYgMj4gL2Rldi9udWxs IHwgXAorCQlkZCBvZj0ke0JVSUxERElSfS8ke2NfaW1nfSBvc2Vlaz0xIG9icz03ODggY29udj1u b3RydW5jIDI+L2Rldi9udWxsCisJICAgIGxvZ3ZlcmJvc2UgImRvbmUgZmxvcHB5IGltYWdlIgog ICAgIGZpCi0KLSAgICAjIGR1bXAgdGhlIHByaW1hcnkgYW5kIHNlY29uZGFyeSBib290Ci0gICAg IyBYWFggcHJpbWFyeSBpcyA1MTIgYnl0ZXMKLSAgICBkZCBpZj0ke2NfYm9vdDF9IG9mPSR7QlVJ TERESVJ9LyR7Y19pbWd9IGNvbnY9bm90cnVuYyAyPi9kZXYvbnVsbAotICAgICMgWFhYIHNlY29u ZGFyeSBzdGFydHMgYWZ0ZXIgdGhlIDB4MTE0ID0gZGVjIDI3NiBieXRlcyBvZiB0aGUgbGFiZWwK LSAgICAjIHNvIHdlIHNraXAgMjc2IGZyb20gdGhlIHNvdXJjZSwgYW5kIDI3Nis1MTI9Nzg4IGZy b20gZHN0Ci0gICAgIyB0aGUgb2xkIHN0eWxlIGJsb2NrcyB1c2VkIDUxMiBhbmQgMTAyNCByZXNw ZWN0aXZlbHkKLQotICAgIGRkIGlmPSR7YjJ9IGlzZWVrPTEgaWJzPTI3NiAyPiAvZGV2L251bGwg fCBcCi0JZGQgb2Y9JHtCVUlMRERJUn0vJHtjX2ltZ30gb3NlZWs9MSBvYnM9Nzg4IGNvbnY9bm90 cnVuYyAyPi9kZXYvbnVsbAotICAgIGxvZ3ZlcmJvc2UgImRvbmUgZmxvcHB5IGltYWdlIgogICAg ICMgWFhYIChsb2cgIkZpeGluZyBwZXJtaXNzaW9ucyI7IGNkICR7ZHN0fTsgY2hvd24gLVIgcm9v dCAqKQogICAgIHJtIC1yZiAke0JVSUxERElSfS9mbG9wcHkudHJlZSB8fCB0cnVlICMgY2xlYW51 cAogICAgICMgZGYgLWlrICR7ZHN0fSB8IGNvbHJtIDcwID4gLmJ1aWxkLnJlcGx5CiAgICAgcm0g LXJmICR7ZHN0fQotICAgIHJtICR7QlVJTERESVJ9LyR7Y19mc30KLSAgICAjIHJtICR7QlVJTERE SVJ9L2tlcm5lbC5negorICAgIHJtIC1mICR7QlVJTERESVJ9L2tlcm5lbC5neiAke0JVSUxERElS fS8ke2NfZnN9CiB9CiAKICMgVGhpcyBmdW5jdGlvbiBjcmVhdGVzIHZhcmlhYmxlcyB3aGljaCBk ZXBlbmQgb24gdGhlIHNvdXJjZSB0cmVlIGluIHVzZToKQEAgLTg2Niw4ICs4NzEsMTkgQEAgc2V0 X2J1aWxkX3BhcmFtZXRlcnMoKSB7CiAjIGFyZ3VtZW50cy4KIAogc2V0X2RlZmF1bHRzCi13aGls ZSBbIHRydWUgXTsgZG8KK2FyZ3M9IiIKK3doaWxlIFsgeCIkMSIgIT0geCBdOyBkbwogICAgIGNh c2UgJDEgaW4KKyAgICAtLXRhcmdldF9hcmNoKQorICAgIAlvX3RhcmdldF9hcmNoPSQyCisgICAg CVRBUkdFVF9BUkNIPSQyCisJZXhwb3J0IFRBUkdFVF9BUkNICisJc2hpZnQKKwk7OworICAgIC0t dGFyZ2V0X2NwdXR5cGUpCisJVEFSR0VUX0NQVVRZUEU9JDIKKyAgICAJc2hpZnQKKwk7OwkKICAg ICAtLXNyYykJIyBzZXQgdGhlIHNvdXJjZSBwYXRoIGluc3RlYWQgb2YgL3Vzci9zcmMKIAlTUkM9 YChjZCAkMjsgcHdkKWAKIAlzaGlmdApAQCAtODgxLDE3ICs4OTcsMTIgQEAgd2hpbGUgWyB0cnVl IF07IGRvCiAJc2hpZnQKIAk7OwogCi0gICAgLS1ub19sb2FkZXIpCSMgb21pdCAvYm9vdC9sb2Fk ZXIsIGp1c3QgcmVseSBvbiBib290MgotCQkJIyAoaXQgbWF5IGhhdmUgcHJvYmxlbXMgd2l0aCBr ZXJuZWxzID4gNE1CKQotCW9fdXNlX2xvYWRlcj0ibm8iCi0JOzsKLQogICAgIC0tYWxsX2luX21m cykKIAlvX2FsbF9pbl9tZnM9InllcyIKIAk7OwogCiAgICAgLS1ub19hbGxfaW5fbWZzKQotCW9f YWxsX2luX21mcz0ibm8iCisJb19hbGxfaW5fbWZzPSIiCiAJOzsKIAogICAgIC0tbW9kdWxlcykJ IyBhbHNvIGJ1aWxkIGtlcm5lbCBtb2R1bGVzCkBAIC05MTEsMjQgKzkyMiwyMSBAQCB3aGlsZSBb IHRydWUgXTsgZG8KIAlvX3RhcnY9InYiCQkJIyB0YXIgdmVyYm9zZSBmbGFnCiAJb19tYWtlb3B0 cz0iLWQgbCIgIyBiZSB2ZXJib3NlCiAJOzsKLQotICAgIC0taXNvKSAjIGdlbmVyYXRlIGlzbyBp bWFnZQotCWdlbmVyYXRlX2lzbz0iWUVTIgotCTs7Ci0KICAgICAqKQotCWJyZWFrCisJYXJncz0i JGFyZ3MgJDEiCQkJIyBhY2N1bXVsYXRlIGFyZ3MKIAk7OwogCiAgICAgZXNhYwogICAgIHNoaWZ0 CiBkb25lCiBzZXRfYnVpbGRfcGFyYW1ldGVycwkjIHRoaW5ncyB0aGF0IGRlcGVuZCBvbiAke1NS Q30KLXNldF90eXBlICQxICQyCQkjIHR5cGUgYW5kIHNpdGUsIHJlc3BlY3RpdmVseQogCiAjIElm ICQxPSJwYWNrYWdlIiwgaXQgY3JlYXRlcyBhIG5lYXQgc2V0IG9mIGZsb3BwaWVzCitzZXQgLS0g JHthcmdzfQogWyAiJDEiID0gInBhY2thZ2UiIF0gJiYgYnVpbGRfcGFja2FnZQogCitzZXRfdHlw ZSAkYXJncwkJIyB0eXBlIGFuZCBzaXRlLCByZXNwZWN0aXZlbHkKKwogWyAiJHtvX2ludGVyYWN0 aXZlfSIgIT0gIk5PIiBdICYmIG1haW5fZGlhbG9nCiAKIGlmIFsgIiR7b19jbGVhbn0iID0gIllF UyIgXSA7IHRoZW4KLS0tIC9kZXYvbnVsbAorKysgYi9yZWxlYXNlL3BpY29ic2QvYnVpbGQvcmVh ZG1lLmFybQpAQCAtMCwwICsxLDE0IEBACitCdWlsZGluZyBQSUNPQlNEIEFSTSBpbWFnZXMKKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorPHNyY2Rpcj4gaXMgdGhlIGRpcmVjdG9yeSB3aGVy ZSB0aGUgRnJlZUJTRCBzb3VyY2UgdHJlZSBsaXZlcy4KKworQ3JlYXRlIHN1aXRhYmxlIGNyb3Nz LWNvbXBpbGluZyBlbnZpcm9ubWVudDoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCitjZCA8c3JjZGlyPgorbWFrZSBUQVJHRVRfQVJDSD1hcm0gVEFSR0VUX0NQ VVRZUEU9eHNjYWxlIGJ1aWxkd29ybGQKK21rZGlyIC1wIC4uL3VzcgorbG4gLXMgL3Vzci9vYmov IC4uL3Vzci9vYmotcGljbworCitCdWlsZCBQSUNPQlNECistLS0tLS0tLS0tLS0tCisuL3BpY29i c2QgLS10YXJnZXRfYXJjaCBhcm0gLS10YXJnZXRfY3B1dHlwZSB4c2NhbGUgLS1zcmMgPHNyY2Rp cj4gLW4gLXYgZ3Vtc3RpeCAK --20cf300514a26a3d3e04b5c0b8e6-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 06:16:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2181C106566B for ; Thu, 5 Jan 2012 06:16:17 +0000 (UTC) (envelope-from adrian.chadd@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 CFD248FC12 for ; Thu, 5 Jan 2012 06:16:16 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so260976vbb.13 for ; Wed, 04 Jan 2012 22:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=p5Nim3hLF1YZuG5STjrOQSMahsxKXkhG2ywaMX17O3c=; b=lRXfLQGx37DoWueEOhCx7MtD0ARwiB8mjwdM76bNTcASimvEF7Igau9YmkNp/ErT7t +20XUNBJ2uNokU1XNRpRH8ePe6CjKID2jUr8E8OWZ+5Ir1FeBd88/dp+Fc+0BZL2cgO3 GcF8SQzebgDw/xYCwjpuNeOKzaNzvdE0klboA= MIME-Version: 1.0 Received: by 10.52.180.98 with SMTP id dn2mr267587vdc.83.1325742624134; Wed, 04 Jan 2012 21:50:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 4 Jan 2012 21:50:24 -0800 (PST) In-Reply-To: References: <20111219224545.GA22631@onelab2.iet.unipi.it> <4EF5915E.1030202@gmail.com> Date: Wed, 4 Jan 2012 21:50:24 -0800 X-Google-Sender-Auth: klXaHXz6vUnUTAS8IEGLe9QIRCU Message-ID: From: Adrian Chadd To: Jacques Fourie Content-Type: text/plain; charset=ISO-8859-1 Cc: rizzo@iet.unipi.it, current@freebsd.org Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 06:16:17 -0000 On 4 January 2012 20:53, Jacques Fourie wrote: > I've posted a diff to -arm about 2 years ago that I used to > cross-build arm picobsd images for a gumstix platform on a i386 host. > I don't know if the diff will apply cleanly anymore but here it is in > anyway. Hi, I've figured out all the right flags to pass to a cross-build environment. Namely: env CROSS_BUILD_TESTING=YES MAKEOBJDIRPREFIX=${X_MAKEOBJDIRPREFIX} \ make ${BUILD_FLAGS} TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ ${X_TARGET_CPUTYPE} KERNCONF=${KERNCONF} DESTDIR=${X_DESTDIR} \ KODIR=/boot/kernel.${KERNCONF}/ \ KMODDIR=/boot/kernel.${KERNCONF}/ \ __MAKE_CONF=/dev/null SRCCONF=/dev/null \ LOCAL_DIRS="${LOCAL_DIRS}" \ LOCAL_TOOL_DIRS="${LOCAL_TOOL_DIRS}" $1 \ .. ignore LOCAL_TOOL_DIRS, I haven't committed that yet to -HEAD. If someone would like to update picobsd to make this work, I'll happily test out patches and commit it to -HEAD. Building -8 and previous needed some extra hacks (eg TARGET_BIG_ENDIAN) which have been removed from -HEAD/-9. Good luck! Adrian From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 06:29:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8320106566B; Thu, 5 Jan 2012 06:29:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98BE18FC08; Thu, 5 Jan 2012 06:29:45 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so290505obb.13 for ; Wed, 04 Jan 2012 22:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+429qArNIZmLiFRu9qvu/BGcC62oE69twV09rmw4HFU=; b=A30NzgKFhA2E/QTFQjz0WFlsRpMPo6sFIY08WF71YIhTX4F/h785tR2D2Z/HLZZmXg 1I1XflXvTR1Wj8Vj3qChQXo2DjsrE1jIh1s6zRgm6+1Dgy9eleD/YgotjIkHn+gFDTIH af3AYLNONjvGSeNhEoVkhSZecLs+6sY9pdzZg= MIME-Version: 1.0 Received: by 10.182.187.37 with SMTP id fp5mr531034obc.21.1325744984960; Wed, 04 Jan 2012 22:29:44 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 4 Jan 2012 22:29:44 -0800 (PST) In-Reply-To: References: <20111219224545.GA22631@onelab2.iet.unipi.it> <4EF5915E.1030202@gmail.com> Date: Wed, 4 Jan 2012 22:29:44 -0800 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: multipart/mixed; boundary=14dae9399e0de42f3e04b5c20ec5 Cc: Jacques Fourie , rizzo@iet.unipi.it, current@freebsd.org Subject: Re: cross-arch building picobsd/nanobsd images ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 06:29:46 -0000 --14dae9399e0de42f3e04b5c20ec5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 4, 2012 at 9:50 PM, Adrian Chadd wrote: > On 4 January 2012 20:53, Jacques Fourie wrote: >> I've posted a diff to -arm about 2 years ago that I used to >> cross-build arm picobsd images for a gumstix platform on a i386 host. >> I don't know if the diff will apply cleanly anymore but here it is in >> anyway. > > Hi, > > I've figured out all the right flags to pass to a cross-build > environment. Namely: ... > .. ignore LOCAL_TOOL_DIRS, I haven't committed that yet to -HEAD. > > If someone would like to update picobsd to make this work, I'll > happily test out patches and commit it to -HEAD. > > Building -8 and previous needed some extra hacks (eg > TARGET_BIG_ENDIAN) which have been removed from -HEAD/-9. Here's the FreeNAS project/iXsystems' contribution to nanobsd which was contributed back to Warner, but hasn't been reviewed / committed to CURRENT since I missed my pre-Christmas window of opportunity :(. There are some potentially helpful gems that could be added to picobsd (and vice versa I'm sure) -- look for NANO_ARCH for instance; it doesn't resolve the TARGET_BIG_ENDIAN issue noted previously, but that's probably part of the reason why NANO_PMAKE is a separate variable... Thanks! -Garrett --14dae9399e0de42f3e04b5c20ec5 Content-Type: application/octet-stream; name="nanobsd-omnibus-01.04.2012.patch" Content-Disposition: attachment; filename="nanobsd-omnibus-01.04.2012.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gx1e65920 SW5kZXg6IHRvb2xzL3Rvb2xzL25hbm9ic2QvbmFub2JzZC5zaAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29s cy90b29scy9uYW5vYnNkL25hbm9ic2Quc2gJKHJldmlzaW9uIDIyOTI3MSkKKysrIHRvb2xzL3Rv b2xzL25hbm9ic2QvbmFub2JzZC5zaAkod29ya2luZyBjb3B5KQpAQCAtNTgsNyArNTgsNyBAQAog I05BTk9fRElTS0lNR0RJUj0iIgogCiAjIFBhcmFsbGVsIE1ha2UKLU5BTk9fUE1BS0U9Im1ha2Ug LWogMyIKK05BTk9fUE1BS0U9Im1ha2UiCiAKICMgVGhlIGRlZmF1bHQgbmFtZSBmb3IgYW55IGlt YWdlIHdlIGNyZWF0ZS4KIE5BTk9fSU1HTkFNRT0iXy5kaXNrLmZ1bGwiCkBAIC03Niw3ICs3Niw3 IEBACiBOQU5PX0tFUk5FTD1HRU5FUklDCiAKICMgS2VybmVsIG1vZHVsZXMgdG8gYnVpbGQ7IGRl ZmF1bHQgaXMgbm9uZQotTkFOT19NT0RVTEVTPQorTkFOT19NT0RVTEVTPSIiCiAKICMgQ3VzdG9t aXplIGNvbW1hbmRzLgogTkFOT19DVVNUT01JWkU9IiIKQEAgLTE0NiwxMiArMTQ2LDE0IEBACiBO QU5PX0xBQkVMPSIiCiAKICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCi0jIEFyY2hpdGVjdHVyZSB0byBidWlsZC4g IENvcnJlc3BvbmRzIHRvIFRBUkdFVF9BUkNIIGluIGEgYnVpbGR3b3JsZC4KLSMgVW5mb3J0dW5h dGVseSwgdGhlcmUncyBubyB3YXkgdG8gc2V0IFRBUkdFVCBhdCB0aGlzIHRpbWUsIGFuZCBpdAot IyBjb25mbGF0ZXMgdGhlIHR3bywgc28gYXJjaGl0ZWN0dXJlcyB3aGVyZSBUQVJHRVQgIT0gVEFS R0VUX0FSQ0ggZG8KLSMgbm90IHdvcmsuICBUaGlzIGRlZmF1bHRzIHRvIHRoZSBhcmNoIG9mIHRo ZSBjdXJyZW50IG1hY2hpbmUuCisjIEFyY2hpdGVjdHVyZSB0byBidWlsZC4gIENvcnJlc3BvbmRz IHRvIFRBUkdFVDpUQVJHRVRfQVJDSCBpbgorIyBidWlsZHdvcmxkLgorIyBUaGlzIGRlZmF1bHRz IHRvIHRoZSBhcmNoaXRlY3R1cmUgYW5kIHByb2Nlc3NvciBvZiB0aGUgY3VycmVudCBtYWNoaW5l LgorIworIyBUaGlzIGFjY2VwdHMganVzdCB0aGUgYXJjaGl0ZWN0dXJlIHRob3VnaCAoZm9yIHNl bGVjdCBhcmNoaXRlY3R1cmVzIGxpa2UKKyMgYW1kNjQsIGkzODYsIGV0YyB3aGVyZSB0aGVyZSBp c24ndCBhIGRpZmZlcmVudCBwcm9jZXNzb3IpLgogCi1OQU5PX0FSQ0g9YHVuYW1lIC1wYAorOiAk e05BTk9fQVJDSD0kKHVuYW1lIC1tKTokKHVuYW1lIC1wKX0KIAogIyBEaXJlY3RvcnkgdG8gcG9w dWxhdGUgL2NmZyBmcm9tCiBOQU5PX0NGR0RJUj0iIgpAQCAtMTU5LDYgKzE2MSwxNiBAQAogIyBE aXJlY3RvcnkgdG8gcG9wdWxhdGUgL2RhdGEgZnJvbQogTkFOT19EQVRBRElSPSIiCiAKKyMgc3Jj LmNvbmYgdG8gdXNlIHdoZW4gYnVpbGRpbmcgdGhlIGltYWdlLiBEZWZhdWx0cyB0byAvZGV2L251 bGwgZm9yIHRoZSBzYWtlCisjIG9mIGRldGVybWluaXNtLgorU1JDQ09ORj0ke1NSQ0NPTkY6PS9k ZXYvbnVsbH0KKworIyBXaGVyZSB0byBwdXQgdGhlIG9iaiBmaWxlcy4gRGVmYXVsdHMgdG8gL3Vz ci9vYmouCitNQUtFT0JKRElSUFJFRklYPS91c3Ivb2JqCisKKyMgRmlsZXMgdG8gZXhjbHVkZSB2 aWEgZmluZCgxKQorTkFOT19JR05PUkVfRklMRVNfRVhQUj0nLyhDVlN8XC5naXR8XC5zdm4pJwor CiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIwogIwogIyBUaGUgZnVuY3Rpb25zIHdoaWNoIGRvIHRoZSByZWFsIHdv cmsuCkBAIC0xODIsNyArMTk0LDYgQEAKIAogCWVjaG8gIiR7Q09ORl9XT1JMRH0iID4gJHtOQU5P X01BS0VfQ09ORl9CVUlMRH0KIAllY2hvICIke0NPTkZfQlVJTER9IiA+PiAke05BTk9fTUFLRV9D T05GX0JVSUxEfQotCWVjaG8gIlNSQ0NPTkY9L2Rldi9udWxsIiA+PiAke05BTk9fTUFLRV9DT05G X0JVSUxEfQogKQogCiBidWlsZF93b3JsZCAoICkgKApAQCAtMTkwLDcgKzIwMSwxMSBAQAogCXBw cmludCAzICJsb2c6ICR7TUFLRU9CSkRJUlBSRUZJWH0vXy5idyIKIAogCWNkICR7TkFOT19TUkN9 Ci0JZW52IFRBUkdFVF9BUkNIPSR7TkFOT19BUkNIfSAke05BTk9fUE1BS0V9IFwKKwllbnYgXAor CQlUQVJHRVQ9JHtOQU5PX0FSQ0glOip9IFwKKwkJVEFSR0VUX0FSQ0g9JHtOQU5PX0FSQ0gjIyo6 fSBcCisJCSR7TkFOT19QTUFLRX0gXAorCQlTUkNDT05GPSR7U1JDQ09ORn0gXAogCQlfX01BS0Vf Q09ORj0ke05BTk9fTUFLRV9DT05GX0JVSUxEfSBidWlsZHdvcmxkIFwKIAkJPiAke01BS0VPQkpE SVJQUkVGSVh9L18uYncgMj4mMQogKQpAQCAtMjE0LDEwICsyMjksMTYgQEAKIAl1bnNldCBUQVJH RVRfQklHX0VORElBTgogCSMgTm90ZTogV2UgaW50ZW50aW9uYWxseSBidWlsZCBhbGwgbW9kdWxl cywgbm90IG9ubHkgdGhlIG9uZXMgaW4KIAkjIE5BTk9fTU9EVUxFUyBzbyB0aGUgYnVpbHQgd29y bGQgY2FuIGJlIHJldXNlZCBieSBtdWx0aXBsZSBpbWFnZXMuCi0JZW52IFRBUkdFVF9BUkNIPSR7 TkFOT19BUkNIfSAke05BTk9fUE1BS0V9IGJ1aWxka2VybmVsIFwKKwllbnYgXAorCQlUQVJHRVQ9 JHtOQU5PX0FSQ0glOip9IFwKKwkJVEFSR0VUX0FSQ0g9JHtOQU5PX0FSQ0gjIyo6fSBcCisJCSR7 TkFOT19QTUFLRX0gXAorCQlidWlsZGtlcm5lbCBcCisJCSR7a2VybmNvbmZkaXI6KyJLRVJOQ09O RkRJUj0ifSR7a2VybmNvbmZkaXJ9IFwKKwkJS0VSTkNPTkY9JHtrZXJuY29uZn0gXAorCQlNT0RV TEVTX09WRVJSSURFPSIke05BTk9fTU9EVUxFU30iIFwKKwkJU1JDQ09ORj0ke1NSQ0NPTkZ9IFwK IAkJX19NQUtFX0NPTkY9JHtOQU5PX01BS0VfQ09ORl9CVUlMRH0gXAotCQkke2tlcm5jb25mZGly OisiS0VSTkNPTkZESVI9In0ke2tlcm5jb25mZGlyfSBcCi0JCUtFUk5DT05GPSR7a2VybmNvbmZ9 CiAJKSA+ICR7TUFLRU9CSkRJUlBSRUZJWH0vXy5iayAyPiYxCiApCiAKQEAgLTI0NSw3ICsyNjYs NiBAQAogCiAJZWNobyAiJHtDT05GX1dPUkxEfSIgPiAke05BTk9fTUFLRV9DT05GX0lOU1RBTEx9 CiAJZWNobyAiJHtDT05GX0lOU1RBTEx9IiA+PiAke05BTk9fTUFLRV9DT05GX0lOU1RBTEx9Ci0J ZWNobyAiU1JDQ09ORj0vZGV2L251bGwiID4+ICR7TkFOT19NQUtFX0NPTkZfSU5TVEFMTH0KICkK IAogaW5zdGFsbF93b3JsZCAoICkgKApAQCAtMjUzLDkgKzI3MywxNCBAQAogCXBwcmludCAzICJs b2c6ICR7TkFOT19PQkp9L18uaXciCiAKIAljZCAke05BTk9fU1JDfQotCWVudiBUQVJHRVRfQVJD SD0ke05BTk9fQVJDSH0gXAotCSR7TkFOT19QTUFLRX0gX19NQUtFX0NPTkY9JHtOQU5PX01BS0Vf Q09ORl9JTlNUQUxMfSBpbnN0YWxsd29ybGQgXAorCWVudiBcCisJCVRBUkdFVD0ke05BTk9fQVJD SCU6Kn0gXAorCQlUQVJHRVRfQVJDSD0ke05BTk9fQVJDSCMjKjp9IFwKKwkJJHtOQU5PX1BNQUtF fSBcCisJCWluc3RhbGx3b3JsZCBcCiAJCURFU1RESVI9JHtOQU5PX1dPUkxERElSfSBcCisJCVNS Q0NPTkY9JHtTUkNDT05GfSBcCisJCV9fTUFLRV9DT05GPSR7TkFOT19NQUtFX0NPTkZfSU5TVEFM TH0gXAogCQk+ICR7TkFOT19PQkp9L18uaXcgMj4mMQogCWNoZmxhZ3MgLVIgbm9zY2hnICR7TkFO T19XT1JMRERJUn0KICkKQEAgLTI2Niw5ICsyOTEsMTQgQEAKIAlwcHJpbnQgMyAibG9nOiAke05B Tk9fT0JKfS9fLmV0YyIKIAogCWNkICR7TkFOT19TUkN9Ci0JZW52IFRBUkdFVF9BUkNIPSR7TkFO T19BUkNIfSBcCi0JJHtOQU5PX1BNQUtFfSBfX01BS0VfQ09ORj0ke05BTk9fTUFLRV9DT05GX0lO U1RBTEx9IGRpc3RyaWJ1dGlvbiBcCisJZW52IFwKKwkJVEFSR0VUPSR7TkFOT19BUkNIJToqfSBc CisJCVRBUkdFVF9BUkNIPSR7TkFOT19BUkNIIyMqOn0gXAorCQkke05BTk9fUE1BS0V9IFwKKwkJ ZGlzdHJpYnV0aW9uIFwKIAkJREVTVERJUj0ke05BTk9fV09STERESVJ9IFwKKwkJU1JDQ09ORj0k e1NSQ0NPTkZ9IFwKKwkJX19NQUtFX0NPTkY9JHtOQU5PX01BS0VfQ09ORl9JTlNUQUxMfSBcCiAJ CT4gJHtOQU5PX09CSn0vXy5ldGMgMj4mMQogCSMgbWFrZS5jb25mIGRvZXNuJ3QgZ2V0IGNyZWF0 ZWQgYnkgZGVmYXVsdCwgYnV0IHNvbWUgcG9ydHMgbmVlZCBpdAogCSMgc28gdGhleSBjYW4gc3Bh bSBpdC4KQEAgLTI4OCwzNiArMzE4LDUzIEBACiAJZmkKIAogCWNkICR7TkFOT19TUkN9Ci0JZW52 IFRBUkdFVF9BUkNIPSR7TkFOT19BUkNIfSAke05BTk9fUE1BS0V9IGluc3RhbGxrZXJuZWwgXAor CWVudiBcCisJCVRBUkdFVD0ke05BTk9fQVJDSCU6Kn0gXAorCQlUQVJHRVRfQVJDSD0ke05BTk9f QVJDSCMjKjp9IFwKKwkJJHtOQU5PX1BNQUtFfSBcCisJCWluc3RhbGxrZXJuZWwgXAogCQlERVNU RElSPSR7TkFOT19XT1JMRERJUn0gXAotCQlfX01BS0VfQ09ORj0ke05BTk9fTUFLRV9DT05GX0lO U1RBTEx9IFwKIAkJJHtrZXJuY29uZmRpcjorIktFUk5DT05GRElSPSJ9JHtrZXJuY29uZmRpcn0g XAogCQlLRVJOQ09ORj0ke2tlcm5jb25mfSBcCiAJCU1PRFVMRVNfT1ZFUlJJREU9IiR7TkFOT19N T0RVTEVTfSIKKwkJU1JDQ09ORj0ke1NSQ0NPTkZ9IFwKKwkJX19NQUtFX0NPTkY9JHtOQU5PX01B S0VfQ09ORl9JTlNUQUxMfSBcCiAJKSA+ICR7TkFOT19PQkp9L18uaWsgMj4mMQogKQogCiBydW5f Y3VzdG9taXplKCkgKAogCiAJcHByaW50IDIgInJ1biBjdXN0b21pemUgc2NyaXB0cyIKLQlmb3Ig YyBpbiAkTkFOT19DVVNUT01JWkUKKwlzZXQgLS0gJE5BTk9fQ1VTVE9NSVpFCisJaT0xCisJbnVt X3N0ZXBzPSQjCisJd2hpbGUgWyAkaSAtbGUgJG51bV9zdGVwcyBdCiAJZG8KLQkJcHByaW50IDIg ImN1c3RvbWl6ZSBcIiRjXCIiCisJCWM9JDEKKwkJcHByaW50IDIgIlskaS8kbnVtX3N0ZXBzXSBj dXN0b21pemUgXCIkY1wiIgogCQlwcHJpbnQgMyAibG9nOiAke05BTk9fT0JKfS9fLmN1c3QuJGMi CiAJCXBwcmludCA0ICJgdHlwZSAkY2AiCiAJCSggc2V0IC14IDsgJGMgKSA+ICR7TkFOT19PQkp9 L18uY3VzdC4kYyAyPiYxCisJCXNoaWZ0CisJCTogJCgoIGkgKz0gMSApKQogCWRvbmUKICkKIAog cnVuX2xhdGVfY3VzdG9taXplKCkgKAogCiAJcHByaW50IDIgInJ1biBsYXRlIGN1c3RvbWl6ZSBz Y3JpcHRzIgotCWZvciBjIGluICROQU5PX0xBVEVfQ1VTVE9NSVpFCisJc2V0IC0tICROQU5PX0xB VEVfQ1VTVE9NSVpFCisJaT0xCisJbnVtX3N0ZXBzPSQjCisJd2hpbGUgWyAkaSAtbGUgJG51bV9z dGVwcyBdCiAJZG8KLQkJcHByaW50IDIgImxhdGUgY3VzdG9taXplIFwiJGNcIiIKKwkJYz0kMQor CQlwcHJpbnQgMiAiWyRpLyRudW1fc3RlcHNdIGxhdGUgY3VzdG9taXplIFwiJGNcIiIKIAkJcHBy aW50IDMgImxvZzogJHtOQU5PX09CSn0vXy5sYXRlX2N1c3QuJGMiCiAJCXBwcmludCA0ICJgdHlw ZSAkY2AiCiAJCSggc2V0IC14IDsgJGMgKSA+ICR7TkFOT19PQkp9L18ubGF0ZV9jdXN0LiRjIDI+ JjEKKwkJc2hpZnQKKwkJOiAkKCggaSArPSAxICkpCiAJZG9uZQogKQogCkBAIC0zMzUsNyArMzgy LDcgQEAKIAkJKAogCQlta2RpciAtcCBldGMvbG9jYWwKIAkJY2QgdXNyL2xvY2FsL2V0YwotCQlm aW5kIC4gLXByaW50IHwgY3BpbyAtZHVtcGwgLi4vLi4vLi4vZXRjL2xvY2FsCisJCWZpbmQgLiB8 IGNwaW8gLVIgcm9vdDp3aGVlbCAtZHVtcGwgLi4vLi4vLi4vZXRjL2xvY2FsCiAJCWNkIC4uCiAJ CXJtIC1yZiBldGMKIAkJbG4gLXMgLi4vLi4vZXRjL2xvY2FsIGV0YwpAQCAtMzQ5LDcgKzM5Niw3 IEBACiAJCSMgdGhlIGZpbGVzIGluIC8kZCB3aWxsIGJlIGhpZGRlbiBieSB0aGUgbW91bnQuCiAJ CSMgWFhYOiBjb25maWd1cmUgLyRkIHJhbWRpc2sgc2l6ZQogCQlta2RpciAtcCBjb25mL2Jhc2Uv JGQgY29uZi9kZWZhdWx0LyRkCi0JCWZpbmQgJGQgLXByaW50IHwgY3BpbyAtZHVtcGwgY29uZi9i YXNlLworCQlmaW5kICRkIHwgY3BpbyAtUiByb290OndoZWVsIC1kdW1wbCBjb25mL2Jhc2UvCiAJ ZG9uZQogCiAJZWNobyAiJE5BTk9fUkFNX0VUQ1NJWkUiID4gY29uZi9iYXNlL2V0Yy9tZF9zaXpl CkBAIC0zNTksOCArNDA2LDggQEAKIAllY2hvICJtb3VudCAtbyBybyAvZGV2LyR7TkFOT19EUklW RX1zMyIgPiBjb25mL2RlZmF1bHQvZXRjL3JlbW91bnQKIAogCSMgUHV0IC90bXAgb24gdGhlIC92 YXIgcmFtZGlzayAoY291bGQgYmUgc3ltbGluayBhbHJlYWR5KQotCXJtZGlyIHRtcCB8fCB0cnVl Ci0Jcm0gdG1wIHx8IHRydWUKKwlybSAtZiB0bXAgfHwgOgorCXJtIC1SZiB0bXAKIAlsbiAtcyB2 YXIvdG1wIHRtcAogCiAJKSA+ICR7TkFOT19PQkp9L18uZGwgMj4mMQpAQCAtMzkwLDcgKzQzNyw3 IEBACiBwcnVuZV91c3IoKSAoCiAKIAkjIFJlbW92ZSBhbGwgZW1wdHkgZGlyZWN0b3JpZXMgaW4g L3VzciAKLQlmaW5kICR7TkFOT19XT1JMRERJUn0vdXNyIC10eXBlIGQgLWRlcHRoIC1wcmludCB8 CisJZmluZCAke05BTk9fV09STERESVJ9L3VzciAtdHlwZSBkIC1kZXB0aCB8CiAJCXdoaWxlIHJl YWQgZAogCQlkbwogCQkJcm1kaXIgJGQgPiAvZGV2L251bGwgMj4mMSB8fCB0cnVlIApAQCAtNDE4 LDcgKzQ2NSw3IEBACiAJZWNobyAiQ3JlYXRpbmcgJHtkZXZ9IHdpdGggJHtkaXJ9IChtb3VudGlu ZyBvbiAke21udH0pIgogCW5ld2ZzX3BhcnQgJGRldiAkbW50ICRsYmwKIAljZCAke2Rpcn0KLQlm aW5kIC4gLXByaW50IHwgZ3JlcCAtRXYgJy8oQ1ZTfFwuc3ZuKScgfCBjcGlvIC1kdW1wdiAke21u dH0KKwlmaW5kIC4gXCEgLXJlZ2V4ICIkTkFOT19JR05PUkVfRklMRVNfRVhQUiIgfCBjcGlvIC1S IHJvb3Q6d2hlZWwgLWR1bXB2ICR7bW50fQogCWRmIC1pICR7bW50fQogCXVtb3VudCAke21udH0K ICkKQEAgLTU4OCw2ICs2MzUsOCBAQAogCSMgYWZ0ZXIgdGhlIGJ1aWxkIGNvbXBsZXRlZCwgZm9y IGluc3RhbmNlIHRvIGNvcHkgdGhlIGZpbmlzaGVkCiAJIyBpbWFnZSB0byBhIG1vcmUgY29udmVu aWVudCBwbGFjZToKIAkjIGNwICR7TkFOT19ESVNLSU1HRElSfS9fLmRpc2suaW1hZ2UgL2hvbWUv ZnRwL3B1Yi9uYW5vYnNkLmRpc2sKKwkjIFRoZSBmb2xsb3dpbmcgbGluZSBpcyBuZWVkZWQgdG8g a2VlcCBiYXNoIGZyb20gYmFyZmluZyBvbiB0aGUgZmlsZS4KKwk6CiApCiAKICMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCkBAIC02NzYsNyArNzI1LDggQEAKIAogY3VzdF9pbnN0YWxsX2ZpbGVzICgpICgKIAljZCAk e05BTk9fVE9PTFN9L0ZpbGVzCi0JZmluZCAuIC1wcmludCB8IGdyZXAgLUV2ICcvKENWU3xcLnN2 biknIHwgY3BpbyAtTGR1bXB2ICR7TkFOT19XT1JMRERJUn0KKwlmaW5kIC4gXCEgLXJlZ2V4ICIk e05BTk9fSUdOT1JFX0ZJTEVTX0VYUFJ9IiB8IFwKKwkgICAgY3BpbyAtUiByb290OndoZWVsIC1M ZHVtcHYgJHtOQU5PX1dPUkxERElSfQogKQogCiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwpAQCAtNjk0LDggKzc0 NCw4IEBACiAJbWtkaXIgLXAgJHtOQU5PX1dPUkxERElSfS9Qa2cKIAkoCiAJCWNkICR7TkFOT19Q QUNLQUdFX0RJUn0KLQkJZmluZCAke05BTk9fUEFDS0FHRV9MSVNUfSAtcHJpbnQgfAotCQkgICAg Y3BpbyAtTGR1bXB2ICR7TkFOT19XT1JMRERJUn0vUGtnCisJCWZpbmQgJHtOQU5PX1BBQ0tBR0Vf TElTVH0gfCBcCisJCSAgICBjcGlvIC1SIHJvb3Q6d2hlZWwgLUxkdW1wdiAke05BTk9fV09STERE SVJ9L1BrZwogCSkKIAogCSMgQ291bnQgJiByZXBvcnQgaG93IG1hbnkgd2UgaGF2ZSB0byBpbnN0 YWxsCkBAIC03NTgsMTA1ICs4MDgsMTEyIEBACiAjIFByb2dyZXNzIFByaW50CiAjCVByaW50ICQy IGF0IGxldmVsICQxLgogcHByaW50KCkgewotICAgIGlmIFsgIiQxIiAtbGUgJFBQTEVWRUwgXTsg dGhlbgotCXJ1bnRpbWU9JCgoIGBkYXRlICslc2AgLSAkTkFOT19TVEFSVFRJTUUgKSkKLQlwcmlu dGYgIiVzICUuJHsxfXMgJXNcbiIgImBkYXRlIC11IC1yICRydW50aW1lICslSDolTTolU2AiICIj IyMjIyIgIiQyIiAxPiYzCi0gICAgZmkKKwlpZiBbICIkMSIgLWxlICRQUExFVkVMIF07IHRoZW4K KwkJcnVudGltZT0kKCggJChkYXRlICsnJXMnKSAtICR7TkFOT19TVEFSVFRJTUV9ICkpCisJCXBy aW50ZiAiJXMgJS4kezF9cyAlc1xuIiAiJChkYXRlIC11IC1yICRydW50aW1lICslSDolTTolUyki ICIjIyMjIyIgIiQyIiA+JjMKKwlmaQogfQogCiB1c2FnZSAoKSB7Ci0JKAotCWVjaG8gIlVzYWdl OiAkMCBbLWJmaWtucXZ3XSBbLWMgY29uZmlnX2ZpbGVdIgotCWVjaG8gIgktYglzdXBwcmVzcyBi dWlsZHMgKGJvdGgga2VybmVsIGFuZCB3b3JsZCkiCi0JZWNobyAiCS1mCXN1cHByZXNzIGNvZGUg c2xpY2UgZXh0cmFjdGlvbiIKLQllY2hvICIJLWkJc3VwcHJlc3MgZGlzayBpbWFnZSBidWlsZCIK LQllY2hvICIJLWsJc3VwcHJlc3MgYnVpbGRrZXJuZWwiCi0JZWNobyAiCS1uCWFkZCAtRE5PX0NM RUFOIHRvIGJ1aWxkd29ybGQsIGJ1aWxka2VybmVsLCBldGMiCi0JZWNobyAiCS1xCW1ha2Ugb3V0 cHV0IG1vcmUgcXVpZXQiCi0JZWNobyAiCS12CW1ha2Ugb3V0cHV0IG1vcmUgdmVyYm9zZSIKLQll Y2hvICIJLXcJc3VwcHJlc3MgYnVpbGR3b3JsZCIKLQllY2hvICIJLWMJc3BlY2lmeSBjb25maWcg ZmlsZSIKLQkpIDE+JjIKKwljYXQgPiYyIDw8RU9GCit1c2FnZTogJHswIyMqL30gWy1iaWtucXZ3 XSBbLWMgY29uZmlnX2ZpbGVdCisJLWIJCXN1cHByZXNzIGJ1aWxkcyAoYm90aCBrZXJuZWwgYW5k IHdvcmxkKQorCS1jIGNvbmZpZ19maWxlCWNvbmZpZyBmaWxlIHRvIHVzZSBhZnRlciBkZWZpbmlu ZyBhbGwKKwkJCWludGVybmFsIHZhcmlhYmxlcy4KKwktaQkJc3VwcHJlc3MgZGlzayBpbWFnZSBi dWlsZAorCS1qIG1ha2Utam9icwludW1iZXIgb2YgbWFrZSBqb2JzIHRvIGludm9rZQorCS1rCQlz dXBwcmVzcyBidWlsZGtlcm5lbAorCS1uCQlhZGQgLUROT19DTEVBTiB0byBidWlsZHdvcmxkLCBi dWlsZGtlcm5lbCwgZXRjCisJLXEJCW1ha2Ugb3V0cHV0IG1vcmUgcXVpZXQKKwktdgkJbWFrZSBv dXRwdXQgbW9yZSB2ZXJib3NlCisJLXcJCXN1cHByZXNzIGJ1aWxkd29ybGQKK0VPRgogCWV4aXQg MgogfQogCiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwogIyBQYXJzZSBhcmd1bWVudHMKIAorc2V0ICtlCisKIGRv X2NsZWFuPXRydWUKIGRvX2tlcm5lbD10cnVlCiBkb193b3JsZD10cnVlCiBkb19pbWFnZT10cnVl CiBkb19jb3B5b3V0X3BhcnRpdGlvbj10cnVlCittYWtlX2pvYnM9MworbmFub19jb25mcz0KIAot c2V0ICtlCi1hcmdzPWBnZXRvcHQgYmM6Zmhpa25xdncgJCpgCi1pZiBbICQ/IC1uZSAwIF0gOyB0 aGVuCi0JdXNhZ2UKLQlleGl0IDIKLWZpCi1zZXQgLWUKLQotc2V0IC0tICRhcmdzCi1mb3IgaQor d2hpbGUgZ2V0b3B0cyAnYmM6ZmhpajprbnF2dycgb3B0Y2gKIGRvCi0JY2FzZSAiJGkiIAotCWlu Ci0JLWIpCisJY2FzZSAiJG9wdGNoIiBpbgorCWIpCiAJCWRvX3dvcmxkPWZhbHNlCiAJCWRvX2tl cm5lbD1mYWxzZQotCQlzaGlmdAogCQk7OwotCS1rKQotCQlkb19rZXJuZWw9ZmFsc2UKLQkJc2hp ZnQKKwljKQorCQlpZiBbIC1mICIkT1BUQVJHIiBdOyB0aGVuCisJCQluYW5vX2NvbmZzPSIkbmFu b19jb25mcyAkT1BUQVJHIgorCQlmaQogCQk7OwotCS1jKQotCQkuICIkMiIKLQkJc2hpZnQKLQkJ c2hpZnQKLQkJOzsKLQktZikKKwlmKQogCQlkb19jb3B5b3V0X3BhcnRpdGlvbj1mYWxzZQotCQlz aGlmdAogCQk7OwotCS1oKQorCWgpCiAJCXVzYWdlCiAJCTs7Ci0JLWkpCisJaSkKIAkJZG9faW1h Z2U9ZmFsc2UKLQkJc2hpZnQKIAkJOzsKLQktbikKKwlqKQorCQllY2hvICRPUFRBUkcgfCBlZ3Jl cCAtcSAnXltbOmRpZ2l0Ol1dKyQnICYmIFsgJE9QVEFSRyAtZ3QgMCBdCisJCWlmIFsgJD8gLW5l IDAgXTsgdGhlbgorCQkJZWNobyAiJHswIyMqL306IC1qIHZhbHVlIG11c3QgYmUgYSBwb3NpdGl2 ZSBpbnRlZ2VyLiIKKwkJCXVzYWdlCisJCWZpCisJCW1ha2Vfam9icz0kT1BUQVJHCisJCTs7CisJ aykKKwkJZG9fa2VybmVsPWZhbHNlCisJCTs7CisJbikKIAkJZG9fY2xlYW49ZmFsc2UKLQkJc2hp ZnQKIAkJOzsKLQktcSkKLQkJUFBMRVZFTD0kKCgkUFBMRVZFTCAtIDEpKQotCQlzaGlmdAorCXEp CisJCTogJCgoIFBQTEVWRUwgLT0gMSkpCiAJCTs7Ci0JLXYpCi0JCVBQTEVWRUw9JCgoJFBQTEVW RUwgKyAxKSkKLQkJc2hpZnQKKwl2KQorCQk6ICQoKCBQUExFVkVMICs9IDEpKQogCQk7OwotCS13 KQorCXcpCiAJCWRvX3dvcmxkPWZhbHNlCi0JCXNoaWZ0CiAJCTs7Ci0JLS0pCi0JCXNoaWZ0Ci0J CWJyZWFrCisJKikKKwkJdXNhZ2UKKwkJOzsKIAllc2FjCiBkb25lCiAKK3NoaWZ0ICQoKCAkT1BU SU5EIC0gMSApKQorCiBpZiBbICQjIC1ndCAwIF0gOyB0aGVuCi0JZWNobyAiJDA6IEV4dHJhbmVv dXMgYXJndW1lbnRzIHN1cHBsaWVkIgorCWVjaG8gIiR7MCMjKi99OiBleHRyYW5lb3VzIGFyZ3Vt ZW50cyBzdXBwbGllZCIKIAl1c2FnZQogZmkKIAorTkFOT19QTUFLRT0iJE5BTk9fUE1BS0UgLWog JG1ha2Vfam9icyIKKworc2V0IC1lCisKICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiAjIFNldHVwIGFuZCBFeHBv cnQgSW50ZXJuYWwgdmFyaWFibGVzCiAjCisKK2ZvciBuYW5vX2NvbmYgaW4gJG5hbm9fY29uZnM7 IGRvCisJZWNobyAiU291cmNpbmcgJG5hbm9fY29uZiIKKwkuICIkbmFub19jb25mIgorZG9uZQor CiB0ZXN0IC1uICIke05BTk9fT0JKfSIgfHwgTkFOT19PQko9L3Vzci9vYmovbmFub2JzZC4ke05B Tk9fTkFNRX0vCiB0ZXN0IC1uICIke01BS0VPQkpESVJQUkVGSVh9IiB8fCBNQUtFT0JKRElSUFJF RklYPSR7TkFOT19PQkp9CiB0ZXN0IC1uICIke05BTk9fRElTS0lNR0RJUn0iIHx8IE5BTk9fRElT S0lNR0RJUj0ke05BTk9fT0JKfQo= --14dae9399e0de42f3e04b5c20ec5-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 07:57:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4FD5106566C; Thu, 5 Jan 2012 07:57:47 +0000 (UTC) (envelope-from adrian.chadd@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 4BB158FC08; Thu, 5 Jan 2012 07:57:45 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so336778vbb.13 for ; Wed, 04 Jan 2012 23:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=NnUQm+so8EsZCtaRNLd0CSQelC9+kFIQk6Xgde9em1w=; b=dM9coviIXtFZFHyY3f09uWHj93jSfTLn5H25GtlcgIOEzbPsvzMyvqwmV2XwoOVZ/z rLHPo1Uam6hzw1+VTcPCRV3rzzn82fTYq6dzsqxh1l2SrV5IDymjSXEiZ9GSI1BjsjfE p0TAvXSKuPADOAQOAGX1SAo4ybFL0Je59/DEw= MIME-Version: 1.0 Received: by 10.52.33.99 with SMTP id q3mr381210vdi.100.1325750264895; Wed, 04 Jan 2012 23:57:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 4 Jan 2012 23:57:44 -0800 (PST) Date: Wed, 4 Jan 2012 23:57:44 -0800 X-Google-Sender-Auth: deumgNbsHau7Q5Qgx30ieF70xUA Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org, freebsd-current , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 07:57:47 -0000 Hi, I'm trying to slim down the freebsd kernel to fit on some devices with 4MB of flash. Since I'm not using NFS or UFS_ACL, I wondered if that code required. It turns out I can just build a kernel with those two disabled. Would it be possible to remove them from "standard" and make them optional? Or is there a reason to keep it in base? If so (eg so things can be kldload'ed that uses the ACL code) can we make it a build-time option, and/or a pair of loadable kernel modules? Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 09:03:11 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7385106564A for ; Thu, 5 Jan 2012 09:03:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7685B8FC16 for ; Thu, 5 Jan 2012 09:03:11 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q05938Qf099748 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 01:03:10 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F05677D.7070602@freebsd.org> Date: Thu, 05 Jan 2012 01:03:57 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <20120105043934.GA37322@nargothrond.kdm.org> In-Reply-To: <20120105043934.GA37322@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, scsi@freebsd.org Subject: Re: CAM Target Layer available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:03:11 -0000 On 1/4/12 8:39 PM, Kenneth D. Merry wrote: > The CAM Target Layer (CTL) is now available for testing. I am planning to > commit it to to head next week, barring any major objections. > > CTL is a disk and processor device emulation subsystem originally written > for Copan Systems under Linux starting in 2003. It has been shipping in > Copan (now SGI) products since 2005. > > It was ported to FreeBSD in 2008, and thanks to an agreement between SGI > (who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is > available under a BSD-style license. The intent behind the agreement was > that Spectra would work to get CTL into the FreeBSD tree. [...] > - Note that the ramdisk backend is a "fake" ramdisk. That is, it is > backed by a small amount of RAM that is used for all I/O requests. This > is useful for performance testing, but not for any data integrity tests. so, If I read this correctly, I should be able to export a fusion-io flash card with ctladm create -b block -o file=/dev/fio0 ?? > - To add a LUN with the block/file backend: > > truncate -s +1T myfile > ctladm create -b block -o file=myfile > ctladm port -o on > From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 10:17:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 948BC1065673; Thu, 5 Jan 2012 10:17:05 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 579498FC14; Thu, 5 Jan 2012 10:17:05 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id AC6921C6439; Thu, 5 Jan 2012 18:01:12 +0800 (CST) Date: Thu, 5 Jan 2012 18:01:12 +0800 From: Denny Lin To: Matthew Tippett Message-ID: <20120105100112.GB47282@mail.hs.ntnu.edu.tw> References: <20120104223158.911B11065678@hub.freebsd.org> <20120104184910.0d604240@kan.dyndns.org> <4F04E626.5040406@phoronix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F04E626.5040406@phoronix.com> User-Agent: Mutt/1.4.2.3i Cc: Joe Holden , FreeBSD Stable Mailing List , Adrian Chadd , Michael Larabel , Current FreeBSD , Arnaud Lacombe Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:17:05 -0000 On Wed, Jan 04, 2012 at 03:52:06PM -0800, Matthew Tippett wrote: > Hmm... No sure what happened there again. What I sent (pulled from my > "Sent" folder... > === > > Thanks for the comment Arnaud. For comparative benchmarking on > Phoronix.com , Michael invariable leaves it in the > default configuration 'in the way the developers or vendor wanted it for > production'. This is by rule. A quick question: why is ZFS used in the benchmark? "Both operating systems were in their stock configuration aside from FreeBSD 9.0 using ZFS." UFS is the default on FreeBSD, not ZFS. FreeBSD was not left in the default configuration. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 10:59:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5475C1065672; Thu, 5 Jan 2012 10:59:17 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9578FC14; Thu, 5 Jan 2012 10:59:16 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1054F62A0; Thu, 5 Jan 2012 10:39:41 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E408B8CB8; Thu, 5 Jan 2012 11:39:40 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd References: Date: Thu, 05 Jan 2012 11:39:40 +0100 In-Reply-To: (Adrian Chadd's message of "Wed, 4 Jan 2012 23:57:44 -0800") Message-ID: <86ty4a8mc3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current , freebsd-arch@freebsd.org Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:59:17 -0000 Adrian Chadd writes: > Since I'm not using NFS or UFS_ACL, I wondered if that code required. > It turns out I can just build a kernel with those two disabled. > > Would it be possible to remove them from "standard" and make them > optional? Or is there a reason to keep it in base? I would be very annoyed if it were no longer possible to netboot GENERIC... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 13:48:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C54106564A; Thu, 5 Jan 2012 13:48:20 +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 42C138FC12; Thu, 5 Jan 2012 13:48:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id EE7FC46B0D; Thu, 5 Jan 2012 08:48:19 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 78918B971; Thu, 5 Jan 2012 08:48:19 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 5 Jan 2012 08:48:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201050848.18414.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jan 2012 08:48:19 -0500 (EST) Cc: freebsd-fs@freebsd.org, Adrian Chadd , freebsd-current Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:48:20 -0000 [ A bit excessive on the cross-posting? arch@ alone was probably fine ] On Thursday, January 05, 2012 2:57:44 am Adrian Chadd wrote: > Hi, > > I'm trying to slim down the freebsd kernel to fit on some devices with > 4MB of flash. > > Since I'm not using NFS or UFS_ACL, I wondered if that code required. > It turns out I can just build a kernel with those two disabled. > > Would it be possible to remove them from "standard" and make them > optional? Or is there a reason to keep it in base? > If so (eg so things can be kldload'ed that uses the ACL code) can we > make it a build-time option, and/or a pair of loadable kernel modules? NFS doesn't actually use them curently, only UFS and ZFS do. Unfortunately we've yet to make it possible to compile ZFS into the kernel, so you can't make the sys/conf/files bits completely accurate yet (it would be nice to let folks who don't need FFS for a ZFS-only system remove FFS and UFS, but this would break that): Index: files =================================================================== --- files (revision 229491) +++ files (working copy) @@ -2393,8 +2393,9 @@ kern/sched_ule.c optional sched_ule kern/serdev_if.m standard kern/stack_protector.c standard \ compile-with "${NORMAL_C:N-fstack-protector*}" -kern/subr_acl_nfs4.c standard -kern/subr_acl_posix1e.c standard +# XXX: subr_acl_nfs4.c is also used by ZFS +kern/subr_acl_nfs4.c optional ufs_acl +kern/subr_acl_posix1e.c optional ufs_acl kern/subr_autoconf.c standard kern/subr_blist.c standard kern/subr_bus.c standard -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 14:24:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24DCD106566C; Thu, 5 Jan 2012 14:24:36 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id E0A798FC1A; Thu, 5 Jan 2012 14:24:35 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q05EOZ5m075787; Thu, 5 Jan 2012 07:24:35 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q05EOZ4L075786; Thu, 5 Jan 2012 07:24:35 -0700 (MST) (envelope-from ken) Date: Thu, 5 Jan 2012 07:24:35 -0700 From: "Kenneth D. Merry" To: Julian Elischer Message-ID: <20120105142435.GA75178@nargothrond.kdm.org> References: <20120105043934.GA37322@nargothrond.kdm.org> <4F05677D.7070602@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F05677D.7070602@freebsd.org> User-Agent: Mutt/1.4.2i Cc: current@freebsd.org, scsi@freebsd.org Subject: Re: CAM Target Layer available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:24:36 -0000 On Thu, Jan 05, 2012 at 01:03:57 -0800, Julian Elischer wrote: > On 1/4/12 8:39 PM, Kenneth D. Merry wrote: > >The CAM Target Layer (CTL) is now available for testing. I am planning to > >commit it to to head next week, barring any major objections. > > > >CTL is a disk and processor device emulation subsystem originally written > >for Copan Systems under Linux starting in 2003. It has been shipping in > >Copan (now SGI) products since 2005. > > > >It was ported to FreeBSD in 2008, and thanks to an agreement between SGI > >(who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is > >available under a BSD-style license. The intent behind the agreement was > >that Spectra would work to get CTL into the FreeBSD tree. > [...] > > > - Note that the ramdisk backend is a "fake" ramdisk. That is, it is > > backed by a small amount of RAM that is used for all I/O requests. > > This > > is useful for performance testing, but not for any data integrity > > tests. > > so, If I read this correctly, I should be able to export a fusion-io > flash card with > ctladm create -b block -o file=/dev/fio0 ?? Yes, that would work. Although last time I tried using a block device, as opposed to a file, I ran into a GEOM panic that looked like it should be pretty easy to fix. If you run into that, you can get around it by disabling sending sync cache to the back end: ctladm realsync off > > - To add a LUN with the block/file backend: > > > > truncate -s +1T myfile > > ctladm create -b block -o file=myfile > > ctladm port -o on > > Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 14:26:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6231065692 for ; Thu, 5 Jan 2012 14:26:23 +0000 (UTC) (envelope-from vertexSymphony@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id AB6CA8FC1D for ; Thu, 5 Jan 2012 14:26:23 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=jvVrFGzXxiIry1WhFXwYxSQqljXMBoDkivdiMkjHIuMt8zx37hOHeup7wJj4R4h65TZx4tDwWV2E u1MfI8+wT81SKr3M9W/b4occIKVk1gn77BJAJsJKjOhkcgB90ML/ Received: from [192.168.0.100] (213-56-16-190.fibertel.com.ar [190.16.56.213]) by mx.zohomail.com with SMTPS id 1325773582966135.10504596842304; Thu, 5 Jan 2012 06:26:22 -0800 (PST) Message-ID: <4F05B302.2010308@zoho.com> Date: Thu, 05 Jan 2012 11:26:10 -0300 From: Alex Kuster User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111230 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20120104223158.911B11065678@hub.freebsd.org> <20120104184910.0d604240@kan.dyndns.org> <4F04E626.5040406@phoronix.com> In-Reply-To: <4F04E626.5040406@phoronix.com> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig47BAA14E1A027AA130B37E10" X-Zoho-Virus-Status: 1 X-ZohoMailClient: External Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:26:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig47BAA14E1A027AA130B37E10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/04/2012 20:52, Matthew Tippett wrote: > > As a service to the community or vendor that publishes the tuning > guide, Michael is more than willing to redo a tuned vs untuned > comparison. To date, the communities have never taken us up on that > offer. In part, this affects Phoronix.com 's > perception in the public, but that is more of a result of a one sided > discussion by a party external to a particular community (with a > healthy touch of journalisticly pumped compare & contrast). For the > FreeBSD community, who else outside of the FreeBSD community actually > runs public comparisons of FreeBSD against anything? If you just want to benchmark defaults, please, use proper defaults and don't do a *custom* ZFS setup (which was IMHO a pretty big and gross mistake). I would be interested in a benchmark that does significant tests with same hardware and REAL default setup. It would be awesome if those benchmarks were re-done that way, so we can compare an out-of-the-box experience even if that's not the last word on how a system will perform (as others said, no one uses a default setup for their servers) And, if anyone else suggests a tuned-system benchmark ... I'm ok with that too as long it's done properly and with guidance of a person of the community that can give proper advice. I'm a regular reader of Phoronix because it's basically easier than being subscribed to a couple of mailing lists, blogs and such just to get latest information on developments. And the site is fairly popular, so you hold a pretty big responsibility in there. I got really disappointed on how a bad benchmark could impact on the reputation of FreeBSD. Things that are not true that people will be repeating (not-so-long-ago I was a moderator on a Linux forum and I saw that misinformation in action, it's terrible !) Sorry if the words sound strong ... but I'm glad that these benchmarks can be re-done. Thanks for reading ! --------------enig47BAA14E1A027AA130B37E10 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.18 (FreeBSD) iQIcBAEBAgAGBQJPBbMLAAoJEJGluUjNIWcdWnEP/RYEisDpnThkBo7QpPcO5zwW sET5rfzz/pJdQB4K68c00CmO0s0qieAZLLTjdWlFi9V21FHCZkBkLtexOVvLAHrs 7Zjx/tzVmd+aaadXNIcu81jGqHyVUrCCj8qOS9xs9IzQPEMjHtGznltpRBuj2MSc 5hJ6owG/EALTlBDIduFsfa79fQCI89r4Phj92o3/alc6fVB26jxxqGq2brb1B9ae 8bMUcFBztRBV7JJeBdKKsvgWKe1uDujquKvmZAjqjY03Azc68n8g+E8heLKXK/TF 7LuCtfPfW2s7cHa5kp7/zMaHwlaHPZXDo98JEb7P7RN6RvEnUb22490VANtlHUN0 4CBCOmDk+YxwNdU3B8m8MJNuGvr9IN3XSMrRfWdmQa/x0lPbg321Ax8Aicqz1Vz5 wiI1x7aEiriPV7HnqjH2nppbdrS+4Ix5n923bSlruURffpWf2cJj4Ps1muvB02nB cIxoTgpmVeHCKrDNbOrq69Xav4E0o5hlyubDlh65V9nJYkcw8Fx19I92cQSXwI0N 3Lwwviblw5RPZM/Uq4h8AeXAdALDq+3FagBOHXm6UZaGzSylQlqk4z8w5Hdu34z3 WBMgc8sfXn7CwVKUV60cv3hSnQZCSah0PwBgCMbSKDqNhn0otJ9Iqo76A3XlOA1o 64iT5L6+tn+EBf8GRHW9 =UXym -----END PGP SIGNATURE----- --------------enig47BAA14E1A027AA130B37E10-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 14:35:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A900106566B for ; Thu, 5 Jan 2012 14:35:02 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id F10F48FC13 for ; Thu, 5 Jan 2012 14:35:01 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RioPE-0007n7-Mp for freebsd-current@freebsd.org; Thu, 05 Jan 2012 06:35:00 -0800 Date: Thu, 5 Jan 2012 06:35:00 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1325774100698-5122813.post@n5.nabble.com> In-Reply-To: References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> <1325708915902-5120743.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:35:02 -0000 As I said before, it's not related, because your problem is X/ hal related, and I was speaking of syscons. Can you set language in X by x11/setxkbmap? You are using hald, and xorg.conf is probably ignored. If you insist on keeping hal, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html should give you some pointers on setting keyboard language. I don't know why you previously had localized keyboard in X. Was that first reboot of system? -- View this message in context: http://freebsd.1045724.n5.nabble.com/bsdinstall-kbdmap-tp5119535p5122813.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 14:42:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC63106564A for ; Thu, 5 Jan 2012 14:42:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id E06588FC16 for ; Thu, 5 Jan 2012 14:42:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LXB00D08Y6ND600@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Thu, 05 Jan 2012 08:42:23 -0600 (CST) Received: from comporellon.tachypleus.net ([unknown] [76.210.61.211]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LXB00A1AY5TVO10@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Thu, 05 Jan 2012 08:41:54 -0600 (CST) Date: Thu, 05 Jan 2012 08:41:53 -0600 From: Nathan Whitehorn In-reply-to: To: freebsd-current@freebsd.org Message-id: <4F05B6B1.8090501@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.61.211 X-Spam-PmxInfo: Server=avs-10, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.5.143015, SenderIP=76.210.61.211 References: <4EFC1260.1060503@luddite.com.au> <4EFCD252.7080209@cran.org.uk> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111113 Thunderbird/8.0 Subject: Re: Apropos Removal of sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:42:24 -0000 On 01/04/12 14:56, Warner Losh wrote: > On Dec 29, 2011, at 1:49 PM, Bruce Cran wrote: > >> On 29/12/2011 18:39, Renato Botelho wrote: >>> IIRC, PCBSD installer can install a regular FreeBSD on ZFS. >> It can do, but you're left with a /very/ basic installation - the hostname, network interfaces etc. aren't configured, which could be a problem for some people. >> >> If I thought there would be any support for it, I'd try and find time to plug in the sade(4) rewrite into sysinstall - it has a rather nice UI and supports ZFS. > The base of the PC-BSD installer is in the system as pc-sysinstall... There were plans to merge bsdinstall with it that never came to fruition. pc-sysinstall handles the hard part of the system install on a huge number of combinations. > > Just FYI. For those interested in this, there is a brief list of the kinds of things that need to be done and hurdles along the way on the wiki at: http://wiki.freebsd.org/PCBSDInstallMerge -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 15:21:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2B0A106564A; Thu, 5 Jan 2012 15:21:00 +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 A0A288FC0C; Thu, 5 Jan 2012 15:21:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q05FKxv9034439; Thu, 5 Jan 2012 10:20:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q05FKx8l034418; Thu, 5 Jan 2012 15:20:59 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Jan 2012 15:20:59 GMT Message-Id: <201201051520.q05FKx8l034418@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: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:21:00 -0000 TB --- 2012-01-05 13:05:41 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 13:05:41 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-01-05 13:05:41 - cleaning the object tree TB --- 2012-01-05 13:06:00 - cvsupping the source tree TB --- 2012-01-05 13:06:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-01-05 13:06:48 - building world TB --- 2012-01-05 13:06:48 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 13:06:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 13:06:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 13:06:48 - SRCCONF=/dev/null TB --- 2012-01-05 13:06:48 - TARGET=ia64 TB --- 2012-01-05 13:06:48 - TARGET_ARCH=ia64 TB --- 2012-01-05 13:06:48 - TZ=UTC TB --- 2012-01-05 13:06:48 - __MAKE_CONF=/dev/null TB --- 2012-01-05 13:06:48 - cd /src TB --- 2012-01-05 13:06:48 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 13:06:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 5 14:35:56 UTC 2012 TB --- 2012-01-05 14:35:56 - generating LINT kernel config TB --- 2012-01-05 14:35:56 - cd /src/sys/ia64/conf TB --- 2012-01-05 14:35:56 - /usr/bin/make -B LINT TB --- 2012-01-05 14:35:56 - cd /src/sys/ia64/conf TB --- 2012-01-05 14:35:56 - /usr/sbin/config -m LINT TB --- 2012-01-05 14:35:56 - building LINT kernel TB --- 2012-01-05 14:35:56 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 14:35:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 14:35:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 14:35:56 - SRCCONF=/dev/null TB --- 2012-01-05 14:35:56 - TARGET=ia64 TB --- 2012-01-05 14:35:56 - TARGET_ARCH=ia64 TB --- 2012-01-05 14:35:56 - TZ=UTC TB --- 2012-01-05 14:35:56 - __MAKE_CONF=/dev/null TB --- 2012-01-05 14:35:56 - cd /src TB --- 2012-01-05 14:35:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 5 14:35:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Jan 5 15:10:48 UTC 2012 TB --- 2012-01-05 15:10:48 - cd /src/sys/ia64/conf TB --- 2012-01-05 15:10:48 - /usr/sbin/config -m GENERIC TB --- 2012-01-05 15:10:48 - building GENERIC kernel TB --- 2012-01-05 15:10:48 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 15:10:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 15:10:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 15:10:48 - SRCCONF=/dev/null TB --- 2012-01-05 15:10:48 - TARGET=ia64 TB --- 2012-01-05 15:10:48 - TARGET_ARCH=ia64 TB --- 2012-01-05 15:10:48 - TZ=UTC TB --- 2012-01-05 15:10:48 - __MAKE_CONF=/dev/null TB --- 2012-01-05 15:10:48 - cd /src TB --- 2012-01-05 15:10:48 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jan 5 15:10:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-05 15:20:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-05 15:20:59 - ERROR: failed to build GENERIC kernel TB --- 2012-01-05 15:20:59 - 6499.09 user 1120.94 system 8118.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 16:47:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8E83106564A for ; Thu, 5 Jan 2012 16:47:55 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 31A168FC14 for ; Thu, 5 Jan 2012 16:47:54 +0000 (UTC) Received: by bkbzv15 with SMTP id zv15so174736bkb.13 for ; Thu, 05 Jan 2012 08:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=72nU7lsuq4m4dpuPA+wBH6C8NeaD4IvZndbDkDq0jWE=; b=jhXC3ODrCMvApqNPt9NDyv+eY0mspZ5avOMl3EcUWBkCOz5T1uQF6PE7i9FccfsBat 9aZIkt2RCPHa+qWfDScFelVdZodfCrMTGMtnmLg/NATsh4bZHIP4GCZ+jisRyphSOQGB +W0nsjcImc8PBJUZ+vRymcjbrUTiD+DS8Bjkk= MIME-Version: 1.0 Received: by 10.204.9.216 with SMTP id m24mr1092063bkm.84.1325782073845; Thu, 05 Jan 2012 08:47:53 -0800 (PST) Received: by 10.204.227.136 with HTTP; Thu, 5 Jan 2012 08:47:53 -0800 (PST) In-Reply-To: References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> <1325708915902-5120743.post@n5.nabble.com> Date: Thu, 5 Jan 2012 16:47:53 +0000 Message-ID: From: Tom Evans To: "Edwin L. Culp W." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:47:55 -0000 On Thu, Jan 5, 2012 at 12:58 AM, Edwin L. Culp W. wr= ote: > I really appreciate your help but I am having a hard time > understanding because this has been working perfectly on FreeBSD 9.0 > since new. ( 4 months ago ) > > Just incase it is important. > > # uname -a > =C2=A0FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed > Jan =C2=A04 05:03:08 CST 2012 > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO =C2=A0amd64 > > My rc.conf has > > keymap=3D"spanish.iso.acc.kbd" Are you sure this is right? My rc.conf has: keymap=3D"uk.iso" ie, no '.kbd' file ending, which is implied. > > I have no /etc/X11 configuration file and haven't ever needed one. > The mouse has never had a problem until I reset the server this > morning. > Mouse? I thought you were talking about keyboard! To get the correct keymap in X from hal, you need to add a policy file, exactly as described in the handbook. Possibly you didn't have hal enabled in earlier X builds, but if you want it to work with hal, you need the policy file. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 17:29:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE23106566C; Thu, 5 Jan 2012 17:29:36 +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 9EFDE8FC08; Thu, 5 Jan 2012 17:29:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q05HTZmE098993; Thu, 5 Jan 2012 12:29:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q05HTZlm098909; Thu, 5 Jan 2012 17:29:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Jan 2012 17:29:35 GMT Message-Id: <201201051729.q05HTZlm098909@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: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:29:36 -0000 TB --- 2012-01-05 14:56:19 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 14:56:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-01-05 14:56:19 - cleaning the object tree TB --- 2012-01-05 14:56:37 - cvsupping the source tree TB --- 2012-01-05 14:56:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-01-05 14:56:50 - building world TB --- 2012-01-05 14:56:50 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 14:56:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 14:56:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 14:56:50 - SRCCONF=/dev/null TB --- 2012-01-05 14:56:50 - TARGET=powerpc TB --- 2012-01-05 14:56:50 - TARGET_ARCH=powerpc TB --- 2012-01-05 14:56:50 - TZ=UTC TB --- 2012-01-05 14:56:50 - __MAKE_CONF=/dev/null TB --- 2012-01-05 14:56:50 - cd /src TB --- 2012-01-05 14:56:50 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 14:56:51 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 5 17:04:26 UTC 2012 TB --- 2012-01-05 17:04:26 - generating LINT kernel config TB --- 2012-01-05 17:04:26 - cd /src/sys/powerpc/conf TB --- 2012-01-05 17:04:26 - /usr/bin/make -B LINT TB --- 2012-01-05 17:04:26 - cd /src/sys/powerpc/conf TB --- 2012-01-05 17:04:26 - /usr/sbin/config -m LINT TB --- 2012-01-05 17:04:26 - building LINT kernel TB --- 2012-01-05 17:04:26 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 17:04:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 17:04:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 17:04:26 - SRCCONF=/dev/null TB --- 2012-01-05 17:04:26 - TARGET=powerpc TB --- 2012-01-05 17:04:26 - TARGET_ARCH=powerpc TB --- 2012-01-05 17:04:26 - TZ=UTC TB --- 2012-01-05 17:04:26 - __MAKE_CONF=/dev/null TB --- 2012-01-05 17:04:26 - cd /src TB --- 2012-01-05 17:04:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 5 17:04:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Jan 5 17:23:07 UTC 2012 TB --- 2012-01-05 17:23:07 - cd /src/sys/powerpc/conf TB --- 2012-01-05 17:23:07 - /usr/sbin/config -m GENERIC TB --- 2012-01-05 17:23:07 - building GENERIC kernel TB --- 2012-01-05 17:23:07 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 17:23:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 17:23:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 17:23:07 - SRCCONF=/dev/null TB --- 2012-01-05 17:23:07 - TARGET=powerpc TB --- 2012-01-05 17:23:07 - TARGET_ARCH=powerpc TB --- 2012-01-05 17:23:07 - TZ=UTC TB --- 2012-01-05 17:23:07 - __MAKE_CONF=/dev/null TB --- 2012-01-05 17:23:07 - cd /src TB --- 2012-01-05 17:23:07 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jan 5 17:23:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-05 17:29:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-05 17:29:35 - ERROR: failed to build GENERIC kernel TB --- 2012-01-05 17:29:35 - 7583.41 user 1223.23 system 9195.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 17:34:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE2AC106566B for ; Thu, 5 Jan 2012 17:34:49 +0000 (UTC) (envelope-from edwinlculp@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 6B5FA8FC08 for ; Thu, 5 Jan 2012 17:34:48 +0000 (UTC) Received: by eaaf13 with SMTP id f13so768778eaa.13 for ; Thu, 05 Jan 2012 09:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1UWzT301dECwKIKhYa3s3/ZV4Z2xs3b9diRyx2gh6FM=; b=OuskSs1hbI8LGi4Whbnp4p7L+EJHmTFdt6lc34fCGSNeVjUpjkQqHxkd1DgxOwBDcP 7T8ih0RhFTcR4d1jzmhtC+gGqoPMY6gWCObQtVhBgP1zd2ENx2mJ5idpreq5nNkRkPo9 3HD84TaExJLZj6hLdRvo4P5Tbw6uRp7YIXbQk= MIME-Version: 1.0 Received: by 10.205.134.139 with SMTP id ic11mr1158933bkc.114.1325784886642; Thu, 05 Jan 2012 09:34:46 -0800 (PST) Received: by 10.205.115.4 with HTTP; Thu, 5 Jan 2012 09:34:46 -0800 (PST) In-Reply-To: References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> <1325708915902-5120743.post@n5.nabble.com> Date: Thu, 5 Jan 2012 11:34:46 -0600 Message-ID: From: "Edwin L. Culp W." To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:34:49 -0000 On Thu, Jan 5, 2012 at 10:47 AM, Tom Evans wrote= : > On Thu, Jan 5, 2012 at 12:58 AM, Edwin L. Culp W. = wrote: >> I really appreciate your help but I am having a hard time >> understanding because this has been working perfectly on FreeBSD 9.0 >> since new. ( 4 months ago ) >> >> Just incase it is important. >> >> # uname -a >> =A0FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed >> Jan =A04 05:03:08 CST 2012 >> root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO =A0amd64 >> >> My rc.conf has >> >> keymap=3D"spanish.iso.acc.kbd" > > Are you sure this is right? My rc.conf has: > > keymap=3D"uk.iso" > > ie, no '.kbd' file ending, which is implied. > >> >> I have no /etc/X11 configuration file and haven't ever needed one. >> The mouse has never had a problem until I reset the server this >> morning. >> > > Mouse? I thought you were talking about keyboard! > > To get the correct keymap in X from hal, you need to add a policy > file, exactly as described in the handbook. Possibly you didn't have > hal enabled in earlier X builds, but if you want it to work with hal, > you need the policy file. > > Cheers > > Tom Thanks Jakub and Tom, Try to answer both together. Hope it isn't confusing. First s/mouse/keyboard/g Before rebooting I ran portmaster -a and updated hald. I then rebooted and my problem begain. Using a standad black terminal works wonderfully. It just needs: keymap=3D"spanish.iso.acc.kbd" in rc.conf I've tried all the spanish maps to get the closest to my keyboard so the rc.conf seems correct. Before the reboot and hald upgrade, all was well. I haven't ever touched nor was I aware that a hal policy file existed. (Going to try killing hal first. It has always been a pain in the...... neck. Sounds like I need to disable hal and restart X and maybe all will be well again. Results. bsd terminal works great but X doesn't recognize the mouse. The problem is definitely hal. I hope it dies soon. Going to study hal a bit. Thanks, ed ed From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 18:20:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1311E106564A; Thu, 5 Jan 2012 18:20:00 +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 D9B898FC12; Thu, 5 Jan 2012 18:19:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q05IJwKB089471; Thu, 5 Jan 2012 13:19:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q05IJw1Y089470; Thu, 5 Jan 2012 18:19:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Jan 2012 18:19:58 GMT Message-Id: <201201051819.q05IJw1Y089470@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: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:20:00 -0000 TB --- 2012-01-05 15:20:59 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 15:20:59 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-05 15:20:59 - cleaning the object tree TB --- 2012-01-05 15:21:19 - cvsupping the source tree TB --- 2012-01-05 15:21:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-05 15:21:31 - building world TB --- 2012-01-05 15:21:31 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 15:21:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 15:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 15:21:31 - SRCCONF=/dev/null TB --- 2012-01-05 15:21:31 - TARGET=powerpc TB --- 2012-01-05 15:21:31 - TARGET_ARCH=powerpc64 TB --- 2012-01-05 15:21:31 - TZ=UTC TB --- 2012-01-05 15:21:31 - __MAKE_CONF=/dev/null TB --- 2012-01-05 15:21:31 - cd /src TB --- 2012-01-05 15:21:31 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 15:21:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jan 5 17:52:27 UTC 2012 TB --- 2012-01-05 17:52:27 - generating LINT kernel config TB --- 2012-01-05 17:52:27 - cd /src/sys/powerpc/conf TB --- 2012-01-05 17:52:27 - /usr/bin/make -B LINT TB --- 2012-01-05 17:52:27 - cd /src/sys/powerpc/conf TB --- 2012-01-05 17:52:27 - /usr/sbin/config -m LINT TB --- 2012-01-05 17:52:27 - building LINT kernel TB --- 2012-01-05 17:52:27 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 17:52:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 17:52:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 17:52:27 - SRCCONF=/dev/null TB --- 2012-01-05 17:52:27 - TARGET=powerpc TB --- 2012-01-05 17:52:27 - TARGET_ARCH=powerpc64 TB --- 2012-01-05 17:52:27 - TZ=UTC TB --- 2012-01-05 17:52:27 - __MAKE_CONF=/dev/null TB --- 2012-01-05 17:52:27 - cd /src TB --- 2012-01-05 17:52:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 5 17:52:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Jan 5 18:13:15 UTC 2012 TB --- 2012-01-05 18:13:15 - cd /src/sys/powerpc/conf TB --- 2012-01-05 18:13:15 - /usr/sbin/config -m GENERIC TB --- 2012-01-05 18:13:15 - skipping GENERIC kernel TB --- 2012-01-05 18:13:15 - cd /src/sys/powerpc/conf TB --- 2012-01-05 18:13:15 - /usr/sbin/config -m GENERIC64 TB --- 2012-01-05 18:13:15 - building GENERIC64 kernel TB --- 2012-01-05 18:13:15 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 18:13:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 18:13:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 18:13:15 - SRCCONF=/dev/null TB --- 2012-01-05 18:13:15 - TARGET=powerpc TB --- 2012-01-05 18:13:15 - TARGET_ARCH=powerpc64 TB --- 2012-01-05 18:13:15 - TZ=UTC TB --- 2012-01-05 18:13:15 - __MAKE_CONF=/dev/null TB --- 2012-01-05 18:13:15 - cd /src TB --- 2012-01-05 18:13:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Jan 5 18:13:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-05 18:19:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-05 18:19:58 - ERROR: failed to build GENERIC64 kernel TB --- 2012-01-05 18:19:58 - 8987.25 user 1518.38 system 10738.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 19:29:58 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AACF1065692; Thu, 5 Jan 2012 19:29:58 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 12ED68FC17; Thu, 5 Jan 2012 19:29:56 +0000 (UTC) Received: by web (Postfix, from userid 143) id B3C19DC261; Wed, 4 Jan 2012 22:16:54 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 5319EDC16B for ; Wed, 4 Jan 2012 22:16:52 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1E8511A6EA5; Wed, 4 Jan 2012 22:11:33 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E6A9210656DC; Wed, 4 Jan 2012 22:11:30 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) 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 C8F941065673; Wed, 4 Jan 2012 22:10:50 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFED8FC0A; Wed, 4 Jan 2012 22:10:50 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id DDC5F9DAF0; Wed, 4 Jan 2012 22:55:08 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id CjgLgB5Artu3; Wed, 4 Jan 2012 22:55:06 +0100 (CET) Received: from danger-mbp.local (adsl-dyn163.78-98-251.t-com.sk [78.98.251.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 4A7599DADE; Wed, 4 Jan 2012 22:55:06 +0100 (CET) Message-ID: <4F04CABE.1050301@FreeBSD.org> Date: Wed, 04 Jan 2012 22:55:10 +0100 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.25pre) Gecko/20111115 Lanikai/3.1.17pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Subject: REMAINDER: Call for FreeBSD Status Reports - 4Q/2011 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:29:58 -0000 Hello everybody, I'd like to remind you that only ca. 10 days have left to the status report submission deadline. Note that we have only received 4 entries so far. I guess most of the people's holidays have finished by now so I hope we will receive much more than that by January 15, 2012. Thanks in advance! PS: Happy New Year 2012! -------- Original Message -------- Subject: REMAINDER: Call for FreeBSD Status Reports - 4Q/2011 Date: Wed, 21 Dec 2011 12:20:01 +0100 From: Daniel Gerzo Organization: The FreeBSD Project To: , , Dear all, I would like to remind you that the next round of status reports covering the fourth quarter of 2011 are due on January 15th, 2012. As this initiative is very popular among our users, I would like to ask you to submit your status reports as sooner than later (holidays are quickly approaching), so that we can compile the report in a timely fashion. Do not hesitate and write a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome as well. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F00F10656D4; Thu, 5 Jan 2012 19:30:02 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 2C85E8FC34; Thu, 5 Jan 2012 19:30:00 +0000 (UTC) Received: by web (Postfix, from userid 143) id A5D45DC318; Thu, 5 Jan 2012 10:21:30 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 6FA85DC315 for ; Thu, 5 Jan 2012 10:21:28 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7025516334D; Thu, 5 Jan 2012 10:17:14 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C4D3510656B6; Thu, 5 Jan 2012 10:17:13 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 948BC1065673; Thu, 5 Jan 2012 10:17:05 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 579498FC14; Thu, 5 Jan 2012 10:17:05 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id AC6921C6439; Thu, 5 Jan 2012 18:01:12 +0800 (CST) Date: Thu, 5 Jan 2012 18:01:12 +0800 From: Denny Lin To: Matthew Tippett Message-ID: <20120105100112.GB47282@mail.hs.ntnu.edu.tw> References: <20120104223158.911B11065678@hub.freebsd.org> <20120104184910.0d604240@kan.dyndns.org> <4F04E626.5040406@phoronix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F04E626.5040406@phoronix.com> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Joe Holden , FreeBSD Stable Mailing List , Adrian Chadd , Michael Larabel , Current FreeBSD , Arnaud Lacombe Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:02 -0000 On Wed, Jan 04, 2012 at 03:52:06PM -0800, Matthew Tippett wrote: > Hmm... No sure what happened there again. What I sent (pulled from my > "Sent" folder... > === > > Thanks for the comment Arnaud. For comparative benchmarking on > Phoronix.com , Michael invariable leaves it in the > default configuration 'in the way the developers or vendor wanted it for > production'. This is by rule. A quick question: why is ZFS used in the benchmark? "Both operating systems were in their stock configuration aside from FreeBSD 9.0 using ZFS." UFS is the default on FreeBSD, not ZFS. FreeBSD was not left in the default configuration. -- Denny Lin _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39B321065732; Thu, 5 Jan 2012 19:30:04 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 21E2D8FC14; Thu, 5 Jan 2012 19:30:02 +0000 (UTC) Received: by web (Postfix, from userid 143) id C4F83DC13B; Sun, 1 Jan 2012 00:21:31 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 600D5DC106 for ; Sun, 1 Jan 2012 00:21:29 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A61A016129E; Sun, 1 Jan 2012 00:17:13 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B4E0510657D9; Sun, 1 Jan 2012 00:17:09 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48F11065670; Sun, 1 Jan 2012 00:16:56 +0000 (UTC) (envelope-from adrian.chadd@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 3C8C58FC0C; Sun, 1 Jan 2012 00:16:55 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so20229233vbb.13 for ; Sat, 31 Dec 2011 16:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3QOKk0brNpNymel4Xe5JPA9QKFC8RuMETf0B2pbfZiA=; b=p3DXrZVrzqEOHJ0R4FQkBpXK+6eirq1ieHO2ijwOR+NgjeAYGloDjOYUcXzen348bR nsSBg8YDsKXmNO8jZYl1/aojbq4xFoYO8K2PN7++l8CkbBUt36pOl0RrBafTGo8OsVWi 7cTazdbQ0n8QvYLDrbuj4jXSVCZLrE/DLTrSo= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr14674422vdf.117.1325377015498; Sat, 31 Dec 2011 16:16:55 -0800 (PST) Received: by 10.52.36.5 with HTTP; Sat, 31 Dec 2011 16:16:55 -0800 (PST) In-Reply-To: <863B2CE2-BB30-4E67-8CB7-9BBFACB9A20A@airwired.net> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> <863B2CE2-BB30-4E67-8CB7-9BBFACB9A20A@airwired.net> Date: Sat, 31 Dec 2011 16:16:55 -0800 X-Google-Sender-Auth: 4bQMlh-3KCih596kXtMnap9_PJA Message-ID: From: Adrian Chadd To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: List Mailing FreeBSD-STABLE , Garrett Cooper , mav@freebsd.org, freebsd-current@freebsd.org, Jeremy Chadwick Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:04 -0000 On 31 December 2011 16:08, Dan Allen wrote: > Almost every day I csup from RELENG_x and build. =A0The traces of RELENG_= 8 are gone, so no, unfortunately I cannot give you a uname -a from those da= ys. Would you consider having a small partition to do the same for HEAD? :P > However, I have a build log file, and I see that I moved from RELENG_8 to= RELENG_9 on Friday, Dec 23, 2011. =A0I csup'd at 12:24:26 MST and discover= ed the failure at 15:41 MST. > > This "nooptions NEW_PCIB" fix does seem rather tenuous if it is not docum= ented. =A0Wouldn't a better route be something like > > =A0if (ACPI < 2.0) > =A0 =A0oldCode(); > =A0else > =A0 =A0newCodeForNewACPI(); > > so that it will always work for everyone without having to build a specia= l kernel? =A0After all, I went from a working system to a hung system which= is not the best upgrade path... ;-) Well it's hard to test stuff out without the hardware. :) And it's quite possible a lot of silly looking issues are actually working around real bugs in the hardware. I'm glad this issue was solved so quickly for you. Let's hope we can get you onto testing out HEAD (in a separate partition!) so we can ensure we don't break the basic stuff. :) Adrian _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D952106576B; Thu, 5 Jan 2012 19:30:05 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id D2C258FC47; Thu, 5 Jan 2012 19:30:03 +0000 (UTC) Received: by web (Postfix, from userid 143) id 40727DC2CC; Wed, 4 Jan 2012 22:42:27 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id BB6B7DC276 for ; Wed, 4 Jan 2012 22:42:24 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id CF65920568B; Wed, 4 Jan 2012 22:35:38 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 08BAC1065748; Wed, 4 Jan 2012 22:35:38 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75EE106566C; Wed, 4 Jan 2012 21:58:30 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCC328FC0C; Wed, 4 Jan 2012 21:58:29 +0000 (UTC) Received: by werb13 with SMTP id b13so15664963wer.13 for ; Wed, 04 Jan 2012 13:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6XEMeBte3msHnx3roQDC91QmbOtPNieE6mOxFDdWWoY=; b=u7K0sXTxjsX9ufdSpSwmxwnfC3tIap1qhVMswDIwcOrNjxdij2yGdZlOuHFKYdCXYO m5ETSJcKwAd/jkg20Dcg8dk/gi/5Ro/ve57Lkl43lmnnEph+MZYljPgqTMvFIe87yIj8 lGUEw5j2CzDBgeKgQBmR7V3PBJabBBYw8LsSE= MIME-Version: 1.0 Received: by 10.216.131.90 with SMTP id l68mr37657293wei.36.1325714308629; Wed, 04 Jan 2012 13:58:28 -0800 (PST) Received: by 10.216.178.204 with HTTP; Wed, 4 Jan 2012 13:58:28 -0800 (PST) In-Reply-To: <4eeb7cf9.43bfec0a.3e38.ffff9d19SMTPIN_ADDED@mx.google.com> References: <4eeb7cf9.43bfec0a.3e38.ffff9d19SMTPIN_ADDED@mx.google.com> Date: Wed, 4 Jan 2012 16:58:28 -0500 Message-ID: From: Arnaud Lacombe To: matthew@phoronix.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Jan 2012 22:35:35 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Adrian Chadd , FreeBSD Stable Mailing List , Joe Holden , Michael Larabel , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:05 -0000 Hi, On Fri, Dec 16, 2011 at 12:16 PM, wrote: > Thanks. > > My request for the person documenting the tunings also runs the benchmark= to > ensure expected behaviour. > Why should you have to tune anything ? Did you tune the Oracle Server install ? If not, you should not have to tune the FreeBSD install, that wouldn't be fair. If you tune FreeBSD, you should tune the Oracle Server install too. It is pretty easy to win at least 30% in performance for certain workload by choosing the right kernel configuration. - Arnaud > The installation, execution and comparison against the benchmarks in the > article is fairly simple. > > Note that some tuning may not be relevant or recommended (ie: some of the= fs > benchmarks are sensitive to barriers and other synchronous operations). = =A0I'd > recommend bowing out of a benchmark with a 'we're going to be slower sinc= e > the default configuration is this way for the following reason' if this i= s > the case. > > Thanks 'someone'. > > Matthew > > > =A0Dec 16, 2011 8:46 AM, Adrian Chadd wrote: > > Can someone please write up a nice, concise blog post somewhere > outlining all of this? > > Extra bonus points if it's a blog that is picked up by > blogs.freebsdish.org and/or some of the other BSD sites. > > Guys/girls/fuzzy things - this is 2011; people look at shiny blog > sites with graphs rather than mailing lists. Sorry, we lost that > battle. :) > > > > Adrian > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@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-current@FreeBSD.ORG Thu Jan 5 19:30:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56DA91065791; Thu, 5 Jan 2012 19:30:05 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 17C7E8FC12; Thu, 5 Jan 2012 19:30:03 +0000 (UTC) Received: by web (Postfix, from userid 143) id 48099DC181; Thu, 5 Jan 2012 00:20:53 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id B9B71DC17B for ; Thu, 5 Jan 2012 00:20:50 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 314E82000AD; Thu, 5 Jan 2012 00:15:47 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5035110656B2; Thu, 5 Jan 2012 00:15:46 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0071D106564A; Thu, 5 Jan 2012 00:15:37 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 947FE8FC17; Thu, 5 Jan 2012 00:15:36 +0000 (UTC) Received: by qcse13 with SMTP id e13so15492725qcs.13 for ; Wed, 04 Jan 2012 16:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=beDoKEUIk0zBuBQW+rbWGI8gjx7JujE5SihTXoewDKE=; b=eKFG+FcpGlE/JOUMCX8Ly87VJO19/uDVi7GcM4vTY5tpaF+Lme1WLgMqJUSqDPUrAB Y2X4k/9kzyZXmJojc7MP/k7mRJTbwCgilBW8m93GWT+sVfpO6k7vBh8XgpEZFxADZ9t2 v5oNDYEcL9r/g6xunxrs8jvL78Nia/xeyHvHc= Received: by 10.229.135.149 with SMTP id n21mr21720325qct.53.1325720956731; Wed, 04 Jan 2012 15:49:16 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id h6sm28236244qap.2.2012.01.04.15.49.15 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 15:49:16 -0800 (PST) Date: Wed, 4 Jan 2012 18:49:10 -0500 From: Alexander Kabaev To: Message-ID: <20120104184910.0d604240@kan.dyndns.org> In-Reply-To: <20120104223158.911B11065678@hub.freebsd.org> References: <20120104223158.911B11065678@hub.freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/E950_Ap3Vq1E8qCyz2buUn_"; protocol="application/pgp-signature" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Adrian Chadd , FreeBSD Stable Mailing List , Joe Holden , Larabel , Michael@FreeBSD.ORG, Current FreeBSD , Arnaud Lacombe Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:05 -0000 --Sig_/E950_Ap3Vq1E8qCyz2buUn_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 04 Jan 2012 14:31:55 -0800 wrote: > Thanks for the comment Arnaud. For comparative benchmarking > on [1]Phoronix.com, Michael inva configuration 'in the way the > developers or production'. This is by rule. However, i poor > scores on be 'it should be tuned, is configured for a diffe The > response from us to this comes in two forms. &nb 1) If it is the > wrong workload for the platform, do a public pos explaining and > analysing the results. Highlighting the rationale fo r the > concious reduction in performance (ie: journaling filesystems with > ba filesystem integrity 2) If tuning can have a material impact > on the results, post a t uning guide with step by step and > rationale. Ie: educate the communit Michael and I have had many > discussions with vendors an on this. In almost all cases, the > vendor has either cha default configuration or accepted the results > as valid. As guide, Micha comparison. To dat offer. In part, > thi public, but that is more of a result of a one sided d party > external to a particular community (with a healthy tou > journalisticly pumped compare & contrast). For the FreeBSD > community, who else outside of the FreeBSD community actually runs > public c Matthew Not really related to the discussion on hand, but the above about the most unreadable email I am yet to read on the public mailing list. --=20 Alexander Kabaev --Sig_/E950_Ap3Vq1E8qCyz2buUn_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPBOV6Q6z1jMm+XZYRAn7AAKDDqfIxM5+mvV3YaP5WyZ7e0ed09QCgzKBU P1N6ba6nwNiQNjP2lDWmJQI= =05rk -----END PGP SIGNATURE----- --Sig_/E950_Ap3Vq1E8qCyz2buUn_-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 19:30:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89FA91065805; Thu, 5 Jan 2012 19:30:06 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 80BA98FC1D; Thu, 5 Jan 2012 19:30:05 +0000 (UTC) Received: by web (Postfix, from userid 143) id 54CB0DC16A; Sun, 1 Jan 2012 02:19:23 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 99942DC111 for ; Sun, 1 Jan 2012 02:19:20 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 19330156AE7; Sun, 1 Jan 2012 02:15:14 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7DAA910656B4; Sun, 1 Jan 2012 02:15:13 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05A63106564A; Sun, 1 Jan 2012 02:14:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 92DE98FC08; Sun, 1 Jan 2012 02:14:55 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so16740778obb.13 for ; Sat, 31 Dec 2011 18:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IEeRanD2MGuEvI+KGPD7qvMu/rPyzdC0K6GRhRstuhg=; b=j3AedlJgs+t5HwPPu/cDrfe2MYnVpewvqqrxmrHU+lIG9YsVsbN/vpAJm90yBxFcjo Wls2HwoWD0VsAMLCwQga1+2TNxoPi8roSWgXTufIxU8uichuMDcqNCDwFEqbJOPyZ+/7 PhC/s2/+VITE0q0oTZY1pF2Sasak/M46B5AKI= MIME-Version: 1.0 Received: by 10.182.51.37 with SMTP id h5mr37900029obo.51.1325384094922; Sat, 31 Dec 2011 18:14:54 -0800 (PST) Received: by 10.182.152.6 with HTTP; Sat, 31 Dec 2011 18:14:54 -0800 (PST) In-Reply-To: <20111231233152.GA54245@icarus.home.lan> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> Date: Sat, 31 Dec 2011 18:14:54 -0800 Message-ID: From: Garrett Cooper To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Dan Allen , freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE , mav@freebsd.org Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:06 -0000 On Sat, Dec 31, 2011 at 3:31 PM, Jeremy Chadwick wrote: > On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote: >> On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: >> >> > Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and >> > try booting the new kernel. See if this works. >> >> It worked! =A0No hang, power button works. =A0Nice. =A0I hope this exper= imental option stays in. >> >> Thank you everyone for your help. =A0Happy New Years! > > This option isn't documented **anywhere** in the entire src tree. =A0It's > purely #ifdef all over. > > The code in question was committed 7 months ago. =A0It was MFC'd to > RELENG_8 6 months ago. =A0Here's the HEAD commit message: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420 > > The RELENG_8 MFC is revision 1.386.2.15. > > The committer is jhb@, with mav@ being the individual who tested it, so > I imagine either of these folks will have some excellent insights as to > what's causing Dan's problem. =A0I'm CC'ing them both directly on this > thread. > > In the meantime: Dan, when you say in your original mail, "I just > upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you > please provide uname -a output from the system when it was running > RELENG_8? =A0I'm looking specifically for the exact time when the kernel > was built, because there may have been fixes (that broke things for you) > between the above commit and present-day RELENG_8 (I have not examined > all commits). It's going to be the feature that's going to cause headaches post-9.0-RELEASE based on my observations of several mailing list posts and the fact that 9.0 isn't actually RELEASEd yet (people have run into issues with acpi, atkbdc, mfi, and usb so far, but that's probably not everything). If it could be made into a runtime tunable, that would be awesome, but that would require changes to driver structures and methods. With a little pointer aliasing and tunable guard sprinkling it wouldn't be hard to solve -- but it's still work. In the meantime, could someone please commit PR # 163748 to note what NEW_PCIB is and MFC it to RELENG_9 and could we consider disabling NEW_PCIB on i386 and pc98 until all the issues are ironed out? Thanks, -Garrett _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B540210657DF; Thu, 5 Jan 2012 19:30:09 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id DEB788FC2F; Thu, 5 Jan 2012 19:30:08 +0000 (UTC) Received: by web (Postfix, from userid 143) id 76963DC210; Sun, 1 Jan 2012 14:01:38 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id C5DCBDC1B3 for ; Sun, 1 Jan 2012 14:01:36 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1383F1A6140; Sun, 1 Jan 2012 13:56:00 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 03B2E10657E8; Sun, 1 Jan 2012 13:55:53 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D20A106566C; Sun, 1 Jan 2012 13:55:40 +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 C656B8FC13; Sun, 1 Jan 2012 13:55:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6045046B09; Sun, 1 Jan 2012 08:55:39 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CA395B91E; Sun, 1 Jan 2012 08:55:38 -0500 (EST) Message-ID: <4F0065E1.8000808@FreeBSD.org> Date: Sun, 01 Jan 2012 08:55:45 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Garrett Cooper References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sun, 01 Jan 2012 08:55:39 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Dan Allen , freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE , mav@freebsd.org, Jeremy Chadwick Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:09 -0000 On 12/31/11 9:14 PM, Garrett Cooper wrote: > On Sat, Dec 31, 2011 at 3:31 PM, Jeremy Chadwick > wrote: >> On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote: >>> On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: >>> >>>> Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and >>>> try booting the new kernel. See if this works. >>> >>> It worked! No hang, power button works. Nice. I hope this experimental option stays in. >>> >>> Thank you everyone for your help. Happy New Years! >> >> This option isn't documented **anywhere** in the entire src tree. It's >> purely #ifdef all over. >> >> The code in question was committed 7 months ago. It was MFC'd to >> RELENG_8 6 months ago. Here's the HEAD commit message: >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420 >> >> The RELENG_8 MFC is revision 1.386.2.15. >> >> The committer is jhb@, with mav@ being the individual who tested it, so >> I imagine either of these folks will have some excellent insights as to >> what's causing Dan's problem. I'm CC'ing them both directly on this >> thread. >> >> In the meantime: Dan, when you say in your original mail, "I just >> upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you >> please provide uname -a output from the system when it was running >> RELENG_8? I'm looking specifically for the exact time when the kernel >> was built, because there may have been fixes (that broke things for you) >> between the above commit and present-day RELENG_8 (I have not examined >> all commits). > > It's going to be the feature that's going to cause headaches > post-9.0-RELEASE based on my observations of several mailing list > posts and the fact that 9.0 isn't actually RELEASEd yet (people have > run into issues with acpi, atkbdc, mfi, and usb so far, but that's > probably not everything). > If it could be made into a runtime tunable, that would be awesome, > but that would require changes to driver structures and methods. With > a little pointer aliasing and tunable guard sprinkling it wouldn't be > hard to solve -- but it's still work. Eh, almost all the problems are not with the PCI-PCI bridge bits, but with the later changes to the ACPI Host-PCI bridge driver, and that is changeable via a tunable. (debug.acpi.disabled="hostres") All of the problems in this case are due to the BIOS providing incomplete or flat-out erroneous information in the ACPI tables about which resource ranges each Host-PCI bridge decodes. Also, there is supposed to be language in the 9.0 errata mentioning this tunable. I had suggested to re@ that we disable it for 9.0 by default, but instead they decided to document it instead since I made the suggestion fairly late in the process (even though at this point that was more like a month ago). Finally, I made a commit this week to HEAD that probably "fixes" most of the issues with BIOSes lying about their Host-PCI bridges (the problem is the BIOS says two different things in two different places when it programs a BAR or other resource that it then claims the parent bridge doesn't handle). The commit specifically fixed a Dell Optiplex GX620, so I imagine it will fix a GX270 just as well (revision 228961). The ACPI bits are not a simple matter of "only use it for ACPI 2.0" to reference an earlier e-mail in this thread. The boxes in question almost certainly have ACPI 3.0 or later BIOSes at this point (remember ACPI 1.0 came out in the 1999/2000 timeframe). The PCI-PCI bridge changes are also not specific to only newer versions of PCI, they go back to the rev 1.1 of the PCI-PCI bridge specification and are fixing deficiencies in our handling of the I/O resource windows in bridges. Together the changes in NEW_PCIB are the last remaining bits to make it possible to use "PNP OS" set to yes for PCI devices. Granted, at this point most BIOSes no longer have that option and just always set it to no, but it is important infrastructure to have in place for hotplug PCI (and cardbus (9 should no longer need the hw.cbb.start_memory tunable hacks on various laptops due to NEW_PCIB), etc.). -- John Baldwin _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23D761065694; Thu, 5 Jan 2012 19:30:01 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 5CA0F8FC12; Thu, 5 Jan 2012 19:30:00 +0000 (UTC) Received: by web (Postfix, from userid 143) id 0F49CDC1D5; Sat, 31 Dec 2011 23:22:18 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id CA8EBDC17B for ; Sat, 31 Dec 2011 23:22:16 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0ADBD201512; Sat, 31 Dec 2011 23:18:01 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 42C7110656B1; Sat, 31 Dec 2011 23:18:01 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0C51065675 for ; Sat, 31 Dec 2011 23:17:47 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 2990D8FC12 for ; Sat, 31 Dec 2011 23:17:47 +0000 (UTC) Received: (qmail 13523 invoked by uid 89); 31 Dec 2011 23:20:15 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 31 Dec 2011 23:20:15 -0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Dan Allen In-Reply-To: Date: Sat, 31 Dec 2011 16:17:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04292366-1297-488F-9239-98565828DDC8@airwired.net> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> To: Garrett Cooper X-Mailer: Apple Mail (2.1251.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-Mailman-Approved-At: Thu, 05 Jan 2012 19:35:18 +0000 Cc: freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE , Jeremy Chadwick Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:01 -0000 On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote: > Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and > try booting the new kernel. See if this works. It worked! No hang, power button works. Nice. I hope this = experimental option stays in. Thank you everyone for your help. Happy New Years! Dan _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E75310656B0; Thu, 5 Jan 2012 19:30:03 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id D42EC8FC3D; Thu, 5 Jan 2012 19:30:01 +0000 (UTC) Received: by web (Postfix, from userid 143) id AE12EDC213; Wed, 4 Jan 2012 23:19:08 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 1EBFFDC1F7 for ; Wed, 4 Jan 2012 23:19:06 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BA290157997; Wed, 4 Jan 2012 23:14:14 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 588D21065740; Wed, 4 Jan 2012 23:14:12 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911B11065678; Wed, 4 Jan 2012 22:31:58 +0000 (UTC) (envelope-from matthew@phoronix.com) Received: from phx1.phoronix.com (173.192.77.202-static.reverse.softlayer.com [173.192.77.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF0C8FC14; Wed, 4 Jan 2012 22:31:58 +0000 (UTC) Received: from mobile-166-205-136-164.mycingular.net ([166.205.136.164] helo=www.palm.com) by phx1.phoronix.com with esmtpa (Exim 4.69) (envelope-from ) id 1RiZNC-0007LN-Oy; Wed, 04 Jan 2012 16:31:56 -0600 Date: Wed, 04 Jan 2012 14:31:55 -0800 From: To: "Arnaud Lacombe" In-Reply-To: X-Mailer: Palm webOS X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - phx1.phoronix.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - phoronix.com Message-Id: <20120104223158.911B11065678@hub.freebsd.org> X-Mailman-Approved-At: Wed, 04 Jan 2012 23:14:09 +0000 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-Mailman-Approved-At: Thu, 05 Jan 2012 20:01:51 +0000 Cc: Adrian Chadd , FreeBSD Stable Mailing List , Joe Holden , Michael Larabel , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:04 -0000 Thanks for the comment Arnaud. For comparative benchmarking on = [1]Phoronix.com, Michael inva= riable leaves it in the default configuration 'in the way the developers or= vendor wanted it for production'. This is by rule. However, i= nvariable the community or vendor for platforms that post poor scores on be= nchmark cry foul about using the default config. 'it should be tuned,= no-one deploys an untuned system' or 'the system is configured for a diffe= rent workload'. The response from us to this comes in two forms. &nb= sp; 1) If it is the wrong workload for the platform, do a public pos= t explaining and analysing the results. Highlighting the rationale fo= r the concious reduction in performance (ie: journaling filesystems with ba= rriers suffer in some write benchmarks for the sake of filesystem integrity= =2E 2) If tuning can have a material impact on the results, post a t= uning guide with step by step and rationale. Ie: educate the communit= y and users. Michael and I have had many discussions with vendors an= d communities on this. In almost all cases, the vendor has either cha= nged the default configuration or accepted the results as valid. As = a service to the community or vendor that publishes the tuning guide, Micha= el is more than willing to redo a tuned vs untuned comparison. To dat= e, the communities have never taken us up on that offer. In part, thi= s affects [2]Phoronix.com's perception in the public, but that is more of a result of a one sided d= iscussion by a party external to a particular community (with a healthy tou= ch of journalisticly pumped compare & contrast). For the FreeBSD = community, who else outside of the FreeBSD community actually runs public c= omparisons of FreeBSD against anything? Matthew -- Sent from my HP Pre3 _________________________________________________________________ On Jan 4, 2012 1:58 PM, Arnaud Lacombe wrote:=0D > Thanks.=0D >=0D &= gt; My request for the person documenting the tunings also runs the benchma= rk to=0D > ensure expected behaviour.=0D >=0D Why should you= have to tune anything ? Did you tune the Oracle Server=0D install ? If = not, you should not have to tune the FreeBSD install,=0D that wouldn't b= e fair. If you tune FreeBSD, you should tune the Oracle=0D Server instal= l too. It is pretty easy to win at least 30% in=0D performance for certa= in workload by choosing the right kernel=0D configuration.=0D =0D = - Arnaud=0D =0D > The installation, execution and comparison agai= nst the benchmarks in the=0D > article is fairly simple.=0D >= =0D > Note that some tuning may not be relevant or recommended (ie: s= ome of the fs=0D > benchmarks are sensitive to barriers and other syn= chronous operations). =C2=A0I'd=0D > recommend bowing out of a benchm= ark with a 'we're going to be slower since=0D > the default configura= tion is this way for the following reason' if this is=0D > the case.= =0D >=0D > Thanks 'someone'.=0D >=0D > Matthew=0D>=0D >=0D > =C2=A0Dec 16, 2011 8:46 AM, Adrian Chadd wrote:=0D >=0D > Can someone please write= up a nice, concise blog post somewhere=0D > outlining all of this?= =0D >=0D > Extra bonus points if it's a blog that is picked up = by=0D > blogs.freebsdish.org and/or some of the other BSD sites.=0D>=0D > Guys/girls/fuzzy things - this is 2011; people look at sh= iny blog=0D > sites with graphs rather than mailing lists. Sorry, we = lost that=0D > battle. :)=0D >=0D >=0D >=0D >= Adrian=0D > _______________________________________________=0D &g= t; freebsd-performance@freebsd.org mailing list=0D > http://lists.fre= ebsd.org/mailman/listinfo/freebsd-performance=0D > To unsubscribe, se= nd any mail to=0D > "freebsd-performance-unsubscribe@freebsd.org"=0D<= br> References 1. 3D"http://Phoronix.com"/ 2. 3D"http://Phoronix.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-current@FreeBSD.ORG Thu Jan 5 19:30:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 547F7106578F; Thu, 5 Jan 2012 19:30:05 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 09DC58FC49; Thu, 5 Jan 2012 19:30:03 +0000 (UTC) Received: by web (Postfix, from userid 143) id 4609FDC17A; Sun, 1 Jan 2012 00:12:27 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id B9BE1DC106 for ; Sun, 1 Jan 2012 00:12:24 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 97464160ED6; Sun, 1 Jan 2012 00:08:26 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5D5DE10656B4; Sun, 1 Jan 2012 00:08:25 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5221065677 for ; Sun, 1 Jan 2012 00:08:12 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id BB90B8FC14 for ; Sun, 1 Jan 2012 00:08:11 +0000 (UTC) Received: (qmail 29807 invoked by uid 89); 1 Jan 2012 00:10:40 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 1 Jan 2012 00:10:40 -0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <20111231233152.GA54245@icarus.home.lan> Date: Sat, 31 Dec 2011 17:08:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <863B2CE2-BB30-4E67-8CB7-9BBFACB9A20A@airwired.net> References: <038588ED-E0E0-46F6-8E28-1926FBE28825@airwired.net> <70F3E6A6-762E-4C4F-B517-C386304DF85F@airwired.net> <8DF650FE-CE0D-4DA4-901C-B19269464F9C@airwired.net> <04292366-1297-488F-9239-98565828DDC8@airwired.net> <20111231233152.GA54245@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1251.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-Mailman-Approved-At: Thu, 05 Jan 2012 20:02:14 +0000 Cc: Garrett Cooper , mav@freebsd.org, freebsd-current@freebsd.org, List Mailing FreeBSD-STABLE Subject: Re: ACPI broke going from 8 to 9 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:05 -0000 On 31 Dec 2011, at 4:31 PM, Jeremy Chadwick wrote: > In the meantime: Dan, when you say in your original mail, "I just > upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you > please provide uname -a output from the system when it was running > RELENG_8? I'm looking specifically for the exact time when the kernel > was built Almost every day I csup from RELENG_x and build. The traces of RELENG_8 = are gone, so no, unfortunately I cannot give you a uname -a from those = days. However, I have a build log file, and I see that I moved from RELENG_8 = to RELENG_9 on Friday, Dec 23, 2011. I csup'd at 12:24:26 MST and = discovered the failure at 15:41 MST. This "nooptions NEW_PCIB" fix does seem rather tenuous if it is not = documented. Wouldn't a better route be something like if (ACPI < 2.0) oldCode(); else newCodeForNewACPI(); so that it will always work for everyone without having to build a = special kernel? After all, I went from a working system to a hung = system which is not the best upgrade path... ;-) Dan _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 19:30:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77EB710656A9; Thu, 5 Jan 2012 19:30:07 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 469058FC13; Thu, 5 Jan 2012 19:30:06 +0000 (UTC) Received: by web (Postfix, from userid 143) id D5C5DDC184; Thu, 5 Jan 2012 00:22:59 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 71E85DC180 for ; Thu, 5 Jan 2012 00:22:59 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A3E2D1A7607; Thu, 5 Jan 2012 00:16:32 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A250A1065723; Thu, 5 Jan 2012 00:16:31 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A87106566C; Thu, 5 Jan 2012 00:09:01 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB448FC1C; Thu, 5 Jan 2012 00:09:01 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so21226709obb.13 for ; Wed, 04 Jan 2012 16:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XbdItQKYiYomCveqZYxYJ+LUwLQyfgERPDjPndldPFk=; b=cELNsjMMEMFMmHw6np5h5sHVkIfqFFkE20+dUbkkCnnX/oJzZ901KT3nE+phbwargC 5my6IDplur3bPgiqW8xs5gy8zxHHYeTXte31U4LcXSGTeQIFTVKWfGBJHAbifNSS1/hW yZ+th9THjZv11CzWZwitcMJuHLWsrGoRYBPDc= MIME-Version: 1.0 Received: by 10.182.159.70 with SMTP id xa6mr49957557obb.1.1325722140669; Wed, 04 Jan 2012 16:09:00 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 4 Jan 2012 16:08:59 -0800 (PST) In-Reply-To: References: <4eeb7cf9.43bfec0a.3e38.ffff9d19SMTPIN_ADDED@mx.google.com> Date: Wed, 4 Jan 2012 16:08:59 -0800 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 05 Jan 2012 00:16:29 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-Mailman-Approved-At: Thu, 05 Jan 2012 20:02:59 +0000 Cc: Adrian Chadd , FreeBSD Stable Mailing List , matthew@phoronix.com, Joe Holden , Michael Larabel , Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" , Jeremy Chadwick Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:30:07 -0000 On Wed, Jan 4, 2012 at 1:58 PM, Arnaud Lacombe wrote: > Hi, > > On Fri, Dec 16, 2011 at 12:16 PM, =A0 wrote: >> Thanks. >> >> My request for the person documenting the tunings also runs the benchmar= k to >> ensure expected behaviour. >> > Why should you have to tune anything ? Did you tune the Oracle Server > install ? If not, you should not have to tune the FreeBSD install, > that wouldn't be fair. If you tune FreeBSD, you should tune the Oracle > Server install too. It is pretty easy to win at least 30% in > performance for certain workload by choosing the right kernel > configuration. This assumes that Oracle doesn't do secret sauce tuning... the Vanilla CentOS/RHEL base is probably a better comparison than the Oracle custom distro. Thanks! -Garrett _______________________________________________ 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-current@FreeBSD.ORG Thu Jan 5 20:03:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7097F106564A; Thu, 5 Jan 2012 20:03:07 +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 224C18FC0A; Thu, 5 Jan 2012 20:03:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q05K36SX046351; Thu, 5 Jan 2012 15:03:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q05K366e046325; Thu, 5 Jan 2012 20:03:06 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Jan 2012 20:03:06 GMT Message-Id: <201201052003.q05K366e046325@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: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:03:07 -0000 TB --- 2012-01-05 18:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 18:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-01-05 18:20:00 - cleaning the object tree TB --- 2012-01-05 18:20:29 - cvsupping the source tree TB --- 2012-01-05 18:20:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-01-05 18:20:47 - building world TB --- 2012-01-05 18:20:47 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 18:20:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 18:20:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 18:20:47 - SRCCONF=/dev/null TB --- 2012-01-05 18:20:47 - TARGET=arm TB --- 2012-01-05 18:20:47 - TARGET_ARCH=arm TB --- 2012-01-05 18:20:47 - TZ=UTC TB --- 2012-01-05 18:20:47 - __MAKE_CONF=/dev/null TB --- 2012-01-05 18:20:47 - cd /src TB --- 2012-01-05 18:20:47 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 18:20:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 5 19:17:33 UTC 2012 TB --- 2012-01-05 19:17:34 - cd /src/sys/arm/conf TB --- 2012-01-05 19:17:34 - /usr/sbin/config -m AVILA TB --- 2012-01-05 19:17:34 - building AVILA kernel TB --- 2012-01-05 19:17:34 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:17:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:17:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:17:34 - SRCCONF=/dev/null TB --- 2012-01-05 19:17:34 - TARGET=arm TB --- 2012-01-05 19:17:34 - TARGET_ARCH=arm TB --- 2012-01-05 19:17:34 - TZ=UTC TB --- 2012-01-05 19:17:34 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:17:34 - cd /src TB --- 2012-01-05 19:17:34 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Jan 5 19:17:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Thu Jan 5 19:20:36 UTC 2012 TB --- 2012-01-05 19:20:36 - cd /src/sys/arm/conf TB --- 2012-01-05 19:20:36 - /usr/sbin/config -m BWCT TB --- 2012-01-05 19:20:38 - building BWCT kernel TB --- 2012-01-05 19:20:38 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:20:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:20:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:20:38 - SRCCONF=/dev/null TB --- 2012-01-05 19:20:38 - TARGET=arm TB --- 2012-01-05 19:20:38 - TARGET_ARCH=arm TB --- 2012-01-05 19:20:38 - TZ=UTC TB --- 2012-01-05 19:20:38 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:20:38 - cd /src TB --- 2012-01-05 19:20:38 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Jan 5 19:20:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Thu Jan 5 19:23:16 UTC 2012 TB --- 2012-01-05 19:23:16 - cd /src/sys/arm/conf TB --- 2012-01-05 19:23:16 - /usr/sbin/config -m CAMBRIA TB --- 2012-01-05 19:23:16 - building CAMBRIA kernel TB --- 2012-01-05 19:23:16 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:23:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:23:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:23:16 - SRCCONF=/dev/null TB --- 2012-01-05 19:23:16 - TARGET=arm TB --- 2012-01-05 19:23:16 - TARGET_ARCH=arm TB --- 2012-01-05 19:23:16 - TZ=UTC TB --- 2012-01-05 19:23:16 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:23:16 - cd /src TB --- 2012-01-05 19:23:16 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Jan 5 19:23:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Thu Jan 5 19:26:15 UTC 2012 TB --- 2012-01-05 19:26:15 - cd /src/sys/arm/conf TB --- 2012-01-05 19:26:15 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-01-05 19:26:15 - building CNS11XXNAS kernel TB --- 2012-01-05 19:26:15 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:26:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:26:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:26:15 - SRCCONF=/dev/null TB --- 2012-01-05 19:26:15 - TARGET=arm TB --- 2012-01-05 19:26:15 - TARGET_ARCH=arm TB --- 2012-01-05 19:26:15 - TZ=UTC TB --- 2012-01-05 19:26:15 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:26:15 - cd /src TB --- 2012-01-05 19:26:15 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Jan 5 19:26:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Thu Jan 5 19:28:48 UTC 2012 TB --- 2012-01-05 19:28:48 - cd /src/sys/arm/conf TB --- 2012-01-05 19:28:48 - /usr/sbin/config -m CRB TB --- 2012-01-05 19:28:48 - building CRB kernel TB --- 2012-01-05 19:28:48 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:28:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:28:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:28:48 - SRCCONF=/dev/null TB --- 2012-01-05 19:28:48 - TARGET=arm TB --- 2012-01-05 19:28:48 - TARGET_ARCH=arm TB --- 2012-01-05 19:28:48 - TZ=UTC TB --- 2012-01-05 19:28:48 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:28:48 - cd /src TB --- 2012-01-05 19:28:48 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Jan 5 19:28:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Thu Jan 5 19:32:39 UTC 2012 TB --- 2012-01-05 19:32:39 - cd /src/sys/arm/conf TB --- 2012-01-05 19:32:39 - /usr/sbin/config -m DB-78XXX TB --- 2012-01-05 19:32:40 - building DB-78XXX kernel TB --- 2012-01-05 19:32:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:32:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:32:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:32:40 - SRCCONF=/dev/null TB --- 2012-01-05 19:32:40 - TARGET=arm TB --- 2012-01-05 19:32:40 - TARGET_ARCH=arm TB --- 2012-01-05 19:32:40 - TZ=UTC TB --- 2012-01-05 19:32:40 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:32:40 - cd /src TB --- 2012-01-05 19:32:40 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Jan 5 19:32:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Thu Jan 5 19:35:22 UTC 2012 TB --- 2012-01-05 19:35:22 - cd /src/sys/arm/conf TB --- 2012-01-05 19:35:22 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-01-05 19:35:22 - building DB-88F5XXX kernel TB --- 2012-01-05 19:35:22 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:35:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:35:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:35:22 - SRCCONF=/dev/null TB --- 2012-01-05 19:35:22 - TARGET=arm TB --- 2012-01-05 19:35:22 - TARGET_ARCH=arm TB --- 2012-01-05 19:35:22 - TZ=UTC TB --- 2012-01-05 19:35:22 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:35:22 - cd /src TB --- 2012-01-05 19:35:22 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Jan 5 19:35:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Thu Jan 5 19:38:03 UTC 2012 TB --- 2012-01-05 19:38:03 - cd /src/sys/arm/conf TB --- 2012-01-05 19:38:03 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-01-05 19:38:03 - building DB-88F6XXX kernel TB --- 2012-01-05 19:38:03 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:38:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:38:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:38:03 - SRCCONF=/dev/null TB --- 2012-01-05 19:38:03 - TARGET=arm TB --- 2012-01-05 19:38:03 - TARGET_ARCH=arm TB --- 2012-01-05 19:38:03 - TZ=UTC TB --- 2012-01-05 19:38:03 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:38:03 - cd /src TB --- 2012-01-05 19:38:03 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Jan 5 19:38:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Thu Jan 5 19:41:17 UTC 2012 TB --- 2012-01-05 19:41:17 - cd /src/sys/arm/conf TB --- 2012-01-05 19:41:17 - /usr/sbin/config -m DOCKSTAR TB --- 2012-01-05 19:41:17 - building DOCKSTAR kernel TB --- 2012-01-05 19:41:17 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:41:17 - SRCCONF=/dev/null TB --- 2012-01-05 19:41:17 - TARGET=arm TB --- 2012-01-05 19:41:17 - TARGET_ARCH=arm TB --- 2012-01-05 19:41:17 - TZ=UTC TB --- 2012-01-05 19:41:17 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:41:17 - cd /src TB --- 2012-01-05 19:41:17 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Jan 5 19:41:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Thu Jan 5 19:43:55 UTC 2012 TB --- 2012-01-05 19:43:55 - cd /src/sys/arm/conf TB --- 2012-01-05 19:43:55 - /usr/sbin/config -m EP80219 TB --- 2012-01-05 19:43:55 - building EP80219 kernel TB --- 2012-01-05 19:43:55 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:43:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:43:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:43:55 - SRCCONF=/dev/null TB --- 2012-01-05 19:43:55 - TARGET=arm TB --- 2012-01-05 19:43:55 - TARGET_ARCH=arm TB --- 2012-01-05 19:43:55 - TZ=UTC TB --- 2012-01-05 19:43:55 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:43:55 - cd /src TB --- 2012-01-05 19:43:55 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Jan 5 19:43:56 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Thu Jan 5 19:47:16 UTC 2012 TB --- 2012-01-05 19:47:16 - WARNING: no kernel config for GENERIC TB --- 2012-01-05 19:47:16 - cd /src/sys/arm/conf TB --- 2012-01-05 19:47:16 - /usr/sbin/config -m GUMSTIX TB --- 2012-01-05 19:47:17 - building GUMSTIX kernel TB --- 2012-01-05 19:47:17 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:47:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:47:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:47:17 - SRCCONF=/dev/null TB --- 2012-01-05 19:47:17 - TARGET=arm TB --- 2012-01-05 19:47:17 - TARGET_ARCH=arm TB --- 2012-01-05 19:47:17 - TZ=UTC TB --- 2012-01-05 19:47:17 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:47:17 - cd /src TB --- 2012-01-05 19:47:17 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Jan 5 19:47:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Thu Jan 5 19:49:40 UTC 2012 TB --- 2012-01-05 19:49:40 - cd /src/sys/arm/conf TB --- 2012-01-05 19:49:40 - /usr/sbin/config -m HL200 TB --- 2012-01-05 19:49:40 - building HL200 kernel TB --- 2012-01-05 19:49:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:49:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:49:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:49:40 - SRCCONF=/dev/null TB --- 2012-01-05 19:49:40 - TARGET=arm TB --- 2012-01-05 19:49:40 - TARGET_ARCH=arm TB --- 2012-01-05 19:49:40 - TZ=UTC TB --- 2012-01-05 19:49:40 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:49:40 - cd /src TB --- 2012-01-05 19:49:40 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Jan 5 19:49:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL200 completed on Thu Jan 5 19:52:18 UTC 2012 TB --- 2012-01-05 19:52:18 - cd /src/sys/arm/conf TB --- 2012-01-05 19:52:18 - /usr/sbin/config -m HL201 TB --- 2012-01-05 19:52:19 - building HL201 kernel TB --- 2012-01-05 19:52:19 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:52:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:52:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:52:19 - SRCCONF=/dev/null TB --- 2012-01-05 19:52:19 - TARGET=arm TB --- 2012-01-05 19:52:19 - TARGET_ARCH=arm TB --- 2012-01-05 19:52:19 - TZ=UTC TB --- 2012-01-05 19:52:19 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:52:19 - cd /src TB --- 2012-01-05 19:52:19 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Jan 5 19:52:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL201 completed on Thu Jan 5 19:54:29 UTC 2012 TB --- 2012-01-05 19:54:29 - cd /src/sys/arm/conf TB --- 2012-01-05 19:54:29 - /usr/sbin/config -m IQ31244 TB --- 2012-01-05 19:54:29 - building IQ31244 kernel TB --- 2012-01-05 19:54:29 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:54:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:54:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:54:29 - SRCCONF=/dev/null TB --- 2012-01-05 19:54:29 - TARGET=arm TB --- 2012-01-05 19:54:29 - TARGET_ARCH=arm TB --- 2012-01-05 19:54:29 - TZ=UTC TB --- 2012-01-05 19:54:29 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:54:29 - cd /src TB --- 2012-01-05 19:54:29 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Jan 5 19:54:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for IQ31244 completed on Thu Jan 5 19:57:55 UTC 2012 TB --- 2012-01-05 19:57:55 - cd /src/sys/arm/conf TB --- 2012-01-05 19:57:55 - /usr/sbin/config -m KB920X TB --- 2012-01-05 19:57:55 - building KB920X kernel TB --- 2012-01-05 19:57:55 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 19:57:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 19:57:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 19:57:55 - SRCCONF=/dev/null TB --- 2012-01-05 19:57:55 - TARGET=arm TB --- 2012-01-05 19:57:55 - TARGET_ARCH=arm TB --- 2012-01-05 19:57:55 - TZ=UTC TB --- 2012-01-05 19:57:55 - __MAKE_CONF=/dev/null TB --- 2012-01-05 19:57:55 - cd /src TB --- 2012-01-05 19:57:55 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Jan 5 19:57:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-05 20:03:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-05 20:03:05 - ERROR: failed to build KB920X kernel TB --- 2012-01-05 20:03:05 - 4598.74 user 1147.10 system 6184.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 20:04:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A81A9106566B for ; Thu, 5 Jan 2012 20:04:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 61FCC8FC0C for ; Thu, 5 Jan 2012 20:04:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RitXk-00076k-Ci>; Thu, 05 Jan 2012 21:04:08 +0100 Received: from e178028167.adsl.alicedsl.de ([85.178.28.167] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RitXk-00005h-7t>; Thu, 05 Jan 2012 21:04:08 +0100 Message-ID: <4F060231.5010606@zedat.fu-berlin.de> Date: Thu, 05 Jan 2012 21:04:01 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120101 Thunderbird/9.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3EA41CB7716596488B12FB88" X-Originating-IP: 85.178.28.167 Subject: WITH_ICONV/WITH_BSD_GREP: Defaults? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:04:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3EA41CB7716596488B12FB88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In FreeBSD 9 and 10, src.conf could be populated with those two knobs WITH_ICONV and WITH_BSD_GREP For some testing purposes, I switched them both to "enabled", so I could test ports and software against these. I didn't realize any serious issue with WITH_BSD_GREP, but I read, some time ago, that bsdggrep does have some speed issues. What is the actual status of bsdgrep in FreeBSD? Another story seems to be with WITH_ICONV. I didn't realize problems until I had harsh faults compiling port lang/gcc46 which tend to fail in a Makefile when WITH_ICONV is enabled. But at that point the issue the first time occured, I hadn't deinstalled port converters/libiconv so I can not say whether those issues came due to confusions. But it seems to tend to confusions having remnants of WITH_iconv installation when disabling the build by deleting or commenting out WITH_ICONV. What is the status of WITH_ICONV? The ports seem still to rely on the port libiconv when being built. Thanks in advance, Oliver --------------enig3EA41CB7716596488B12FB88 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.18 (FreeBSD) iQEcBAEBAgAGBQJPBgI3AAoJEOgBcD7A/5N8AxYH/3UQYdwJ/ROq5Nqg1BhML76H hWgin49fSh4XZ5LgJV7f22dexCYEkxPZPkOy/dT1G+jJ2TaTWpeVY9/pG7h6XqNm lRsMq/suWK8ecWRUAlX4NUXwc5ckG3nWEw8fga8g6FBRbTIbavrSHla2yGIdlcHC sxJe4GmtGEKOyKzQubfOl1Ps1APCxzOMb8gsj+K8froAtiLGk2Db/wXRuKn744e3 HQ/z7TW969GSRfDNb814Ggb/cFmhOh47+BPHy8u5wUienb+kL7DY9n2xxE/M8qg8 OvkEe2ykw1gMA0llzhBScrGtC9qUcbztRBE0//MunVujXqpXPLtS4vcRs8vAsTc= =HXCi -----END PGP SIGNATURE----- --------------enig3EA41CB7716596488B12FB88-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 21:06:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72EC9106566C; Thu, 5 Jan 2012 21:06:14 +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 4345E8FC0C; Thu, 5 Jan 2012 21:06:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q05L6D5x097502; Thu, 5 Jan 2012 16:06:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q05L6DqZ097376; Thu, 5 Jan 2012 21:06:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Jan 2012 21:06:13 GMT Message-Id: <201201052106.q05L6DqZ097376@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: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:06:14 -0000 TB --- 2012-01-05 18:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 18:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-05 18:20:00 - cleaning the object tree TB --- 2012-01-05 18:20:30 - cvsupping the source tree TB --- 2012-01-05 18:20:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-05 18:20:47 - building world TB --- 2012-01-05 18:20:47 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 18:20:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 18:20:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 18:20:47 - SRCCONF=/dev/null TB --- 2012-01-05 18:20:47 - TARGET=pc98 TB --- 2012-01-05 18:20:47 - TARGET_ARCH=i386 TB --- 2012-01-05 18:20:47 - TZ=UTC TB --- 2012-01-05 18:20:47 - __MAKE_CONF=/dev/null TB --- 2012-01-05 18:20:47 - cd /src TB --- 2012-01-05 18:20:47 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 18:20:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 5 20:30:04 UTC 2012 TB --- 2012-01-05 20:30:04 - generating LINT kernel config TB --- 2012-01-05 20:30:04 - cd /src/sys/pc98/conf TB --- 2012-01-05 20:30:04 - /usr/bin/make -B LINT TB --- 2012-01-05 20:30:04 - cd /src/sys/pc98/conf TB --- 2012-01-05 20:30:04 - /usr/sbin/config -m LINT TB --- 2012-01-05 20:30:04 - building LINT kernel TB --- 2012-01-05 20:30:04 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 20:30:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 20:30:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 20:30:04 - SRCCONF=/dev/null TB --- 2012-01-05 20:30:04 - TARGET=pc98 TB --- 2012-01-05 20:30:04 - TARGET_ARCH=i386 TB --- 2012-01-05 20:30:04 - TZ=UTC TB --- 2012-01-05 20:30:04 - __MAKE_CONF=/dev/null TB --- 2012-01-05 20:30:04 - cd /src TB --- 2012-01-05 20:30:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 5 20:30:04 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Jan 5 20:58:42 UTC 2012 TB --- 2012-01-05 20:58:42 - cd /src/sys/pc98/conf TB --- 2012-01-05 20:58:42 - /usr/sbin/config -m GENERIC TB --- 2012-01-05 20:58:42 - building GENERIC kernel TB --- 2012-01-05 20:58:42 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 20:58:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 20:58:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 20:58:42 - SRCCONF=/dev/null TB --- 2012-01-05 20:58:42 - TARGET=pc98 TB --- 2012-01-05 20:58:42 - TARGET_ARCH=i386 TB --- 2012-01-05 20:58:42 - TZ=UTC TB --- 2012-01-05 20:58:42 - __MAKE_CONF=/dev/null TB --- 2012-01-05 20:58:42 - cd /src TB --- 2012-01-05 20:58:42 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jan 5 20:58:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-05 21:06:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-05 21:06:12 - ERROR: failed to build GENERIC kernel TB --- 2012-01-05 21:06:12 - 7936.90 user 1431.73 system 9971.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 22:12:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7117C1065675 for ; Thu, 5 Jan 2012 22:12:33 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with ESMTP id 274BD8FC0A for ; Thu, 5 Jan 2012 22:12:32 +0000 (UTC) Received: (qmail 47626 invoked by uid 89); 5 Jan 2012 22:12:32 -0000 Received: from localhost (HELO pop.pknet.net) (127.0.0.1) by poshta.pknet.net with ESMTP; 5 Jan 2012 22:12:32 -0000 Received: from 74.63.162.21 (SquirrelMail authenticated user fbsdq@peterk.org) by pop.pknet.net with HTTP; Thu, 5 Jan 2012 15:12:32 -0700 Message-ID: <5eac2995697ee99fcfda6d071ad09edc.squirrel@pop.pknet.net> Date: Thu, 5 Jan 2012 15:12:32 -0700 From: "Peter" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: stable/9 still looking for packages at 9-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:12:33 -0000 Hello, Installed 9-RELEASE amd64, svn the latest stable/9 sources, built/installed kernel/world and did pkg_add - It is still by default pointing at -current: pkbsdpkg:#uname -a FreeBSD pkbsdpkg 9.0-STABLE FreeBSD 9.0-STABLE #0 r229599: Thu Jan 5 10:23:52 MST 2012 peter@pkbsd.pk.pb:/usr/obj/usr/src/sys/GENERIC amd64 pkbsdpkg:#echo $PACKAGESITE pkbsdpkg:#pkg_add -r test Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/test.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/test.tbz' by URL pkbsdpkg:# pkbsdpkg:#pwd /usr/src/usr.sbin/pkg_install pkbsdpkg:#grep -R packages-9 * add/main.c: { 900000, 900499, "/packages-9.0-release" }, add/main.c: { 900000, 999000, "/packages-9-current" }, ??? On a fresh 9-release install works properly: 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [15:10] igormolko: pkg_add -r test Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/test.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/test.tbz' by URL ]Peter[ From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 22:20:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42F421065677 for ; Thu, 5 Jan 2012 22:20:44 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DB4408FC0C for ; Thu, 5 Jan 2012 22:20:43 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Rivfv-0005ny-3J>; Thu, 05 Jan 2012 23:20:43 +0100 Received: from e178028167.adsl.alicedsl.de ([85.178.28.167] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Rivfu-0006hI-Sc>; Thu, 05 Jan 2012 23:20:43 +0100 Message-ID: <4F062232.1020204@zedat.fu-berlin.de> Date: Thu, 05 Jan 2012 23:20:34 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120101 Thunderbird/9.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF8EFBA312E8C4EE49918715" X-Originating-IP: 85.178.28.167 Subject: WITH_LIBCPLUSPLUS on FreeBSD 10.0-CURRENT/amd64 fails with CLANG: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:20:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF8EFBA312E8C4EE49918715 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When compiling most recent CURRENT on amd64 platform, using CLANG and enabled WITH_LIBCPLUSPLUS, I receive the follwing error since two days now. Build shown below was made avoiding -jX when doing buildworld. [SNIP] rpcgen -C -c /usr/src/lib/librpcsvc/../../include/rpcsvc/ypupdate_prot.x -o ypupdate_prot_xdr.c rm -f .depend CC=3D'cc -m32 -march=3Dnative -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=3Dgnu99 klm_prot_xdr.c mount_xdr.c nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c rnusers_xdr.c rquota_xdr.c rstat_xdr.c rwall_xdr.c sm_inter_xdr.c spray_xdr.c yppasswd_xdr.c ypxfrd_xdr.c ypupdate_prot_xdr.c /usr/src/lib/librpcsvc/rnusers.c /usr/src/lib/librpcsvc/rstat.c /usr/src/lib/librpcsvc/rwall.c /usr/src/lib/librpcsvc/yp_passwd.c /usr/src/lib/librpcsvc/yp_update.c /usr/src/lib/librpcsvc/secretkey.c /usr/src/lib/librpcsvc/xcrypt.c =3D=3D=3D> lib/libsbuf (depend) =3D=3D=3D> lib/libtacplus (depend) =3D=3D=3D> lib/libutil (depend) =3D=3D=3D> lib/libypclnt (depend) =3D=3D=3D> lib/libcxxrt (depend) =3D=3D=3D> lib/libc++ (depend) rm -f .depend CC=3D'cc -m32 -march=3Dnative -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=3Dc++0x /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" cc1plus: error: unrecognized command line option "-std=3Dc++0x" mkdep: compile failed --------------enigEF8EFBA312E8C4EE49918715 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.18 (FreeBSD) iQEcBAEBAgAGBQJPBiI6AAoJEOgBcD7A/5N8aDAIAMONxhRFbi8UrMYAZM4s8DJw 1gdiGjD5fkki1eHx8ySA4e/lDo/aYd59LoV5cJ40E3qMWLqb5UWt+xblrIax0x+8 bxge9HeFZNd7pNDSUzoB1pXCWh7yxUBo1DEHfXu5Y1np10gJp0rcaEq1IxmIxqBn 7ptsfCtkqQSqxi+EGbnzXoQbGGcFwqujUzMcJ+paM7t6erGtTzFNzCjLZN510Ly+ yS7MoJZ2CjUf+Ax2HvI32GJXN/2JG1vR+t2pPZ/ERcssmPXPbPPihxsOOdwBiK6i nM0Ncw3Uhxx+NNmd0H0uZCLx0PEez9qxQy8+5YOninHocOZF+qbFJcIOMavq3dg= =kcuz -----END PGP SIGNATURE----- --------------enigEF8EFBA312E8C4EE49918715-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 23:17:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D527106566C for ; Thu, 5 Jan 2012 23:17:44 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id C81128FC08 for ; Thu, 5 Jan 2012 23:17:42 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 79BFF14E69ED; Fri, 6 Jan 2012 00:00:49 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PzAkHeP7Ev3X; Fri, 6 Jan 2012 00:00:47 +0100 (CET) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 504E514E69D0; Fri, 6 Jan 2012 00:00:47 +0100 (CET) Message-ID: <4F062B99.6030202@FreeBSD.org> Date: Fri, 06 Jan 2012 00:00:41 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111124 Thunderbird/10.0a2 MIME-Version: 1.0 To: "O. Hartmann" References: <4F060231.5010606@zedat.fu-berlin.de> In-Reply-To: <4F060231.5010606@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current FreeBSD Subject: Re: WITH_ICONV/WITH_BSD_GREP: Defaults? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:17:44 -0000 On 2012.01.05. 21:04, O. Hartmann wrote: > In FreeBSD 9 and 10, src.conf could be populated with those two knobs > > WITH_ICONV > and > WITH_BSD_GREP > > For some testing purposes, I switched them both to "enabled", so I could > test ports and software against these. > > I didn't realize any serious issue with WITH_BSD_GREP, but I read, some > time ago, that bsdggrep does have some speed issues. What is the actual > status of bsdgrep in FreeBSD? Yes, BSD grep has significant performance problems. It is quite a complex issue because GNU grep uses some shortcuts to speed up pattern matching. I don't want to put that in BSD grep because that does not seem correct to me. Such code belongs to the regex library. Not just logically but practically, as well, so that other dependencies can also benefit from a faster pattern matching. However, it cannot be done with the POSIX-compliant API so it requires some extensions. From the last GSoC, there is an ongoing work on this but currently, I'm having exams at the university. I hope I can finish it after my exams. > > Another story seems to be with WITH_ICONV. I didn't realize problems > until I had harsh faults compiling port lang/gcc46 which tend to fail in > a Makefile when WITH_ICONV is enabled. But at that point the issue the > first time occured, I hadn't deinstalled port converters/libiconv so I > can not say whether those issues came due to confusions. But it seems to > tend to confusions having remnants of WITH_iconv installation when > disabling the build by deleting or commenting out WITH_ICONV. > What is the status of WITH_ICONV? > The ports seem still to rely on the port libiconv when being built. BSD iconv works quite well in some cases but there are some problems on my TODO list, so I preferred to leave it off by default until they are solved. Gabor From owner-freebsd-current@FreeBSD.ORG Thu Jan 5 23:47:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D516106566B; Thu, 5 Jan 2012 23:47:37 +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 E76CF8FC08; Thu, 5 Jan 2012 23:47:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q05Nla62024318; Thu, 5 Jan 2012 18:47:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q05NlZnU024305; Thu, 5 Jan 2012 23:47:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Jan 2012 23:47:35 GMT Message-Id: <201201052347.q05NlZnU024305@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:47:37 -0000 TB --- 2012-01-05 18:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 18:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-05 18:20:00 - cleaning the object tree TB --- 2012-01-05 18:21:04 - cvsupping the source tree TB --- 2012-01-05 18:21:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-05 18:21:15 - building world TB --- 2012-01-05 18:21:15 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 18:21:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 18:21:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 18:21:15 - SRCCONF=/dev/null TB --- 2012-01-05 18:21:15 - TARGET=i386 TB --- 2012-01-05 18:21:15 - TARGET_ARCH=i386 TB --- 2012-01-05 18:21:15 - TZ=UTC TB --- 2012-01-05 18:21:15 - __MAKE_CONF=/dev/null TB --- 2012-01-05 18:21:15 - cd /src TB --- 2012-01-05 18:21:15 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 18:21:16 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 5 20:30:46 UTC 2012 TB --- 2012-01-05 20:30:46 - generating LINT kernel config TB --- 2012-01-05 20:30:46 - cd /src/sys/i386/conf TB --- 2012-01-05 20:30:46 - /usr/bin/make -B LINT TB --- 2012-01-05 20:30:47 - cd /src/sys/i386/conf TB --- 2012-01-05 20:30:47 - /usr/sbin/config -m LINT TB --- 2012-01-05 20:30:47 - building LINT kernel TB --- 2012-01-05 20:30:47 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 20:30:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 20:30:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 20:30:47 - SRCCONF=/dev/null TB --- 2012-01-05 20:30:47 - TARGET=i386 TB --- 2012-01-05 20:30:47 - TARGET_ARCH=i386 TB --- 2012-01-05 20:30:47 - TZ=UTC TB --- 2012-01-05 20:30:47 - __MAKE_CONF=/dev/null TB --- 2012-01-05 20:30:47 - cd /src TB --- 2012-01-05 20:30:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 5 20:30:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Jan 5 21:03:00 UTC 2012 TB --- 2012-01-05 21:03:00 - cd /src/sys/i386/conf TB --- 2012-01-05 21:03:00 - /usr/sbin/config -m LINT-NOINET TB --- 2012-01-05 21:03:00 - building LINT-NOINET kernel TB --- 2012-01-05 21:03:00 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 21:03:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 21:03:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 21:03:00 - SRCCONF=/dev/null TB --- 2012-01-05 21:03:00 - TARGET=i386 TB --- 2012-01-05 21:03:00 - TARGET_ARCH=i386 TB --- 2012-01-05 21:03:00 - TZ=UTC TB --- 2012-01-05 21:03:00 - __MAKE_CONF=/dev/null TB --- 2012-01-05 21:03:00 - cd /src TB --- 2012-01-05 21:03:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Jan 5 21:03:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Thu Jan 5 21:33:29 UTC 2012 TB --- 2012-01-05 21:33:29 - cd /src/sys/i386/conf TB --- 2012-01-05 21:33:29 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-01-05 21:33:29 - building LINT-NOINET6 kernel TB --- 2012-01-05 21:33:29 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 21:33:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 21:33:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 21:33:29 - SRCCONF=/dev/null TB --- 2012-01-05 21:33:29 - TARGET=i386 TB --- 2012-01-05 21:33:29 - TARGET_ARCH=i386 TB --- 2012-01-05 21:33:29 - TZ=UTC TB --- 2012-01-05 21:33:29 - __MAKE_CONF=/dev/null TB --- 2012-01-05 21:33:29 - cd /src TB --- 2012-01-05 21:33:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Jan 5 21:33:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Thu Jan 5 22:04:42 UTC 2012 TB --- 2012-01-05 22:04:42 - cd /src/sys/i386/conf TB --- 2012-01-05 22:04:42 - /usr/sbin/config -m LINT-NOIP TB --- 2012-01-05 22:04:42 - building LINT-NOIP kernel TB --- 2012-01-05 22:04:42 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 22:04:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 22:04:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 22:04:42 - SRCCONF=/dev/null TB --- 2012-01-05 22:04:42 - TARGET=i386 TB --- 2012-01-05 22:04:42 - TARGET_ARCH=i386 TB --- 2012-01-05 22:04:42 - TZ=UTC TB --- 2012-01-05 22:04:42 - __MAKE_CONF=/dev/null TB --- 2012-01-05 22:04:42 - cd /src TB --- 2012-01-05 22:04:42 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Jan 5 22:04:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Thu Jan 5 22:33:07 UTC 2012 TB --- 2012-01-05 22:33:07 - cd /src/sys/i386/conf TB --- 2012-01-05 22:33:07 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-01-05 22:33:07 - building LINT-VIMAGE kernel TB --- 2012-01-05 22:33:07 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 22:33:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 22:33:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 22:33:07 - SRCCONF=/dev/null TB --- 2012-01-05 22:33:07 - TARGET=i386 TB --- 2012-01-05 22:33:07 - TARGET_ARCH=i386 TB --- 2012-01-05 22:33:07 - TZ=UTC TB --- 2012-01-05 22:33:07 - __MAKE_CONF=/dev/null TB --- 2012-01-05 22:33:07 - cd /src TB --- 2012-01-05 22:33:07 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Jan 5 22:33:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Thu Jan 5 23:04:51 UTC 2012 TB --- 2012-01-05 23:04:51 - cd /src/sys/i386/conf TB --- 2012-01-05 23:04:52 - /usr/sbin/config -m GENERIC TB --- 2012-01-05 23:04:52 - building GENERIC kernel TB --- 2012-01-05 23:04:52 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 23:04:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 23:04:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 23:04:52 - SRCCONF=/dev/null TB --- 2012-01-05 23:04:52 - TARGET=i386 TB --- 2012-01-05 23:04:52 - TARGET_ARCH=i386 TB --- 2012-01-05 23:04:52 - TZ=UTC TB --- 2012-01-05 23:04:52 - __MAKE_CONF=/dev/null TB --- 2012-01-05 23:04:52 - cd /src TB --- 2012-01-05 23:04:52 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Jan 5 23:04:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Jan 5 23:30:07 UTC 2012 TB --- 2012-01-05 23:30:07 - cd /src/sys/i386/conf TB --- 2012-01-05 23:30:07 - /usr/sbin/config -m PAE TB --- 2012-01-05 23:30:07 - building PAE kernel TB --- 2012-01-05 23:30:07 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 23:30:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 23:30:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 23:30:07 - SRCCONF=/dev/null TB --- 2012-01-05 23:30:07 - TARGET=i386 TB --- 2012-01-05 23:30:07 - TARGET_ARCH=i386 TB --- 2012-01-05 23:30:07 - TZ=UTC TB --- 2012-01-05 23:30:07 - __MAKE_CONF=/dev/null TB --- 2012-01-05 23:30:07 - cd /src TB --- 2012-01-05 23:30:07 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Thu Jan 5 23:30:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Thu Jan 5 23:36:54 UTC 2012 TB --- 2012-01-05 23:36:54 - cd /src/sys/i386/conf TB --- 2012-01-05 23:36:54 - /usr/sbin/config -m XBOX TB --- 2012-01-05 23:36:54 - building XBOX kernel TB --- 2012-01-05 23:36:54 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 23:36:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 23:36:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 23:36:54 - SRCCONF=/dev/null TB --- 2012-01-05 23:36:54 - TARGET=i386 TB --- 2012-01-05 23:36:54 - TARGET_ARCH=i386 TB --- 2012-01-05 23:36:54 - TZ=UTC TB --- 2012-01-05 23:36:54 - __MAKE_CONF=/dev/null TB --- 2012-01-05 23:36:54 - cd /src TB --- 2012-01-05 23:36:54 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Thu Jan 5 23:36:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Thu Jan 5 23:40:17 UTC 2012 TB --- 2012-01-05 23:40:17 - cd /src/sys/i386/conf TB --- 2012-01-05 23:40:17 - /usr/sbin/config -m XEN TB --- 2012-01-05 23:40:17 - building XEN kernel TB --- 2012-01-05 23:40:17 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 23:40:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 23:40:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 23:40:17 - SRCCONF=/dev/null TB --- 2012-01-05 23:40:17 - TARGET=i386 TB --- 2012-01-05 23:40:17 - TARGET_ARCH=i386 TB --- 2012-01-05 23:40:17 - TZ=UTC TB --- 2012-01-05 23:40:17 - __MAKE_CONF=/dev/null TB --- 2012-01-05 23:40:17 - cd /src TB --- 2012-01-05 23:40:17 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Thu Jan 5 23:40:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-05 23:47:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-05 23:47:35 - ERROR: failed to build XEN kernel TB --- 2012-01-05 23:47:35 - 15657.30 user 2692.16 system 19654.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 00:42:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D58B106567B for ; Fri, 6 Jan 2012 00:42:33 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2856E8FC0A for ; Fri, 6 Jan 2012 00:42:33 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so1821948obb.13 for ; Thu, 05 Jan 2012 16:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AbdF7Bdt+Xr8oG5arlJHMhjdD7y9BV79VDt2JXFGj9E=; b=E41I26JYPcuItKY9gdY/fDS7sYa0Pzj9D9B3PwSlxSwiMDyP3euFGWAUqSOME0FqKt lmkoOibwXWODy1w8YKistartaWkdkmU0Rc5dixtNe5VnJw4hQ/R88svm9WBQVVJvOJUJ 3Rj3nbU/sA52qRsyAtFU/tOy4WcH2vgDB1w3g= MIME-Version: 1.0 Received: by 10.182.1.8 with SMTP id 8mr3263585obi.11.1325810552663; Thu, 05 Jan 2012 16:42:32 -0800 (PST) Received: by 10.182.152.6 with HTTP; Thu, 5 Jan 2012 16:42:32 -0800 (PST) In-Reply-To: <5eac2995697ee99fcfda6d071ad09edc.squirrel@pop.pknet.net> References: <5eac2995697ee99fcfda6d071ad09edc.squirrel@pop.pknet.net> Date: Thu, 5 Jan 2012 16:42:32 -0800 Message-ID: From: Garrett Cooper To: Peter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: stable/9 still looking for packages at 9-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:42:33 -0000 On Thu, Jan 5, 2012 at 2:12 PM, Peter wrote: > Hello, > =A0Installed 9-RELEASE amd64, svn the latest stable/9 sources, > built/installed kernel/world and did pkg_add - It is still by default > pointing at -current: > > pkbsdpkg:#uname -a > FreeBSD pkbsdpkg 9.0-STABLE FreeBSD 9.0-STABLE #0 r229599: Thu Jan =A05 > 10:23:52 MST 2012 =A0 =A0 peter@pkbsd.pk.pb:/usr/obj/usr/src/sys/GENERIC > amd64 > pkbsdpkg:#echo $PACKAGESITE > > pkbsdpkg:#pkg_add -r test > Error: Unable to get > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/t= est.tbz: > File unavailable (e.g., file not found, no access) > pkg_add: unable to fetch > 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/= test.tbz' > by URL > pkbsdpkg:# > > > pkbsdpkg:#pwd > /usr/src/usr.sbin/pkg_install > pkbsdpkg:#grep -R packages-9 * > add/main.c: =A0 =A0 { 900000, 900499, "/packages-9.0-release" }, > add/main.c: =A0 =A0 { 900000, 999000, "/packages-9-current" }, > > ??? > > On a fresh 9-release install works properly: > 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > [15:10] igormolko: pkg_add -r test > Error: Unable to get > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest= /test.tbz: > File unavailable (e.g., file not found, no access) > pkg_add: unable to fetch > 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Lates= t/test.tbz' > by URL svn up / c[v]sup your tree. It was recently merged/fixed by kensmith. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 01:36:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C241065670; Fri, 6 Jan 2012 01:36:19 +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 BD7EF8FC08; Fri, 6 Jan 2012 01:36:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q061aIvh046684; Thu, 5 Jan 2012 20:36:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q061aI6H046683; Fri, 6 Jan 2012 01:36:18 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 01:36:18 GMT Message-Id: <201201060136.q061aI6H046683@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: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:36:20 -0000 TB --- 2012-01-05 22:35:12 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-05 22:35:12 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-05 22:35:12 - cleaning the object tree TB --- 2012-01-05 22:35:35 - cvsupping the source tree TB --- 2012-01-05 22:35:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-05 22:35:47 - building world TB --- 2012-01-05 22:35:47 - CROSS_BUILD_TESTING=YES TB --- 2012-01-05 22:35:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-05 22:35:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-05 22:35:47 - SRCCONF=/dev/null TB --- 2012-01-05 22:35:47 - TARGET=powerpc TB --- 2012-01-05 22:35:47 - TARGET_ARCH=powerpc64 TB --- 2012-01-05 22:35:47 - TZ=UTC TB --- 2012-01-05 22:35:47 - __MAKE_CONF=/dev/null TB --- 2012-01-05 22:35:47 - cd /src TB --- 2012-01-05 22:35:47 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 5 22:35:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Jan 6 01:08:40 UTC 2012 TB --- 2012-01-06 01:08:40 - generating LINT kernel config TB --- 2012-01-06 01:08:40 - cd /src/sys/powerpc/conf TB --- 2012-01-06 01:08:40 - /usr/bin/make -B LINT TB --- 2012-01-06 01:08:40 - cd /src/sys/powerpc/conf TB --- 2012-01-06 01:08:40 - /usr/sbin/config -m LINT TB --- 2012-01-06 01:08:40 - building LINT kernel TB --- 2012-01-06 01:08:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 01:08:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 01:08:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 01:08:40 - SRCCONF=/dev/null TB --- 2012-01-06 01:08:40 - TARGET=powerpc TB --- 2012-01-06 01:08:40 - TARGET_ARCH=powerpc64 TB --- 2012-01-06 01:08:40 - TZ=UTC TB --- 2012-01-06 01:08:40 - __MAKE_CONF=/dev/null TB --- 2012-01-06 01:08:40 - cd /src TB --- 2012-01-06 01:08:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 6 01:08:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Jan 6 01:29:33 UTC 2012 TB --- 2012-01-06 01:29:33 - cd /src/sys/powerpc/conf TB --- 2012-01-06 01:29:33 - /usr/sbin/config -m GENERIC TB --- 2012-01-06 01:29:33 - skipping GENERIC kernel TB --- 2012-01-06 01:29:33 - cd /src/sys/powerpc/conf TB --- 2012-01-06 01:29:33 - /usr/sbin/config -m GENERIC64 TB --- 2012-01-06 01:29:33 - building GENERIC64 kernel TB --- 2012-01-06 01:29:33 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 01:29:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 01:29:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 01:29:33 - SRCCONF=/dev/null TB --- 2012-01-06 01:29:33 - TARGET=powerpc TB --- 2012-01-06 01:29:33 - TARGET_ARCH=powerpc64 TB --- 2012-01-06 01:29:33 - TZ=UTC TB --- 2012-01-06 01:29:33 - __MAKE_CONF=/dev/null TB --- 2012-01-06 01:29:33 - cd /src TB --- 2012-01-06 01:29:33 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Fri Jan 6 01:29:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 01:36:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 01:36:18 - ERROR: failed to build GENERIC64 kernel TB --- 2012-01-06 01:36:18 - 9034.40 user 1545.84 system 10866.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 04:26:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D0E106564A; Fri, 6 Jan 2012 04:26:39 +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 A1A018FC14; Fri, 6 Jan 2012 04:26:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q064Qc0T047152; Thu, 5 Jan 2012 23:26:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q064QcuG047057; Fri, 6 Jan 2012 04:26:38 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 04:26:38 GMT Message-Id: <201201060426.q064QcuG047057@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: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 04:26:39 -0000 TB --- 2012-01-06 01:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 01:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-06 01:40:00 - cleaning the object tree TB --- 2012-01-06 01:40:31 - cvsupping the source tree TB --- 2012-01-06 01:40:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-06 01:40:48 - building world TB --- 2012-01-06 01:40:48 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 01:40:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 01:40:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 01:40:48 - SRCCONF=/dev/null TB --- 2012-01-06 01:40:48 - TARGET=pc98 TB --- 2012-01-06 01:40:48 - TARGET_ARCH=i386 TB --- 2012-01-06 01:40:48 - TZ=UTC TB --- 2012-01-06 01:40:48 - __MAKE_CONF=/dev/null TB --- 2012-01-06 01:40:48 - cd /src TB --- 2012-01-06 01:40:48 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 01:40:49 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 6 03:50:24 UTC 2012 TB --- 2012-01-06 03:50:24 - generating LINT kernel config TB --- 2012-01-06 03:50:24 - cd /src/sys/pc98/conf TB --- 2012-01-06 03:50:24 - /usr/bin/make -B LINT TB --- 2012-01-06 03:50:24 - cd /src/sys/pc98/conf TB --- 2012-01-06 03:50:24 - /usr/sbin/config -m LINT TB --- 2012-01-06 03:50:24 - building LINT kernel TB --- 2012-01-06 03:50:24 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 03:50:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 03:50:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 03:50:24 - SRCCONF=/dev/null TB --- 2012-01-06 03:50:24 - TARGET=pc98 TB --- 2012-01-06 03:50:24 - TARGET_ARCH=i386 TB --- 2012-01-06 03:50:24 - TZ=UTC TB --- 2012-01-06 03:50:24 - __MAKE_CONF=/dev/null TB --- 2012-01-06 03:50:24 - cd /src TB --- 2012-01-06 03:50:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 6 03:50:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Jan 6 04:18:44 UTC 2012 TB --- 2012-01-06 04:18:44 - cd /src/sys/pc98/conf TB --- 2012-01-06 04:18:44 - /usr/sbin/config -m GENERIC TB --- 2012-01-06 04:18:44 - building GENERIC kernel TB --- 2012-01-06 04:18:44 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 04:18:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 04:18:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 04:18:44 - SRCCONF=/dev/null TB --- 2012-01-06 04:18:44 - TARGET=pc98 TB --- 2012-01-06 04:18:44 - TARGET_ARCH=i386 TB --- 2012-01-06 04:18:44 - TZ=UTC TB --- 2012-01-06 04:18:44 - __MAKE_CONF=/dev/null TB --- 2012-01-06 04:18:44 - cd /src TB --- 2012-01-06 04:18:44 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 6 04:18:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 04:26:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 04:26:38 - ERROR: failed to build GENERIC kernel TB --- 2012-01-06 04:26:38 - 7936.34 user 1431.32 system 9997.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 07:08:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49F291065673; Fri, 6 Jan 2012 07:08:33 +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 D87C68FC22; Fri, 6 Jan 2012 07:08:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q0678Vea009739; Fri, 6 Jan 2012 02:08:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q0678VPw009708; Fri, 6 Jan 2012 07:08:31 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 07:08:31 GMT Message-Id: <201201060708.q0678VPw009708@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:08:33 -0000 TB --- 2012-01-06 01:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 01:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-06 01:40:00 - cleaning the object tree TB --- 2012-01-06 01:41:04 - cvsupping the source tree TB --- 2012-01-06 01:41:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-06 01:41:17 - building world TB --- 2012-01-06 01:41:17 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 01:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 01:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 01:41:17 - SRCCONF=/dev/null TB --- 2012-01-06 01:41:17 - TARGET=i386 TB --- 2012-01-06 01:41:17 - TARGET_ARCH=i386 TB --- 2012-01-06 01:41:17 - TZ=UTC TB --- 2012-01-06 01:41:17 - __MAKE_CONF=/dev/null TB --- 2012-01-06 01:41:17 - cd /src TB --- 2012-01-06 01:41:17 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 01:41:17 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 6 03:51:19 UTC 2012 TB --- 2012-01-06 03:51:19 - generating LINT kernel config TB --- 2012-01-06 03:51:19 - cd /src/sys/i386/conf TB --- 2012-01-06 03:51:19 - /usr/bin/make -B LINT TB --- 2012-01-06 03:51:19 - cd /src/sys/i386/conf TB --- 2012-01-06 03:51:19 - /usr/sbin/config -m LINT TB --- 2012-01-06 03:51:19 - building LINT kernel TB --- 2012-01-06 03:51:19 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 03:51:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 03:51:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 03:51:19 - SRCCONF=/dev/null TB --- 2012-01-06 03:51:19 - TARGET=i386 TB --- 2012-01-06 03:51:19 - TARGET_ARCH=i386 TB --- 2012-01-06 03:51:19 - TZ=UTC TB --- 2012-01-06 03:51:19 - __MAKE_CONF=/dev/null TB --- 2012-01-06 03:51:19 - cd /src TB --- 2012-01-06 03:51:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 6 03:51:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Jan 6 04:23:40 UTC 2012 TB --- 2012-01-06 04:23:40 - cd /src/sys/i386/conf TB --- 2012-01-06 04:23:40 - /usr/sbin/config -m LINT-NOINET TB --- 2012-01-06 04:23:40 - building LINT-NOINET kernel TB --- 2012-01-06 04:23:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 04:23:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 04:23:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 04:23:40 - SRCCONF=/dev/null TB --- 2012-01-06 04:23:40 - TARGET=i386 TB --- 2012-01-06 04:23:40 - TARGET_ARCH=i386 TB --- 2012-01-06 04:23:40 - TZ=UTC TB --- 2012-01-06 04:23:40 - __MAKE_CONF=/dev/null TB --- 2012-01-06 04:23:40 - cd /src TB --- 2012-01-06 04:23:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Jan 6 04:23:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Jan 6 04:54:27 UTC 2012 TB --- 2012-01-06 04:54:27 - cd /src/sys/i386/conf TB --- 2012-01-06 04:54:27 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-01-06 04:54:28 - building LINT-NOINET6 kernel TB --- 2012-01-06 04:54:28 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 04:54:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 04:54:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 04:54:28 - SRCCONF=/dev/null TB --- 2012-01-06 04:54:28 - TARGET=i386 TB --- 2012-01-06 04:54:28 - TARGET_ARCH=i386 TB --- 2012-01-06 04:54:28 - TZ=UTC TB --- 2012-01-06 04:54:28 - __MAKE_CONF=/dev/null TB --- 2012-01-06 04:54:28 - cd /src TB --- 2012-01-06 04:54:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Jan 6 04:54:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Fri Jan 6 05:25:45 UTC 2012 TB --- 2012-01-06 05:25:45 - cd /src/sys/i386/conf TB --- 2012-01-06 05:25:45 - /usr/sbin/config -m LINT-NOIP TB --- 2012-01-06 05:25:45 - building LINT-NOIP kernel TB --- 2012-01-06 05:25:45 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 05:25:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 05:25:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 05:25:45 - SRCCONF=/dev/null TB --- 2012-01-06 05:25:45 - TARGET=i386 TB --- 2012-01-06 05:25:45 - TARGET_ARCH=i386 TB --- 2012-01-06 05:25:45 - TZ=UTC TB --- 2012-01-06 05:25:45 - __MAKE_CONF=/dev/null TB --- 2012-01-06 05:25:45 - cd /src TB --- 2012-01-06 05:25:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Jan 6 05:25:45 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Fri Jan 6 05:54:10 UTC 2012 TB --- 2012-01-06 05:54:10 - cd /src/sys/i386/conf TB --- 2012-01-06 05:54:10 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-01-06 05:54:10 - building LINT-VIMAGE kernel TB --- 2012-01-06 05:54:10 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 05:54:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 05:54:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 05:54:10 - SRCCONF=/dev/null TB --- 2012-01-06 05:54:10 - TARGET=i386 TB --- 2012-01-06 05:54:10 - TARGET_ARCH=i386 TB --- 2012-01-06 05:54:10 - TZ=UTC TB --- 2012-01-06 05:54:10 - __MAKE_CONF=/dev/null TB --- 2012-01-06 05:54:10 - cd /src TB --- 2012-01-06 05:54:10 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Jan 6 05:54:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Fri Jan 6 06:25:55 UTC 2012 TB --- 2012-01-06 06:25:55 - cd /src/sys/i386/conf TB --- 2012-01-06 06:25:55 - /usr/sbin/config -m GENERIC TB --- 2012-01-06 06:25:55 - building GENERIC kernel TB --- 2012-01-06 06:25:55 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 06:25:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 06:25:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 06:25:55 - SRCCONF=/dev/null TB --- 2012-01-06 06:25:55 - TARGET=i386 TB --- 2012-01-06 06:25:55 - TARGET_ARCH=i386 TB --- 2012-01-06 06:25:55 - TZ=UTC TB --- 2012-01-06 06:25:55 - __MAKE_CONF=/dev/null TB --- 2012-01-06 06:25:55 - cd /src TB --- 2012-01-06 06:25:55 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 6 06:25:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Jan 6 06:51:01 UTC 2012 TB --- 2012-01-06 06:51:01 - cd /src/sys/i386/conf TB --- 2012-01-06 06:51:01 - /usr/sbin/config -m PAE TB --- 2012-01-06 06:51:01 - building PAE kernel TB --- 2012-01-06 06:51:01 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 06:51:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 06:51:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 06:51:01 - SRCCONF=/dev/null TB --- 2012-01-06 06:51:01 - TARGET=i386 TB --- 2012-01-06 06:51:01 - TARGET_ARCH=i386 TB --- 2012-01-06 06:51:01 - TZ=UTC TB --- 2012-01-06 06:51:01 - __MAKE_CONF=/dev/null TB --- 2012-01-06 06:51:01 - cd /src TB --- 2012-01-06 06:51:01 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Jan 6 06:51:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Jan 6 06:57:47 UTC 2012 TB --- 2012-01-06 06:57:47 - cd /src/sys/i386/conf TB --- 2012-01-06 06:57:47 - /usr/sbin/config -m XBOX TB --- 2012-01-06 06:57:47 - building XBOX kernel TB --- 2012-01-06 06:57:47 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 06:57:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 06:57:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 06:57:47 - SRCCONF=/dev/null TB --- 2012-01-06 06:57:47 - TARGET=i386 TB --- 2012-01-06 06:57:47 - TARGET_ARCH=i386 TB --- 2012-01-06 06:57:47 - TZ=UTC TB --- 2012-01-06 06:57:47 - __MAKE_CONF=/dev/null TB --- 2012-01-06 06:57:47 - cd /src TB --- 2012-01-06 06:57:47 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Fri Jan 6 06:57:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Fri Jan 6 07:01:39 UTC 2012 TB --- 2012-01-06 07:01:39 - cd /src/sys/i386/conf TB --- 2012-01-06 07:01:39 - /usr/sbin/config -m XEN TB --- 2012-01-06 07:01:39 - building XEN kernel TB --- 2012-01-06 07:01:39 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 07:01:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 07:01:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 07:01:39 - SRCCONF=/dev/null TB --- 2012-01-06 07:01:39 - TARGET=i386 TB --- 2012-01-06 07:01:39 - TARGET_ARCH=i386 TB --- 2012-01-06 07:01:39 - TZ=UTC TB --- 2012-01-06 07:01:39 - __MAKE_CONF=/dev/null TB --- 2012-01-06 07:01:39 - cd /src TB --- 2012-01-06 07:01:39 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Jan 6 07:01:39 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 07:08:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 07:08:30 - ERROR: failed to build XEN kernel TB --- 2012-01-06 07:08:30 - 15681.69 user 2701.15 system 19710.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 07:47:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21C5A106566C for ; Fri, 6 Jan 2012 07:47:34 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7DF8FC0A for ; Fri, 6 Jan 2012 07:47:33 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id D944A6A61CB; Fri, 6 Jan 2012 08:47:31 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id OkkpAQEE0h4w; Fri, 6 Jan 2012 08:47:31 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 998796A6016; Fri, 6 Jan 2012 08:47:31 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id q067lV3g082919; Fri, 6 Jan 2012 08:47:31 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id q067lVHd082781; Fri, 6 Jan 2012 08:47:31 +0100 (CET) (envelope-from lars) Date: Fri, 6 Jan 2012 08:47:31 +0100 From: Lars Engels To: Tom Evans Message-ID: <20120106074731.GG48523@e-new.0x20.net> References: <1325682607290-5119535.post@n5.nabble.com> <1325682892011-5119548.post@n5.nabble.com> <1325708292675-5120710.post@n5.nabble.com> <1325708915902-5120743.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SKW69dzTt3T8RCN0" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall kbdmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:47:34 -0000 --SKW69dzTt3T8RCN0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 05, 2012 at 04:47:53PM +0000, Tom Evans wrote: > On Thu, Jan 5, 2012 at 12:58 AM, Edwin L. Culp W. = wrote: > > I really appreciate your help but I am having a hard time > > understanding because this has been working perfectly on FreeBSD 9.0 > > since new. ( 4 months ago ) > > > > Just incase it is important. > > > > # uname -a > > =C2=A0FreeBSD home.encontacto.net 9.0-STABLE FreeBSD 9.0-STABLE #44: Wed > > Jan =C2=A04 05:03:08 CST 2012 > > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO =C2=A0amd64 > > > > My rc.conf has > > > > keymap=3D"spanish.iso.acc.kbd" >=20 > Are you sure this is right? My rc.conf has: >=20 > keymap=3D"uk.iso" >=20 > ie, no '.kbd' file ending, which is implied. Both versions work. Try:=20 kbdcontrol -l uk.iso=20 kbdcontrol -l uk.iso.kbd --SKW69dzTt3T8RCN0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8GpxMACgkQKc512sD3afjI6QCdGJ/V7pHhx9m2AkuBpUNjmC7V Ro4An0mn11+LLP8Ds1kZRw7kT/uQ2rm/ =6UGj -----END PGP SIGNATURE----- --SKW69dzTt3T8RCN0-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 07:48:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5ED1065670 for ; Fri, 6 Jan 2012 07:48:33 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 0DDD58FC0C for ; Fri, 6 Jan 2012 07:48:32 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id D38F77F385D; Fri, 6 Jan 2012 08:31:04 +0100 (CET) Date: Fri, 6 Jan 2012 08:31:04 +0100 From: Roman Divacky To: "O. Hartmann" Message-ID: <20120106073104.GA50351@freebsd.org> References: <4F062232.1020204@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F062232.1020204@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Current FreeBSD Subject: Re: WITH_LIBCPLUSPLUS on FreeBSD 10.0-CURRENT/amd64 fails with CLANG: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:48:33 -0000 what makes you think you're using clang? On Thu, Jan 05, 2012 at 11:20:34PM +0100, O. Hartmann wrote: > When compiling most recent CURRENT on amd64 platform, using CLANG and > enabled WITH_LIBCPLUSPLUS, I receive the follwing error since two days > now. Build shown below was made avoiding -jX when doing buildworld. > > [SNIP] > rpcgen -C -c /usr/src/lib/librpcsvc/../../include/rpcsvc/ypupdate_prot.x > -o ypupdate_prot_xdr.c > rm -f .depend > CC='cc -m32 -march=native -DCOMPAT_32BIT -isystem > /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 > -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a -DYP > -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 klm_prot_xdr.c > mount_xdr.c nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c rnusers_xdr.c > rquota_xdr.c rstat_xdr.c rwall_xdr.c sm_inter_xdr.c spray_xdr.c > yppasswd_xdr.c ypxfrd_xdr.c ypupdate_prot_xdr.c > /usr/src/lib/librpcsvc/rnusers.c /usr/src/lib/librpcsvc/rstat.c > /usr/src/lib/librpcsvc/rwall.c /usr/src/lib/librpcsvc/yp_passwd.c > /usr/src/lib/librpcsvc/yp_update.c /usr/src/lib/librpcsvc/secretkey.c > /usr/src/lib/librpcsvc/xcrypt.c > ===> lib/libsbuf (depend) > ===> lib/libtacplus (depend) > ===> lib/libutil (depend) > ===> lib/libypclnt (depend) > ===> lib/libcxxrt (depend) > ===> lib/libc++ (depend) > rm -f .depend > CC='cc -m32 -march=native -DCOMPAT_32BIT -isystem > /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 > -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a > -I/usr/src/lib/libc++/../../contrib/libc++/include > -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=c++0x > /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp > /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > cc1plus: error: unrecognized command line option "-std=c++0x" > mkdep: compile failed > From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 08:40:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C60B1106564A; Fri, 6 Jan 2012 08:40:32 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 668E18FC15; Fri, 6 Jan 2012 08:40:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Rj5Lj-0001I6-DM>; Fri, 06 Jan 2012 09:40:31 +0100 Received: from e178006202.adsl.alicedsl.de ([85.178.6.202] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Rj5Lj-0000Cg-6m>; Fri, 06 Jan 2012 09:40:31 +0100 Message-ID: <4F06B378.7050404@zedat.fu-berlin.de> Date: Fri, 06 Jan 2012 09:40:24 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120101 Thunderbird/9.0 MIME-Version: 1.0 To: Roman Divacky References: <4F062232.1020204@zedat.fu-berlin.de> <20120106073104.GA50351@freebsd.org> In-Reply-To: <20120106073104.GA50351@freebsd.org> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF10EB13667C5F3055D17CBE9" X-Originating-IP: 85.178.6.202 Cc: Current FreeBSD Subject: Re: WITH_LIBCPLUSPLUS on FreeBSD 10.0-CURRENT/amd64 fails with CLANG: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:40:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF10EB13667C5F3055D17CBE9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/06/12 08:31, Roman Divacky wrote: > what makes you think you're using clang? >=20 > On Thu, Jan 05, 2012 at 11:20:34PM +0100, O. Hartmann wrote: >> When compiling most recent CURRENT on amd64 platform, using CLANG and >> enabled WITH_LIBCPLUSPLUS, I receive the follwing error since two days= >> now. Build shown below was made avoiding -jX when doing buildworld. >> My blindness and my trust in a kind of "deus ex machina" :-( Sorry. Obviously, these lines in make.conf seem to fail recently when building the sources: ### ### CLANG ### =2Eif !defined(NO_CLANG) =2Eif ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys= /*} =2Eif !defined(CC) || ${CC} =3D=3D "cc" CC=3D clang =2Eendif =2Eif !defined(CXX) || ${CXX} =3D=3D "c++" CXX=3D clang++ =2Eendif =2Eif !defined(CPP) || ${CPP} =3D=3D "cpp" CPP=3D clang-cpp =2Eendif ## Don't die on warnings NO_WERROR=3D WERROR=3D ### Don't forget this when using Jails! #NO_FSCHG=3D # CFLAGS+=3D -pipe -O3 -fno-strict-aliasing COPTFLAGS+=3D -pipe -O3 =2Eendif =2Eendif I commented out the =2Eif ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys= /*} for port's compiling purposes (some ports are pissed off when CLANG tries to compile). I commented them again and started a "make buildword" without any -jX again ... Oliver >> [SNIP] >> rpcgen -C -c /usr/src/lib/librpcsvc/../../include/rpcsvc/ypupdate_prot= =2Ex >> -o ypupdate_prot_xdr.c >> rm -f .depend >> CC=3D'cc -m32 -march=3Dnative -DCOMPAT_32BIT -isystem >> /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib3= 2 >> -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a -DYP >> -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=3Dgnu99 klm_prot_xdr= =2Ec >> mount_xdr.c nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c rnusers_xdr.c >> rquota_xdr.c rstat_xdr.c rwall_xdr.c sm_inter_xdr.c spray_xdr.c >> yppasswd_xdr.c ypxfrd_xdr.c ypupdate_prot_xdr.c >> /usr/src/lib/librpcsvc/rnusers.c /usr/src/lib/librpcsvc/rstat.c >> /usr/src/lib/librpcsvc/rwall.c /usr/src/lib/librpcsvc/yp_passwd.c >> /usr/src/lib/librpcsvc/yp_update.c /usr/src/lib/librpcsvc/secretkey.c >> /usr/src/lib/librpcsvc/xcrypt.c >> =3D=3D=3D> lib/libsbuf (depend) >> =3D=3D=3D> lib/libtacplus (depend) >> =3D=3D=3D> lib/libutil (depend) >> =3D=3D=3D> lib/libypclnt (depend) >> =3D=3D=3D> lib/libcxxrt (depend) >> =3D=3D=3D> lib/libc++ (depend) >> rm -f .depend >> CC=3D'cc -m32 -march=3Dnative -DCOMPAT_32BIT -isystem >> /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib3= 2 >> -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a >> -I/usr/src/lib/libc++/../../contrib/libc++/include >> -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=3Dc++0x >> /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp >> /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> cc1plus: error: unrecognized command line option "-std=3Dc++0x" >> mkdep: compile failed >> >=20 --------------enigF10EB13667C5F3055D17CBE9 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.18 (FreeBSD) iQEcBAEBAgAGBQJPBrN+AAoJEOgBcD7A/5N8FgUH/3sDTci1r6JWpPNWc4hJpis/ /Ow5jsvFWj3qQ5KvgW6Cnts2sgvbsXWsfwhqj1qwmwautibRQqPXadOGLKtscr4Y +oUvtaE7dDLgx2j+L/BCav/79c9eAyHnB0zRhfRYZ46lNbzGVYryNEmJODoFyT/o u4lyrJ6vkH8mnzvAwpLUCnMWltOS5NoprlJSTXY4JV5D1eFxsUkSWq2WAGd8C24P u3RN0Jct/9blKu28GoiJWYW4v09Q/3AKkRtSCT0W/JHcun74C9gfBDYL4c2BI05u Vf4WZldXaZbjKw8fNuDKbEDnNETgUpRwz9btbnLUk82BDcEysGTB8LsMvFMuPC0= =UCP8 -----END PGP SIGNATURE----- --------------enigF10EB13667C5F3055D17CBE9-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 12:17:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2B371065673; Fri, 6 Jan 2012 12:17:09 +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 C05D18FC1B; Fri, 6 Jan 2012 12:17:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06CH9Dm029324; Fri, 6 Jan 2012 07:17:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06CH8uv029267; Fri, 6 Jan 2012 12:17:08 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 12:17:08 GMT Message-Id: <201201061217.q06CH8uv029267@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: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:17:10 -0000 TB --- 2012-01-06 09:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 09:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-06 09:30:00 - cleaning the object tree TB --- 2012-01-06 09:30:30 - cvsupping the source tree TB --- 2012-01-06 09:30:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-06 09:31:00 - building world TB --- 2012-01-06 09:31:00 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 09:31:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 09:31:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 09:31:00 - SRCCONF=/dev/null TB --- 2012-01-06 09:31:00 - TARGET=pc98 TB --- 2012-01-06 09:31:00 - TARGET_ARCH=i386 TB --- 2012-01-06 09:31:00 - TZ=UTC TB --- 2012-01-06 09:31:00 - __MAKE_CONF=/dev/null TB --- 2012-01-06 09:31:00 - cd /src TB --- 2012-01-06 09:31:00 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 09:31:00 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 6 11:40:15 UTC 2012 TB --- 2012-01-06 11:40:16 - generating LINT kernel config TB --- 2012-01-06 11:40:16 - cd /src/sys/pc98/conf TB --- 2012-01-06 11:40:16 - /usr/bin/make -B LINT TB --- 2012-01-06 11:40:16 - cd /src/sys/pc98/conf TB --- 2012-01-06 11:40:16 - /usr/sbin/config -m LINT TB --- 2012-01-06 11:40:16 - building LINT kernel TB --- 2012-01-06 11:40:16 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 11:40:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 11:40:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 11:40:16 - SRCCONF=/dev/null TB --- 2012-01-06 11:40:16 - TARGET=pc98 TB --- 2012-01-06 11:40:16 - TARGET_ARCH=i386 TB --- 2012-01-06 11:40:16 - TZ=UTC TB --- 2012-01-06 11:40:16 - __MAKE_CONF=/dev/null TB --- 2012-01-06 11:40:16 - cd /src TB --- 2012-01-06 11:40:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 6 11:40:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Jan 6 12:09:01 UTC 2012 TB --- 2012-01-06 12:09:01 - cd /src/sys/pc98/conf TB --- 2012-01-06 12:09:01 - /usr/sbin/config -m GENERIC TB --- 2012-01-06 12:09:01 - building GENERIC kernel TB --- 2012-01-06 12:09:01 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 12:09:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 12:09:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 12:09:01 - SRCCONF=/dev/null TB --- 2012-01-06 12:09:01 - TARGET=pc98 TB --- 2012-01-06 12:09:01 - TARGET_ARCH=i386 TB --- 2012-01-06 12:09:01 - TZ=UTC TB --- 2012-01-06 12:09:01 - __MAKE_CONF=/dev/null TB --- 2012-01-06 12:09:01 - cd /src TB --- 2012-01-06 12:09:01 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 6 12:09:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 12:17:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 12:17:08 - ERROR: failed to build GENERIC kernel TB --- 2012-01-06 12:17:08 - 7947.52 user 1428.65 system 10027.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 12:49:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D512B1065672; Fri, 6 Jan 2012 12:49:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9031B8FC13; Fri, 6 Jan 2012 12:49:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a142:4d3d:445:4dd1] (unknown [IPv6:2001:7b8:3a7:0:a142:4d3d:445:4dd1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 977485C37; Fri, 6 Jan 2012 13:49:44 +0100 (CET) Message-ID: <4F06EDEC.5030805@FreeBSD.org> Date: Fri, 06 Jan 2012 13:49:48 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "O. Hartmann" References: <4F062232.1020204@zedat.fu-berlin.de> <20120106073104.GA50351@freebsd.org> <4F06B378.7050404@zedat.fu-berlin.de> In-Reply-To: <4F06B378.7050404@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , Current FreeBSD Subject: Re: WITH_LIBCPLUSPLUS on FreeBSD 10.0-CURRENT/amd64 fails with CLANG: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:49:45 -0000 On 2012-01-06 09:40, O. Hartmann wrote: ... > Obviously, these lines in make.conf seem to fail recently when building > the sources: > > ### > ### CLANG > ### > > .if !defined(NO_CLANG) > .if ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys/*} Hi Oliver, The problem is that the ${.CURDIR:M/usr/src/*} expressions are wrong, they will not match when you are *exactly* in /usr/src or in /usr/obj. So for any operations in the "root" of your source checkout, or of your object directory, CC will still be 'cc', and unexpected things will happen. It is better to use: .if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*} || ${.CURDIR:M/sys*} or if you want to be strict: .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/obj} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys} || ${.CURDIR:M/sys/*} It is similar to a problem another user reported on freebsd-stable (though he got a weird linker error instead): http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/065172.html After some analysis, it turned out he had the same problem in his make.conf: http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/065183.html From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 14:16:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4676106564A for ; Fri, 6 Jan 2012 14:16:52 +0000 (UTC) (envelope-from fbsdq@peterk.org) Received: from poshta.pknet.net (poshta.pknet.net [216.241.167.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA2C8FC12 for ; Fri, 6 Jan 2012 14:16:52 +0000 (UTC) Received: (qmail 50295 invoked by uid 89); 6 Jan 2012 14:16:51 -0000 Received: from localhost (HELO pop.pknet.net) (127.0.0.1) by poshta.pknet.net with ESMTP; 6 Jan 2012 14:16:51 -0000 Received: from 74.63.162.21 (SquirrelMail authenticated user fbsdq@peterk.org) by pop.pknet.net with HTTP; Fri, 6 Jan 2012 07:16:51 -0700 Message-ID: In-Reply-To: References: <5eac2995697ee99fcfda6d071ad09edc.squirrel@pop.pknet.net> Date: Fri, 6 Jan 2012 07:16:51 -0700 From: "Peter" To: "Garrett Cooper" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Peter , freebsd-current@freebsd.org Subject: Re: stable/9 still looking for packages at 9-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 14:16:52 -0000 > On Thu, Jan 5, 2012 at 2:12 PM, Peter wrote: >> Hello, >>  Installed 9-RELEASE amd64, svn the latest stable/9 sources, >> built/installed kernel/world and did pkg_add - It is still by default >> pointing at -current: >> >> pkbsdpkg:#uname -a >> FreeBSD pkbsdpkg 9.0-STABLE FreeBSD 9.0-STABLE #0 r229599: Thu Jan  5 >> 10:23:52 MST 2012     peter@pkbsd.pk.pb:/usr/obj/usr/src/sys/GENERIC >> amd64 >> pkbsdpkg:#echo $PACKAGESITE >> >> pkbsdpkg:#pkg_add -r test >> Error: Unable to get >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/test.tbz: >> File unavailable (e.g., file not found, no access) >> pkg_add: unable to fetch >> 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/test.tbz' >> by URL >> pkbsdpkg:# >> >> >> pkbsdpkg:#pwd >> /usr/src/usr.sbin/pkg_install >> pkbsdpkg:#grep -R packages-9 * >> add/main.c:     { 900000, 900499, "/packages-9.0-release" }, >> add/main.c:     { 900000, 999000, "/packages-9-current" }, >> >> ??? >> >> On a fresh 9-release install works properly: >> 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 >> root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> [15:10] igormolko: pkg_add -r test >> Error: Unable to get >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/test.tbz: >> File unavailable (e.g., file not found, no access) >> pkg_add: unable to fetch >> 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/test.tbz' >> by URL > > svn up / c[v]sup your tree. It was recently merged/fixed by kensmith. > Thanks, > -Garrett Not for stable/9 [__FreeBSD_version 900500+: pkbsd:#pwd /usr/src pkbsd:#svn up Updating '.': At revision 229701. pkbsd:#svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.freebsd.org/base/stable/9 Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 229701 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 229695 Last Changed Date: 2012-01-06 04:06:15 -0700 (Fri, 06 Jan 2012) pkbsd:#grep -R packages-9 /usr/src/usr.sbin/pkg_install/* /usr/src/usr.sbin/pkg_install/add/main.c: { 900000, 900499, "/packages-9.0-release" }, /usr/src/usr.sbin/pkg_install/add/main.c: { 900000, 999000, "/packages-9-current" }, ]Peter[ From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 14:58:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D327106564A; Fri, 6 Jan 2012 14:58:16 +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 A4EF38FC12; Fri, 6 Jan 2012 14:58:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06EwEPo004995; Fri, 6 Jan 2012 09:58:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06EwEu4004973; Fri, 6 Jan 2012 14:58:14 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 14:58:14 GMT Message-Id: <201201061458.q06EwEu4004973@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 14:58:16 -0000 TB --- 2012-01-06 09:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 09:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-06 09:30:00 - cleaning the object tree TB --- 2012-01-06 09:30:55 - cvsupping the source tree TB --- 2012-01-06 09:30:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-06 09:31:08 - building world TB --- 2012-01-06 09:31:08 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 09:31:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 09:31:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 09:31:08 - SRCCONF=/dev/null TB --- 2012-01-06 09:31:08 - TARGET=i386 TB --- 2012-01-06 09:31:08 - TARGET_ARCH=i386 TB --- 2012-01-06 09:31:08 - TZ=UTC TB --- 2012-01-06 09:31:08 - __MAKE_CONF=/dev/null TB --- 2012-01-06 09:31:08 - cd /src TB --- 2012-01-06 09:31:08 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 09:31:09 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 6 11:40:51 UTC 2012 TB --- 2012-01-06 11:40:51 - generating LINT kernel config TB --- 2012-01-06 11:40:51 - cd /src/sys/i386/conf TB --- 2012-01-06 11:40:51 - /usr/bin/make -B LINT TB --- 2012-01-06 11:40:51 - cd /src/sys/i386/conf TB --- 2012-01-06 11:40:51 - /usr/sbin/config -m LINT TB --- 2012-01-06 11:40:51 - building LINT kernel TB --- 2012-01-06 11:40:51 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 11:40:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 11:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 11:40:51 - SRCCONF=/dev/null TB --- 2012-01-06 11:40:51 - TARGET=i386 TB --- 2012-01-06 11:40:51 - TARGET_ARCH=i386 TB --- 2012-01-06 11:40:51 - TZ=UTC TB --- 2012-01-06 11:40:51 - __MAKE_CONF=/dev/null TB --- 2012-01-06 11:40:51 - cd /src TB --- 2012-01-06 11:40:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 6 11:40:51 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Jan 6 12:13:08 UTC 2012 TB --- 2012-01-06 12:13:08 - cd /src/sys/i386/conf TB --- 2012-01-06 12:13:08 - /usr/sbin/config -m LINT-NOINET TB --- 2012-01-06 12:13:08 - building LINT-NOINET kernel TB --- 2012-01-06 12:13:08 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 12:13:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 12:13:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 12:13:08 - SRCCONF=/dev/null TB --- 2012-01-06 12:13:08 - TARGET=i386 TB --- 2012-01-06 12:13:08 - TARGET_ARCH=i386 TB --- 2012-01-06 12:13:08 - TZ=UTC TB --- 2012-01-06 12:13:08 - __MAKE_CONF=/dev/null TB --- 2012-01-06 12:13:08 - cd /src TB --- 2012-01-06 12:13:08 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Jan 6 12:13:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Jan 6 12:43:56 UTC 2012 TB --- 2012-01-06 12:43:56 - cd /src/sys/i386/conf TB --- 2012-01-06 12:43:56 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-01-06 12:43:56 - building LINT-NOINET6 kernel TB --- 2012-01-06 12:43:56 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 12:43:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 12:43:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 12:43:56 - SRCCONF=/dev/null TB --- 2012-01-06 12:43:56 - TARGET=i386 TB --- 2012-01-06 12:43:56 - TARGET_ARCH=i386 TB --- 2012-01-06 12:43:56 - TZ=UTC TB --- 2012-01-06 12:43:56 - __MAKE_CONF=/dev/null TB --- 2012-01-06 12:43:56 - cd /src TB --- 2012-01-06 12:43:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Jan 6 12:43:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Fri Jan 6 13:15:17 UTC 2012 TB --- 2012-01-06 13:15:17 - cd /src/sys/i386/conf TB --- 2012-01-06 13:15:17 - /usr/sbin/config -m LINT-NOIP TB --- 2012-01-06 13:15:17 - building LINT-NOIP kernel TB --- 2012-01-06 13:15:17 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 13:15:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 13:15:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 13:15:17 - SRCCONF=/dev/null TB --- 2012-01-06 13:15:17 - TARGET=i386 TB --- 2012-01-06 13:15:17 - TARGET_ARCH=i386 TB --- 2012-01-06 13:15:17 - TZ=UTC TB --- 2012-01-06 13:15:17 - __MAKE_CONF=/dev/null TB --- 2012-01-06 13:15:17 - cd /src TB --- 2012-01-06 13:15:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Fri Jan 6 13:15:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Fri Jan 6 13:43:58 UTC 2012 TB --- 2012-01-06 13:43:58 - cd /src/sys/i386/conf TB --- 2012-01-06 13:43:58 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-01-06 13:43:58 - building LINT-VIMAGE kernel TB --- 2012-01-06 13:43:58 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 13:43:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 13:43:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 13:43:58 - SRCCONF=/dev/null TB --- 2012-01-06 13:43:58 - TARGET=i386 TB --- 2012-01-06 13:43:58 - TARGET_ARCH=i386 TB --- 2012-01-06 13:43:58 - TZ=UTC TB --- 2012-01-06 13:43:58 - __MAKE_CONF=/dev/null TB --- 2012-01-06 13:43:58 - cd /src TB --- 2012-01-06 13:43:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Fri Jan 6 13:43:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Fri Jan 6 14:15:40 UTC 2012 TB --- 2012-01-06 14:15:40 - cd /src/sys/i386/conf TB --- 2012-01-06 14:15:40 - /usr/sbin/config -m GENERIC TB --- 2012-01-06 14:15:41 - building GENERIC kernel TB --- 2012-01-06 14:15:41 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 14:15:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 14:15:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 14:15:41 - SRCCONF=/dev/null TB --- 2012-01-06 14:15:41 - TARGET=i386 TB --- 2012-01-06 14:15:41 - TARGET_ARCH=i386 TB --- 2012-01-06 14:15:41 - TZ=UTC TB --- 2012-01-06 14:15:41 - __MAKE_CONF=/dev/null TB --- 2012-01-06 14:15:41 - cd /src TB --- 2012-01-06 14:15:41 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 6 14:15:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Jan 6 14:41:04 UTC 2012 TB --- 2012-01-06 14:41:04 - cd /src/sys/i386/conf TB --- 2012-01-06 14:41:04 - /usr/sbin/config -m PAE TB --- 2012-01-06 14:41:04 - building PAE kernel TB --- 2012-01-06 14:41:04 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 14:41:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 14:41:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 14:41:04 - SRCCONF=/dev/null TB --- 2012-01-06 14:41:04 - TARGET=i386 TB --- 2012-01-06 14:41:04 - TARGET_ARCH=i386 TB --- 2012-01-06 14:41:04 - TZ=UTC TB --- 2012-01-06 14:41:04 - __MAKE_CONF=/dev/null TB --- 2012-01-06 14:41:04 - cd /src TB --- 2012-01-06 14:41:04 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Jan 6 14:41:04 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Jan 6 14:47:51 UTC 2012 TB --- 2012-01-06 14:47:51 - cd /src/sys/i386/conf TB --- 2012-01-06 14:47:51 - /usr/sbin/config -m XBOX TB --- 2012-01-06 14:47:51 - building XBOX kernel TB --- 2012-01-06 14:47:51 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 14:47:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 14:47:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 14:47:51 - SRCCONF=/dev/null TB --- 2012-01-06 14:47:51 - TARGET=i386 TB --- 2012-01-06 14:47:51 - TARGET_ARCH=i386 TB --- 2012-01-06 14:47:51 - TZ=UTC TB --- 2012-01-06 14:47:51 - __MAKE_CONF=/dev/null TB --- 2012-01-06 14:47:51 - cd /src TB --- 2012-01-06 14:47:51 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Fri Jan 6 14:47:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Fri Jan 6 14:51:11 UTC 2012 TB --- 2012-01-06 14:51:11 - cd /src/sys/i386/conf TB --- 2012-01-06 14:51:11 - /usr/sbin/config -m XEN TB --- 2012-01-06 14:51:11 - building XEN kernel TB --- 2012-01-06 14:51:11 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 14:51:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 14:51:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 14:51:11 - SRCCONF=/dev/null TB --- 2012-01-06 14:51:11 - TARGET=i386 TB --- 2012-01-06 14:51:11 - TARGET_ARCH=i386 TB --- 2012-01-06 14:51:11 - TZ=UTC TB --- 2012-01-06 14:51:11 - __MAKE_CONF=/dev/null TB --- 2012-01-06 14:51:11 - cd /src TB --- 2012-01-06 14:51:11 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Jan 6 14:51:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 14:58:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 14:58:14 - ERROR: failed to build XEN kernel TB --- 2012-01-06 14:58:14 - 15654.05 user 2704.86 system 19693.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 15:36:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D50031065675; Fri, 6 Jan 2012 15:36:06 +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 A07E38FC0A; Fri, 6 Jan 2012 15:36:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06Fa5lX091667; Fri, 6 Jan 2012 10:36:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06Fa5GT091658; Fri, 6 Jan 2012 15:36:05 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 15:36:05 GMT Message-Id: <201201061536.q06Fa5GT091658@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: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:36:07 -0000 TB --- 2012-01-06 14:09:40 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 14:09:40 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-01-06 14:09:40 - cleaning the object tree TB --- 2012-01-06 14:10:00 - cvsupping the source tree TB --- 2012-01-06 14:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-01-06 14:10:13 - building world TB --- 2012-01-06 14:10:13 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 14:10:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 14:10:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 14:10:13 - SRCCONF=/dev/null TB --- 2012-01-06 14:10:13 - TARGET=powerpc TB --- 2012-01-06 14:10:13 - TARGET_ARCH=powerpc64 TB --- 2012-01-06 14:10:13 - TZ=UTC TB --- 2012-01-06 14:10:13 - __MAKE_CONF=/dev/null TB --- 2012-01-06 14:10:13 - cd /src TB --- 2012-01-06 14:10:13 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 14:10:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils -I. -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp c++ -O2 -pipe -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils -I. -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SSAUpdater.cpp c++ -O2 -pipe -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils -I. -I/src/lib/clang/libllvmtransformutils/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SimplifyCFG.cpp /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SimplifyCFG.cpp: In function 'bool SimplifyCondBranchToTwoReturns(llvm::BranchInst*, llvm::IRBuilder >&)': /src/lib/clang/libllvmtransformutils/../../../contrib/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1380: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libllvmtransformutils. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 15:36:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 15:36:05 - ERROR: failed to build world TB --- 2012-01-06 15:36:05 - 4295.80 user 631.52 system 5185.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 15:48:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34807106566B; Fri, 6 Jan 2012 15:48:39 +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 D31738FC18; Fri, 6 Jan 2012 15:48:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06FmbCd037109; Fri, 6 Jan 2012 10:48:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06FmbQn037103; Fri, 6 Jan 2012 15:48:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 15:48:37 GMT Message-Id: <201201061548.q06FmbQn037103@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: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:48:39 -0000 TB --- 2012-01-06 14:58:14 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 14:58:14 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-01-06 14:58:14 - cleaning the object tree TB --- 2012-01-06 14:58:30 - cvsupping the source tree TB --- 2012-01-06 14:58:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-01-06 14:58:42 - building world TB --- 2012-01-06 14:58:42 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 14:58:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 14:58:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 14:58:42 - SRCCONF=/dev/null TB --- 2012-01-06 14:58:42 - TARGET=sparc64 TB --- 2012-01-06 14:58:42 - TARGET_ARCH=sparc64 TB --- 2012-01-06 14:58:42 - TZ=UTC TB --- 2012-01-06 14:58:42 - __MAKE_CONF=/dev/null TB --- 2012-01-06 14:58:42 - cd /src TB --- 2012-01-06 14:58:42 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 14:58:42 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_capture.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_script.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o ddb ddb.o ddb_capture.o ddb_script.o -lkvm gzip -cn /src/sbin/ddb/ddb.8 > ddb.8.gz ===> sbin/devd (all) c++ -O2 -pipe -I. -I/src/sbin/devd -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In constructor 'media::media(config&, const char*, const char*)': /src/sbin/devd/devd.cc:301: error: 'IFM_CARP' was not declared in this scope *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 15:48:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 15:48:37 - ERROR: failed to build world TB --- 2012-01-06 15:48:37 - 2319.24 user 553.76 system 3022.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 16:57:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898A1106564A; Fri, 6 Jan 2012 16:57:51 +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 282AD8FC14; Fri, 6 Jan 2012 16:57:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06Gvov5019981; Fri, 6 Jan 2012 11:57:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06GvoI4019980; Fri, 6 Jan 2012 16:57:50 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 16:57:50 GMT Message-Id: <201201061657.q06GvoI4019980@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: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:57:51 -0000 TB --- 2012-01-06 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 16:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-01-06 16:10:00 - cleaning the object tree TB --- 2012-01-06 16:10:39 - cvsupping the source tree TB --- 2012-01-06 16:10:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-01-06 16:10:58 - building world TB --- 2012-01-06 16:10:58 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 16:10:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 16:10:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 16:10:58 - SRCCONF=/dev/null TB --- 2012-01-06 16:10:58 - TARGET=arm TB --- 2012-01-06 16:10:58 - TARGET_ARCH=arm TB --- 2012-01-06 16:10:58 - TZ=UTC TB --- 2012-01-06 16:10:58 - __MAKE_CONF=/dev/null TB --- 2012-01-06 16:10:58 - cd /src TB --- 2012-01-06 16:10:58 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 16:10:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_capture.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_script.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o ddb ddb.o ddb_capture.o ddb_script.o -lkvm gzip -cn /src/sbin/ddb/ddb.8 > ddb.8.gz ===> sbin/devd (all) c++ -O -pipe -I. -I/src/sbin/devd -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In constructor 'media::media(config&, const char*, const char*)': /src/sbin/devd/devd.cc:301: error: 'IFM_CARP' was not declared in this scope *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 16:57:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 16:57:49 - ERROR: failed to build world TB --- 2012-01-06 16:57:49 - 2009.04 user 625.67 system 2869.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 17:15:06 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027BF106566B for ; Fri, 6 Jan 2012 17:15:06 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) by mx1.freebsd.org (Postfix) with ESMTP id B72918FC0A for ; Fri, 6 Jan 2012 17:15:05 +0000 (UTC) Received: from p57918c7a.dip.t-dialin.net ([87.145.140.122] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RjDNg-0005P1-6g for freebsd-current@FreeBSD.org; Fri, 06 Jan 2012 18:15:04 +0100 Message-ID: <4F072C13.6000606@gwdg.de> Date: Fri, 06 Jan 2012 18:14:59 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Subject: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:15:06 -0000 I am getting the following error when trying to build recent 10.0-CURRENT kernel (amd64)? [..snip..] cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/RHURLIN -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /usr/src/sys/modules/ath. *** Error code 1 I observe this behaviour on three boxes. Any help is really appreciated. Thanks in advance, Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 17:30:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C4EF106566B for ; Fri, 6 Jan 2012 17:30:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 250178FC24 for ; Fri, 6 Jan 2012 17:30:09 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so2225071vcb.13 for ; Fri, 06 Jan 2012 09:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G0k8TnxFOVMjFyGgxIh+2YoD0ZxoizRAhhkfi8+nzHQ=; b=AeCtb0QF9cQ4puJlbC15OzJuDiymeapIPmpYzhDkeBb1wy4DyFMuHna4f5lmeNp0om 7nONVNLh/ryDAsQieFXy4FDR+DJeVMGP2VI+Kjg37e8Q6o/wypNG4gOXi0mLjC/1XiRM BumTZMdzuIvAz7tAFt6Ifkc41k/MhOpuY1doE= MIME-Version: 1.0 Received: by 10.220.156.134 with SMTP id x6mr4220666vcw.17.1325871009356; Fri, 06 Jan 2012 09:30:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 09:30:09 -0800 (PST) In-Reply-To: <4F072C13.6000606@gwdg.de> References: <4F072C13.6000606@gwdg.de> Date: Fri, 6 Jan 2012 09:30:09 -0800 X-Google-Sender-Auth: ovKb5nph1tL72eNhz0F0E16ORew Message-ID: From: Adrian Chadd To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:30:10 -0000 i thought I had captured these. just add options AH_SUPPORT_AR5416 to your kernel. Adrian On 6 January 2012 09:14, Rainer Hurling wrote: > I am getting the following error when trying to build recent 10.0-CURRENT > kernel (amd64)? > > [..snip..] > cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Werror -D_KERNEL > -DKLD_MODULE -nostdinc =A0-I. -I/usr/src/sys/modules/ath/../../dev/ath > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 -fno-common =A0-fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/RHURLIN =A0-mno-sse -mcmodel=3Dkernel -mno-red-zon= e > -mno-mmx -msoft-float =A0-fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototyp= es > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option = =A0 =A0-c > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function > 'ath_tx_aggr_comp_aggr': > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct > ath_tx_status' has no member named 'ts_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct > ath_tx_status' has no member named 'ts_ba_low' > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct > ath_tx_status' has no member named 'ts_ba_high' > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct > ath_tx_status' has no member named 'ts_tid' > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct > ath_tx_status' has no member named 'ts_tid' > *** Error code 1 > Stop in /usr/src/sys/modules/ath. > *** Error code 1 > > > I observe this behaviour on three boxes. Any help is really appreciated. > > Thanks in advance, > Rainer Hurling > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:06:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77DCB106566B; Fri, 6 Jan 2012 18:06:10 +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 13DA48FC12; Fri, 6 Jan 2012 18:06:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06I69xV090017; Fri, 6 Jan 2012 13:06:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06I69SO089992; Fri, 6 Jan 2012 18:06:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 18:06:09 GMT Message-Id: <201201061806.q06I69SO089992@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:06:10 -0000 TB --- 2012-01-06 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 16:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-06 16:10:00 - cleaning the object tree TB --- 2012-01-06 16:11:13 - cvsupping the source tree TB --- 2012-01-06 16:11:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-06 16:11:26 - building world TB --- 2012-01-06 16:11:26 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 16:11:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 16:11:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 16:11:26 - SRCCONF=/dev/null TB --- 2012-01-06 16:11:26 - TARGET=i386 TB --- 2012-01-06 16:11:26 - TARGET_ARCH=i386 TB --- 2012-01-06 16:11:26 - TZ=UTC TB --- 2012-01-06 16:11:26 - __MAKE_CONF=/dev/null TB --- 2012-01-06 16:11:26 - cd /src TB --- 2012-01-06 16:11:26 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 16:11:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_capture.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_script.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o ddb ddb.o ddb_capture.o ddb_script.o -lkvm gzip -cn /src/sbin/ddb/ddb.8 > ddb.8.gz ===> sbin/devd (all) c++ -O2 -pipe -I. -I/src/sbin/devd -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In constructor 'media::media(config&, const char*, const char*)': /src/sbin/devd/devd.cc:301: error: 'IFM_CARP' was not declared in this scope *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 18:06:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 18:06:08 - ERROR: failed to build world TB --- 2012-01-06 18:06:08 - 5612.89 user 951.83 system 6968.03 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:06:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2027F1065670; Fri, 6 Jan 2012 18:06:13 +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 B876D8FC16; Fri, 6 Jan 2012 18:06:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06I6Cmj090296; Fri, 6 Jan 2012 13:06:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06I6CBT090291; Fri, 6 Jan 2012 18:06:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 18:06:12 GMT Message-Id: <201201061806.q06I6CBT090291@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: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:06:13 -0000 TB --- 2012-01-06 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 16:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-01-06 16:10:00 - cleaning the object tree TB --- 2012-01-06 16:10:39 - cvsupping the source tree TB --- 2012-01-06 16:10:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-01-06 16:10:58 - building world TB --- 2012-01-06 16:10:58 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 16:10:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 16:10:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 16:10:58 - SRCCONF=/dev/null TB --- 2012-01-06 16:10:58 - TARGET=pc98 TB --- 2012-01-06 16:10:58 - TARGET_ARCH=i386 TB --- 2012-01-06 16:10:58 - TZ=UTC TB --- 2012-01-06 16:10:58 - __MAKE_CONF=/dev/null TB --- 2012-01-06 16:10:58 - cd /src TB --- 2012-01-06 16:10:58 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 16:10:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_capture.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_script.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o ddb ddb.o ddb_capture.o ddb_script.o -lkvm gzip -cn /src/sbin/ddb/ddb.8 > ddb.8.gz ===> sbin/devd (all) c++ -O2 -pipe -I. -I/src/sbin/devd -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In constructor 'media::media(config&, const char*, const char*)': /src/sbin/devd/devd.cc:301: error: 'IFM_CARP' was not declared in this scope *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 18:06:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 18:06:12 - ERROR: failed to build world TB --- 2012-01-06 18:06:12 - 5605.61 user 965.97 system 6971.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:07:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0901065673; Fri, 6 Jan 2012 18:07:06 +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 39E7A8FC1A; Fri, 6 Jan 2012 18:07:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q06I75QQ094170; Fri, 6 Jan 2012 13:07:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q06I75xY094169; Fri, 6 Jan 2012 18:07:05 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Jan 2012 18:07:05 GMT Message-Id: <201201061807.q06I75xY094169@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: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:07:06 -0000 TB --- 2012-01-06 16:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 16:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-01-06 16:10:00 - cleaning the object tree TB --- 2012-01-06 16:11:13 - cvsupping the source tree TB --- 2012-01-06 16:11:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-01-06 16:11:25 - building world TB --- 2012-01-06 16:11:25 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 16:11:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 16:11:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 16:11:25 - SRCCONF=/dev/null TB --- 2012-01-06 16:11:25 - TARGET=amd64 TB --- 2012-01-06 16:11:25 - TARGET_ARCH=amd64 TB --- 2012-01-06 16:11:25 - TZ=UTC TB --- 2012-01-06 16:11:25 - __MAKE_CONF=/dev/null TB --- 2012-01-06 16:11:25 - cd /src TB --- 2012-01-06 16:11:25 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 16:11:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_capture.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ddb/ddb_script.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o ddb ddb.o ddb_capture.o ddb_script.o -lkvm gzip -cn /src/sbin/ddb/ddb.8 > ddb.8.gz ===> sbin/devd (all) c++ -O2 -pipe -I. -I/src/sbin/devd -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In constructor 'media::media(config&, const char*, const char*)': /src/sbin/devd/devd.cc:301: error: 'IFM_CARP' was not declared in this scope *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-06 18:07:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-06 18:07:05 - ERROR: failed to build world TB --- 2012-01-06 18:07:05 - 5643.40 user 962.36 system 7024.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:19:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 562781065675 for ; Fri, 6 Jan 2012 18:19:10 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) by mx1.freebsd.org (Postfix) with ESMTP id D9EF88FC08 for ; Fri, 6 Jan 2012 18:19:09 +0000 (UTC) Received: from p57918c7a.dip.t-dialin.net ([87.145.140.122] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RjENg-0005fo-6k; Fri, 06 Jan 2012 19:19:08 +0100 Message-ID: <4F073B1B.6000707@gwdg.de> Date: Fri, 06 Jan 2012 19:19:07 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd References: <4F072C13.6000606@gwdg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:19:10 -0000 On 06.01.2012 18:30 (UTC+1), Adrian Chadd wrote: > i thought I had captured these. > > just add > > options AH_SUPPORT_AR5416 > > to your kernel. Ah, I indeed missed the new option in GENERIC, because I build with modified kernel config file. I commented all wireless network drivers and their options out. But the error remains. Is it necessary to have this option uncommented even when the driver ath is commented out? Many thanks for your fast response, Rainer > Adrian > > On 6 January 2012 09:14, Rainer Hurling wrote: >> I am getting the following error when trying to build recent 10.0-CURRENT >> kernel (amd64)? >> >> [..snip..] >> cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -Werror -D_KERNEL >> -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../dev/ath >> -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal >> -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-common -fno-omit-frame-pointer >> -I/usr/obj/usr/src/sys/RHURLIN -mno-sse -mcmodel=kernel -mno-red-zone >> -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >> -fstack-protector -std=iso9899:1999 -fstack-protector -Wall >> -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign >> -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function >> 'ath_tx_aggr_comp_aggr': >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct >> ath_tx_status' has no member named 'ts_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct >> ath_tx_status' has no member named 'ts_ba_low' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct >> ath_tx_status' has no member named 'ts_ba_high' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct >> ath_tx_status' has no member named 'ts_tid' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct >> ath_tx_status' has no member named 'ts_tid' >> *** Error code 1 >> Stop in /usr/src/sys/modules/ath. >> *** Error code 1 >> >> >> I observe this behaviour on three boxes. Any help is really appreciated. >> >> Thanks in advance, >> Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:09:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F6E10656D1 for ; Fri, 6 Jan 2012 18:09:28 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from moh1-ve1.go2.pl (moh1-ve1.go2.pl [193.17.41.131]) by mx1.freebsd.org (Postfix) with ESMTP id E51338FC13 for ; Fri, 6 Jan 2012 18:09:27 +0000 (UTC) Received: from moh1-ve1.go2.pl (unknown [10.0.0.131]) by moh1-ve1.go2.pl (Postfix) with ESMTP id B290191E9BB for ; Fri, 6 Jan 2012 19:09:14 +0100 (CET) Received: from unknown (unknown [10.0.0.142]) by moh1-ve1.go2.pl (Postfix) with SMTP for ; Fri, 6 Jan 2012 19:09:14 +0100 (CET) Received: from host892524678.com-promis.3s.pl [89.25.246.78] by poczta.o2.pl with ESMTP id nAtGKr; Fri, 06 Jan 2012 19:09:14 +0100 Message-ID: <4F0738C7.4000003@o2.pl> Date: Fri, 06 Jan 2012 19:09:11 +0100 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: kabaev@gmail.com References: <20120105200331.95D63106576D@hub.freebsd.org> In-Reply-To: <20120105200331.95D63106576D@hub.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-O2-Trust: 2, 67 X-O2-SPF: neutral X-Mailman-Approved-At: Fri, 06 Jan 2012 18:29:38 +0000 Cc: freebsd-current@freebsd.org Subject: Re: freebsd-current Digest, Vol 429, Issue 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:09:28 -0000 On 2012-01-05 21:03, kabaev@gmail.com wrote: > On Wed, 04 Jan 2012 14:31:55 -0800 > wrote: > >> > Thanks for the comment Arnaud. For comparative benchmarking >> > on [1]Phoronix.com, Michael inva configuration 'in the way the >> > developers or production'. This is by rule. However, i poor >> > scores on be 'it should be tuned, is configured for a diffe The >> > response from us to this comes in two forms.&nb 1) If it is the >> > wrong workload for the platform, do a public pos explaining and >> > analysing the results. Highlighting the rationale fo r the >> > concious reduction in performance (ie: journaling filesystems with >> > ba filesystem integrity 2) If tuning can have a material impact >> > on the results, post a t uning guide with step by step and >> > rationale. Ie: educate the communit Michael and I have had many >> > discussions with vendors an on this. In almost all cases, the >> > vendor has either cha default configuration or accepted the results >> > as valid. As guide, Micha comparison. To dat offer. In part, >> > thi public, but that is more of a result of a one sided d party >> > external to a particular community (with a healthy tou >> > journalisticly pumped compare& contrast). For the FreeBSD >> > community, who else outside of the FreeBSD community actually runs >> > public c Matthew > Not really related to the discussion on hand, but the above about the > most unreadable email I am yet to read on the public mailing list. Yeah, I actually ignored it because of poor readability. -- Twoje radio From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:35:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 261F8106566C for ; Fri, 6 Jan 2012 18:35:32 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E34FC8FC0C for ; Fri, 6 Jan 2012 18:35:31 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3108863obb.13 for ; Fri, 06 Jan 2012 10:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HeRTtGJ29H5QsKuZYcf+ZI9P2Gq6eejian7ro6bMydo=; b=sV4782BN52S2pJoIPMb8g0W9coJ6JiW/RFQDqGQtS9ksD21cIHcTS9GsDIv4JZB7mr ES4lQ1VheSHSm3oO0Pos3oudA+YtTf2Nsr0WOD62Qi190Z6YEnRw+dX6mQf8+WXO/37p MfbStlzX95MYwME1WG+wnzdTu2xozVeA5BWu8= MIME-Version: 1.0 Received: by 10.182.76.134 with SMTP id k6mr5763605obw.10.1325874931389; Fri, 06 Jan 2012 10:35:31 -0800 (PST) Received: by 10.182.171.67 with HTTP; Fri, 6 Jan 2012 10:35:31 -0800 (PST) In-Reply-To: <201201061850.33863.pinter@tresorium.hu> References: <201201061850.33863.pinter@tresorium.hu> Date: Fri, 6 Jan 2012 21:35:31 +0300 Message-ID: From: Sergey Kandaurov To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: [RFC] fix git detection code in newvers.sh when svn installed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:35:32 -0000 On 6 January 2012 21:50, Oliver Pinter wrote: > Hi All! > > When svn installed and the source stored in git, then now the version > detection failed. The attached patch fixed this situation. > FWIW, a different version proposed by Maciej Milewski on -current some time ago. I don't have/use git, so I cannot test these changes. It is good in the sense that it doesn't duplicate a search path. The patch is below for reference: --- sys/conf/newvers.sh 2011-11-19 00:56:50.795815738 +0100 +++ sys/conf/newvers-patched.sh 2011-11-19 00:58:21.187818982 +0100 @@ -88,14 +88,14 @@ i=`${MAKE:-make} -V KERN_IDENT` for dir in /bin /usr/bin /usr/local/bin; do - if [ -x "${dir}/svnversion" ] ; then - svnversion=${dir}/svnversion - break - fi if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git" break fi + if [ -x "${dir}/svnversion" ] ; then + svnversion=${dir}/svnversion + break + fi done if [ -n "$svnversion" ] ; then -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 18:22:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 729141065751; Fri, 6 Jan 2012 18:22:07 +0000 (UTC) (envelope-from pinter@tresorium.hu) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB14A8FC20; Fri, 6 Jan 2012 18:22:06 +0000 (UTC) Received: by eekc50 with SMTP id c50so1442170eek.13 for ; Fri, 06 Jan 2012 10:22:05 -0800 (PST) Received: by 10.14.125.210 with SMTP id z58mr2604447eeh.100.1325872242590; Fri, 06 Jan 2012 09:50:42 -0800 (PST) Received: from peonia (peonia.teteny.elte.hu. [157.181.96.25]) by mx.google.com with ESMTPS id e12sm99713469eea.5.2012.01.06.09.50.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 09:50:41 -0800 (PST) From: Oliver Pinter Organization: Tresorium Ltd. To: stable@freebsd.org Date: Fri, 6 Jan 2012 18:50:33 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_pRzBPReUZlYSbPc" Message-Id: <201201061850.33863.pinter@tresorium.hu> X-Mailman-Approved-At: Fri, 06 Jan 2012 19:05:32 +0000 Cc: current@freebsd.org Subject: [RFC] fix git detection code in newvers.sh when svn installed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:22:07 -0000 --Boundary-00=_pRzBPReUZlYSbPc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All! When svn installed and the source stored in git, then now the version detection failed. The attached patch fixed this situation. -- Oliver Pinter (Tresorium) --Boundary-00=_pRzBPReUZlYSbPc Content-Type: text/x-diff; charset="iso 8859-15"; name="20120103121800-fix-newvers-sh-git.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="20120103121800-fix-newvers-sh-git.diff" =46rom a84c998c251a83ba3fa3c734b7fbc6fe1af17c6a Mon Sep 17 00:00:00 2001 =46rom: Oliver Pinter Date: Tue, 3 Jan 2012 12:17:43 +0100 Subject: [PATCH] fix git detection code in newvers.sh Signed-off-by: Oliver Pinter diff --git a/sys/conf/newvers.sh b/sys/conf/newvers.sh index c6184a8..b015735 100644 =2D-- a/sys/conf/newvers.sh +++ b/sys/conf/newvers.sh @@ -92,6 +92,9 @@ for dir in /bin /usr/bin /usr/local/bin; do svnversion=3D${dir}/svnversion break fi +done + +for dir in /bin /usr/bin /usr/local/bin; do if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then git_cmd=3D"${dir}/git --git-dir=3D${SYSDIR}/../.git" break --Boundary-00=_pRzBPReUZlYSbPc-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 19:16:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2960F106566B for ; Fri, 6 Jan 2012 19:16:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id DDA408FC12 for ; Fri, 6 Jan 2012 19:16:13 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q06J2PbO048908; Fri, 6 Jan 2012 11:02:25 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q06J2PsV048907; Fri, 6 Jan 2012 11:02:25 -0800 (PST) (envelope-from david) Date: Fri, 6 Jan 2012 11:02:25 -0800 From: David Wolfskill To: Oliver Pinter Message-ID: <20120106190225.GR1733@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Oliver Pinter , current@freebsd.org References: <201201061850.33863.pinter@tresorium.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ff5AkW+g6+eEohN" Content-Disposition: inline In-Reply-To: <201201061850.33863.pinter@tresorium.hu> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: [RFC] fix git detection code in newvers.sh when svn installed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:16:14 -0000 --7ff5AkW+g6+eEohN Content-Type: multipart/mixed; boundary="SENi13OXelf/Rv8V" Content-Disposition: inline --SENi13OXelf/Rv8V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [-stable@ removed, as there's no need to cross-post this. dhw] On Fri, Jan 06, 2012 at 06:50:33PM +0100, Oliver Pinter wrote: > Hi All! >=20 > When svn installed and the source stored in git, then now the version=20 > detection failed. The attached patch fixed this situation. > ... Caveat: I don't use git. Given that folks will use various combinations of VCSen to maintain their source trees, rather than hacking/munging newvers.sh whenever the behavior of a certain subset of VCSen changes, why not change newvers.sh to source the site-specific code in question? We (the FreeBSD project) could provide some sample files, but folks who want to do something different would have an easy way to do that without hacking newvers.sh. E.g., the attached. I would normally make the file being sourced a symlink to a selected file. Note: Yes, some of the examples are absurd. The point is to illustrate the idea. I've been using this code in head, stable/9, and stable/8 since late November; I track eack of those daily (both on a build machine and on my laptop). Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --SENi13OXelf/Rv8V Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="newvers.sh.patch" Content-Transfer-Encoding: quoted-printable diff -Nru conf/get_version_from_jot.sh conf/get_version_from_jot.sh --- conf/get_version_from_jot.sh 1969-12-31 16:00:00.000000000 -0800 +++ conf/get_version_from_jot.sh 2011-11-20 08:29:19.000000000 -0800 @@ -0,0 +1,4 @@ +# Sample get_version_from_vcs.sh as a silly example +get_version_from_vcs() { + jot -r 1 $( date +%s ) +} diff -Nru conf/get_version_from_null.sh conf/get_version_from_null.sh --- conf/get_version_from_null.sh 1969-12-31 16:00:00.000000000 -0800 +++ conf/get_version_from_null.sh 2011-11-19 11:24:51.000000000 -0800 @@ -0,0 +1,4 @@ +# Sample get_version_from_vcs.sh as a silly example +get_version_from_vcs() { + echo "" +} diff -Nru conf/get_version_from_svn.sh conf/get_version_from_svn.sh --- conf/get_version_from_svn.sh 1969-12-31 16:00:00.000000000 -0800 +++ conf/get_version_from_svn.sh 2011-11-29 13:32:25.000000000 -0800 @@ -0,0 +1,17 @@ +# Sample get_version_from_vcs.sh for use with SVN +get_version_from_vcs() { + for dir in /bin /usr/bin /usr/local/bin; do + if [ -x "${dir}/svnversion" ] ; then + svnversion=3D${dir}/svnversion + break + fi + done + if [ -n "$svnversion" ] ; then + svn=3D`cd ${SYSDIR} && $svnversion` + case "$svn" in + [0-9]*) svn=3D"r${svn}" ;; + *) unset svn ;; + esac + fi + echo "$svn" +} diff -Nru conf/get_version_from_vcs.sh conf/get_version_from_vcs.sh --- conf/get_version_from_vcs.sh 1969-12-31 16:00:00.000000000 -0800 +++ conf/get_version_from_vcs.sh 2011-11-20 08:29:45.000000000 -0800 @@ -0,0 +1,5 @@ +# dhw's get_version_from_vcs.sh for use with SVN to get GRN for entire /us= r/src +# I know where I keep svnversion, so I don't need to look for it. +get_version_from_vcs() { + /usr/local/bin/svnversion /usr/src/ +} diff -Nru conf/newvers.sh conf/newvers.sh --- conf/newvers.sh 2012-01-06 10:40:08.000000000 -0800 +++ conf/newvers.sh 2012-01-06 10:47:58.000000000 -0800 @@ -87,51 +87,25 @@ v=3D`cat version` u=3D${USER:-root} d=3D`pwd` h=3D${HOSTNAME:-`hostname`} = t=3D`date` i=3D`${MAKE:-make} -V KERN_IDENT` =20 -for dir in /bin /usr/bin /usr/local/bin; do - if [ -x "${dir}/svnversion" ] ; then - svnversion=3D${dir}/svnversion - break - fi - if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then - git_cmd=3D"${dir}/git --git-dir=3D${SYSDIR}/../.git" - break - fi -done - -if [ -n "$svnversion" ] ; then - svn=3D`cd ${SYSDIR} && $svnversion` - case "$svn" in - [0-9]*) svn=3D" r${svn}" ;; - *) unset svn ;; - esac +if [ -r ${SYSDIR}/conf/get_version_from_vcs.sh ] ; then + . ${SYSDIR}/conf/get_version_from_vcs.sh +else + # Fallback function to get a "version ID" if we can't find + # a replacement function. + get_version_from_vcs() { + date +%s + } fi +version_from_vcs=3D`get_version_from_vcs` =20 -if [ -n "$git_cmd" ] ; then - git=3D`$git_cmd rev-parse --verify --short HEAD 2>/dev/null` - svn=3D`$git_cmd svn find-rev $git 2>/dev/null` - if [ -n "$svn" ] ; then - svn=3D" r${svn}" - git=3D"=3D${git}" - else - svn=3D`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \ - sed -n 's/^.*@\([0-9][0-9]*\).*$/\1/p'` - if [ -n $svn ] ; then - svn=3D" r${svn}" - git=3D"+${git}" - else - git=3D" ${git}" - fi - fi - if $git_cmd --work-tree=3D${SYSDIR}/.. diff-index \ - --name-only HEAD | read dummy; then - git=3D"${git}-dirty" - fi +if [ -n "$version_from_vcs" ]; then + version_from_vcs=3D" $version_from_vcs" fi =20 cat << EOF > vers.c $COPYRIGHT -#define SCCSSTR "@(#)${VERSION} #${v}${svn}${git}: ${t}" -#define VERSTR "${VERSION} #${v}${svn}${git}: ${t}\\n ${u}@${h}:${d}\\n" +#define SCCSSTR "@(#)${VERSION} #${v}${version_from_vcs}: ${t}" +#define VERSTR "${VERSION} #${v}${version_from_vcs}: ${t}\\n ${u}@${h}:= ${d}\\n" #define RELSTR "${RELEASE}" =20 char sccs[sizeof(SCCSSTR) > 128 ? sizeof(SCCSSTR) : 128] =3D SCCSSTR; --SENi13OXelf/Rv8V-- --7ff5AkW+g6+eEohN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8HRUAACgkQmprOCmdXAD1eYwCbBpS6Tl639jyeBOORwCwYOSFQ epMAnjnihv7VgT5lfzwH8zAjixlZDzcJ =vEhQ -----END PGP SIGNATURE----- --7ff5AkW+g6+eEohN-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 19:16:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D71D1065678; Fri, 6 Jan 2012 19:16:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8DFE8FC18; Fri, 6 Jan 2012 19:16:54 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3172669obb.13 for ; Fri, 06 Jan 2012 11:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MPjmpaZwc/8KSw0f7lvktWIRLGDDzv04h8AilE6phUU=; b=XBGhdI9+0HKVKiae3a56IWeTP0838Vt4N8N1TAtA8KUfRFnvKB9z5N9s5KOM1yRNjS QbWaKZfWRH+mWm40ZFGUOzCKjtLfUiNdiO85OcehoMnNI9PyY+zLLSv1NCicYA153f1L TOrXkI6G7eNkpkAInnsZnTYxL0hzYeJuOMuiA= MIME-Version: 1.0 Received: by 10.182.1.67 with SMTP id 3mr5869198obk.31.1325877414133; Fri, 06 Jan 2012 11:16:54 -0800 (PST) Received: by 10.182.152.6 with HTTP; Fri, 6 Jan 2012 11:16:54 -0800 (PST) In-Reply-To: <201201062002.29775.pinter@tresorium.hu> References: <201201061850.33863.pinter@tresorium.hu> <201201062002.29775.pinter@tresorium.hu> Date: Fri, 6 Jan 2012 11:16:54 -0800 Message-ID: From: Garrett Cooper To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Sergey Kandaurov , current@freebsd.org Subject: Re: [RFC] fix git detection code in newvers.sh when svn installed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:16:55 -0000 On Fri, Jan 6, 2012 at 11:02 AM, Oliver Pinter wrote: > On Friday 06 January 2012 19:35:31 Sergey Kandaurov wrote: >> On 6 January 2012 21:50, Oliver Pinter wrote: >> > Hi All! >> > >> > When svn installed and the source stored in git, then now the version >> > detection failed. The attached patch fixed this situation. >> >> FWIW, a different version proposed by Maciej Milewski on -current >> some time ago. I don't have/use git, so I cannot test these changes. >> It is good in the sense that it doesn't duplicate a search path. >> The patch is below for reference: >> >> --- sys/conf/newvers.sh =A0 =A0 =A0 2011-11-19 00:56:50.795815738 +0100 >> +++ sys/conf/newvers-patched.sh =A0 =A0 =A0 2011-11-19 00:58:21.18781898= 2 +0100 >> @@ -88,14 +88,14 @@ >> =A0i=3D`${MAKE:-make} -V KERN_IDENT` >> >> =A0for dir in /bin /usr/bin /usr/local/bin; do >> - =A0 =A0 if [ -x "${dir}/svnversion" ] ; then >> - =A0 =A0 =A0 =A0 =A0 =A0 svnversion=3D${dir}/svnversion >> - =A0 =A0 =A0 =A0 =A0 =A0 break >> - =A0 =A0 fi >> =A0 =A0 =A0 if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 git_cmd=3D"${dir}/git --git-dir=3D${SYSDIR}/= ../.git" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break >> =A0 =A0 =A0 fi >> + =A0 =A0 if [ -x "${dir}/svnversion" ] ; then >> + =A0 =A0 =A0 =A0 =A0 =A0 svnversion=3D${dir}/svnversion >> + =A0 =A0 =A0 =A0 =A0 =A0 break >> + =A0 =A0 fi >> =A0done >> >> =A0if [ -n "$svnversion" ] ; then > > The problem with this, when git founded first and the source not stored i= n > git, then the svn version not correctly set, due the loop first found git= , > and than breaked out. > > The same situation as my patch fixed, but from svn viewpoint. This detection method might be worth mentioning as well (look for SVNVERSION: http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/build/n= ano_env?revision=3D9392&view=3Dmarkup ). Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 19:02:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 048BC106564A; Fri, 6 Jan 2012 19:02:39 +0000 (UTC) (envelope-from pinter@tresorium.hu) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63D7B8FC0C; Fri, 6 Jan 2012 19:02:37 +0000 (UTC) Received: by eekc50 with SMTP id c50so1466962eek.13 for ; Fri, 06 Jan 2012 11:02:37 -0800 (PST) Received: by 10.213.31.66 with SMTP id x2mr1427392ebc.60.1325876557140; Fri, 06 Jan 2012 11:02:37 -0800 (PST) Received: from peonia (peonia.teteny.elte.hu. [157.181.96.25]) by mx.google.com with ESMTPS id t1sm251296590eeb.3.2012.01.06.11.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 11:02:36 -0800 (PST) From: Oliver Pinter Organization: Tresorium Ltd. To: Sergey Kandaurov Date: Fri, 6 Jan 2012 20:02:29 +0100 User-Agent: KMail/1.9.10 References: <201201061850.33863.pinter@tresorium.hu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201201062002.29775.pinter@tresorium.hu> X-Mailman-Approved-At: Fri, 06 Jan 2012 19:24:23 +0000 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: [RFC] fix git detection code in newvers.sh when svn installed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:02:39 -0000 On Friday 06 January 2012 19:35:31 Sergey Kandaurov wrote: > On 6 January 2012 21:50, Oliver Pinter wrote: > > Hi All! > > > > When svn installed and the source stored in git, then now the version > > detection failed. The attached patch fixed this situation. > > FWIW, a different version proposed by Maciej Milewski on -current > some time ago. I don't have/use git, so I cannot test these changes. > It is good in the sense that it doesn't duplicate a search path. > The patch is below for reference: > > --- sys/conf/newvers.sh 2011-11-19 00:56:50.795815738 +0100 > +++ sys/conf/newvers-patched.sh 2011-11-19 00:58:21.187818982 +0100 > @@ -88,14 +88,14 @@ > i=`${MAKE:-make} -V KERN_IDENT` > > for dir in /bin /usr/bin /usr/local/bin; do > - if [ -x "${dir}/svnversion" ] ; then > - svnversion=${dir}/svnversion > - break > - fi > if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then > git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git" > break > fi > + if [ -x "${dir}/svnversion" ] ; then > + svnversion=${dir}/svnversion > + break > + fi > done > > if [ -n "$svnversion" ] ; then The problem with this, when git founded first and the source not stored in git, then the svn version not correctly set, due the loop first found git, and than breaked out. The same situation as my patch fixed, but from svn viewpoint. -- Oliver Pinter (Tresorium) From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 20:07:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4053210656D9 for ; Fri, 6 Jan 2012 20:07:19 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id F13C08FC0A for ; Fri, 6 Jan 2012 20:07:18 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1RjG4L-0003Fg-R7 for freebsd-current@freebsd.org; Fri, 06 Jan 2012 20:07:18 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RjG4L-0000pA-MP for freebsd-current@freebsd.org; Fri, 06 Jan 2012 20:07:17 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q06K7HD3094377 for ; Fri, 6 Jan 2012 20:07:17 GMT (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q06K7Hih094376 for freebsd-current@freebsd.org; Fri, 6 Jan 2012 20:07:17 GMT (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Fri, 6 Jan 2012 20:07:17 +0000 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20120106200717.GA94337@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: bwi0: bwi_init_statechg: error 12 on MAC init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:07:19 -0000 This is on r228936M amd64 (the only modification is 9.9 patch in /usr/src/sys/conf/newvers.h) However, I've never used this pccard before. ******************************************************** 1. On inserting the card: ******************************************************** # pciconf -lv bwi0@pci0:3:0:0: class=0x028000 card=0x00481737 chip=0x431814e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller' class = network # dmesg bwi0: mem 0xcc502000-0xcc503fff irq 20 at device 0.0 on cardbus0 bwi0: BBP: id 0x4318, rev 0x2, pkg 2 bwi0: MAC: rev 9 bwi0: PHY: type 2, rev 7, ver 3 bwi0: RF: manu 0x17f, type 0x2050, rev 8 bwi0: invalid antenna gain in sprom # ifconfig -a bwi0: flags=8802 metric 0 mtu 2290 ether 00:18:39:c7:71:21 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ******************************************************** 2. After creating wlan device: # ifconfig wlan create wlandev bwi0 inet 192.168.0.102 ******************************************************** # dmesg wlan0: Ethernet address: 00:18:39:c7:71:21 Sleeping on "fwload" with the following non-sleepable locks held: exclusive sleep mutex bwi0 (network driver) r = 0 (0xffffff8001744018) locked @ /usr/src/sys/dev/bwi/if_bwi.c:1312 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_warn() at witness_warn+0x2c6 _sleep() at _sleep+0x61 firmware_get() at firmware_get+0x15c bwi_mac_init() at bwi_mac_init+0xd3f bwi_init_statechg() at bwi_init_statechg+0x78 bwi_ioctl() at bwi_ioctl+0xaf taskqueue_run_locked() at taskqueue_run_locked+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80ce9d9d00, rbp = 0 --- bwi_v3_ucode: could not load firmware image, error 2 bwi0: request firmware bwi_v3_ucode failed bwi0: bwi_init_statechg: error 12 on MAC init bwi0: need multicast update callback # ifconfig -a bwi0: flags=8803 metric 0 mtu 2290 ether 00:18:39:c7:71:21 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated wlan0: flags=8843 metric 0 mtu 1500 ether 00:18:39:c7:71:21 inet 192.168.0.102 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::218:39ff:fec7:7121%wlan0 prefixlen 64 scopeid 0xa nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 bintval 0 ******************************************************** 3. wpa_supplicant: ******************************************************** # wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. *and so on* # ifconfig -a wlan0: flags=8802 metric 0 mtu 1500 ether 00:18:39:c7:71:21 inet 192.168.0.102 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::218:39ff:fec7:7121%wlan0 prefixlen 64 scopeid 0xa nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode WPA1+WPA2/802.11i privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 bintval 0 Any further testing I should do? Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 21:30:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A46FE1065676; Fri, 6 Jan 2012 21:30:33 +0000 (UTC) (envelope-from adrian.chadd@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 271858FC16; Fri, 6 Jan 2012 21:30:32 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2468820vbb.13 for ; Fri, 06 Jan 2012 13:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7i8L0JobRQXi8fpSUb/2zL5mr/eigMvIQmnjRiCPRqI=; b=DzZQTnzId4Lpls/2IaBjYGlBnvAdJ/5lxyqsnFmGdhduKjvt4B1f4hcVMjc1blwcre haPiqY19K2Yh2vixvPGfSr6wA5wtIU7pmRmWOlUTFyvJq94i/6ZtjuEH+NIXhhShAdLq HujoLAtCQlCTm93bpFuQGqUV2xSy4MfcL89ME= MIME-Version: 1.0 Received: by 10.52.24.35 with SMTP id r3mr3881435vdf.81.1325885431095; Fri, 06 Jan 2012 13:30:31 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 13:30:31 -0800 (PST) In-Reply-To: <86ty4a8mc3.fsf@ds4.des.no> References: <86ty4a8mc3.fsf@ds4.des.no> Date: Fri, 6 Jan 2012 13:30:31 -0800 X-Google-Sender-Auth: VrRk9ZViKHedD6PwnMzfkv_i4i4 Message-ID: From: Adrian Chadd To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current , freebsd-arch@freebsd.org Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:30:33 -0000 2012/1/5 Dag-Erling Sm=F8rgrav : > Adrian Chadd writes: >> Since I'm not using NFS or UFS_ACL, I wondered if that code required. >> It turns out I can just build a kernel with those two disabled. >> >> Would it be possible to remove them from "standard" and make them >> optional? Or is there a reason to keep it in base? > > I would be very annoyed if it were no longer possible to netboot > GENERIC... I don't want to break that. :) I Just don't want to compile it in unless I'm using NFS/ZFS, and on my 4MB flash boards I'm not booting w/ NFS compiled in statically.. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 21:37:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3CFF1065676; Fri, 6 Jan 2012 21:37:19 +0000 (UTC) (envelope-from adrian.chadd@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 384678FC12; Fri, 6 Jan 2012 21:37:19 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2475220vbb.13 for ; Fri, 06 Jan 2012 13:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h5I48bZmkhT/BL8aTjZtM+ME+4su8sNBZEiKc/J1Ze4=; b=TovoUsGPZ+hQI7Dl/UFHa0WNC3+04nTj36ACPAataWHfTqC4Rr49Y9z4xWFX/prgqb R+NMbmDg3kiRzsQYp+bisGr/mjycBwxRCN72fy0houhGrSH0EBu60ThAM2PfuLKC0YDB V15z3HTQpI7uZ4XFz6B3cxHbvBo0bMye20VuA= MIME-Version: 1.0 Received: by 10.52.26.66 with SMTP id j2mr3838387vdg.98.1325885838661; Fri, 06 Jan 2012 13:37:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 13:37:18 -0800 (PST) In-Reply-To: <201201050848.18414.jhb@freebsd.org> References: <201201050848.18414.jhb@freebsd.org> Date: Fri, 6 Jan 2012 13:37:18 -0800 X-Google-Sender-Auth: U9y4aWPHvV9i3FSLOZqseimAzS4 Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current , freebsd-arch@freebsd.org Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:37:19 -0000 On 5 January 2012 05:48, John Baldwin wrote: > [ A bit excessive on the cross-posting? =A0arch@ alone was probably fine = ] I wanted to capture the attention of relevant people, as I don't want to break some subtle setup that I'm not at all aware of. > NFS doesn't actually use them curently, only UFS and ZFS do. =A0Unfortuna= tely > we've yet to make it possible to compile ZFS into the kernel, so you can'= t > make the sys/conf/files bits completely accurate yet (it would be nice to > let folks who don't need FFS for a ZFS-only system remove FFS and UFS, bu= t > this would break that): Ok. I'll just test that the GENERIC build works and then commit it. adrian From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 21:42:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F113D1065678 for ; Fri, 6 Jan 2012 21:42:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A91738FC1B for ; Fri, 6 Jan 2012 21:42:06 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so2479272vcb.13 for ; Fri, 06 Jan 2012 13:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cRU/doXMwl7EUax+BKv5aS318FwwZ/Mz+TwIZNd4r0w=; b=sv2XLCkio8XRW1hlI3YrLpSv82xXFpDq7rzB6FV0e2qUZU4ZaMD3icf8Ps1FNy0WrV mXE9eIf9lWBiredwh4qYD3MGbXln4TlyYS7gqhTo/Khqw6liQq5YkWYs0GwSP4jJX0Gq lirJB8253oODWBTAoWGKACarpXFFohZXRyLAU= MIME-Version: 1.0 Received: by 10.52.35.10 with SMTP id d10mr3820913vdj.132.1325886125910; Fri, 06 Jan 2012 13:42:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 13:42:05 -0800 (PST) In-Reply-To: <4F073B1B.6000707@gwdg.de> References: <4F072C13.6000606@gwdg.de> <4F073B1B.6000707@gwdg.de> Date: Fri, 6 Jan 2012 13:42:05 -0800 X-Google-Sender-Auth: fNOTbA5kKXqPQnqhkuBHqPTAk1s Message-ID: From: Adrian Chadd To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:42:07 -0000 On 6 January 2012 10:19, Rainer Hurling wrote: > I commented all wireless network drivers and their options out. But the > error remains. Is it necessary to have this option uncommented even when the > driver ath is commented out? Yes, because of how the wlan/ath modules are built. You need to have AH_SUPPORT_AR5416 in the kernel config file, as the driver/module currently doesn't build without it. I'll eventually fix that, but right now I just want to leave that option in and not hack up the Makefile to define said option. Otherwise other options (eg enabling 11n, enabling hal debugging, etc) are completely ignored when building modules. Same with IEEE80211_SUPPORT_MESH i believe. I should really re-verify that. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 21:49:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8F62106564A; Fri, 6 Jan 2012 21:49:44 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 914708FC0C; Fri, 6 Jan 2012 21:49:44 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3401958obb.13 for ; Fri, 06 Jan 2012 13:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LTTUY4XC60toS4a/n3bB01uWJLb00dzOGoJOejaFpSM=; b=tSfRFuBKUBVWsdEmtBh7t+/Y/cH7SZsAh69/Ga7QZ2RYTb8D7k1lYjgfWxbtIds1VI MyVRqyBuqdD8OZ7MOieXAoQ2FUOURkP1F3nGlgYsHE5meDxaRV9qVuc2vZ9+AAeO5XMN Q1OpmvcSfdnj9vcFB9f3MVclUlF7AjtHWZ8Ng= MIME-Version: 1.0 Received: by 10.182.74.36 with SMTP id q4mr6118227obv.77.1325886584137; Fri, 06 Jan 2012 13:49:44 -0800 (PST) Received: by 10.182.150.70 with HTTP; Fri, 6 Jan 2012 13:49:44 -0800 (PST) In-Reply-To: References: <4F072C13.6000606@gwdg.de> <4F073B1B.6000707@gwdg.de> Date: Fri, 6 Jan 2012 23:49:44 +0200 Message-ID: From: Alexander Yerenkow To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:49:44 -0000 2012/1/6 Adrian Chadd > On 6 January 2012 10:19, Rainer Hurling wrote: > > > I commented all wireless network drivers and their options out. But the > > error remains. Is it necessary to have this option uncommented even when > the > > driver ath is commented out? > > Yes, because of how the wlan/ath modules are built. You need to have > AH_SUPPORT_AR5416 in the kernel config file, as the driver/module > currently doesn't build without it. > I'm sorry for intruding in this topic, but it seems to me similar subject; Did FreeBSD ever tried to make config variables structured and with specified dependencies? To make clear what I mean - is anyone tried to implement some deps spec file (Or some special Makefile's sections, whatever), so if you specified feature A in kernel, it can check if you also specified B (which is required by A)? In this way config could provide feedback when you trying to build kernel without needed dependencies, and many peoples could save their time not compiling non-buildable kernel. > I'll eventually fix that, but right now I just want to leave that > option in and not hack up the Makefile to define said option. > Otherwise other options (eg enabling 11n, enabling hal debugging, etc) > are completely ignored when building modules. > > Same with IEEE80211_SUPPORT_MESH i believe. I should really re-verify that. > > > Adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 22:08:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080471065672; Fri, 6 Jan 2012 22:08:02 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) by mx1.freebsd.org (Postfix) with ESMTP id BAFEE8FC14; Fri, 6 Jan 2012 22:08:01 +0000 (UTC) Received: from p57918c7a.dip.t-dialin.net ([87.145.140.122] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RjHxA-0003iY-AK; Fri, 06 Jan 2012 23:08:00 +0100 Message-ID: <4F0770BF.9080906@gwdg.de> Date: Fri, 06 Jan 2012 23:07:59 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd References: <4F072C13.6000606@gwdg.de> <4F073B1B.6000707@gwdg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:08:02 -0000 On 06.01.2012 22:42 (UTC+1), Adrian Chadd wrote: > On 6 January 2012 10:19, Rainer Hurling wrote: > >> I commented all wireless network drivers and their options out. But the >> error remains. Is it necessary to have this option uncommented even when the >> driver ath is commented out? > > Yes, because of how the wlan/ath modules are built. You need to have > AH_SUPPORT_AR5416 in the kernel config file, as the driver/module > currently doesn't build without it. I just tested it with AH_SUPPORT_AR5416 enabled (but ath devices disabled) and it builds fine. > I'll eventually fix that, but right now I just want to leave that > option in and not hack up the Makefile to define said option. > Otherwise other options (eg enabling 11n, enabling hal debugging, etc) > are completely ignored when building modules. > > Same with IEEE80211_SUPPORT_MESH i believe. I should really re-verify that. Even with IEEE80211_SUPPORT_MESH disabled the kernel builds. So it seems this is not necessary to activate. Thanks again for help and clarifying it, Rainer > Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 22:14:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA64E106566C; Fri, 6 Jan 2012 22:14:22 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACC08FC08; Fri, 6 Jan 2012 22:14:22 +0000 (UTC) Received: from p57918c7a.dip.t-dialin.net ([87.145.140.122] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RjI3I-0004Q2-Gu; Fri, 06 Jan 2012 23:14:20 +0100 Message-ID: <4F07723C.2090907@gwdg.de> Date: Fri, 06 Jan 2012 23:14:20 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Alexander Yerenkow References: <4F072C13.6000606@gwdg.de> <4F073B1B.6000707@gwdg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:14:22 -0000 On 06.01.2012 22:49 (UTC+1), Alexander Yerenkow wrote: > 2012/1/6 Adrian Chadd > > > On 6 January 2012 10:19, Rainer Hurling > wrote: > > > I commented all wireless network drivers and their options out. > But the > > error remains. Is it necessary to have this option uncommented > even when the > > driver ath is commented out? > > Yes, because of how the wlan/ath modules are built. You need to have > AH_SUPPORT_AR5416 in the kernel config file, as the driver/module > currently doesn't build without it. > > > I'm sorry for intruding in this topic, but it seems to me similar subject; No problem. I also sometimes have to try for functional configs, before kernel build again. Some kind of deps spec could be very useful. And also some kind of notification for relevant kernel config changes, introduced by updates, would be of help. > Did FreeBSD ever tried to make config variables structured and with > specified dependencies? > To make clear what I mean - is anyone tried to implement some deps spec > file (Or some special Makefile's sections, whatever), so if you > specified feature A in kernel, it can check if you also specified B > (which is required by A)? > In this way config could provide feedback when you trying to build > kernel without needed dependencies, and many peoples could save their > time not compiling non-buildable kernel. > > > I'll eventually fix that, but right now I just want to leave that > option in and not hack up the Makefile to define said option. > Otherwise other options (eg enabling 11n, enabling hal debugging, etc) > are completely ignored when building modules. > > Same with IEEE80211_SUPPORT_MESH i believe. I should really > re-verify that. > > > Adrian > > > -- > Regards, > Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 22:17:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C2D1065672 for ; Fri, 6 Jan 2012 22:17:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1BD18FC12 for ; Fri, 6 Jan 2012 22:17:56 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so2510450vcb.13 for ; Fri, 06 Jan 2012 14:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=g4omxWj86t6yGWVHc7CIPCucq72A6/yKiAzomhC69n8=; b=x8AH3UsWL6Edp3+gxLuUZderlDucV+v3faCBoIGFwsUnra2MMM3na9CfLySyuuZbnW 7GD3M5s/3jMv6SbGELIU1+wSK4v5lc3kR163CEzChTZw2kQr78eDw/WPC6NVOhylSlnb EAgBA608OS5CUWWmwl76M/gqyWDn1ZMiJFUrU= MIME-Version: 1.0 Received: by 10.220.156.134 with SMTP id x6mr4722412vcw.17.1325888276147; Fri, 06 Jan 2012 14:17:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 14:17:56 -0800 (PST) In-Reply-To: <4F0770BF.9080906@gwdg.de> References: <4F072C13.6000606@gwdg.de> <4F073B1B.6000707@gwdg.de> <4F0770BF.9080906@gwdg.de> Date: Fri, 6 Jan 2012 14:17:56 -0800 X-Google-Sender-Auth: __q1ncmEWwMxFEQTQYPM3aCJSpo Message-ID: From: Adrian Chadd To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Kernel does not build on 10.0-CURRENT (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:17:57 -0000 I'm more worried about the module loading as well as building. So if you're not using wireless, fine, but I'd hate to see the default builds produce modules that can't be used. ;) Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 22:56:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4C7A106564A for ; Fri, 6 Jan 2012 22:56:47 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9E13C8FC15 for ; Fri, 6 Jan 2012 22:56:47 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RjIiM-0002QT-EA>; Fri, 06 Jan 2012 23:56:46 +0100 Received: from e178017170.adsl.alicedsl.de ([85.178.17.170] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RjIiM-000702-8r>; Fri, 06 Jan 2012 23:56:46 +0100 Message-ID: <4F077C2D.6040309@zedat.fu-berlin.de> Date: Fri, 06 Jan 2012 23:56:45 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120101 Thunderbird/9.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB96AB9B388A283C77AA244CE" X-Originating-IP: 85.178.17.170 Subject: kernel: build fails in most recent sources in ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:56:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB96AB9B388A283C77AA244CE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I receive this error since I reeled in the most recent sources for FBSD 10.0-CURRENT/amd64. I build the system with CLANG. clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 -fno-strict-aliasing -march=3Dnative -D_KERNEL -DKLD_MODULE -nostdinc -I= =2E -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 -fno-strict-aliasing -march=3Dnative -D_KERNEL -DKLD_MODULE -nostdinc -I= =2E -I/usr/src/sys/modules/ath/../../dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136:17: error: no member named 'ts_flags' in 'struct ath_tx_status' hasba =3D !! (ts.ts_flags & HAL_TX_BA); ~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139:13: error: no member named 'ts_ba_low' in 'struct ath_tx_status' ba[0] =3D ts.ts_ba_low; ~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140:13: error: no member named 'ts_ba_high' in 'struct ath_tx_status' ba[1] =3D ts.ts_ba_high; ~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156:16: error: no member named 'ts_tid' in 'struct ath_tx_status' if (tid !=3D ts.ts_tid) { ~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158:25: error: no member named 'ts_tid' in 'struct ath_tx_status' __func__, tid, ts.ts_tid); ~~ ^ 5 errors generated. --------------enigB96AB9B388A283C77AA244CE 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.18 (FreeBSD) iQEcBAEBAgAGBQJPB3wtAAoJEOgBcD7A/5N8d2IH/0xJT9LDhlUDDQkIZLJYHysO HrfdMC4JS4LceGI4eDdTPoP4INV2xd2pZ4Tsyv/xvlJ9eIRTA7EEdW5M33Xmygfe dUMCvus0y7JYx+me19LpgjD887K0nnOuXgVwQnHCIi8z1W+nmW0TS7Q2hFjJSMKD 8TsfUAGKudyjBwvltDT3eFA/UkxmyGRXPsXHPYU7WoGQJsKzHzDiQo8a0x8bxjTr p/N66dO2Q78YiJQW7VC7LCUXyCAhpKNld2FjgZQYTvzRKpkMRJVGhip2grp0UWBB vns5cnHHR2JFvrFRSk/bUPykq85nakDmWH7MVQTA8JtPwTdaGedlFpMQqoyZVB8= =+tmr -----END PGP SIGNATURE----- --------------enigB96AB9B388A283C77AA244CE-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 6 23:13:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4946B1065670 for ; Fri, 6 Jan 2012 23:13:35 +0000 (UTC) (envelope-from adrian.chadd@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 F35118FC14 for ; Fri, 6 Jan 2012 23:13:34 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2551124vbb.13 for ; Fri, 06 Jan 2012 15:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wTiMbTyxCzLR01GybDn808cWa4+mvTYzguyDMTjrWgA=; b=eySgBlHm7UTNT8RQC+Cc0Kk2+GVKL4ua9Fdc/+V09G0YEnLYpmcxX+mPOb6dxsqbIm Sy/kovb7iIwDf5jvag0JSPO/8jVgzMWdxgQpjk2TAIWNFtwOWFBqGFq+5DX7TcOy6GH4 3Nm2kLR13gQ1okndtqcjMZFG7+sfCWMLqXzEc= MIME-Version: 1.0 Received: by 10.52.24.35 with SMTP id r3mr4001262vdf.81.1325891614159; Fri, 06 Jan 2012 15:13:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 15:13:34 -0800 (PST) In-Reply-To: <4F077C2D.6040309@zedat.fu-berlin.de> References: <4F077C2D.6040309@zedat.fu-berlin.de> Date: Fri, 6 Jan 2012 15:13:34 -0800 X-Google-Sender-Auth: QrZwX9IVnumKgFAy8iStQxso9nk Message-ID: From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Current FreeBSD Subject: Re: kernel: build fails in most recent sources in ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 23:13:35 -0000 Hi, You need to build the system with: options AH_SUPPORT_AR5416 .. even if you're not building _with_ the ath device. This is a byproduct of how the modules are currently built. I'm sorry for introducing this breakage. I'm going to try and fix the driver soon but it's going to require a little more extensive code shuffling and changes to make it "neat" to do. Adrian On 6 January 2012 14:56, O. Hartmann wrote: > Hello, > I receive this error since I reeled in the most recent sources for FBSD > 10.0-CURRENT/amd64. I build the system with CLANG. > > > > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 > -fno-strict-aliasing -march=3Dnative -D_KERNEL -DKLD_MODULE -nostdinc =A0= -I. > -I/usr/src/sys/modules/ath/../../dev/ath > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq > -fno-common =A0-fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR > -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality =A0-c > /usr/src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3 > -fno-strict-aliasing -march=3Dnative -D_KERNEL -DKLD_MODULE -nostdinc =A0= -I. > -I/usr/src/sys/modules/ath/../../dev/ath > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq > -fno-common =A0-fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR > -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > -fformat-extensions =A0-Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality =A0-c > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136:17: error: no > member named 'ts_flags' in 'struct ath_tx_status' > =A0 =A0 =A0 =A0hasba =3D !! (ts.ts_flags & HAL_TX_BA); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~~ ^ > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139:13: error: no > member named 'ts_ba_low' in 'struct ath_tx_status' > =A0 =A0 =A0 =A0ba[0] =3D ts.ts_ba_low; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~~ ^ > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140:13: error: no > member named 'ts_ba_high' in 'struct ath_tx_status' > =A0 =A0 =A0 =A0ba[1] =3D ts.ts_ba_high; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~~ ^ > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156:16: error: no > member named 'ts_tid' in 'struct ath_tx_status' > =A0 =A0 =A0 =A0if (tid !=3D ts.ts_tid) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ~~ ^ > /usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158:25: error: no > member named 'ts_tid' in 'struct ath_tx_status' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, tid, ts.ts_tid); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ~~ ^ > 5 errors generated. > > From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 00:21:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A99106564A for ; Sat, 7 Jan 2012 00:21:07 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailB.acsu.buffalo.edu (localmailb.acsu.buffalo.edu [128.205.5.200]) by mx1.freebsd.org (Postfix) with ESMTP id F1A308FC0C for ; Sat, 7 Jan 2012 00:21:06 +0000 (UTC) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4C9481C5C; Fri, 6 Jan 2012 19:21:06 -0500 (EST) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailB.acsu.buffalo.edu (Postfix) with ESMTP id B587F21C2; Fri, 6 Jan 2012 19:21:05 -0500 (EST) Received: from smtp4.acsu.buffalo.edu (smtp4.acsu.buffalo.edu [128.205.5.229]) by localmailB.acsu.buffalo.edu (Prefixe) with ESMTP id 8A31C1C5C; Fri, 6 Jan 2012 19:21:05 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp4.acsu.buffalo.edu (Postfix) with ESMTPSA id 45F6D48576; Fri, 6 Jan 2012 19:21:05 -0500 (EST) From: Ken Smith To: Peter In-Reply-To: References: <5eac2995697ee99fcfda6d071ad09edc.squirrel@pop.pknet.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SRclbEyiWxWrQ9WGtBI9" Date: Fri, 06 Jan 2012 19:21:04 -0500 Message-ID: <1325895664.81172.4.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: stable/9 still looking for packages at 9-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 00:21:07 -0000 --=-SRclbEyiWxWrQ9WGtBI9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Fri, 2012-01-06 at 07:16 -0700, Peter wrote: > Not for stable/9 [__FreeBSD_version 900500+: Sorry for the delay cleaning that up. It should be fixed as of r229748. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-SRclbEyiWxWrQ9WGtBI9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8Hj/AACgkQ/G14VSmup/aWTQCffsMYaKnyrj6rdGNf8JvzSSSV POAAn1/OUKp2D4udel7nInuSu5ValG/1 =a8Bl -----END PGP SIGNATURE----- --=-SRclbEyiWxWrQ9WGtBI9-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 02:47:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D61E106566B; Sat, 7 Jan 2012 02:47:49 +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 C97FF8FC0A; Sat, 7 Jan 2012 02:47:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q072llEn092498; Fri, 6 Jan 2012 21:47:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q072llfT092497; Sat, 7 Jan 2012 02:47:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Jan 2012 02:47:47 GMT Message-Id: <201201070247.q072llfT092497@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 02:47:49 -0000 TB --- 2012-01-06 21:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-06 21:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-06 21:20:00 - cleaning the object tree TB --- 2012-01-06 21:20:14 - cvsupping the source tree TB --- 2012-01-06 21:20:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-06 21:20:40 - building world TB --- 2012-01-06 21:20:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 21:20:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 21:20:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 21:20:40 - SRCCONF=/dev/null TB --- 2012-01-06 21:20:40 - TARGET=i386 TB --- 2012-01-06 21:20:40 - TARGET_ARCH=i386 TB --- 2012-01-06 21:20:40 - TZ=UTC TB --- 2012-01-06 21:20:40 - __MAKE_CONF=/dev/null TB --- 2012-01-06 21:20:40 - cd /src TB --- 2012-01-06 21:20:40 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 6 21:20:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 6 23:30:26 UTC 2012 TB --- 2012-01-06 23:30:26 - generating LINT kernel config TB --- 2012-01-06 23:30:26 - cd /src/sys/i386/conf TB --- 2012-01-06 23:30:26 - /usr/bin/make -B LINT TB --- 2012-01-06 23:30:26 - cd /src/sys/i386/conf TB --- 2012-01-06 23:30:27 - /usr/sbin/config -m LINT TB --- 2012-01-06 23:30:27 - building LINT kernel TB --- 2012-01-06 23:30:27 - CROSS_BUILD_TESTING=YES TB --- 2012-01-06 23:30:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-06 23:30:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-06 23:30:27 - SRCCONF=/dev/null TB --- 2012-01-06 23:30:27 - TARGET=i386 TB --- 2012-01-06 23:30:27 - TARGET_ARCH=i386 TB --- 2012-01-06 23:30:27 - TZ=UTC TB --- 2012-01-06 23:30:27 - __MAKE_CONF=/dev/null TB --- 2012-01-06 23:30:27 - cd /src TB --- 2012-01-06 23:30:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 6 23:30:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jan 7 00:02:48 UTC 2012 TB --- 2012-01-07 00:02:48 - cd /src/sys/i386/conf TB --- 2012-01-07 00:02:48 - /usr/sbin/config -m LINT-NOINET TB --- 2012-01-07 00:02:48 - building LINT-NOINET kernel TB --- 2012-01-07 00:02:48 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 00:02:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 00:02:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 00:02:48 - SRCCONF=/dev/null TB --- 2012-01-07 00:02:48 - TARGET=i386 TB --- 2012-01-07 00:02:48 - TARGET_ARCH=i386 TB --- 2012-01-07 00:02:48 - TZ=UTC TB --- 2012-01-07 00:02:48 - __MAKE_CONF=/dev/null TB --- 2012-01-07 00:02:48 - cd /src TB --- 2012-01-07 00:02:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jan 7 00:02:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jan 7 00:33:34 UTC 2012 TB --- 2012-01-07 00:33:34 - cd /src/sys/i386/conf TB --- 2012-01-07 00:33:34 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-01-07 00:33:34 - building LINT-NOINET6 kernel TB --- 2012-01-07 00:33:34 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 00:33:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 00:33:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 00:33:34 - SRCCONF=/dev/null TB --- 2012-01-07 00:33:34 - TARGET=i386 TB --- 2012-01-07 00:33:34 - TARGET_ARCH=i386 TB --- 2012-01-07 00:33:34 - TZ=UTC TB --- 2012-01-07 00:33:34 - __MAKE_CONF=/dev/null TB --- 2012-01-07 00:33:34 - cd /src TB --- 2012-01-07 00:33:34 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jan 7 00:33:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jan 7 01:04:59 UTC 2012 TB --- 2012-01-07 01:04:59 - cd /src/sys/i386/conf TB --- 2012-01-07 01:04:59 - /usr/sbin/config -m LINT-NOIP TB --- 2012-01-07 01:04:59 - building LINT-NOIP kernel TB --- 2012-01-07 01:04:59 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 01:04:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 01:04:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 01:04:59 - SRCCONF=/dev/null TB --- 2012-01-07 01:04:59 - TARGET=i386 TB --- 2012-01-07 01:04:59 - TARGET_ARCH=i386 TB --- 2012-01-07 01:04:59 - TZ=UTC TB --- 2012-01-07 01:04:59 - __MAKE_CONF=/dev/null TB --- 2012-01-07 01:04:59 - cd /src TB --- 2012-01-07 01:04:59 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jan 7 01:04:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jan 7 01:33:36 UTC 2012 TB --- 2012-01-07 01:33:36 - cd /src/sys/i386/conf TB --- 2012-01-07 01:33:36 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-01-07 01:33:36 - building LINT-VIMAGE kernel TB --- 2012-01-07 01:33:36 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 01:33:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 01:33:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 01:33:36 - SRCCONF=/dev/null TB --- 2012-01-07 01:33:36 - TARGET=i386 TB --- 2012-01-07 01:33:36 - TARGET_ARCH=i386 TB --- 2012-01-07 01:33:36 - TZ=UTC TB --- 2012-01-07 01:33:36 - __MAKE_CONF=/dev/null TB --- 2012-01-07 01:33:36 - cd /src TB --- 2012-01-07 01:33:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jan 7 01:33:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sat Jan 7 02:05:28 UTC 2012 TB --- 2012-01-07 02:05:28 - cd /src/sys/i386/conf TB --- 2012-01-07 02:05:28 - /usr/sbin/config -m GENERIC TB --- 2012-01-07 02:05:28 - building GENERIC kernel TB --- 2012-01-07 02:05:28 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 02:05:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 02:05:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 02:05:28 - SRCCONF=/dev/null TB --- 2012-01-07 02:05:28 - TARGET=i386 TB --- 2012-01-07 02:05:28 - TARGET_ARCH=i386 TB --- 2012-01-07 02:05:28 - TZ=UTC TB --- 2012-01-07 02:05:28 - __MAKE_CONF=/dev/null TB --- 2012-01-07 02:05:28 - cd /src TB --- 2012-01-07 02:05:28 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jan 7 02:05:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jan 7 02:30:36 UTC 2012 TB --- 2012-01-07 02:30:36 - cd /src/sys/i386/conf TB --- 2012-01-07 02:30:36 - /usr/sbin/config -m PAE TB --- 2012-01-07 02:30:36 - building PAE kernel TB --- 2012-01-07 02:30:36 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 02:30:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 02:30:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 02:30:36 - SRCCONF=/dev/null TB --- 2012-01-07 02:30:36 - TARGET=i386 TB --- 2012-01-07 02:30:36 - TARGET_ARCH=i386 TB --- 2012-01-07 02:30:36 - TZ=UTC TB --- 2012-01-07 02:30:36 - __MAKE_CONF=/dev/null TB --- 2012-01-07 02:30:36 - cd /src TB --- 2012-01-07 02:30:36 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jan 7 02:30:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jan 7 02:37:22 UTC 2012 TB --- 2012-01-07 02:37:22 - cd /src/sys/i386/conf TB --- 2012-01-07 02:37:22 - /usr/sbin/config -m XBOX TB --- 2012-01-07 02:37:22 - building XBOX kernel TB --- 2012-01-07 02:37:22 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 02:37:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 02:37:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 02:37:22 - SRCCONF=/dev/null TB --- 2012-01-07 02:37:22 - TARGET=i386 TB --- 2012-01-07 02:37:22 - TARGET_ARCH=i386 TB --- 2012-01-07 02:37:22 - TZ=UTC TB --- 2012-01-07 02:37:22 - __MAKE_CONF=/dev/null TB --- 2012-01-07 02:37:22 - cd /src TB --- 2012-01-07 02:37:22 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jan 7 02:37:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jan 7 02:40:44 UTC 2012 TB --- 2012-01-07 02:40:44 - cd /src/sys/i386/conf TB --- 2012-01-07 02:40:44 - /usr/sbin/config -m XEN TB --- 2012-01-07 02:40:44 - building XEN kernel TB --- 2012-01-07 02:40:44 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 02:40:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 02:40:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 02:40:44 - SRCCONF=/dev/null TB --- 2012-01-07 02:40:44 - TARGET=i386 TB --- 2012-01-07 02:40:44 - TARGET_ARCH=i386 TB --- 2012-01-07 02:40:44 - TZ=UTC TB --- 2012-01-07 02:40:44 - __MAKE_CONF=/dev/null TB --- 2012-01-07 02:40:44 - cd /src TB --- 2012-01-07 02:40:44 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jan 7 02:40:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-07 02:47:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-07 02:47:47 - ERROR: failed to build XEN kernel TB --- 2012-01-07 02:47:47 - 15654.50 user 2674.76 system 19666.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 02:57:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 881B41065677 for ; Sat, 7 Jan 2012 02:57:56 +0000 (UTC) (envelope-from public@macfreek.nl) Received: from aphrodite.kinkhorst.nl (aphrodite.kinkhorst.nl [IPv6:2001:888:214f::f4]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2488FC0A for ; Sat, 7 Jan 2012 02:57:55 +0000 (UTC) Received: from lampje.macfreek.nl (lampje.macfreek.nl [145.99.1.74]) by aphrodite.kinkhorst.nl (Postfix) with ESMTPSA id 7A1221760F8 for ; Sat, 7 Jan 2012 03:57:53 +0100 (CET) Message-ID: <4F07B4B1.6070101@macfreek.nl> Date: Sat, 07 Jan 2012 03:57:53 +0100 From: Freek Dijkstra User-Agent: Postbox 2.1.4 (Macintosh/20110308) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: ZFS fails with bsdinstaller 9.0RC3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 02:57:56 -0000 Hi, I just tried to install FreeBSD 9.0RC3 with a ZFS-only file system. I succeeded by doing a manual install. The bsdinstaller failed: it would write not write the new filesystem to /mnt as expected (I presume it has overwritten the memstick filesystem at /). I'm relative new to FreeBSD, so I'm trying to understand what I did wrong, or if this is quirk in the bsdinstaller (unlikely). This is how it failed: - ----- start log #1 -------- When bsdinstall asks how to partition the disk, drop to the shell. Use this shell to set up partitions for the new system. When finished, mount the system at /mnt and place an fstab file for the new system at /tmp/bsdinstall_etc/fstab. Then type 'exit'. You can also enter the partition editor at any time by entering 'bsdinstall partedit'. # gpart add -t freebsd-zfs -l ssd0 ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 # gpart show ada0 => 34 30932925 ada0 GPT (14G) 34 128 1 freebsd-boot (64k) 162 30932797 2 freebsd-zfs (14G) # zpool list ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 no pools available # zpool import no pools available to import # zpool create -m /mnt zroot /dev/gpt/ssd0 # zpool set bootfs=zroot zroot # zfs set checksum=fletcher4 zroot # zfs create zroot/var # zfs create zroot/var/log # zfs set compression=lzjb zroot/var/log # zfs create zroot/tmp # chmod 1777 /mnt/tmp # zfs create -V 2G zroot/swap # zfs set org.freebsd:swap=on zroot/swap # zfs set checksum=off zroot/swap (Not creating /tmp/bsdinstall_etc/fstab since ZFS takes care of the mounting). # touch /tmp/bsdinstall_etc/fstab # exit (Proceed with bsdinstall as usual. After running it is finished, I drop back to the shell:) # zfs list internal error: failed to initialize ZFS library # ls /mnt # ls /mnt/var ls: /mnt/var: No such file or directory Nothing is there, and the "internal error" made me suspicious that / was overwritten, despite that it was mounted as read-only. I found it also odd that /mnt/var "does not exist", even though it is a mount point. # mount /dev/ufs/FreeBSD_Install on / (ufs, local, noatime, read-only) devfs on /dev (devfs, local, multilabel) /dev/md0 on /var (ufs, local) /dev/md1 on /tmp (ufs, local) zroot on /mnt (zfs, local, nfsv4acls) zroot/var on /mnt/var (zfs, local, nfsv4acls) zroot/var/log on /mnt/var/log (zfs, local, nfsv4acls) zroot/tmp on /mnt/tmp (zfs, local, nfsv4acls) - ----- end log #1 -------- Most online manuals suggest to let mount handle the mounting of disk, so instead of # zpool create -m /mnt zroot /dev/gpt/ssd0 I tried: # zpool create -m legacy zroot /dev/gpt/ssd0 and created /tmp/bsdinstall_etc/fstab: # Device Mountpoint FStype Options Dump Pass# zroot / zfs rw,noatime 0 0 zroot/swap none swap sw 0 0 zroot/tmp /tmp zfs rw,noatime 0 0 zroot/var /var zfs rw,noatime 0 0 zroot/var/log /var/log zfs rw,noatime 0 0 However, this gave the same result. /mnt was empty. I was able to create a perfectly good file system by manually finishing the installation process: - ----- start log #2 -------- [continuation of log #1, just before the #exit] # cd /usr/freebsd-dist/ # tar --unlink -xpJf base.txz -C /mnt # tar --unlink -xpJf kernel.txz -C /mnt # tar --unlink -xpJf ports.txz -C /mnt # echo 'zfs_enable="YES"' >> /mnt/etc/rc.conf # echo 'hostname="myhost.example.org"' >> /mnt/etc/rc.conf # echo 'ifconfig_em1="DHCP"' >> /mnt/etc/rc.conf # echo 'zfs_load="YES"' >> /mnt/boot/loader.conf # echo 'vfs.root.mountfrom="zfs:zroot"' >> /mnt/boot/loader.conf # echo 'console="comconsole"' >> /mnt/boot/loader.conf # echo 'comconsole_speed="19200"' >> /mnt/boot/loader.conf # echo '# Mounting of disk is handled by ZFS' >> /mnt/etc/fstab # vi /etc/ttys (enable ttyu0 and disable ttyv0 to ttyv7, since I have a Soekris, and must resort to headless -serial console- installation, without monitor) # chroot /mnt # passwd # tzsetup # exit # zfs umount -a # zpool export zroot # zpool import -o cachefile=/tmp/zpool.cache zroot # cp /boot/zfs/zpool.cache /mnt/boot/zfs/zpool.cache # zfs umount -a # zfs set mountpoint=/ zroot # /sbin/reboot now >> success! - ----- end log #2 -------- Any clue why the manual installation succeeded, but the bsdinstall failed? I would presume bsdinstall would do just the same thing, only with a (much) nicer GUI. Regards, Freek From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 03:05:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0D3106566C for ; Sat, 7 Jan 2012 03:05:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCF938FC18 for ; Sat, 7 Jan 2012 03:05:37 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so3638782obb.13 for ; Fri, 06 Jan 2012 19:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Db82JqxzYw4AMxL9YVNwpuzrI/izPcEBHdM/w8L9xyQ=; b=O6T5pVVzkEXzIusli/Ai1SMxjRvLY9rv3YyY0qE6RpG2/aZRKDWwMs0xy0TylvWWZ/ VKEgYdpPCAAMM3Zd/JrQXGMGo7obsI6nIVT2nOd7/iyoDcP3STs/fH7SSl/1IRFdoaqc qinCrP+ae0/LwqgM1HoBYknOTzaLBs6Nm9AvQ= MIME-Version: 1.0 Received: by 10.182.46.68 with SMTP id t4mr6773824obm.41.1325905537146; Fri, 06 Jan 2012 19:05:37 -0800 (PST) Received: by 10.182.152.6 with HTTP; Fri, 6 Jan 2012 19:05:37 -0800 (PST) In-Reply-To: <4F07B4B1.6070101@macfreek.nl> References: <4F07B4B1.6070101@macfreek.nl> Date: Fri, 6 Jan 2012 19:05:37 -0800 Message-ID: From: Garrett Cooper To: Freek Dijkstra Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ZFS fails with bsdinstaller 9.0RC3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 03:05:38 -0000 On Fri, Jan 6, 2012 at 6:57 PM, Freek Dijkstra wrote: > Hi, > > I just tried to install FreeBSD 9.0RC3 with a ZFS-only file system. I > succeeded by doing a manual install. The bsdinstaller failed: it would > write not write the new filesystem to /mnt as expected (I presume it has > overwritten the memstick filesystem at /). I'm relative new to FreeBSD, > so I'm trying to understand what I did wrong, or if this is quirk in the > bsdinstaller (unlikely). Uh, memory serves me correctly, you were in the zfs root... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 04:31:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF537106564A; Sat, 7 Jan 2012 04:31:42 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 725EB8FC08; Sat, 7 Jan 2012 04:31:42 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RjNwT-0003RT-7q>; Sat, 07 Jan 2012 05:31:41 +0100 Received: from e178012028.adsl.alicedsl.de ([85.178.12.28] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RjNwT-0003S5-2l>; Sat, 07 Jan 2012 05:31:41 +0100 Message-ID: <4F07CAA5.5020405@zedat.fu-berlin.de> Date: Sat, 07 Jan 2012 05:31:33 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120101 Thunderbird/9.0 MIME-Version: 1.0 To: Dimitry Andric References: <4F062232.1020204@zedat.fu-berlin.de> <20120106073104.GA50351@freebsd.org> <4F06B378.7050404@zedat.fu-berlin.de> <4F06EDEC.5030805@FreeBSD.org> In-Reply-To: <4F06EDEC.5030805@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C156C66E430EA2546CF83FA" X-Originating-IP: 85.178.12.28 Cc: Roman Divacky , Current FreeBSD Subject: Re: WITH_LIBCPLUSPLUS on FreeBSD 10.0-CURRENT/amd64 fails with CLANG: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 04:31:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C156C66E430EA2546CF83FA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/06/12 13:49, Dimitry Andric wrote: > On 2012-01-06 09:40, O. Hartmann wrote: > ... >> Obviously, these lines in make.conf seem to fail recently when buildin= g >> the sources: >> >> ### >> ### CLANG >> ### >> >> .if !defined(NO_CLANG) >> .if ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/obj/*} || >> ${.CURDIR:M/sys/*} >=20 > Hi Oliver, >=20 > The problem is that the ${.CURDIR:M/usr/src/*} expressions are wrong, > they will not match when you are *exactly* in /usr/src or in /usr/obj. >=20 > So for any operations in the "root" of your source checkout, or of your= > object directory, CC will still be 'cc', and unexpected things will > happen. >=20 > It is better to use: >=20 > .if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*} || ${.CURDIR:M/sys= *} >=20 > or if you want to be strict: >=20 > .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || > ${.CURDIR:M/usr/obj} || ${.CURDIR:M/usr/obj/*} || ${.CURDIR:M/sys} || > ${.CURDIR:M/sys/*} >=20 > It is similar to a problem another user reported on freebsd-stable > (though he got a weird linker error instead): >=20 > =20 > http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/065172.= html >=20 > After some analysis, it turned out he had the same problem in his > make.conf: >=20 > =20 > http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/065183.= html Hello Dimitry. Thanks for the correction. My bad. I think I copied and pasted this line without thinking or I added the slashes by my own will without knowing the consequences - small changes, big impact. Thanks a lot, Oliver --------------enig2C156C66E430EA2546CF83FA 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.18 (FreeBSD) iQEcBAEBAgAGBQJPB8qsAAoJEOgBcD7A/5N8KDcIAMoVVIGQDHlJrjM5cx3R8+Kh IzhCughP6pHPoKlY4y21YBMOCtNYACl6dO74t4RK3bF+ILXYXfrmDxC5qYXdUglR gX62PZTDMeuHeyQGro9dhVfUxX6Du3QKytloCF/M0/5J5R+XorGFb6bVPpU3tt8F IR9s5cjY09U6NO6jlbOw0/6kaSWjo+5aENXVPheOxls6h+BT/kwMkYm13WXvxEgD eYOatvERUEM40SYjs/LAo7Zei76oD7dohjrKAJJ6TCH1JODgX7AyeNddrzSXwjpN bwASuqFtFVBmJ5e7oM/u1+Ygh1YmVm51CsYQ1btiXWKXtvolM1vdA5mWwpuQ+PQ= =3TSg -----END PGP SIGNATURE----- --------------enig2C156C66E430EA2546CF83FA-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 10:36:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A92FF106566C; Sat, 7 Jan 2012 10:36:12 +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 4042F8FC08; Sat, 7 Jan 2012 10:36:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q07AaBnS005621; Sat, 7 Jan 2012 05:36:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q07AaBZD005616; Sat, 7 Jan 2012 10:36:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Jan 2012 10:36:11 GMT Message-Id: <201201071036.q07AaBZD005616@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 10:36:12 -0000 TB --- 2012-01-07 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-07 05:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-07 05:10:00 - cleaning the object tree TB --- 2012-01-07 05:11:01 - cvsupping the source tree TB --- 2012-01-07 05:11:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-07 05:11:14 - building world TB --- 2012-01-07 05:11:14 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 05:11:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 05:11:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 05:11:14 - SRCCONF=/dev/null TB --- 2012-01-07 05:11:14 - TARGET=i386 TB --- 2012-01-07 05:11:14 - TARGET_ARCH=i386 TB --- 2012-01-07 05:11:14 - TZ=UTC TB --- 2012-01-07 05:11:14 - __MAKE_CONF=/dev/null TB --- 2012-01-07 05:11:14 - cd /src TB --- 2012-01-07 05:11:14 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 7 05:11:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 7 07:20:10 UTC 2012 TB --- 2012-01-07 07:20:11 - generating LINT kernel config TB --- 2012-01-07 07:20:11 - cd /src/sys/i386/conf TB --- 2012-01-07 07:20:11 - /usr/bin/make -B LINT TB --- 2012-01-07 07:20:11 - cd /src/sys/i386/conf TB --- 2012-01-07 07:20:11 - /usr/sbin/config -m LINT TB --- 2012-01-07 07:20:11 - building LINT kernel TB --- 2012-01-07 07:20:11 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 07:20:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 07:20:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 07:20:11 - SRCCONF=/dev/null TB --- 2012-01-07 07:20:11 - TARGET=i386 TB --- 2012-01-07 07:20:11 - TARGET_ARCH=i386 TB --- 2012-01-07 07:20:11 - TZ=UTC TB --- 2012-01-07 07:20:11 - __MAKE_CONF=/dev/null TB --- 2012-01-07 07:20:11 - cd /src TB --- 2012-01-07 07:20:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 7 07:20:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jan 7 07:52:11 UTC 2012 TB --- 2012-01-07 07:52:11 - cd /src/sys/i386/conf TB --- 2012-01-07 07:52:11 - /usr/sbin/config -m LINT-NOINET TB --- 2012-01-07 07:52:11 - building LINT-NOINET kernel TB --- 2012-01-07 07:52:11 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 07:52:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 07:52:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 07:52:11 - SRCCONF=/dev/null TB --- 2012-01-07 07:52:11 - TARGET=i386 TB --- 2012-01-07 07:52:11 - TARGET_ARCH=i386 TB --- 2012-01-07 07:52:11 - TZ=UTC TB --- 2012-01-07 07:52:11 - __MAKE_CONF=/dev/null TB --- 2012-01-07 07:52:11 - cd /src TB --- 2012-01-07 07:52:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jan 7 07:52:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jan 7 08:23:06 UTC 2012 TB --- 2012-01-07 08:23:06 - cd /src/sys/i386/conf TB --- 2012-01-07 08:23:06 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-01-07 08:23:06 - building LINT-NOINET6 kernel TB --- 2012-01-07 08:23:06 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 08:23:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 08:23:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 08:23:06 - SRCCONF=/dev/null TB --- 2012-01-07 08:23:06 - TARGET=i386 TB --- 2012-01-07 08:23:06 - TARGET_ARCH=i386 TB --- 2012-01-07 08:23:06 - TZ=UTC TB --- 2012-01-07 08:23:06 - __MAKE_CONF=/dev/null TB --- 2012-01-07 08:23:06 - cd /src TB --- 2012-01-07 08:23:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jan 7 08:23:06 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jan 7 08:54:01 UTC 2012 TB --- 2012-01-07 08:54:01 - cd /src/sys/i386/conf TB --- 2012-01-07 08:54:01 - /usr/sbin/config -m LINT-NOIP TB --- 2012-01-07 08:54:01 - building LINT-NOIP kernel TB --- 2012-01-07 08:54:01 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 08:54:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 08:54:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 08:54:01 - SRCCONF=/dev/null TB --- 2012-01-07 08:54:01 - TARGET=i386 TB --- 2012-01-07 08:54:01 - TARGET_ARCH=i386 TB --- 2012-01-07 08:54:01 - TZ=UTC TB --- 2012-01-07 08:54:01 - __MAKE_CONF=/dev/null TB --- 2012-01-07 08:54:01 - cd /src TB --- 2012-01-07 08:54:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jan 7 08:54:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jan 7 09:22:22 UTC 2012 TB --- 2012-01-07 09:22:22 - cd /src/sys/i386/conf TB --- 2012-01-07 09:22:22 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-01-07 09:22:22 - building LINT-VIMAGE kernel TB --- 2012-01-07 09:22:22 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 09:22:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 09:22:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 09:22:22 - SRCCONF=/dev/null TB --- 2012-01-07 09:22:22 - TARGET=i386 TB --- 2012-01-07 09:22:22 - TARGET_ARCH=i386 TB --- 2012-01-07 09:22:22 - TZ=UTC TB --- 2012-01-07 09:22:22 - __MAKE_CONF=/dev/null TB --- 2012-01-07 09:22:22 - cd /src TB --- 2012-01-07 09:22:22 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jan 7 09:22:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sat Jan 7 09:54:16 UTC 2012 TB --- 2012-01-07 09:54:16 - cd /src/sys/i386/conf TB --- 2012-01-07 09:54:16 - /usr/sbin/config -m GENERIC TB --- 2012-01-07 09:54:16 - building GENERIC kernel TB --- 2012-01-07 09:54:16 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 09:54:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 09:54:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 09:54:16 - SRCCONF=/dev/null TB --- 2012-01-07 09:54:16 - TARGET=i386 TB --- 2012-01-07 09:54:16 - TARGET_ARCH=i386 TB --- 2012-01-07 09:54:16 - TZ=UTC TB --- 2012-01-07 09:54:16 - __MAKE_CONF=/dev/null TB --- 2012-01-07 09:54:16 - cd /src TB --- 2012-01-07 09:54:16 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jan 7 09:54:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jan 7 10:18:56 UTC 2012 TB --- 2012-01-07 10:18:56 - cd /src/sys/i386/conf TB --- 2012-01-07 10:18:56 - /usr/sbin/config -m PAE TB --- 2012-01-07 10:18:56 - building PAE kernel TB --- 2012-01-07 10:18:56 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 10:18:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 10:18:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 10:18:56 - SRCCONF=/dev/null TB --- 2012-01-07 10:18:56 - TARGET=i386 TB --- 2012-01-07 10:18:56 - TARGET_ARCH=i386 TB --- 2012-01-07 10:18:56 - TZ=UTC TB --- 2012-01-07 10:18:56 - __MAKE_CONF=/dev/null TB --- 2012-01-07 10:18:56 - cd /src TB --- 2012-01-07 10:18:56 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jan 7 10:18:56 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jan 7 10:25:40 UTC 2012 TB --- 2012-01-07 10:25:40 - cd /src/sys/i386/conf TB --- 2012-01-07 10:25:40 - /usr/sbin/config -m XBOX TB --- 2012-01-07 10:25:40 - building XBOX kernel TB --- 2012-01-07 10:25:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 10:25:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 10:25:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 10:25:40 - SRCCONF=/dev/null TB --- 2012-01-07 10:25:40 - TARGET=i386 TB --- 2012-01-07 10:25:40 - TARGET_ARCH=i386 TB --- 2012-01-07 10:25:40 - TZ=UTC TB --- 2012-01-07 10:25:40 - __MAKE_CONF=/dev/null TB --- 2012-01-07 10:25:40 - cd /src TB --- 2012-01-07 10:25:40 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jan 7 10:25:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jan 7 10:29:34 UTC 2012 TB --- 2012-01-07 10:29:34 - cd /src/sys/i386/conf TB --- 2012-01-07 10:29:34 - /usr/sbin/config -m XEN TB --- 2012-01-07 10:29:34 - building XEN kernel TB --- 2012-01-07 10:29:34 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 10:29:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 10:29:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 10:29:34 - SRCCONF=/dev/null TB --- 2012-01-07 10:29:34 - TARGET=i386 TB --- 2012-01-07 10:29:34 - TARGET_ARCH=i386 TB --- 2012-01-07 10:29:34 - TZ=UTC TB --- 2012-01-07 10:29:34 - __MAKE_CONF=/dev/null TB --- 2012-01-07 10:29:34 - cd /src TB --- 2012-01-07 10:29:34 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jan 7 10:29:35 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-07 10:36:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-07 10:36:10 - ERROR: failed to build XEN kernel TB --- 2012-01-07 10:36:10 - 15562.20 user 2678.21 system 19570.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 13:53:35 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ABFA106566B for ; Sat, 7 Jan 2012 13:53:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 404BE8FC15 for ; Sat, 7 Jan 2012 13:53:34 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q07DrRFT021626; Sat, 7 Jan 2012 05:53:31 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201201071353.q07DrRFT021626@gw.catspoiler.org> Date: Sat, 7 Jan 2012 05:53:27 -0800 (PST) From: Don Lewis To: des@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: couldn't log on to my -CURRENT machine after upgrade to latest PAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 13:53:35 -0000 I just upgraded my -CURRENT machine for the first time since mid-November. When I rebooted, I was surprised that I was unable to log in via either ssh or directly on the console. The diagnostics printed to the console indicated that pam_skey.so was missing. Since that was nuked a long time ago, I was puzzled about why it seemed to be required again. I was able to get on the machine by booting it single user. I moved /etc/pam.conf out of the way and am now able to log in. Nothing referenced pam_skey under /etc/pam.d, but I found than I had an ancient copy of /etc/pam.conf that still used pam_skey. The documentation says that /etc/pam.conf is only used if /etc/pam.d/service-name isn't found, and the code appears to agree with that, however this doesn't seem to be working as expected after the latest import of PAM. From owner-freebsd-current@FreeBSD.ORG Sat Jan 7 18:27:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15840106564A; Sat, 7 Jan 2012 18:27:38 +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 A807F8FC12; Sat, 7 Jan 2012 18:27:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id q07IRagM011159; Sat, 7 Jan 2012 13:27:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id q07IRakt011151; Sat, 7 Jan 2012 18:27:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Jan 2012 18:27:36 GMT Message-Id: <201201071827.q07IRakt011151@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: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 18:27:38 -0000 TB --- 2012-01-07 13:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2012-01-07 13:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-01-07 13:00:00 - cleaning the object tree TB --- 2012-01-07 13:00:52 - cvsupping the source tree TB --- 2012-01-07 13:00:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-01-07 13:01:19 - building world TB --- 2012-01-07 13:01:19 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 13:01:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 13:01:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 13:01:19 - SRCCONF=/dev/null TB --- 2012-01-07 13:01:19 - TARGET=i386 TB --- 2012-01-07 13:01:19 - TARGET_ARCH=i386 TB --- 2012-01-07 13:01:19 - TZ=UTC TB --- 2012-01-07 13:01:19 - __MAKE_CONF=/dev/null TB --- 2012-01-07 13:01:19 - cd /src TB --- 2012-01-07 13:01:19 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 7 13:01:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 7 15:10:41 UTC 2012 TB --- 2012-01-07 15:10:41 - generating LINT kernel config TB --- 2012-01-07 15:10:41 - cd /src/sys/i386/conf TB --- 2012-01-07 15:10:41 - /usr/bin/make -B LINT TB --- 2012-01-07 15:10:41 - cd /src/sys/i386/conf TB --- 2012-01-07 15:10:41 - /usr/sbin/config -m LINT TB --- 2012-01-07 15:10:41 - building LINT kernel TB --- 2012-01-07 15:10:41 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 15:10:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 15:10:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 15:10:41 - SRCCONF=/dev/null TB --- 2012-01-07 15:10:41 - TARGET=i386 TB --- 2012-01-07 15:10:41 - TARGET_ARCH=i386 TB --- 2012-01-07 15:10:41 - TZ=UTC TB --- 2012-01-07 15:10:41 - __MAKE_CONF=/dev/null TB --- 2012-01-07 15:10:41 - cd /src TB --- 2012-01-07 15:10:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 7 15:10:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jan 7 15:42:51 UTC 2012 TB --- 2012-01-07 15:42:51 - cd /src/sys/i386/conf TB --- 2012-01-07 15:42:51 - /usr/sbin/config -m LINT-NOINET TB --- 2012-01-07 15:42:51 - building LINT-NOINET kernel TB --- 2012-01-07 15:42:51 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 15:42:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 15:42:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 15:42:51 - SRCCONF=/dev/null TB --- 2012-01-07 15:42:51 - TARGET=i386 TB --- 2012-01-07 15:42:51 - TARGET_ARCH=i386 TB --- 2012-01-07 15:42:51 - TZ=UTC TB --- 2012-01-07 15:42:51 - __MAKE_CONF=/dev/null TB --- 2012-01-07 15:42:51 - cd /src TB --- 2012-01-07 15:42:51 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jan 7 15:42:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jan 7 16:13:32 UTC 2012 TB --- 2012-01-07 16:13:32 - cd /src/sys/i386/conf TB --- 2012-01-07 16:13:32 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-01-07 16:13:33 - building LINT-NOINET6 kernel TB --- 2012-01-07 16:13:33 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 16:13:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 16:13:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 16:13:33 - SRCCONF=/dev/null TB --- 2012-01-07 16:13:33 - TARGET=i386 TB --- 2012-01-07 16:13:33 - TARGET_ARCH=i386 TB --- 2012-01-07 16:13:33 - TZ=UTC TB --- 2012-01-07 16:13:33 - __MAKE_CONF=/dev/null TB --- 2012-01-07 16:13:33 - cd /src TB --- 2012-01-07 16:13:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jan 7 16:13:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jan 7 16:44:40 UTC 2012 TB --- 2012-01-07 16:44:40 - cd /src/sys/i386/conf TB --- 2012-01-07 16:44:40 - /usr/sbin/config -m LINT-NOIP TB --- 2012-01-07 16:44:40 - building LINT-NOIP kernel TB --- 2012-01-07 16:44:40 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 16:44:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 16:44:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 16:44:40 - SRCCONF=/dev/null TB --- 2012-01-07 16:44:40 - TARGET=i386 TB --- 2012-01-07 16:44:40 - TARGET_ARCH=i386 TB --- 2012-01-07 16:44:40 - TZ=UTC TB --- 2012-01-07 16:44:40 - __MAKE_CONF=/dev/null TB --- 2012-01-07 16:44:40 - cd /src TB --- 2012-01-07 16:44:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jan 7 16:44:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jan 7 17:13:16 UTC 2012 TB --- 2012-01-07 17:13:16 - cd /src/sys/i386/conf TB --- 2012-01-07 17:13:16 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-01-07 17:13:16 - building LINT-VIMAGE kernel TB --- 2012-01-07 17:13:16 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 17:13:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 17:13:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 17:13:16 - SRCCONF=/dev/null TB --- 2012-01-07 17:13:16 - TARGET=i386 TB --- 2012-01-07 17:13:16 - TARGET_ARCH=i386 TB --- 2012-01-07 17:13:16 - TZ=UTC TB --- 2012-01-07 17:13:16 - __MAKE_CONF=/dev/null TB --- 2012-01-07 17:13:16 - cd /src TB --- 2012-01-07 17:13:16 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jan 7 17:13:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sat Jan 7 17:45:07 UTC 2012 TB --- 2012-01-07 17:45:07 - cd /src/sys/i386/conf TB --- 2012-01-07 17:45:07 - /usr/sbin/config -m GENERIC TB --- 2012-01-07 17:45:07 - building GENERIC kernel TB --- 2012-01-07 17:45:07 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 17:45:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 17:45:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 17:45:07 - SRCCONF=/dev/null TB --- 2012-01-07 17:45:07 - TARGET=i386 TB --- 2012-01-07 17:45:07 - TARGET_ARCH=i386 TB --- 2012-01-07 17:45:07 - TZ=UTC TB --- 2012-01-07 17:45:07 - __MAKE_CONF=/dev/null TB --- 2012-01-07 17:45:07 - cd /src TB --- 2012-01-07 17:45:07 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jan 7 17:45:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jan 7 18:10:25 UTC 2012 TB --- 2012-01-07 18:10:25 - cd /src/sys/i386/conf TB --- 2012-01-07 18:10:25 - /usr/sbin/config -m PAE TB --- 2012-01-07 18:10:25 - building PAE kernel TB --- 2012-01-07 18:10:25 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 18:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 18:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 18:10:25 - SRCCONF=/dev/null TB --- 2012-01-07 18:10:25 - TARGET=i386 TB --- 2012-01-07 18:10:25 - TARGET_ARCH=i386 TB --- 2012-01-07 18:10:25 - TZ=UTC TB --- 2012-01-07 18:10:25 - __MAKE_CONF=/dev/null TB --- 2012-01-07 18:10:25 - cd /src TB --- 2012-01-07 18:10:25 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jan 7 18:10:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jan 7 18:17:06 UTC 2012 TB --- 2012-01-07 18:17:06 - cd /src/sys/i386/conf TB --- 2012-01-07 18:17:06 - /usr/sbin/config -m XBOX TB --- 2012-01-07 18:17:06 - building XBOX kernel TB --- 2012-01-07 18:17:06 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 18:17:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 18:17:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 18:17:06 - SRCCONF=/dev/null TB --- 2012-01-07 18:17:06 - TARGET=i386 TB --- 2012-01-07 18:17:06 - TARGET_ARCH=i386 TB --- 2012-01-07 18:17:06 - TZ=UTC TB --- 2012-01-07 18:17:06 - __MAKE_CONF=/dev/null TB --- 2012-01-07 18:17:06 - cd /src TB --- 2012-01-07 18:17:06 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jan 7 18:17:06 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jan 7 18:20:36 UTC 2012 TB --- 2012-01-07 18:20:36 - cd /src/sys/i386/conf TB --- 2012-01-07 18:20:36 - /usr/sbin/config -m XEN TB --- 2012-01-07 18:20:36 - building XEN kernel TB --- 2012-01-07 18:20:36 - CROSS_BUILD_TESTING=YES TB --- 2012-01-07 18:20:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-07 18:20:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-07 18:20:36 - SRCCONF=/dev/null TB --- 2012-01-07 18:20:36 - TARGET=i386 TB --- 2012-01-07 18:20:36 - TARGET_ARCH=i386 TB --- 2012-01-07 18:20:36 - TZ=UTC TB --- 2012-01-07 18:20:36 - __MAKE_CONF=/dev/null TB --- 2012-01-07 18:20:36 - cd /src TB --- 2012-01-07 18:20:36 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jan 7 18:20:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_aggr_comp_aggr': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136: error: 'struct ath_tx_status' has no member named 'ts_flags' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139: error: 'struct ath_tx_status' has no member named 'ts_ba_low' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140: error: 'struct ath_tx_status' has no member named 'ts_ba_high' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156: error: 'struct ath_tx_status' has no member named 'ts_tid' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158: error: 'struct ath_tx_status' has no member named 'ts_tid' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-07 18:27:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-07 18:27:36 - ERROR: failed to build XEN kernel TB --- 2012-01-07 18:27:36 - 15566.43 user 2722.06 system 19656.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full