From owner-freebsd-stable@FreeBSD.ORG Mon Aug 25 06:09:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22CC9E0 for ; Mon, 25 Aug 2014 06:09:57 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1259327B for ; Mon, 25 Aug 2014 06:09:56 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z11so11892239lbi.27 for ; Sun, 24 Aug 2014 23:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=qnvuaErRqwG+aJchjyO5OrpKWTJdpeztnI4VfUZNr6U=; b=waunnZS1WYLwm6b4JaUFTbCv9ItYBy7iG5YbTFRAgG1rrH1UIrQcNkhJPIsJwSThEg rNZ/CDe37FsyweofjjIs5q/Un9Q8i80THrpN8RuIC+nSnvZNpv+Z/7FotpGBK+OU+InP 8trZ1chhKxwWj5n93/PtlSDN98NJuE8ryG8erA9FAWwBRkTDlcwX9MwvEDRFfnLPDUUZ esGzzttjSHHlyKrWyAobdoo3LL+sSuHeta9F7xlJnqt9Trfz5Lay9HH484BE29IID2Yn hj0jQ+UiFE0lUg5d+TPquNl2fKcr1koDaYV36ppoMExR61fU08TPoCId2YnSOeyMgwrq UT5g== X-Received: by 10.112.52.130 with SMTP id t2mr18579713lbo.61.1408946994393; Sun, 24 Aug 2014 23:09:54 -0700 (PDT) Received: from laptop.minsk.domain (minsk.nivalnetwork.com. [86.57.144.74]) by mx.google.com with ESMTPSA id dk4sm61077339lbb.38.2014.08.24.23.09.52 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Aug 2014 23:09:53 -0700 (PDT) Date: Mon, 25 Aug 2014 09:10:12 +0300 From: "Sergey V. Dyatko" To: Subject: strange load avg calculation on 10. Message-ID: <20140825091012.589f010e@laptop.minsk.domain> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 06:09:57 -0000 Hi, I have few VMs with FreeBSD 10-R / 10-STABLE running under qemu-kvm, all of them show me strange load avg on top/w output, something like: last pid: 17711; load averages: 0.22, 0.15, 0.15 up 4+11:52:35 05:54:08 24 processes: 1 running, 23 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 5456K Active, 176M Inact, 385M Wired, 827M Buf, 7381M Free -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 07:23:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7CEB815 for ; Tue, 26 Aug 2014 07:23:42 +0000 (UTC) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id C51DD32A0 for ; Tue, 26 Aug 2014 07:23:42 +0000 (UTC) Received: from akips.com (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id 5A39915 for ; Tue, 26 Aug 2014 17:17:19 +1000 (EST) Date: Tue, 26 Aug 2014 17:16:57 +1000 From: Paul Koch To: Subject: 10.0 interaction with vmware Message-ID: <20140826171657.0c79c54d@akips.com> Organization: AKIPS X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on host1.akips.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:23:42 -0000 Curious if anyone has an understanding of what actually goes on with VMWare memory control of a FreeBSD 10 guest when open-vm-tools is installed and how it could affect performance. Our typical customer environment is a largish VMWare server with an appropriate amount of RAM allocated to the guest, which currently runs FreeBSD 10.0p7 + our software, UFS root, and data stored on a ZFS partition. Our software mmaps large database files, does rather largish data collection (ping, snmp, netflow, syslog, etc) and mostly cruises along, but performance drops off a cliff in low memory situations. We don't install open-vm-tools at the moment, therefore we have a known amount of memory to work with (ie. what the customer initially=20 configured the guest for), but our customers (or in particular, their VM guys) would really like vmware tools or open-vm-tools by default. =46rom what we gather, many sites choose to "over provision" the memory in the VM setups, and when memory gets low, the host takes back=20 some of the RAM allocated to the guest. How does this work actually work ? Does it only take back what FreeBSD considers to be "free" memory or can the host start taking back "inactive", "wired", "zfs arc" memory ? We tend to rely on stuff being in inactive and zfs arc. If we start swapping, we are dead. Also, is there much of a performance hit if the host steals back free memory, and then gives it back ? We'd assume all memory the host gives to the guest is pre-bzero'ed so the FreeBSD wouldn't need to also bzero it. Paul. --=20 Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 08:21:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25CFCAF0 for ; Tue, 26 Aug 2014 08:21:36 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B46B8388B for ; Tue, 26 Aug 2014 08:21:35 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so3716809wiv.9 for ; Tue, 26 Aug 2014 01:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Pek+jig7i3lwogitWmeWjF/oI0mtjl1OCXSgJnqOTPw=; b=kT8XDzql90PVmbRxByZYn9GJ52G9Dq97e+U5BnENt1RUFwRka4M0DgKdI1KN/7zgHM kq/Ct/m1imrn/RcmSTFJi1jkHQ4DElrO0TfL0QFfy/zkynkhsYnt1Eo6woBafwjKZpnd lVIQRsowXXWqcUeSVahIhOkrocKDv/9wPa6w+GbWgM7ZNxx4byCrMMmzrAHlD9FkS1Ca jkxTIe4Nn9DUEjIiYhoYZqjNvBluvwDYcQGoTVCxRxaiWMDhPwMGW4E97gmnZkIi8jnq QbYGqrDcVXF6edehN535sXyUd6C9NaKk1RuDxSMrIZNCnGtZ0ZqhUSbQi1pT7Icg1bY4 h8bQ== X-Received: by 10.180.39.172 with SMTP id q12mr20232074wik.55.1409041294027; Tue, 26 Aug 2014 01:21:34 -0700 (PDT) Received: from kontrol.kode5.net (host81-157-206-146.range81-157.btcentralplus.com. [81.157.206.146]) by mx.google.com with ESMTPSA id z8sm9508388wiv.24.2014.08.26.01.21.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 01:21:33 -0700 (PDT) Message-ID: <53FC438C.20105@gmail.com> Date: Tue, 26 Aug 2014 09:21:32 +0100 From: Jamie Griffin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD Questions Subject: drm error in dmesg since using newcons Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 08:21:36 -0000 I posted this info in questions@ but got no feedback so thought I should post here instead. Details below. Does anyone know what is causing this error? I'm now using r270438 and it happened again on this version too. info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state i915: render error detected, EIR: 0x00000010 IPEIR: 0x00000000 IPEHR: 0x01000000 INSTDONE: 0xfffffffe INSTPS: 0x0001e000 INSTDONE1: 0xffffffff ACTHD: 0x0320ba08 page table error PGTBL_ER: 0x00000002 error: [drm:pid12:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking Does anyone know what this is and what I should/could do to fix it? This system is FreeBSD 10-STABLE r269787 amd64 From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 13:39:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 970BDB6 for ; Tue, 26 Aug 2014 13:39:25 +0000 (UTC) Received: from smtp.teambox.fr (smtp.teambox.fr [212.129.12.31]) by mx1.freebsd.org (Postfix) with ESMTP id 300B63763 for ; Tue, 26 Aug 2014 13:39:24 +0000 (UTC) Received: from mail.teambox.fr (mail.teambox.fr [212.129.12.27]) by smtp.teambox.fr (Postfix) with ESMTPSA id 502211202D0 for ; Tue, 26 Aug 2014 15:30:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.local.mindstep.fr (Postfix) with ESMTP id B1F03FCA617 for ; Tue, 26 Aug 2014 15:30:03 +0200 (CEST) (envelope-from patrick.bihan-faou@teambox.fr) X-Virus-Scanned: by amavisd-new on ZunoBox at mail.local.mindstep.fr Received: from mail.local.mindstep.fr ([127.0.0.1]) by localhost (mail.local.mindstep.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ixVIBbG6IuQT for ; Tue, 26 Aug 2014 15:30:03 +0200 (CEST) Received: from [192.168.25.62] (crest.mindstep.com [88.167.204.204]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.local.mindstep.fr (Postfix) with ESMTP id 6A828FCA429 for ; Tue, 26 Aug 2014 15:30:03 +0200 (CEST) (envelope-from patrick.bihan-faou@teambox.fr) Message-ID: <53FC8BD9.3070903@teambox.fr> Date: Tue, 26 Aug 2014 15:30:01 +0200 From: Patrick Bihan-Faou Organization: TeamBox SARL User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.0 interaction with vmware References: <20140826171657.0c79c54d@akips.com> In-Reply-To: <20140826171657.0c79c54d@akips.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 13:39:25 -0000 Hi, From what I understand of the VMWare tools is that it adds a kernel module that comunicates with the host. When the host is under memory pressure it claims some of the memory used by each VM by asking the kernel module to grab RAM. This active RAM is "reserved" by the kernel module and can then be used by the host for another VM. This mechanism will increase the memory pressure inside your VM, which can lead to some swapping or freeing of otherwise less used memory pages in the OS. This cooperative mode of sharing the memory pressure experienced by the hypervisor is called "ballooning" in VMWare terms. The kernel module responsible to implement the VM side of this si called vmmemctl.ko. If the memory requirements cannot be met using this "ballooning" technique (or if none of the VM have the vmware tools enabled), you will start to see swapping at the host level, which will be much worse than swapping at the VM level. This is the main reason why you should run the vmware tools. Regards, Patrick. On 26/08/2014 09:16, Paul Koch wrote: > Curious if anyone has an understanding of what actually goes on > with VMWare memory control of a FreeBSD 10 guest when open-vm-tools > is installed and how it could affect performance. > > Our typical customer environment is a largish VMWare server with > an appropriate amount of RAM allocated to the guest, which currently > runs FreeBSD 10.0p7 + our software, UFS root, and data stored on a > ZFS partition. Our software mmaps large database files, does rather > largish data collection (ping, snmp, netflow, syslog, etc) and > mostly cruises along, but performance drops off a cliff in low > memory situations. > > We don't install open-vm-tools at the moment, therefore we have a known > amount of memory to work with (ie. what the customer initially > configured the guest for), but our customers (or in particular, their > VM guys) would really like vmware tools or open-vm-tools by default. > > From what we gather, many sites choose to "over provision" the memory > in the VM setups, and when memory gets low, the host takes back > some of the RAM allocated to the guest. > > How does this work actually work ? Does it only take back what > FreeBSD considers to be "free" memory or can the host start taking > back "inactive", "wired", "zfs arc" memory ? We tend to rely on > stuff being in inactive and zfs arc. If we start swapping, we > are dead. > > Also, is there much of a performance hit if the host steals back > free memory, and then gives it back ? We'd assume all memory > the host gives to the guest is pre-bzero'ed so the FreeBSD wouldn't > need to also bzero it. > > Paul. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 14:03:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 456E6F2B for ; Tue, 26 Aug 2014 14:03:31 +0000 (UTC) Received: from mail.intermedix.com (mail.epbs.com [66.210.191.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Barracuda/emailAddress=sales@barracuda.com", Issuer "Barracuda/emailAddress=sales@barracuda.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 01E0F3AD4 for ; Tue, 26 Aug 2014 14:03:30 +0000 (UTC) X-ASG-Debug-ID: 1409061803-049956325c46a8b0001-BIHDGU Received: from mailgate00.corp.okcyok1.priv.intermedix.com (mailgate00.epbs.com [10.130.4.34]) by mail.intermedix.com with ESMTP id yqPSlunKEhfshyyW; Tue, 26 Aug 2014 09:03:23 -0500 (CDT) X-Barracuda-Envelope-From: Steve.Polyack@intermedix.com X-ASG-Whitelist: Client X-WSS-ID: 0NAX31L-01-7GA-02 X-M-MSG: Received: from exchange02.epbs.com (exchange02.okcyok0.priv.intermedix.com [192.168.25.29]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailgate00.corp.okcyok1.priv.intermedix.com (Postfix) with ESMTPS id 237C9B9056F; Tue, 26 Aug 2014 09:03:20 -0500 (CDT) Received: from EXCHANGE03.epbs.com ([0000:0000:0000:0000:0000:0000:0.0.0.1]) by exchange02.epbs.com ([192.168.25.29]) with mapi; Tue, 26 Aug 2014 09:03:22 -0500 From: "Polyack, Steve" To: Alan Cox , "freebsd-stable@freebsd.org" Date: Tue, 26 Aug 2014 09:03:20 -0500 Subject: RE: vmdaemon CPU usage and poor performance in 10.0-RELEASE Thread-Topic: vmdaemon CPU usage and poor performance in 10.0-RELEASE X-ASG-Orig-Subj: RE: vmdaemon CPU usage and poor performance in 10.0-RELEASE Thread-Index: Ac+9Dr2YRCM5RMwwQtGdvWvRp2XaMQEJ5EJg Message-ID: <4D557EC7CC2A544AA7C1A3B9CBA2B36726493B318B@exchange03.epbs.com> References: <4D557EC7CC2A544AA7C1A3B9CBA2B36726098846B4@exchange03.epbs.com> <20140813152522.GI9400@home.opsec.eu> <4D557EC7CC2A544AA7C1A3B9CBA2B36726098847AF@exchange03.epbs.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609BBA3C4@exchange03.epbs.com> <53F24E5B.1010809@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609BBA64F@exchange03.epbs.com> <53F2790C.20703@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF28E5@exchange03.epbs.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF2F8F@exchange03.epbs.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF31F0@exchange03.epbs.com> <53F4C4C2.1030109@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF335D@exchange03.epbs.com> <53F4C82E.5000900@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF33F6@exchange03.epbs.com> <53F59AF6.6080204@rice.edu> In-Reply-To: <53F59AF6.6080204@rice.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mailgate00.epbs.com[10.130.4.34] X-Barracuda-Start-Time: 1409061803 X-Barracuda-URL: http://192.168.25.21:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at intermedix.com X-Barracuda-BRTS-Status: 1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:03:31 -0000 > -----Original Message----- > From: Alan Cox [mailto:alc@rice.edu] > Sent: Thursday, August 21, 2014 3:09 AM > To: Polyack, Steve; freebsd-stable@freebsd.org > Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE >=20 > On 08/20/2014 11:22, Polyack, Steve wrote: > >> -----Original Message----- > >> From: Alan Cox [mailto:alc@rice.edu] > >> Sent: Wednesday, August 20, 2014 12:09 PM > >> To: Polyack, Steve; freebsd-stable@freebsd.org > >> Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE > >> > >> On 08/20/2014 10:56, Polyack, Steve wrote: > >>>> -----Original Message----- > >>>> From: Alan Cox [mailto:alc@rice.edu] > >>>> Sent: Wednesday, August 20, 2014 11:55 AM > >>>> To: Polyack, Steve; freebsd-stable@freebsd.org > >>>> Subject: Re: vmdaemon CPU usage and poor performance in 10.0- > RELEASE > >>>> > >>>> On 08/20/2014 09:55, Polyack, Steve wrote: > >>>>>> -----Original Message----- > >>>>>> From: Polyack, Steve > >>>>>> Sent: Wednesday, August 20, 2014 9:14 AM > >>>>>> To: Polyack, Steve; Alan Cox; freebsd-stable@freebsd.org > >>>>>> Subject: RE: vmdaemon CPU usage and poor performance in 10.0- > >> RELEASE > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > >>>>>>> stable@freebsd.org] On Behalf Of Polyack, Steve > >>>>>>> Sent: Tuesday, August 19, 2014 12:37 PM > >>>>>>> To: Alan Cox; freebsd-stable@freebsd.org > >>>>>>> Subject: RE: vmdaemon CPU usage and poor performance in 10.0- > >>>> RELEASE > >>>>>>>> -----Original Message----- > >>>>>>>> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > >>>>>>>> stable@freebsd.org] On Behalf Of Alan Cox > >>>>>>>> Sent: Monday, August 18, 2014 6:07 PM > >>>>>>>> To: freebsd-stable@freebsd.org > >>>>>>>> Subject: Re: vmdaemon CPU usage and poor performance in 10.0- > >>>>>> RELEASE > >>>>>>>> On 08/18/2014 16:29, Polyack, Steve wrote: > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: owner-freebsd-stable@freebsd.org [mailto:owner- > freebsd- > >>>>>>>>>> stable@freebsd.org] On Behalf Of Alan Cox > >>>>>>>>>> Sent: Monday, August 18, 2014 3:05 PM > >>>>>>>>>> To: freebsd-stable@freebsd.org > >>>>>>>>>> Subject: Re: vmdaemon CPU usage and poor performance in > 10.0- > >>>>>>> RELEASE > >>>>>>>>>> On 08/18/2014 13:42, Polyack, Steve wrote: > >>>>>>>>>>> Excuse my poorly formatted reply at the moment, but this > seems > >> to > >>>>>>>> have > >>>>>>>>>> fixed our problems. I'm going to update the bug report with a > >> note. > >>>>>>>>>>> Thanks Alan! > >>>>>>>>>> You're welcome. And, thanks for letting me know of the > outcome. > >>>>>>>>>> > >>>>>>>>> Actually, I may have spoken too soon, as it looks like we're se= eing > >>>>>>>> vmdaemon tying up the system again: > >>>>>>>>> root 6 100.0 0.0 0 16 - DL We= d04PM 4:37.95 > >>>>>>> [vmdaemon] > >>>>>>>>> Is there anything I can check to help narrow down what may be > the > >>>>>>>> problem? KTrace/truss on the "process" doesn't give any > >> information, I > >>>>>>>> suppose because it's actually a kernel thread. > >>>>>>>> > >>>>>>>> Can you provide the full output of top? Is there anything unusu= al > >>>> about > >>>>>>>> the hardware or software configuration? > >>>>>>> This may have just been a fluke (maybe NFS caching the old > >>>> vm_pageout.c > >>>>>>> during the first source build). We've rebuilt and are monitoring= it > >> now. > >>>>>>> The hardware consists of a few Dell PowerEdge R720xd servers with > >>>> 256GB > >>>>>>> of RAM and array of SSDs (no ZFS). 64GB is dedicated to postgres > >>>>>>> shared_buffers right now. FreeBSD 10, PostgreSQL 9.3, Slony-I > v2.2.2, > >>>> and > >>>>>>> redis-2.8.11 are all in use here. I can't say that anything is u= nusual > >> about > >>>>>> the > >>>>>>> configuration. > >>>>>>> > >>>>>> We are still seeing the issue. It seems to manifest once the "Fre= e" > >>>> memory > >>>>>> gets under 10GB (of 256GB on the system), even though ~200GB of > this > >> is > >>>>>> classified as Inactive. For us, this was about 7 hours of databas= e > >> activity > >>>>>> (initial replication w/ slony). Right now vmdaemon is consuming > 100% > >>>> CPU > >>>>>> and shows 671:34 CPU time when it showed 0:00 up until the > problem > >>>>>> manifested. The full top output (that fits on my screen) is below= : > >>>>>> > >>>>>> last pid: 62309; load averages: 4.05, 4.24, 4.10 > >>>>>> up 0+22:34:31 09:08:43 > >>>>>> 159 processes: 8 running, 145 sleeping, 1 waiting, 5 lock > >>>>>> CPU: 14.5% user, 0.0% nice, 4.9% system, 0.0% interrupt, 80.5% = idle > >>>>>> Mem: 26G Active, 216G Inact, 4122M Wired, 1178M Cache, 1632M Buf, > >>>> 2136M > >>>>>> Free > >>>>>> Swap: 32G Total, 32G Free > >>>>>> > >>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME = WCPU > >>>>>> COMMAND > >>>>>> 11 root 32 155 ki31 0K 512K CPU31 31 669.6H 2= 934.23% idle > >>>>>> 6 root 1 -16 - 0K 16K CPU19 19 678:57 1= 00.00% > vmdaemon > >>>>>> 1963 pgsql 1 45 0 67538M 208M CPU0 0 121:46 = 17.38% > >> postgres > >>>>>> 2037 pgsql 1 77 0 67536M 2200K *vm ob 14 6:24 = 15.97% > >> postgres > >>>>>> 1864 pgsql 1 31 0 67536M 1290M semwai 4 174:41 = 15.19% > >>>> postgres > >>>>>> 1996 pgsql 1 38 0 67538M 202M semwai 16 120:27 = 15.09% > >>>> postgres > >>>>>> 1959 pgsql 1 39 0 67538M 204M CPU27 27 117:30 = 15.09% > >> postgres > >>>>>> 1849 pgsql 1 32 0 67536M 1272M semwai 23 126:22 = 13.96% > >>>> postgres > >>>>>> 1997 pgsql 1 31 0 67538M 206M CPU30 30 122:26 = 11.77% > >> postgres > >>>>>> 2002 pgsql 1 34 0 67538M 182M sbwait 11 55:20 = 11.28% > >> postgres > >>>>>> 1961 pgsql 1 32 0 67538M 206M CPU12 12 121:47 = 10.99% > >> postgres > >>>>>> 1964 pgsql 1 30 0 67538M 206M semwai 28 122:08 = 9.86% > >> postgres > >>>>>> 1962 pgsql 1 29 0 67538M 1286M sbwait 2 45:49 = 7.18% > >> postgres > >>>>>> 1752 root 1 22 0 78356K 8688K CPU2 2 175:46 = 6.88% snmpd > >>>>>> 1965 pgsql 1 25 0 67538M 207M semwai 9 120:55 = 6.59% > >> postgres > >>>>>> 1960 pgsql 1 23 0 67538M 177M semwai 6 52:42 = 4.88% > >> postgres > >>>>>> 1863 pgsql 1 25 0 67542M 388M semwai 25 9:12 = 2.20% > >> postgres > >>>>>> 1859 pgsql 1 22 0 67538M 1453M *vm ob 20 6:13 = 2.10% > >> postgres > >>>>>> 1860 pgsql 1 22 0 67538M 1454M sbwait 8 6:08 = 1.95% > postgres > >>>>>> 1848 pgsql 1 21 0 67586M 66676M *vm ob 30 517:07 = 1.66% > >>>> postgres > >>>>>> 1856 pgsql 1 22 0 67538M 290M *vm ob 15 5:39 = 1.66% > >> postgres > >>>>>> 1846 pgsql 1 21 0 67538M 163M sbwait 15 5:46 = 1.46% > postgres > >>>>>> 1853 pgsql 1 21 0 67538M 110M sbwait 30 8:54 = 1.17% > postgres > >>>>>> 1989 pgsql 1 23 0 67536M 5180K sbwait 18 1:41 = 0.98% > postgres > >>>>>> 5 root 1 -16 - 0K 16K psleep 6 9:33 = 0.78% pagedaemon > >>>>>> 1854 pgsql 1 20 0 67538M 338M sbwait 22 5:38 = 0.78% > postgres > >>>>>> 1861 pgsql 1 20 0 67538M 286M sbwait 15 6:13 = 0.68% > postgres > >>>>>> 1857 pgsql 1 20 0 67538M 1454M semwai 10 6:19 = 0.49% > >> postgres > >>>>>> 1999 pgsql 1 36 0 67538M 156M *vm ob 28 120:56 = 0.39% > >> postgres > >>>>>> 1851 pgsql 1 20 0 67538M 136M sbwait 22 5:48 = 0.39% > postgres > >>>>>> 1975 pgsql 1 20 0 67536M 5688K sbwait 25 1:40 = 0.29% > postgres > >>>>>> 1858 pgsql 1 20 0 67538M 417M sbwait 3 5:55 = 0.20% > postgres > >>>>>> 2031 pgsql 1 20 0 67536M 5664K sbwait 5 3:26 = 0.10% > postgres > >>>>>> 1834 root 12 20 0 71892K 12848K select 20 34:05 = 0.00% slon > >>>>>> 12 root 78 -76 - 0K 1248K WAIT 0 25:47 = 0.00% intr > >>>>>> 2041 pgsql 1 20 0 67536M 5932K sbwait 14 12:50 = 0.00% > >> postgres > >>>>>> 2039 pgsql 1 20 0 67536M 5960K sbwait 17 9:59 = 0.00% > postgres > >>>>>> 2038 pgsql 1 20 0 67536M 5956K sbwait 6 8:21 = 0.00% > postgres > >>>>>> 2040 pgsql 1 20 0 67536M 5996K sbwait 7 8:20 = 0.00% > postgres > >>>>>> 2032 pgsql 1 20 0 67536M 5800K sbwait 22 7:03 = 0.00% > postgres > >>>>>> 2036 pgsql 1 20 0 67536M 5748K sbwait 23 6:38 = 0.00% > postgres > >>>>>> 1812 pgsql 1 20 0 67538M 59185M select 1 5:46 = 0.00% > postgres > >>>>>> 2005 pgsql 1 20 0 67536M 5788K sbwait 23 5:14 = 0.00% > postgres > >>>>>> 2035 pgsql 1 20 0 67536M 4892K sbwait 18 4:52 = 0.00% > >> > >>>>>> 1852 pgsql 1 21 0 67536M 1230M semwai 7 4:47 = 0.00% > >> postgres > >>>>>> 13 root 3 -8 - 0K 48K - 28 4:46 = 0.00% geom > >>>>>> > >>>>>> > >>>>> Another thing I've noticed is that this sysctl vm.stats counter is > >> increasing > >>>> fairly rapidly: > >>>>> # sysctl vm.stats.vm.v_pdpages && sleep 1 && sysctl > >>>> vm.stats.vm.v_pdpages > >>>>> vm.stats.vm.v_pdpages: 3455264541 > >>>>> vm.stats.vm.v_pdpages: 3662158383 > >>>> I'm not sure what that tells us, because both the page daemon and th= e > >> vm > >>>> ("swap") daemon increment this counter. > >>>> > >>>>> Also, to demonstrate what kind of problems this seems to cause: > >>>>> # time sleep 1 > >>>>> > >>>>> real 0m18.288s > >>>>> user 0m0.001s > >>>>> sys 0m0.004s > >>>> If you change the sysctl vm.swap_enabled to 0, how does your system > >>>> behave? > >>>> > >>> Setting vm.swap_enabled to 0 made the problem clear up almost > >> instantly. vmdaemon is back to 0.00% CPU usage and the system is > >> responsive once again. > >>> > >> I doubt that you need whole process swapping. The page daemon is > >> probably sufficient. See how things go for a few days and let me know= . > >> > >> There is still a bug here that needs diagnosing and fixing. So, I wil= l > >> likely send you a debugging patch in the near future, and ask you to > >> reenable swapping under that patch. > >> > > If it helps at all - setting vm.swap_enabled=3D0 seems to fix the probl= em > even without the aforementioned patch to vm_pageout.c. > > >=20 >=20 > I have a couple hypotheses for what is causing your problem. The > attached patch addresses one of them. Please apply this patch and then > reset vm._swap_enabled back to 1. >=20 This seems to have solved the problem. We have been running for ~16 hours = where "Free" memory has been under 2GB on one of these sytems under postgre= s/slony load and vmdaemon shows 0:00.00 CPU time used. Vm.swap_enabled is = set to the default (1). Thanks again, Steve From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 17:17:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5A831AC for ; Tue, 26 Aug 2014 17:17:14 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A035F3DC5 for ; Tue, 26 Aug 2014 17:17:14 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s7QHCT8P022635; Tue, 26 Aug 2014 12:17:05 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1p0g21rbk4-1; Tue, 26 Aug 2014 12:17:04 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 8AC644C0096; Tue, 26 Aug 2014 12:17:04 -0500 (CDT) Message-ID: <53FCC10E.4010300@rice.edu> Date: Tue, 26 Aug 2014 12:17:02 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Polyack, Steve" , "freebsd-stable@freebsd.org" Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE References: <4D557EC7CC2A544AA7C1A3B9CBA2B36726098846B4@exchange03.epbs.com> <20140813152522.GI9400@home.opsec.eu> <4D557EC7CC2A544AA7C1A3B9CBA2B36726098847AF@exchange03.epbs.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609BBA3C4@exchange03.epbs.com> <53F24E5B.1010809@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609BBA64F@exchange03.epbs.com> <53F2790C.20703@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF28E5@exchange03.epbs.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF2F8F@exchange03.epbs.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF31F0@exchange03.epbs.com> <53F4C4C2.1030109@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF335D@exchange03.epbs.com> <53F4C82E.5000900@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF33F6@exchange03.epbs.com> <53F59AF6.6080204@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B36726493B318B@exchange03.epbs.com> In-Reply-To: <4D557EC7CC2A544AA7C1A3B9CBA2B36726493B318B@exchange03.epbs.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=7.19010057048664e-09 kscore.compositescore=6.53647691528647e-11 circleOfTrustscore=0 compositescore=0.601168957438983 urlsuspect_oldscore=0.00116895743898306 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.601168957438983 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408260191 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 17:17:15 -0000 On 08/26/2014 09:03, Polyack, Steve wrote: >> -----Original Message----- >> From: Alan Cox [mailto:alc@rice.edu] >> Sent: Thursday, August 21, 2014 3:09 AM >> To: Polyack, Steve; freebsd-stable@freebsd.org >> Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE >> >> On 08/20/2014 11:22, Polyack, Steve wrote: >>>> -----Original Message----- >>>> From: Alan Cox [mailto:alc@rice.edu] >>>> Sent: Wednesday, August 20, 2014 12:09 PM >>>> To: Polyack, Steve; freebsd-stable@freebsd.org >>>> Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE >>>> >>>> On 08/20/2014 10:56, Polyack, Steve wrote: >>>>>> -----Original Message----- >>>>>> From: Alan Cox [mailto:alc@rice.edu] >>>>>> Sent: Wednesday, August 20, 2014 11:55 AM >>>>>> To: Polyack, Steve; freebsd-stable@freebsd.org >>>>>> Subject: Re: vmdaemon CPU usage and poor performance in 10.0- >> RELEASE >>>>>> On 08/20/2014 09:55, Polyack, Steve wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: Polyack, Steve >>>>>>>> Sent: Wednesday, August 20, 2014 9:14 AM >>>>>>>> To: Polyack, Steve; Alan Cox; freebsd-stable@freebsd.org >>>>>>>> Subject: RE: vmdaemon CPU usage and poor performance in 10.0- >>>> RELEASE >>>>>>>>> -----Original Message----- >>>>>>>>> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >>>>>>>>> stable@freebsd.org] On Behalf Of Polyack, Steve >>>>>>>>> Sent: Tuesday, August 19, 2014 12:37 PM >>>>>>>>> To: Alan Cox; freebsd-stable@freebsd.org >>>>>>>>> Subject: RE: vmdaemon CPU usage and poor performance in 10.0- >>>>>> RELEASE >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >>>>>>>>>> stable@freebsd.org] On Behalf Of Alan Cox >>>>>>>>>> Sent: Monday, August 18, 2014 6:07 PM >>>>>>>>>> To: freebsd-stable@freebsd.org >>>>>>>>>> Subject: Re: vmdaemon CPU usage and poor performance in 10.0- >>>>>>>> RELEASE >>>>>>>>>> On 08/18/2014 16:29, Polyack, Steve wrote: >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: owner-freebsd-stable@freebsd.org [mailto:owner- >> freebsd- >>>>>>>>>>>> stable@freebsd.org] On Behalf Of Alan Cox >>>>>>>>>>>> Sent: Monday, August 18, 2014 3:05 PM >>>>>>>>>>>> To: freebsd-stable@freebsd.org >>>>>>>>>>>> Subject: Re: vmdaemon CPU usage and poor performance in >> 10.0- >>>>>>>>> RELEASE >>>>>>>>>>>> On 08/18/2014 13:42, Polyack, Steve wrote: >>>>>>>>>>>>> Excuse my poorly formatted reply at the moment, but this >> seems >>>> to >>>>>>>>>> have >>>>>>>>>>>> fixed our problems. I'm going to update the bug report with a >>>> note. >>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> You're welcome. And, thanks for letting me know of the >> outcome. >>>>>>>>>>> Actually, I may have spoken too soon, as it looks like we're seeing >>>>>>>>>> vmdaemon tying up the system again: >>>>>>>>>>> root 6 100.0 0.0 0 16 - DL Wed04PM 4:37.95 >>>>>>>>> [vmdaemon] >>>>>>>>>>> Is there anything I can check to help narrow down what may be >> the >>>>>>>>>> problem? KTrace/truss on the "process" doesn't give any >>>> information, I >>>>>>>>>> suppose because it's actually a kernel thread. >>>>>>>>>> >>>>>>>>>> Can you provide the full output of top? Is there anything unusual >>>>>> about >>>>>>>>>> the hardware or software configuration? >>>>>>>>> This may have just been a fluke (maybe NFS caching the old >>>>>> vm_pageout.c >>>>>>>>> during the first source build). We've rebuilt and are monitoring it >>>> now. >>>>>>>>> The hardware consists of a few Dell PowerEdge R720xd servers with >>>>>> 256GB >>>>>>>>> of RAM and array of SSDs (no ZFS). 64GB is dedicated to postgres >>>>>>>>> shared_buffers right now. FreeBSD 10, PostgreSQL 9.3, Slony-I >> v2.2.2, >>>>>> and >>>>>>>>> redis-2.8.11 are all in use here. I can't say that anything is unusual >>>> about >>>>>>>> the >>>>>>>>> configuration. >>>>>>>>> >>>>>>>> We are still seeing the issue. It seems to manifest once the "Free" >>>>>> memory >>>>>>>> gets under 10GB (of 256GB on the system), even though ~200GB of >> this >>>> is >>>>>>>> classified as Inactive. For us, this was about 7 hours of database >>>> activity >>>>>>>> (initial replication w/ slony). Right now vmdaemon is consuming >> 100% >>>>>> CPU >>>>>>>> and shows 671:34 CPU time when it showed 0:00 up until the >> problem >>>>>>>> manifested. The full top output (that fits on my screen) is below: >>>>>>>> >>>>>>>> last pid: 62309; load averages: 4.05, 4.24, 4.10 >>>>>>>> up 0+22:34:31 09:08:43 >>>>>>>> 159 processes: 8 running, 145 sleeping, 1 waiting, 5 lock >>>>>>>> CPU: 14.5% user, 0.0% nice, 4.9% system, 0.0% interrupt, 80.5% idle >>>>>>>> Mem: 26G Active, 216G Inact, 4122M Wired, 1178M Cache, 1632M Buf, >>>>>> 2136M >>>>>>>> Free >>>>>>>> Swap: 32G Total, 32G Free >>>>>>>> >>>>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>>>>> COMMAND >>>>>>>> 11 root 32 155 ki31 0K 512K CPU31 31 669.6H 2934.23% idle >>>>>>>> 6 root 1 -16 - 0K 16K CPU19 19 678:57 100.00% >> vmdaemon >>>>>>>> 1963 pgsql 1 45 0 67538M 208M CPU0 0 121:46 17.38% >>>> postgres >>>>>>>> 2037 pgsql 1 77 0 67536M 2200K *vm ob 14 6:24 15.97% >>>> postgres >>>>>>>> 1864 pgsql 1 31 0 67536M 1290M semwai 4 174:41 15.19% >>>>>> postgres >>>>>>>> 1996 pgsql 1 38 0 67538M 202M semwai 16 120:27 15.09% >>>>>> postgres >>>>>>>> 1959 pgsql 1 39 0 67538M 204M CPU27 27 117:30 15.09% >>>> postgres >>>>>>>> 1849 pgsql 1 32 0 67536M 1272M semwai 23 126:22 13.96% >>>>>> postgres >>>>>>>> 1997 pgsql 1 31 0 67538M 206M CPU30 30 122:26 11.77% >>>> postgres >>>>>>>> 2002 pgsql 1 34 0 67538M 182M sbwait 11 55:20 11.28% >>>> postgres >>>>>>>> 1961 pgsql 1 32 0 67538M 206M CPU12 12 121:47 10.99% >>>> postgres >>>>>>>> 1964 pgsql 1 30 0 67538M 206M semwai 28 122:08 9.86% >>>> postgres >>>>>>>> 1962 pgsql 1 29 0 67538M 1286M sbwait 2 45:49 7.18% >>>> postgres >>>>>>>> 1752 root 1 22 0 78356K 8688K CPU2 2 175:46 6.88% snmpd >>>>>>>> 1965 pgsql 1 25 0 67538M 207M semwai 9 120:55 6.59% >>>> postgres >>>>>>>> 1960 pgsql 1 23 0 67538M 177M semwai 6 52:42 4.88% >>>> postgres >>>>>>>> 1863 pgsql 1 25 0 67542M 388M semwai 25 9:12 2.20% >>>> postgres >>>>>>>> 1859 pgsql 1 22 0 67538M 1453M *vm ob 20 6:13 2.10% >>>> postgres >>>>>>>> 1860 pgsql 1 22 0 67538M 1454M sbwait 8 6:08 1.95% >> postgres >>>>>>>> 1848 pgsql 1 21 0 67586M 66676M *vm ob 30 517:07 1.66% >>>>>> postgres >>>>>>>> 1856 pgsql 1 22 0 67538M 290M *vm ob 15 5:39 1.66% >>>> postgres >>>>>>>> 1846 pgsql 1 21 0 67538M 163M sbwait 15 5:46 1.46% >> postgres >>>>>>>> 1853 pgsql 1 21 0 67538M 110M sbwait 30 8:54 1.17% >> postgres >>>>>>>> 1989 pgsql 1 23 0 67536M 5180K sbwait 18 1:41 0.98% >> postgres >>>>>>>> 5 root 1 -16 - 0K 16K psleep 6 9:33 0.78% pagedaemon >>>>>>>> 1854 pgsql 1 20 0 67538M 338M sbwait 22 5:38 0.78% >> postgres >>>>>>>> 1861 pgsql 1 20 0 67538M 286M sbwait 15 6:13 0.68% >> postgres >>>>>>>> 1857 pgsql 1 20 0 67538M 1454M semwai 10 6:19 0.49% >>>> postgres >>>>>>>> 1999 pgsql 1 36 0 67538M 156M *vm ob 28 120:56 0.39% >>>> postgres >>>>>>>> 1851 pgsql 1 20 0 67538M 136M sbwait 22 5:48 0.39% >> postgres >>>>>>>> 1975 pgsql 1 20 0 67536M 5688K sbwait 25 1:40 0.29% >> postgres >>>>>>>> 1858 pgsql 1 20 0 67538M 417M sbwait 3 5:55 0.20% >> postgres >>>>>>>> 2031 pgsql 1 20 0 67536M 5664K sbwait 5 3:26 0.10% >> postgres >>>>>>>> 1834 root 12 20 0 71892K 12848K select 20 34:05 0.00% slon >>>>>>>> 12 root 78 -76 - 0K 1248K WAIT 0 25:47 0.00% intr >>>>>>>> 2041 pgsql 1 20 0 67536M 5932K sbwait 14 12:50 0.00% >>>> postgres >>>>>>>> 2039 pgsql 1 20 0 67536M 5960K sbwait 17 9:59 0.00% >> postgres >>>>>>>> 2038 pgsql 1 20 0 67536M 5956K sbwait 6 8:21 0.00% >> postgres >>>>>>>> 2040 pgsql 1 20 0 67536M 5996K sbwait 7 8:20 0.00% >> postgres >>>>>>>> 2032 pgsql 1 20 0 67536M 5800K sbwait 22 7:03 0.00% >> postgres >>>>>>>> 2036 pgsql 1 20 0 67536M 5748K sbwait 23 6:38 0.00% >> postgres >>>>>>>> 1812 pgsql 1 20 0 67538M 59185M select 1 5:46 0.00% >> postgres >>>>>>>> 2005 pgsql 1 20 0 67536M 5788K sbwait 23 5:14 0.00% >> postgres >>>>>>>> 2035 pgsql 1 20 0 67536M 4892K sbwait 18 4:52 0.00% >>>> >>>>>>>> 1852 pgsql 1 21 0 67536M 1230M semwai 7 4:47 0.00% >>>> postgres >>>>>>>> 13 root 3 -8 - 0K 48K - 28 4:46 0.00% geom >>>>>>>> >>>>>>>> >>>>>>> Another thing I've noticed is that this sysctl vm.stats counter is >>>> increasing >>>>>> fairly rapidly: >>>>>>> # sysctl vm.stats.vm.v_pdpages && sleep 1 && sysctl >>>>>> vm.stats.vm.v_pdpages >>>>>>> vm.stats.vm.v_pdpages: 3455264541 >>>>>>> vm.stats.vm.v_pdpages: 3662158383 >>>>>> I'm not sure what that tells us, because both the page daemon and the >>>> vm >>>>>> ("swap") daemon increment this counter. >>>>>> >>>>>>> Also, to demonstrate what kind of problems this seems to cause: >>>>>>> # time sleep 1 >>>>>>> >>>>>>> real 0m18.288s >>>>>>> user 0m0.001s >>>>>>> sys 0m0.004s >>>>>> If you change the sysctl vm.swap_enabled to 0, how does your system >>>>>> behave? >>>>>> >>>>> Setting vm.swap_enabled to 0 made the problem clear up almost >>>> instantly. vmdaemon is back to 0.00% CPU usage and the system is >>>> responsive once again. >>>> I doubt that you need whole process swapping. The page daemon is >>>> probably sufficient. See how things go for a few days and let me know. >>>> >>>> There is still a bug here that needs diagnosing and fixing. So, I will >>>> likely send you a debugging patch in the near future, and ask you to >>>> reenable swapping under that patch. >>>> >>> If it helps at all - setting vm.swap_enabled=0 seems to fix the problem >> even without the aforementioned patch to vm_pageout.c. >> >> I have a couple hypotheses for what is causing your problem. The >> attached patch addresses one of them. Please apply this patch and then >> reset vm._swap_enabled back to 1. >> > This seems to have solved the problem. We have been running for ~16 hours where "Free" memory has been under 2GB on one of these sytems under postgres/slony load and vmdaemon shows 0:00.00 CPU time used. Vm.swap_enabled is set to the default (1). > Good. I will get this change into 10.1. That said, your experience still points to another unresolved problem. We wakeup the vmdaemon at most once per second. On your machine, lock contention appears to be slowing the vmdaemon's progress enough that it doesn't complete a pass before we might wake it up again. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 18:40:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7528B85F for ; Tue, 26 Aug 2014 18:40:19 +0000 (UTC) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE174387F for ; Tue, 26 Aug 2014 18:40:18 +0000 (UTC) Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 194dcf35.0.1364445.00-2364.3816878.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 26 Aug 2014 18:40:18 +0000 (UTC) X-MXL-Hash: 53fcd4925171b78e-841ee1aad677bb69e38013fe3c8935acf660b46e Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id s7QIeHph031496 for ; Tue, 26 Aug 2014 13:40:17 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id s7QIeE2j031483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Aug 2014 13:40:15 -0500 Received: from MOSTLS1MSGHUBAF.ITServices.sbc.com (MOSTLS1MSGHUBAF.itservices.sbc.com [135.41.4.153]) by dalint01.pst.cso.att.com (RSA Interceptor) for ; Tue, 26 Aug 2014 18:40:00 GMT Received: from MOSTLS1MSGUSRFH.ITServices.sbc.com ([169.254.8.110]) by MOSTLS1MSGHUBAF.ITServices.sbc.com ([135.41.4.153]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 13:40:00 -0500 From: "RANDOLPH, DONALD L" To: "freebsd-stable@freebsd.org" Subject: Dell PowerEdge R920 w/ Perc H730P Thread-Topic: Dell PowerEdge R920 w/ Perc H730P Thread-Index: Ac/BXSoZsQMlzFY4RA+G3JzbQbBx0w== Date: Tue, 26 Aug 2014 18:39:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.201.115.88] MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=J84dGnbS c=1 sm=1 a=srMsL6ituuWTYeky9Bs9mA==:17 a] X-AnalysisOut: [=laSaauTa8Z0A:10 a=T1A6nYNprZYA:10 a=ofMgfj31e3cA:10 a=1bW] X-AnalysisOut: [CgR6wC0cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=B4er6YvJN3eeHsnn_dUA:9 a=CjuIK1q_8ugA:10 a=Mu-XDr] X-AnalysisOut: [byHHYA:10 a=sYqtUjLH-2EA:10 a=uT4Dey3Rg70A:10 a=yMhMjlubAA] X-AnalysisOut: [AA:8 a=SSmOFEACAAAA:8 a=jpEIZJRALnje2cuLMUQA:9 a=gKO2Hq4RS] X-AnalysisOut: [VkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:] X-AnalysisOut: [10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:40:19 -0000 I'm having an issue install FreeBSD 10.0 on a Dell PowerEdge w/ the Perc H7= 30P raid controller. I see there has been support added for the controller in the stable version= using the mrsas driver. But when I boot up in the installer... it is still trying to use the older = mfi driver. How do I get the installer to properly recognize the raid controller? Are there any logs I can provide to help solve this issue? Thanks Don From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 18:47:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C1DAE7F; Tue, 26 Aug 2014 18:47:03 +0000 (UTC) Date: Tue, 26 Aug 2014 14:46:59 -0400 From: Glen Barber To: "RANDOLPH, DONALD L" Subject: Re: Dell PowerEdge R920 w/ Perc H730P Message-ID: <20140826184659.GB3131@hub.FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:47:04 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 06:39:59PM +0000, RANDOLPH, DONALD L wrote: > I'm having an issue install FreeBSD 10.0 on a Dell PowerEdge w/ the Perc = H730P raid controller. > I see there has been support added for the controller in the stable versi= on using the mrsas driver. > But when I boot up in the installer... it is still trying to use the olde= r mfi driver. > How do I get the installer to properly recognize the raid controller? > Are there any logs I can provide to help solve this issue? >=20 At the loader(8) prompt, try: set hw.mfi.mrsas_enable=3D1 boot There is an overlap between some mfi(4) drivers and the mrsas(4) driver, and the mfi(4) probe happens first. Glen --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT/NYjAAoJELls3eqvi17Q3E8P/A1LlvTQWrHpYlcLl1XoBuW6 YPweZut5aGRm+DC0MGWxmjokxWEZ9HxjvMHk5EIOJbXAwMh25L5DMt6+69JPTnzr IEkvE+h/lS2CpSOmuCcqERl5YdJTkYvuF4M4hHV9GlY4G8npllvROGYQmv/1gYBR DsZa5130JIPEbwvBJxFhYJ/ZYaWMCl/y8l8iCQJRzAzJyRxMV59UxRtTu3b62y1a jvFdqU2M26mXIk9YZPbVwW491BAxyqnquDCQLB+AfRCVoJpdiYxR8RKQ+bpAMr3L 1KBROgHFxU0BxynW/vV2b5d03MxDvekukRHQ9S2RYljL1Q22p9LsaU/+e4jgQxKT JuToaCBtUF4vsjZlUjY9J37NQCtHAUY/pZZNEvbMMPq2F7g//FcTjWH89GUb5jts ew17uta2p8ZO6u0YIdKaBm0YHYfAybbQM+U5cba4Q+Dwdm89HHSs5cpjQ6ZiuSIb gkdv0jWTCQVCL4kPxEmkmI2+s1XmtMU3IAruLEtGrbjZOKBTNu/TaKFcwcRQolUW CQ1XcgJme1sNEPCJZj8GEWdI4V2nLYmKu9lRx8DLOiq5U6bMBo683wE2XdBOWXgY q3RUh3NmYtxLIm2DvCfMWW6kJFtmHnGmCR0ekm1PMFPWv7RyEW1ys8N5TVmBFQVS lPNGVw/KiWkIwzG4OxsV =bC1x -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 19:02:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8755E95E; Tue, 26 Aug 2014 19:02:34 +0000 (UTC) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 131C23B6E; Tue, 26 Aug 2014 19:02:33 +0000 (UTC) Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 8c9dcf35.0.1380871.00-2378.3864215.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 26 Aug 2014 19:02:34 +0000 (UTC) X-MXL-Hash: 53fcd9ca5eb1c7ea-d51d471a1d11dbfa648fe90d877d08037f38c38f Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id s7QJ2Vwi023160; Tue, 26 Aug 2014 14:02:32 -0500 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id s7QJ2Pfr023000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 14:02:25 -0500 Received: from MOSTLS1MSGHUBAC.ITServices.sbc.com (MOSTLS1MSGHUBAC.itservices.sbc.com [135.41.4.150]) by dalint02.pst.cso.att.com (RSA Interceptor); Tue, 26 Aug 2014 19:02:10 GMT Received: from MOSTLS1MSGUSRFH.ITServices.sbc.com ([169.254.8.110]) by MOSTLS1MSGHUBAC.ITServices.sbc.com ([135.41.4.150]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 14:02:09 -0500 From: "RANDOLPH, DONALD L" To: Glen Barber Subject: RE: Dell PowerEdge R920 w/ Perc H730P Thread-Topic: Dell PowerEdge R920 w/ Perc H730P Thread-Index: Ac/BXSoZsQMlzFY4RA+G3JzbQbBx0wAKtymAAAn7nuA= Date: Tue, 26 Aug 2014 19:02:09 +0000 Message-ID: References: <20140826184659.GB3131@hub.FreeBSD.org> In-Reply-To: <20140826184659.GB3131@hub.FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.201.115.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=J84dGnbS c=1 sm=1 a=srMsL6ituuWTYeky9Bs9mA==:17 a] X-AnalysisOut: [=bJuSpRN2vOUA:10 a=rroYxYZkpRkA:10 a=ofMgfj31e3cA:10 a=1bW] X-AnalysisOut: [CgR6wC0cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=6I5d2MoRAAAA:8 a=ZMkylGKD1tU7Yq] X-AnalysisOut: [BtKWgA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:02:34 -0000 The install failed using the method below. While extracting the archives I= get an mfi command failed... then a series of mfi0: COMMAND 0xfffffe0001fc= f388 timeout after 76 seconds... and it keeps incrementing from there. Should the drive still show up as mfid0 during install? I was expecting to= see mrsasd0 or something of that sort. Thanks -----Original Message----- From: Glen Barber [mailto:gjb@freebsd.org]=20 Sent: Tuesday, August 26, 2014 1:47 PM To: RANDOLPH, DONALD L Cc: freebsd-stable@freebsd.org Subject: Re: Dell PowerEdge R920 w/ Perc H730P On Tue, Aug 26, 2014 at 06:39:59PM +0000, RANDOLPH, DONALD L wrote: > I'm having an issue install FreeBSD 10.0 on a Dell PowerEdge w/ the Perc = H730P raid controller. > I see there has been support added for the controller in the stable versi= on using the mrsas driver. > But when I boot up in the installer... it is still trying to use the olde= r mfi driver. > How do I get the installer to properly recognize the raid controller? > Are there any logs I can provide to help solve this issue? >=20 At the loader(8) prompt, try: set hw.mfi.mrsas_enable=3D1 boot There is an overlap between some mfi(4) drivers and the mrsas(4) driver, and the mfi(4) probe happens first. Glen From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 19:05:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7639B7C; Tue, 26 Aug 2014 19:05:30 +0000 (UTC) Date: Tue, 26 Aug 2014 15:05:27 -0400 From: Glen Barber To: "RANDOLPH, DONALD L" Subject: Re: Dell PowerEdge R920 w/ Perc H730P Message-ID: <20140826190527.GC3131@hub.FreeBSD.org> References: <20140826184659.GB3131@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:05:31 -0000 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 07:02:09PM +0000, RANDOLPH, DONALD L wrote: >> At the loader(8) prompt, try: >>=20 >> set hw.mfi.mrsas_enable=3D1 >> boot >>=20 >> There is an overlap between some mfi(4) drivers and the mrsas(4) driver, >> and the mfi(4) probe happens first. >>=20 >=20 > The install failed using the method below. While extracting the archives= I get an mfi command failed... then a series of mfi0: COMMAND 0xfffffe0001= fcf388 timeout after 76 seconds... and it keeps incrementing from there. >=20 > Should the drive still show up as mfid0 during install? I was expecting = to see mrsasd0 or something of that sort. >=20 Perhaps try unloading the mfi(4) driver, too. set hw.mfi.mrsas_enable=3D1 unload mfi load mrsas boot Glen --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT/Np3AAoJELls3eqvi17QfigP/3AgSaGn2DmH4ctp0UNmvgHR Q1lLOk3tqSzOSRzNLtsIrO6b2tIN0WwmqnsCehoLMQTBeFj1BGdhBZ4ze24uFCkG Lv2DV8Gep/7UypoY4Ny7uMDnk8xvrYD8yBANG6ldjEcINO0KPxzvxK/AYwqv4iXi dMTFFfTfKFBzzVDBvLPsBJBFcRxWhGsktd4xjsR4PV1G82JwavkrRjC2K6AQlXqs 0TWNoSRwWUOhOosVmIFoPg3R5UuhkImNjKkypto6M41dLxOWIw0NXm30Taf5zqkb wRrNPeDR9GH5IArCZVECGTnUb8LIy7WEY7kX/45DL5pHRzpzTPvPDnOkQWcWcJDA XE4KlzJ2vGI6muVwt5W+9ZtBhxnD2rTs4GsQ6GJkXXNZv8FQOcvwjlgUR8n/NIwm Z4z9AhT/qeoN5DjITl+TwT2l4IATWdDNAwTXlqd46VX3j9N/84t+nmy9fBxJK0jZ CdR42M3rmysq4DjSt2MbtVizt8LNaXala5olwkYQTlNzLyKimyVR/N+phpFb5M+D WAoi3+k3dabUa1cyTWl2fLR6TBJA6uK2FkaidYor+m/NWIQxccyQmh4uLASUqICs QgCEIOMw+5yiThiD4x2/BGVf4/3IsLUQWZOsnavBpfw2Pu0kUX/VaJrXSR38zw6H OqPLNvgOjCfJZR9Js2b/ =2mih -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 19:14:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0CD3198; Tue, 26 Aug 2014 19:14:25 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AE4A3DAA; Tue, 26 Aug 2014 19:14:25 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id z107so11861059qgd.9 for ; Tue, 26 Aug 2014 12:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wlE0NT8oUIbEZTRnAUL45ePwb+DRi1AuKI5F1Y5EvOg=; b=lGoKtE5GWeQsDcsvXiAuPzUVqcx0vGFi1Dv0Y98vtn1msNYC+9qXis5n3D7l2fsrhk o3Yk8zlbpKY/bIoIPdpAyjLF9Vy2Jj11VvMoOfm8o6L+9prtYDly4pIk1PIWEhGuil62 C6pWH0qSvZu/dvoLmPZCEpV5AczCGQ2+s1GR4B0q/Ta13/RP9w4EkIvvO1SQ6tKkANCN 7/sMY8EGeqV5EsFojQeRcUMK+Zl+zwm198fymhmN7BNFfs8QqiBfpuCRPx072CqLMBXl nIdW3SRlUWPTe6d0blBuveNpIBDJG9viDfW1vYx061pVwCC6JWK9lgpZxpiFoXlo3LXE dO2g== X-Received: by 10.140.105.138 with SMTP id c10mr19152572qgf.15.1409080464443; Tue, 26 Aug 2014 12:14:24 -0700 (PDT) Received: from charmander.home ([64.229.13.35]) by mx.google.com with ESMTPSA id b7sm11967574qan.37.2014.08.26.12.14.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 12:14:24 -0700 (PDT) Sender: Mark Johnston Date: Tue, 26 Aug 2014 15:13:21 -0400 From: Mark Johnston To: "RANDOLPH, DONALD L" Subject: Re: Dell PowerEdge R920 w/ Perc H730P Message-ID: <20140826191321.GA1526@charmander.home> References: <20140826184659.GB3131@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:14:25 -0000 On Tue, Aug 26, 2014 at 07:02:09PM +0000, RANDOLPH, DONALD L wrote: > The install failed using the method below. While extracting the archives I get an mfi command failed... then a series of mfi0: COMMAND 0xfffffe0001fcf388 timeout after 76 seconds... and it keeps incrementing from there. It looks like the mrsas_enable tunable was never merged to stable/10. :( I can merge it in a bit (together with 267451) if no one has objections. > > Should the drive still show up as mfid0 during install? I was expecting to see mrsasd0 or something of that sort. With mrsas(4) the volumes will show up as daN. > > Thanks > > -----Original Message----- > From: Glen Barber [mailto:gjb@freebsd.org] > Sent: Tuesday, August 26, 2014 1:47 PM > To: RANDOLPH, DONALD L > Cc: freebsd-stable@freebsd.org > Subject: Re: Dell PowerEdge R920 w/ Perc H730P > > On Tue, Aug 26, 2014 at 06:39:59PM +0000, RANDOLPH, DONALD L wrote: > > I'm having an issue install FreeBSD 10.0 on a Dell PowerEdge w/ the Perc H730P raid controller. > > I see there has been support added for the controller in the stable version using the mrsas driver. > > But when I boot up in the installer... it is still trying to use the older mfi driver. > > How do I get the installer to properly recognize the raid controller? > > Are there any logs I can provide to help solve this issue? > > > > At the loader(8) prompt, try: > > set hw.mfi.mrsas_enable=1 > boot > > There is an overlap between some mfi(4) drivers and the mrsas(4) driver, > and the mfi(4) probe happens first. > > Glen > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 19:17:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D336658E; Tue, 26 Aug 2014 19:17:58 +0000 (UTC) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D6B93E3C; Tue, 26 Aug 2014 19:17:58 +0000 (UTC) Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 46ddcf35.0.1392846.00-2345.3898828.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 26 Aug 2014 19:17:58 +0000 (UTC) X-MXL-Hash: 53fcdd6642c9eeee-e9422ccc66b977d43ef50cbacff4d143c76dcd97 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id s7QJHtNZ009491; Tue, 26 Aug 2014 14:17:56 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id s7QJHnr3009232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 14:17:51 -0500 Received: from MOSTLS1MSGHUBAC.ITServices.sbc.com (MOSTLS1MSGHUBAC.itservices.sbc.com [135.41.4.150]) by dalint01.pst.cso.att.com (RSA Interceptor); Tue, 26 Aug 2014 19:17:32 GMT Received: from MOSTLS1MSGUSRFH.ITServices.sbc.com ([169.254.8.110]) by MOSTLS1MSGHUBAC.ITServices.sbc.com ([135.41.4.150]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 14:17:31 -0500 From: "RANDOLPH, DONALD L" To: Glen Barber Subject: RE: Dell PowerEdge R920 w/ Perc H730P Thread-Topic: Dell PowerEdge R920 w/ Perc H730P Thread-Index: Ac/BXSoZsQMlzFY4RA+G3JzbQbBx0wAKtymAAAn7nuD//7VLgIAAUOmA Date: Tue, 26 Aug 2014 19:17:30 +0000 Message-ID: References: <20140826184659.GB3131@hub.FreeBSD.org> <20140826190527.GC3131@hub.FreeBSD.org> In-Reply-To: <20140826190527.GC3131@hub.FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.201.115.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=J84dGnbS c=1 sm=1 a=srMsL6ituuWTYeky9Bs9mA==:17 a] X-AnalysisOut: [=bJuSpRN2vOUA:10 a=rroYxYZkpRkA:10 a=ofMgfj31e3cA:10 a=1bW] X-AnalysisOut: [CgR6wC0cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=n0J_wyUc-k66AOLDNq8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:17:58 -0000 Ok when I try this... after I enter load mrsas it tells me 'can't find mrsa= s'. =20 So is the driver not included in the installer kernel? On Tue, Aug 26, 2014 at 07:02:09PM +0000, RANDOLPH, DONALD L wrote: >> At the loader(8) prompt, try: >>=20 >> set hw.mfi.mrsas_enable=3D1 >> boot >>=20 >> There is an overlap between some mfi(4) drivers and the mrsas(4) driver, >> and the mfi(4) probe happens first. >>=20 >=20 > The install failed using the method below. While extracting the archives= I get an mfi command failed... then a series of mfi0: COMMAND 0xfffffe0001= fcf388 timeout after 76 seconds... and it keeps incrementing from there. >=20 > Should the drive still show up as mfid0 during install? I was expecting = to see mrsasd0 or something of that sort. >=20 Perhaps try unloading the mfi(4) driver, too. set hw.mfi.mrsas_enable=3D1 unload mfi load mrsas boot Glen From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 19:25:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D83087D7; Tue, 26 Aug 2014 19:25:13 +0000 (UTC) Date: Tue, 26 Aug 2014 15:25:10 -0400 From: Glen Barber To: Mark Johnston Subject: Re: Dell PowerEdge R920 w/ Perc H730P Message-ID: <20140826192510.GD3131@hub.FreeBSD.org> References: <20140826184659.GB3131@hub.FreeBSD.org> <20140826191321.GA1526@charmander.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kvUQC+jR9YzypDnK" Content-Disposition: inline In-Reply-To: <20140826191321.GA1526@charmander.home> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-stable@freebsd.org" , "RANDOLPH, DONALD L" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:25:14 -0000 --kvUQC+jR9YzypDnK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 03:13:21PM -0400, Mark Johnston wrote: > On Tue, Aug 26, 2014 at 07:02:09PM +0000, RANDOLPH, DONALD L wrote: > > The install failed using the method below. While extracting the archiv= es I get an mfi command failed... then a series of mfi0: COMMAND 0xfffffe00= 01fcf388 timeout after 76 seconds... and it keeps incrementing from there. >=20 > It looks like the mrsas_enable tunable was never merged to stable/10. :( > I can merge it in a bit (together with 267451) if no one has objections. >=20 Please go ahead. Glen --kvUQC+jR9YzypDnK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT/N8WAAoJELls3eqvi17QEm0P/1KSii6RgczOc1iv+0jXSXCr YT+QXWht+KDe57VINShFaXD1r8ixkKOxPk2j2XT7kYng6ymq0vgSGZFDsICQtl+8 ajg698QC4qvmkXqQ8FPUzvzXylHqB0QApMxTmR21BtDJTDY5g2tGC5zM+Gpq42Uj y1w8EBrZDMnMPCBxvZdlw9M31gOWG3+aLm/SP5Z2Ym1TUkvD3qgiFqiygq1pnxC9 IGap8o//J9/wGIN0rEjG36nTmERQtMigIroiCF1Oj9LTns+8T+EnorRGXuyWNVap 68hUxA92Hww5ya3dVW65E2BA5elDQqN6CnCLpJ++5ymB2iylmh/bzefUVJmD2q+I M22y7weLpXXL6gAF9vsaIwyyKIExBiYUNftq/p7woxaFF0apHha0tI3lJF6hCzz9 OVS0BlCOQMEi7xnr46jElwfThAEHX9KPJn7lRSr+LaVUdefDN+omUG+jTch/ZTWA 14l2Z4YB2jrwLWiDJNDxt7pRDJBQBm5Bkti+MIDSjY5fQZhvzIuKLtKlg3qARoZ6 0mjGohFwhfpBZMULHAkhTm7n1hiWO1CccAJMfNbLbJH09Qlc/zkPGMKAseIUVcKM I4JedZKFDBe7BdutgsA9o5rUtm8uW6w2+mnmJokjUmaPF/48A4bMe9xrWRy+LB4H ti5KteVZYup0IudDXQiU =7Rur -----END PGP SIGNATURE----- --kvUQC+jR9YzypDnK-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 20:01:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F28344AE for ; Tue, 26 Aug 2014 20:01:48 +0000 (UTC) Received: from asmtp01.netarrest.com (asmtp01.netarrest.com [67.228.24.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE33C36CE for ; Tue, 26 Aug 2014 20:01:48 +0000 (UTC) Received: from HPTouch (p5B07696D.dip0.t-ipconnect.de [91.7.105.109]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp01.netarrest.com (Postfix) with ESMTPSA id 75B68990012 for ; Tue, 26 Aug 2014 15:01:46 -0500 (CDT) Reply-To: promotion@sunrise.ch Message-ID: <7929395f96863a57f75fa5420011cb05@sunrise.ch> From: "SoundCloud" To: Subject: New message from SoundCloud PR Date: Tue, 26 Aug 2014 22:01:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:01:49 -0000 [letter.png] Hey, [1]SoundCloudPR sent you a message: The SoundCloud Promotional Service offers Artists, DJ's, Singers and Managers a simple, cost-effective way to reach targeted followers, sales, comments, plays and downloads on SoundCloud. We target like-minded users who are interested in your new tracks, releases and sets. Artists that generate a lot of honest consistent feedbacks and traffic to their profiles are the ones who stand out from the crowd. To check this new service, go directly to the [2]SoundCloud Promotion Page [1eCW8gV] [3]SoundCloudPR [4]Promote your account [5]Unsubscribe References Visible links 1. http://bit.ly/scpromo 2. http://bit.ly/scpromo 3. http://bit.ly/scpromo 4. http://bit.ly/scpromo 5. mailto:soundcloudnow@outlook.com?subject=NOMORE Hidden links: 7. http://bit.ly/scpromo From owner-freebsd-stable@FreeBSD.ORG Tue Aug 26 20:38:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA0A2580 for ; Tue, 26 Aug 2014 20:38:50 +0000 (UTC) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5944A3A9E for ; Tue, 26 Aug 2014 20:38:49 +0000 (UTC) Received: from godricw.thegrapevine.local ([118.208.163.118]) by p3plsmtpa11-02.prod.phx3.secureserver.net with id jYee1o0042Zb20N01YefPi; Tue, 26 Aug 2014 13:38:40 -0700 Message-ID: <53FCF04C.9090703@techtangents.com> Date: Wed, 27 Aug 2014 06:38:36 +1000 From: "dylan@techtangents.com" User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: RE: 10.0 interaction with vmware References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:38:50 -0000 Hi Paul, > We don't install open-vm-tools at the moment, therefore we have a known amount of memory to work with... That's not correct. I'd suggest reading up on vsphere's memory management. This article goes into it in depth, there's others around. http://www.vmware.com/files/pdf/mem_mgmt_perf_vsphere5.pdf I think you want to set a memory "reservation" for this vm in vmware. "Reservation is a guaranteed lower bound on the amount of host physical memory the host reserves for a virtual machine even when host memory is overcommitted." The vmware tools provide drivers for the paravirtualised devices. They also provide the ability to 'balloon' memory - see the above article. Basically, ballooning is a memory reduction technique which reduces host memory usage by inducing artificial memory pressure in the VM, encouraging the VM's kernel to swap out things it doesn't need. VMware tools or not, if the host is under memory pressure, it will attempt to reduce memory usage using several techniques. Transparent page sharing, memory compression and swapping don't require vmware tools - it's just the ballooning that does. In any case, memory reservation or "shares" for the VM should help - if the memory is reserved for the vm, the hypervisor won't try and reclaim memory from the vm. I think having tools installed should be a good thing. Kind regards, Dylan > freebsd-stable-request@freebsd.org > > 26 August 2014 10:00 pm > Send freebsd-stable mailing list submissions to > freebsd-stable@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > or, via email, send a message with subject or body 'help' to > freebsd-stable-request@freebsd.org > > You can reach the person managing the list at > freebsd-stable-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-stable digest..." > > > Today's Topics: > > 1. 10.0 interaction with vmware (Paul Koch) > 2. drm error in dmesg since using newcons (Jamie Griffin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 26 Aug 2014 17:16:57 +1000 > From: Paul Koch > To: > Subject: 10.0 interaction with vmware > Message-ID: <20140826171657.0c79c54d@akips.com> > Content-Type: text/plain; charset=US-ASCII > > > Curious if anyone has an understanding of what actually goes on > with VMWare memory control of a FreeBSD 10 guest when open-vm-tools > is installed and how it could affect performance. > > Our typical customer environment is a largish VMWare server with > an appropriate amount of RAM allocated to the guest, which currently > runs FreeBSD 10.0p7 + our software, UFS root, and data stored on a > ZFS partition. Our software mmaps large database files, does rather > largish data collection (ping, snmp, netflow, syslog, etc) and > mostly cruises along, but performance drops off a cliff in low > memory situations. > > We don't install open-vm-tools at the moment, therefore we have a known > amount of memory to work with (ie. what the customer initially > configured the guest for), but our customers (or in particular, their > VM guys) would really like vmware tools or open-vm-tools by default. > > >From what we gather, many sites choose to "over provision" the memory > in the VM setups, and when memory gets low, the host takes back > some of the RAM allocated to the guest. > > How does this work actually work ? Does it only take back what > FreeBSD considers to be "free" memory or can the host start taking > back "inactive", "wired", "zfs arc" memory ? We tend to rely on > stuff being in inactive and zfs arc. If we start swapping, we > are dead. > > Also, is there much of a performance hit if the host steals back > free memory, and then gives it back ? We'd assume all memory > the host gives to the guest is pre-bzero'ed so the FreeBSD wouldn't > need to also bzero it. > > Paul. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 27 15:28:00 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 470E4C18 for ; Wed, 27 Aug 2014 15:28:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1026230F2 for ; Wed, 27 Aug 2014 15:28:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7RFRxs8086134 for ; Wed, 27 Aug 2014 15:27:59 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7RFRxaY086128 for stable@FreeBSD.org; Wed, 27 Aug 2014 15:27:59 GMT (envelope-from bdrewery) Received: (qmail 62955 invoked from network); 27 Aug 2014 10:27:58 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 27 Aug 2014 10:27:58 -0500 Message-ID: <53FDF8F8.1070501@FreeBSD.org> Date: Wed, 27 Aug 2014 10:27:52 -0500 From: Bryan Drewery Reply-To: Ports FreeBSD Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: pkg@FreeBSD.org, ports@FreeBSD.org Subject: Pkg 1.3.7 out. Special handling recommended to avoid reinstalls. References: <53F4CC79.5000607@FreeBSD.org> <53F6188D.7090505@FreeBSD.org> In-Reply-To: <53F6188D.7090505@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB" X-Mailman-Approved-At: Wed, 27 Aug 2014 16:31:53 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 15:28:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pkg 1.3.7 is now released. The port is updated. pkg.FreeBSD.org packages are now published with fixed shared libraries. It was found that 'pkg update -f' may be required as well. Here are the updated instructions: - Binary package users should run 'pkg update -f' and 'pkg check -Ba' after upgrading to pkg-1.3.7 and before updating any other packages. This avoids needing to reinstall anything not needed due to changed shared libraries. For binary package users: # pkg install ports-mgmt/pkg # pkg update -f # pkg check -Ba # pkg upgrade For port users: # portsnap fetch update # make -C /usr/ports/ports-mgmt/pkg build deinstall install clean # pkg check -Ba - People building packages for serving to other systems need to rebuild all packages with 1.3.7. The previous announcement explaining this in more detail is at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-August/000= 086.html --=20 Regards, Bryan Drewery --KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT/fj4AAoJEDXXcbtuRpfPFh8H/2LFypX/Q28Hsli0979ETTyL Rkq0qE8YCrqiL4hjB58oXARcJ8hTSFtSfa8anJwh1qnjYFLaR6Aoo8bqnxp/IQ4t rxAhtblFo9Z8FbY1axy152XIwV29NKokBl3uapQUXkfpxIKtxE5s7Qm2nsALJfFx s4TN7+6oZlPanbbkBJH5UCjDVpIbO7bGqjJ7P0pa0l6eiwvrji6g1Va65U2WBSHW CBsjVAoIms/BnBu2+ZgVqNZDL7ube58MwLE9wKiXM9A1cWxqpYAZ7KC/Xe/pnFRG wuD1VSXCExtYXQpnxt5E9eRdE3AHxviwmG8OorJbGX9oJdZQPwJQ3yix526x/OU= =W2U7 -----END PGP SIGNATURE----- --KOqqM1JrRieVlRvFfl3xxSXLoSU38kOHB-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 01:45:55 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EB60A69 for ; Thu, 28 Aug 2014 01:45:55 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB99635FC for ; Thu, 28 Aug 2014 01:45:54 +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 s7S1jlrA067448 for ; Wed, 27 Aug 2014 18:45:51 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408280145.s7S1jlrA067448@gw.catspoiler.org> Date: Wed, 27 Aug 2014 18:45:47 -0700 (PDT) From: Don Lewis Subject: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: stable@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 01:45:55 -0000 I'm trying to create an 8.4-STABLE i386 poudriere jail on a host that is running 10.0-STABLE amd64. I'm running the following commmand: poudriere jail -c -j 84STABLEi386 -m svn -v stable/8 -a i386 -p default Unfortuantely, I'm getting stuck at this point: ===> gnu/usr.bin/gperf/doc (obj) /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc created for /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc rm -f .depend mkdep -f .depend -a -I/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/include -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /var/poudriere/jails/84STABLEi386/usr/src/! gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc echo gperf: /usr/lib/libc.a /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend echo gperf: /usr/lib/libstdc++.a >> .depend ===> gnu/usr.bin/gperf/doc (depend) make: don't know how to make /usr/lib/libstdc++.a. Stop *** Error code 2 1 error *** Error code 2 1 error *** [buildworld] Error code 2 1 error ====>> Error: Failed to 'make buildworld' ====>> Error while creating jail, cleaning up. ====>> Removing 84STABLEi386 jail... done There's no /usr/lib/libstdc++.a on this machine because libstdc++ has been removed from /usr/src on FreeBSD 10. If I set WITH_GCC=yes in /etc/src.conf, I get /usr/bin/gcc, but no g++ or libstdc++. And why are gperf and groff bootstrap tools anyway??? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 11:15:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C9DAC42 for ; Thu, 28 Aug 2014 11:15:48 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E185E1440 for ; Thu, 28 Aug 2014 11:15:47 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s7SBFdOU003502 for ; Thu, 28 Aug 2014 07:15:44 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53FF0F5B.6050300@m5p.com> Date: Thu, 28 Aug 2014 07:15:39 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD Stable Mailing List Subject: OpenOffice 4 on 10-STABLE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 28 Aug 2014 07:15:44 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 11:15:48 -0000 Is anyone able to get an editors/openoffice-5 compile to complete? Of late, something name unopkg.bin keeps getting a seg fault during the build process (but doesn't leave a core file). If I run it with no arguments under the base system gdb (after setting LD_LIBRARY_PATH to /usr/ports/editors/openoffice-4/work/aoo-4.1.0/main/solver/410/unxfbsdx.pro/lib) it crashes in getCascadeMapping in main/cppu/source/uno/cascade_mapping.cxx but according to gdb from ports, it crashes in _GLOBAL__sub_I_cascade_mapping.cxx(void). 10.0-STABLE FreeBSD 10.0-STABLE #0 r270324M (the M is because I use SCHED_4BSD instead of SCHED_ULE). -- George From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 11:19:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9288CEFA for ; Thu, 28 Aug 2014 11:19:01 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3AFF014A6 for ; Thu, 28 Aug 2014 11:19:01 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s7SBItAk003534 for ; Thu, 28 Aug 2014 07:19:00 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53FF101F.5050504@m5p.com> Date: Thu, 28 Aug 2014 07:18:55 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: OpenOffice 4 on 10-STABLE References: <53FF0F5B.6050300@m5p.com> In-Reply-To: <53FF0F5B.6050300@m5p.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 28 Aug 2014 07:19:00 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 11:19:01 -0000 On 08/28/14 07:15, George Mitchell wrote: > [...] editors/openoffice-5 [...] I meant openoffice-4. There's something wrong with my keyboard. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 12:27:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 844D34EE for ; Thu, 28 Aug 2014 12:27:18 +0000 (UTC) Received: from smtp.pobox.com (smtp.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4FEBA1D20 for ; Thu, 28 Aug 2014 12:27:17 +0000 (UTC) Received: from smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 7227432DC1 for ; Thu, 28 Aug 2014 08:23:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=tQasU05utFqhrZ2ZTg8c100ScI8=; b=QMcLtVa T1OUreXV8EdsZBfn5YYPejOylWQEOPblB1iLmE7ZRQPFwmQ9OV51oAoRo8G5e7GV S5w0Dy5n5m6LIPGWkoTEe7qO/9eXTflYU6jF/UCOMK5zJujS1M0WI22VFLKLxi6T AvswQV7DlvfcOrS0xHr+jOTHPhgcQzAilN8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=pTswamwIiP92IWADcvZyn9bz3d+k38zKJ TbdAzpM5pScN3qXIOMRfpKj0cNSdL6tTwpEtH+njyemI3622FLiC0jBdzfFlGNyg KDEM/DVmHi10Y2rSUKDMY/MaVU9m6aObkX3eD3fFHeRP+5GMTN6sFrG341XhWEhW B4PpgRwzWE= Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 2A7FC32DC0 for ; Thu, 28 Aug 2014 08:23:14 -0400 (EDT) Received: from localhost (unknown [50.90.2.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id EA6D132DBB for ; Thu, 28 Aug 2014 08:23:05 -0400 (EDT) Date: Thu, 28 Aug 2014 08:23:05 -0400 From: Chris Nehren To: freebsd-stable@freebsd.org Subject: Re: OpenOffice 4 on 10-STABLE Message-ID: <20140828122305.GB25916@satori.lan> Mail-Followup-To: freebsd-stable@freebsd.org References: <53FF0F5B.6050300@m5p.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mSxgbZZZvrAyzONB" Content-Disposition: inline In-Reply-To: <53FF0F5B.6050300@m5p.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 103EF058-2EAE-11E4-AC1C-9903E9FBB39C-49531120!pb-smtp0.pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:27:18 -0000 --mSxgbZZZvrAyzONB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 28, 2014 at 07:15:39 -0400, George Mitchell wrote: > Is anyone able to get an editors/openoffice-5 compile to complete? Of > late, something name unopkg.bin keeps getting a seg fault during the > build process (but doesn't leave a core file). If I run it with no > arguments under the base system gdb (after setting LD_LIBRARY_PATH to > /usr/ports/editors/openoffice-4/work/aoo-4.1.0/main/solver/410/unxfbsdx.p= ro/lib) > it crashes in getCascadeMapping in main/cppu/source/uno/cascade_mapping.c= xx > but according to gdb from ports, it crashes in > _GLOBAL__sub_I_cascade_mapping.cxx(void). Any specific reason you're sticking with openoffice instead of libreoffice? The latter is receiving far more developer attention and is making greater strides in features. --=20 Chris Nehren --mSxgbZZZvrAyzONB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJbBAABAgBFBQJT/x8pPhSAAAAAABUAIHBrYS1hZGRyZXNzQGdudXBnLm9yZ2Nu ZWhyZW4rZnJlZWJzZC1zdGFibGVAcG9ib3guY29tAAoJEBHA+GJAM0vP9ZkQAJVE A1KnA++t/mSMUR84lPY6ac/NAPw4Y7xdqe2UISwfIpHrWVNlo2l+kMQxM/0vAuiH sQtJxvRYuDJ4didEg1BQlb1iDmE+fRdVzY9vjCg6ovH54KOQ0F5PX1POTbGifVpM dzSrwXXMnSRZ2R8Z1Ug6iPempyekPZB5yTd7Gur2tEX4H7W7u5AgRfNUT2trZov4 TIWwPE0fXeUICX+HDqk6KWsrtIu/m6zFyNj/GIVE9Ecw6DHlsi4f2pP/zGEDf5Wg O9tICJP2II3kfYkyBw8R3Y0273MYpnSU6lzz8KpEl+pTHDa50f934Dpw2xonPz4g BIRCpQ3tIkAP2R3iT0xrsWCIP8Ufjrh7m+m7C/0fv+beOUSY+WUWXsZVU1yaQwTx SyR3S0tEJYSUBOURWIoXP+EHBIaElsCjuh6nOPqEDDBi/nLI47YI8979ANc8QCJ+ X4IVV16TBJIaM7MRCeNhy5jRhOsDEA1cU9DBQ3oDLU3ThI5MJ6aI/HTIMA6LuZ0A J5Cb+HAHkmPxz0to2g1Kozlw9hpAnJKmRGueJrSy40RJqk5UFHLe6Z4bmZr8w/0R IreTzypRALIN+mXDGkpGygkqNC9nijfsGkzObvr3hPjfjfhxrD4Ooadg0idgeoRf JPX8iTpnX3O7Or45cxJZojZlxb0GH5xpVclgiwbx =5ibC -----END PGP SIGNATURE----- --mSxgbZZZvrAyzONB-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 15:03:18 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 477D5B35 for ; Thu, 28 Aug 2014 15:03:18 +0000 (UTC) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by mx1.freebsd.org (Postfix) with ESMTP id EE67F1210 for ; Thu, 28 Aug 2014 15:03:17 +0000 (UTC) Received: from [98.139.215.143] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2014 15:03:11 -0000 Received: from [98.139.212.231] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2014 15:03:11 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 28 Aug 2014 15:03:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 529242.39358.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 60223 invoked by uid 60001); 28 Aug 2014 15:03:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1409238190; bh=unw/QCbPh615nuJ/9s2cSvKE4+tSfvWLc+wpFqWDaFQ=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=F0cO93ifyXBrtKa8ywRyH0ga/TRGn+PKdddZMxzH1bejDiP171GN0C+LTL4WvMxwIZm5NMV8W3c6ojkhVZ2Q+4u7k1xgBL+PFeLwh4lPZ3FXxY3Y+NRdItNubHbcYh2ZDsdLx7TWCp4tz5da69D5O6TQrvJK7Cmrsm2g1JK22YI= X-YMail-OSG: .FmtNqwVM1mmmgffpa9sMJ4SmgX.ehyHSyzXaVW1SBia0b0 urTUXNt2zgjTUMwANxzXe3jufO_7mnjkvH8HM5OwSQS1RdMMiWUhQRHpVFZt uUWLfV2tDcB1aAaa_6eMdqm1eSiLsMW8qTjvI5tGciCl_bHy5kAA_uYKFoJ8 S8DxWGdKFNI_fX9AoCgGgbYuXbPDdF5Sg7DYqPsWUFQoK4_fyAfjSRTG5C.o Fkw.3cce8rodVRbpVmqJxrvF7oR_I4tCzC9cZkv.nhvthw5P6n5AB_D4THhY xU3kPzf3V2feEvsaK.RHW9n1GhRKwrOoVfN2_qKlApj3nX_zhZ3aPfH8SaQS wKefoRgg1bSRJf2sjYux1IVwElarjcMrhOTx6ThMahDTg.8GRyv8dBHG2Gvs 0eMuH_l_.Y8h2IVzToL3Xxv52rjQ8TtByfrs7LRLMRZeySV6slUpAE1ExXMy Gsbln99NnsSSQ3bAY.F_Gl7RFfNwFgUL1VcGsm1XBAE4LRcF6eDe4j9OWlHr nlIdX79YU4TvVoad9pV2a0Dp83y4si2B_dx_9d_NTFgmFgYKvBAMjwd3SUdu qQ1K_dRH.BATTKJHDQpeLt0MuZZjDYlbw675W_IzAKxMEcrm.09e8o2AhF12 C4GerqB56vwXKVfkPR_kebyjAUNOLvk8ZTzCNA8Gi_EfIg6oxmPnQLhxwRNe lEI9DCFUD5RSRpcyDfpEV6vdaTkBzpjE- Received: from [87.11.56.176] by web140904.mail.bf1.yahoo.com via HTTP; Thu, 28 Aug 2014 08:03:10 PDT X-Rocket-MIMEInfo: 002.001, SSBoYXZlIHByb2JsZW0gd2l0aCB4b3JnIHdpdGggbXkgY3VzdG9tIGtlcm5lbCBib3RoIHdpdGggYW5kIHdpdGhvdXQgVlQgc3VwcG9ydHMuCkkgY2FuIHN0aWxsIHJlYm9vdCB3aXRoIGdlbmVyaWMgYW5kIGhhdmUgeG9yZyB3b3JrLk15IHN5c3RlbTpGcmVlQlNEIHN0aW5nIDEwLjAtU1RBQkxFIEZyZWVCU0QgMTAuMC1TVEFCTEUgIzAgcjI2OTc4OTogTW9uIEF1ZyAxMSAwMjo0NzowMiBVVEMgMjAxNMKgwqDCoMKgIHJvb3RAZ3JpbmQuZnJlZWJzZC5vcmc6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQwEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.203.696 Message-ID: <1409238190.56909.YahooMailNeo@web140904.mail.bf1.yahoo.com> Date: Thu, 28 Aug 2014 08:03:10 -0700 From: Filippo Moretti Reply-To: Filippo Moretti Subject: Problem with xorg To: "stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:03:18 -0000 I have problem with xorg with my custom kernel both with and without VT sup= ports.=0AI can still reboot with generic and have xorg work.My system:FreeB= SD sting 10.0-STABLE FreeBSD 10.0-STABLE #0 r269789: Mon Aug 11 02:47:02 UT= C 2014=A0=A0=A0=A0 root@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC=A0 i= 386=0AWith my kernel-vt I get a sementation fault,while with SC I got a com= plete crash=0A=0A=A0[=A0 3431.172] =0AX.Org X Server 1.12.4=0ARelease Date:= 2012-08-27=0A[=A0 3431.173] X Protocol Version 11, Revision 0=0A[=A0 3431.= 173] Build Operating System: FreeBSD 10.0-STABLE i386 =0A[=A0 3431.174] Cur= rent Operating System: FreeBSD sting 10.0-STABLE FreeBSD 10.0-STABLE #0 r27= 0390: Mon Aug 25 21:32:19 CEST 2014=A0=A0=A0=A0 root@sting:/usr/obj/usr/src= /sys/STING_VT i386=0A[=A0 3431.176] Build Date: 24 August 2014=A0 01:03:15P= M=0A[=A0 3431.176] =A0=0A[=A0 3431.177] Current version of pixman: 0.32.4= =0A[=A0 3431.177]=A0=A0=A0 Before reporting problems, check http://wiki.x.o= rg=0A=A0=A0=A0=A0=A0=A0=A0 to make sure that you have the latest version.= =0A[=A0 3431.178] Markers: (--) probed, (**) from config file, (=3D=3D) def= ault setting,=0A=A0=A0=A0=A0=A0=A0=A0 (++) from command line, (!!) notice, = (II) informational,=0A=A0=A0=A0=A0=A0=A0=A0 (WW) warning, (EE) error, (NI) = not implemented, (??) unknown.=0A[=A0 3431.180] (=3D=3D) Log file: "/var/lo= g/Xorg.0.log", Time: Thu Aug 28 16:13:31 2014=0A[=A0 3431.207] (=3D=3D) Usi= ng config file: "/etc/X11/xorg.conf"=0A[=A0 3431.226] (=3D=3D) ServerLayout= "X.org Configured"=0A[=A0 3431.226] (**) |-->Screen "Screen0" (0)=0A[=A0 3= 431.226] (**) |=A0=A0 |-->Monitor "Monitor0"=0A[=A0 3431.230] (**) |=A0=A0 = |-->Device "Card0"=0A[=A0 3431.230] (**) |=A0=A0 |-->Device "Card0"=0A[=A0 = 3431.230] (**) |-->Input Device "Mouse0"=0A[=A0 3431.230] (**) |-->Input De= vice "Keyboard0"=0A[=A0 3431.230] (=3D=3D) Automatically adding devices=0A[= =A0 3431.231] (=3D=3D) Automatically enabling devices=0A[=A0 3431.256] (WW)= The directory "/usr/local/lib/X11/fonts/local/sgi/" does not exist.=0A[=A0= 3431.257]=A0=A0=A0 Entry deleted from font path.=0A[=A0 3431.258] (WW) The= directory "/usr/local/lib/X11/fonts/Droid/" does not exist.=0A[=A0 3431.25= 8]=A0=A0=A0 Entry deleted from font path.=0A[=A0 3431.258] (WW) The directo= ry "/usr/local/lib/X11/fonts/URW/" does not exist.=0A[=A0 3431.258]=A0=A0= =A0 Entry deleted from font path.=0A[=A0 3431.261] (**) FontPath set to:=0A= =A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/misc/,=0A=A0=A0=A0=A0=A0=A0= =A0 /usr/local/lib/X11/fonts/TTF/,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X= 11/fonts/OTF,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/Type1/,=0A= =A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/100dpi/,=0A=A0=A0=A0=A0=A0= =A0=A0 /usr/local/lib/X11/fonts/75dpi/,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/= lib/X11/fonts/jmk-x11-fonts/,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fo= nts/dejavu/,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/urwfonts-ttf/= ,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/misc/,=0A=A0=A0=A0=A0=A0= =A0=A0 /usr/local/lib/X11/fonts/TTF/,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/li= b/X11/fonts/OTF/,=0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/Type1/,= =0A=A0=A0=A0=A0=A0=A0=A0 /usr/local/lib/X11/fonts/100dpi/,=0A=A0=A0=A0=A0= =A0=A0=A0 /usr/local/lib/X11/fonts/75dpi/=0A[=A0 3431.261] (**) ModulePath = set to "/usr/local/lib/xorg/modules"=0A[=A0 3431.261] (WW) Hotplugging is o= n, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.=0A[= =A0 3431.261] (WW) Disabling Mouse0=0A[=A0 3431.261] (WW) Disabling Keyboar= d0=0A[=A0 3431.261] (WW) Disabling Mouse0=0A[=A0 3431.261] (WW) Disabling K= eyboard0=0A[=A0 3431.261] (II) Loader magic: 0x81f1cf8=0A[=A0 3431.262] (II= ) Module ABI versions:=0A[=A0 3431.262]=A0=A0=A0 X.Org ANSI C Emulation: 0.= 4=0A[=A0 3431.262]=A0=A0=A0 X.Org Video Driver: 12.1=0A[=A0 3431.262]=A0=A0= =A0 X.Org XInput driver : 16.0=0A[=A0 3431.262]=A0=A0=A0 X.Org Server Exten= sion : 6.0=0A[=A0 3431.265] (--) PCI:*(0:1:0:0) 1002:5b60:1002:0302 rev 0, = Mem @ 0xc0000000/134217728, 0xd0000000/65536, I/O @ 0x0000a800/256, BIOS @ = 0x????????/65536=0A[=A0 3431.266] (--) PCI: (0:1:0:1) 1002:5b70:1002:0303 r= ev 0, Mem @ 0xdf9d0000/65536=0A[=A0 3431.267] (II) "extmod" will be loaded.= This was enabled by default and also specified in the config file.=0A[=A0 = 3431.267] (II) "dbe" will be loaded. This was enabled by default and also s= pecified in the config file.=0A[=A0 3431.267] (II) "glx" will be loaded. Th= is was enabled by default and also specified in the config file.=0A[=A0 343= 1.267] (II) "record" will be loaded. This was enabled by default and also = =0A=0A=A0[=A0 3431.267] (II) "dri" will be loaded by default.=0A[=A0 3431.2= 67] (II) "dri2" will be loaded. This was enabled by default and also specif= ied in the config file.=0A[=A0 3431.268] (II) LoadModule: "extmod"=0A[=A0 3= 431.271] (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so= =0A[=A0 3431.273] (II) Module extmod: vendor=3D"X.Org Foundation"=0A[=A0 34= 31.273]=A0=A0=A0 compiled for 1.12.4, module version =3D 1.0.0=0A[=A0 3431.= 273]=A0=A0=A0 Module class: X.Org Server Extension=0A[=A0 3431.273]=A0=A0= =A0 ABI class: X.Org Server Extension, version 6.0=0A[=A0 3431.273] (II) Lo= ading extension MIT-SCREEN-SAVER=0A[=A0 3431.274] (II) Loading extension XF= ree86-VidModeExtension=0A[=A0 3431.274] (II) Loading extension XFree86-DGA= =0A[=A0 3431.274] (II) Loading extension DPMS=0A[=A0 3431.274] (II) Loading= extension XVideo=0A[=A0 3431.274] (II) Loading extension XVideo-MotionComp= ensation=0A[=A0 3431.275] (II) Loading extension X-Resource=0A[=A0 3431.275= ] (II) LoadModule: "record"=0A[=A0 3431.277] (II) Loading /usr/local/lib/xo= rg/modules/extensions/librecord.so=0A[=A0 3431.278] (II) Module record: ven= dor=3D"X.Org Foundation"=0A[=A0 3431.279]=A0=A0=A0 compiled for 1.12.4, mod= ule version =3D 1.13.0=0A[=A0 3431.279]=A0=A0=A0 Module class: X.Org Server= Extension=0A[=A0 3431.279]=A0=A0=A0 ABI class: X.Org Server Extension, ver= sion 6.0=0A=0A=0A[=A0 3434.354] (**) USB Receiver: always reports core even= ts=0A[=A0 3434.354] (**) USB Receiver: always reports core events=0A[=A0 34= 34.354] (**) Option "Protocol" "standard"=0A[=A0 3434.354] (WW) Option "Dev= ice" requires an string value=0A[=A0 3434.354] (**) Option "XkbRules" "base= "=0A[=A0 3434.354] (**) Option "XkbModel" "pc105"=0A[=A0 3434.354] (**) Opt= ion "XkbLayout" "us"=0A[=A0 3434.354] (**) Option "config_info" "hal:/org/f= reedesktop/Hal/devices/usb_device_46d_c517_noserial_if0"=0A[=A0 3434.354] (= II) XINPUT: Adding extended input device "USB Receiver" (type: KEYBOARD, id= 7)=0A[=A0 3434.354] Segmentation fault at address 0x2a3da760=0A[=A0 3434.3= 54] =0AFatal server error:=0A[=A0 3434.354] Caught signal 11 (Segmentation = fault). Server aborting=0A[=A0 3434.354] =0A[=A0 3434.355] =0APlease consul= t the The X.Org Foundation support =0A=A0=A0=A0=A0=A0=A0=A0=A0 at http://wi= ki.x.org=0A=A0for help. =0A[=A0 3434.355] Please also check the log file at= "/var/log/Xorg.0.log" for additional information.=0A=0A=0Aand this refer t= o the crash:=0ADump header from device /dev/ada1p3=0A=A0 Architecture: i386= =0A=A0 Architecture Version: 2=0A=A0 Dump Length: 126341120B (120 MB)=0A=A0= Blocksize: 512=0A=A0 Dumptime: Thu Aug 28 17:32:05 2014=0A=A0 Hostname: st= ing=0A=A0 Magic: FreeBSD Kernel Dump=0A=A0 Version String: FreeBSD 10.0-STA= BLE #0 r270390: Thu Aug 28 16:50:15 CEST 2014=0A=A0=A0=A0 root@sting:/usr/o= bj/usr/src/sys/STING=0A=A0 Panic String: make_dev_credv: bad si_name (error= =3D17, si_name=3Ddri/card0)=0A=A0 Dump Parity: 1120275581=0A=A0 Bounds: 0= =0A=A0 Dump Status: good=0AAny help appreciated=0AFilippo From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 15:10:05 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BE21235; Thu, 28 Aug 2014 15:10:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EBA512DB; Thu, 28 Aug 2014 15:10:04 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XN1Ko-000Jwb-Cj; Thu, 28 Aug 2014 15:09:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s7SF9vts001235; Thu, 28 Aug 2014 09:09:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+n8x72ICaLU5sHhg4rB2R7 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host From: Ian Lepore To: Don Lewis In-Reply-To: <201408280145.s7S1jlrA067448@gw.catspoiler.org> References: <201408280145.s7S1jlrA067448@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Aug 2014 09:09:56 -0600 Message-ID: <1409238596.1150.134.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:10:05 -0000 On Wed, 2014-08-27 at 18:45 -0700, Don Lewis wrote: > I'm trying to create an 8.4-STABLE i386 poudriere jail on a host that is > running 10.0-STABLE amd64. I'm running the following commmand: > > poudriere jail -c -j 84STABLEi386 -m svn -v stable/8 -a i386 -p default > > Unfortuantely, I'm getting stuck at this point: > > ===> gnu/usr.bin/gperf/doc (obj) > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc created for /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc > rm -f .depend > mkdep -f .depend -a -I/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/include -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /var/poudriere/jails/84STABLEi386/usr/sr! c/! > gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc > echo gperf: /usr/lib/libc.a /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend > echo gperf: /usr/lib/libstdc++.a >> .depend > ===> gnu/usr.bin/gperf/doc (depend) > make: don't know how to make /usr/lib/libstdc++.a. Stop > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > ====>> Error: Failed to 'make buildworld' > ====>> Error while creating jail, cleaning up. > ====>> Removing 84STABLEi386 jail... done > > > There's no /usr/lib/libstdc++.a on this machine because libstdc++ has > been removed from /usr/src on FreeBSD 10. If I set WITH_GCC=yes in > /etc/src.conf, I get /usr/bin/gcc, but no g++ or libstdc++. And why are > gperf and groff bootstrap tools anyway??? > Try adding WITH_GNUCXX. -- Ian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 16:13:33 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8558A9F5 for ; Thu, 28 Aug 2014 16:13:33 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30D7D1C35 for ; Thu, 28 Aug 2014 16:13:33 +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 s7SGDNwp068879; Thu, 28 Aug 2014 09:13:27 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408281613.s7SGDNwp068879@gw.catspoiler.org> Date: Thu, 28 Aug 2014 09:13:23 -0700 (PDT) From: Don Lewis Subject: Re: OpenOffice 4 on 10-STABLE To: george+freebsd@m5p.com In-Reply-To: <53FF0F5B.6050300@m5p.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 16:13:33 -0000 On 28 Aug, George Mitchell wrote: > Is anyone able to get an editors/openoffice-5 compile to complete? Of > late, something name unopkg.bin keeps getting a seg fault during the > build process (but doesn't leave a core file). If I run it with no > arguments under the base system gdb (after setting LD_LIBRARY_PATH to > /usr/ports/editors/openoffice-4/work/aoo-4.1.0/main/solver/410/unxfbsdx.pro/lib) > it crashes in getCascadeMapping in main/cppu/source/uno/cascade_mapping.cxx > but according to gdb from ports, it crashes in > _GLOBAL__sub_I_cascade_mapping.cxx(void). Sounds like you are trying to build the r364119 version of the port. I tracked down the build problem in that version to both libc++ and libstdc++ getting linked in to the executables. Revision r366163 fixes the problem, but you should probably upgrade to r366281, which is OpenOffice 4.1.1. According to the release announcement, it has some critical bug fixes, including some security fixes. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 17:43:41 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DDFCD4; Thu, 28 Aug 2014 17:43:41 +0000 (UTC) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCCC7186B; Thu, 28 Aug 2014 17:43:40 +0000 (UTC) Received: from fwd23.aul.t-online.de (fwd23.aul.t-online.de [172.20.26.128]) by mailout12.t-online.de (Postfix) with SMTP id 725CC2CD907; Thu, 28 Aug 2014 19:43:32 +0200 (CEST) Received: from [192.168.119.33] (VUd4q8ZaZhnNG80j9vVmQlvpDhlZZJ+qYHoGQTnyubhmvJXu6qPG6aor49REY8ZgFe@[84.154.101.219]) by fwd23.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XN3jE-2B6Voe0; Thu, 28 Aug 2014 19:43:20 +0200 Message-ID: <53FF6A32.6020509@freebsd.org> Date: Thu, 28 Aug 2014 19:43:14 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Filippo Moretti , "stable@freebsd.org" Subject: Re: Problem with xorg References: <1409238190.56909.YahooMailNeo@web140904.mail.bf1.yahoo.com> In-Reply-To: <1409238190.56909.YahooMailNeo@web140904.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: VUd4q8ZaZhnNG80j9vVmQlvpDhlZZJ+qYHoGQTnyubhmvJXu6qPG6aor49REY8ZgFe X-TOI-MSGID: 9c221bb1-93ca-4909-ade2-50e0adce37f1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:43:41 -0000 Am 28.08.2014 um 17:03 schrieb Filippo Moretti via freebsd-stable: > I have problem with xorg with my custom kernel both with and without VT supports. > I can still reboot with generic and have xorg work.My system:FreeBSD sting 10.0-STABLE FreeBSD 10.0-STABLE #0 r269789: Mon Aug 11 02:47:02 UTC 2014 root@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 > With my kernel-vt I get a sementation fault,while with SC I got a complete crash [...] > [ 3434.354] (**) Option "Protocol" "standard" > [ 3434.354] (WW) Option "Device" requires an string value > [ 3434.354] (**) Option "XkbRules" "base" > [ 3434.354] (**) Option "XkbModel" "pc105" > [ 3434.354] (**) Option "XkbLayout" "us" > [ 3434.354] (**) Option "config_info" "hal:/org/freedesktop/Hal/devices/usb_device_46d_c517_noserial_if0" > [ 3434.354] (II) XINPUT: Adding extended input device "USB Receiver" (type: KEYBOARD, id 7) > [ 3434.354] Segmentation fault at address 0x2a3da760 > [ 3434.354] > Fatal server error: > [ 3434.354] Caught signal 11 (Segmentation fault). Server aborting > [ 3434.354] > [ 3434.355] > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [ 3434.355] Please also check the log file at "/var/log/Xorg.0.log" for additional information. Just a me-to, but on -CURRENT: [ 357.752] (**) Keyboard0: always reports core events [ 357.752] (**) Option "Protocol" "standard" [ 357.752] (**) Option "XkbRules" "xorg" [ 357.752] (**) Option "XkbModel" "pc105" [ 357.752] (**) Option "XkbLayout" "de" [ 357.752] (**) Option "XkbVariant" "nodeadkeys" [ 357.752] (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD, id 7) [ 357.752] Segmentation fault at address 0x80500ae80 [ 357.752] Fatal server error: [ 357.752] Caught signal 11 (Segmentation fault). Server aborting This did not happen, a few weeks ago, but I cannot identify the date or SVN revision of when this problem appeared. This is a very fresh -CURRENT on amd64 (i7/2600 internal GPU) with kernel and world in sync and X11 related ports rebuild because I thought that they had become inconsistent ... BTW: I did not test with syscons instead of vt. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 17:50:36 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F257251; Thu, 28 Aug 2014 17:50:36 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21B3218C9; Thu, 28 Aug 2014 17:50:36 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::8d95:d569:56a0:ccd4] (unknown [IPv6:2001:7b8:3a7:0:8d95:d569:56a0:ccd4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4F91FB803; Thu, 28 Aug 2014 19:50:32 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_80837FB0-77DB-4B7D-B32E-D01AB6B294E5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host From: Dimitry Andric In-Reply-To: <201408280145.s7S1jlrA067448@gw.catspoiler.org> Date: Thu, 28 Aug 2014 19:50:10 +0200 Message-Id: <4EFE0F86-BB71-4D2C-90F4-CFA7F594AD52@FreeBSD.org> References: <201408280145.s7S1jlrA067448@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.1878.6) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:50:36 -0000 --Apple-Mail=_80837FB0-77DB-4B7D-B32E-D01AB6B294E5 Content-Type: multipart/mixed; boundary="Apple-Mail=_AE2E4B31-B9C1-446E-8B23-AC7603870F5E" --Apple-Mail=_AE2E4B31-B9C1-446E-8B23-AC7603870F5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Aug 2014, at 03:45, Don Lewis wrote: > I'm trying to create an 8.4-STABLE i386 poudriere jail on a host that = is > running 10.0-STABLE amd64. I'm running the following commmand: >=20 > poudriere jail -c -j 84STABLEi386 -m svn -v stable/8 -a i386 -p = default >=20 > Unfortuantely, I'm getting stuck at this point: >=20 > =3D=3D=3D> gnu/usr.bin/gperf/doc (obj) > = /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/var/poudriere/j= ails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc created for = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc > rm -f .depend > mkdep -f .depend -a = -I/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/in= clude = -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../con= trib/gperf/lib = -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/bool-array.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/hash-table.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/input.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/keyword-list.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/keyword.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/main.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/options.cc /var/poudriere/jails/84STABLEi386/usr/src/! > gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/positions.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/search.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/src/version.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/lib/getline.cc = /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contr= ib/gperf/lib/hash.cc =20 > echo gperf: /usr/lib/libc.a = /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/lib/= libegacy.a >> .depend > echo gperf: /usr/lib/libstdc++.a >> .depend > =3D=3D=3D> gnu/usr.bin/gperf/doc (depend) > make: don't know how to make /usr/lib/libstdc++.a. Stop It would have been nice to MFC r257658 to stable/8, which fixes this. However, it depends on EARLY_BUILD being defined in Makefile.inc1 during the early build stages, and this support was not MFC'd to stable/8, because it is clang-related. If you often build older branches or releases on 10.x or 11.x, it is probably easiest to just build your system using WITH_GNUCXX, so libstdc++ gets built and installed. Alternatively, try the attached patch for stable/8, which uses the BOOTSTRAPPING variable to detect the early buildworld stages instead. > There's no /usr/lib/libstdc++.a on this machine because libstdc++ has > been removed from /usr/src on FreeBSD 10. If I set WITH_GCC=3Dyes in > /etc/src.conf, I get /usr/bin/gcc, but no g++ or libstdc++. You want to use WITH_GNUCXX instead. > And why are > gperf and groff bootstrap tools anyway??? gperf is used during the build of g++, groff is used to format manpages. -Dimitry --Apple-Mail=_AE2E4B31-B9C1-446E-8B23-AC7603870F5E Content-Disposition: attachment; filename=stable8-bootstrap-libstdcxx-1.diff Content-Type: application/octet-stream; name="stable8-bootstrap-libstdcxx-1.diff" Content-Transfer-Encoding: 7bit Index: share/mk/bsd.prog.mk =================================================================== --- share/mk/bsd.prog.mk (revision 270646) +++ share/mk/bsd.prog.mk (working copy) @@ -134,7 +134,7 @@ .endif .else echo ${PROG}: ${LIBC} ${DPADD} >> ${DEPENDFILE} -.if defined(PROG_CXX) +.if defined(PROG_CXX) && !defined(BOOTSTRAPPING) echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE} .endif .endif --Apple-Mail=_AE2E4B31-B9C1-446E-8B23-AC7603870F5E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_AE2E4B31-B9C1-446E-8B23-AC7603870F5E-- --Apple-Mail=_80837FB0-77DB-4B7D-B32E-D01AB6B294E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlP/a+UACgkQsF6jCi4glqMT5ACguwAKgYrjf/JWn0HxIXEcu12j PkgAn3NN/4KUX5BP/hjj+1z13kARwq8j =ejUu -----END PGP SIGNATURE----- --Apple-Mail=_80837FB0-77DB-4B7D-B32E-D01AB6B294E5-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 18:38:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0E8A550; Thu, 28 Aug 2014 18:38:19 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 261731E2A; Thu, 28 Aug 2014 18:38:19 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s7SIcFI2078602; Thu, 28 Aug 2014 14:38:15 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <53FF7722.2010309@sentex.net> Date: Thu, 28 Aug 2014 14:38:26 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: controller errors from RELENG_9 to RELENG_10 upgrade Content-Type: multipart/mixed; boundary="------------010301090204020805060905" X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:38:19 -0000 This is a multi-part message in MIME format. --------------010301090204020805060905 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I upgraded one of our file servers to RELENG_10 this AM and noticed the box started throwing a lot of errors all of a sudden on different disks and port multipliers. The disks do not have any errors according to smartctl. Now zfs detected write errors and forced a scrub on ada6 Any idea how to track this down ? dmesg and the errors attached in the txt file. loader is simple and is the same from before. hint.siis.0.msi=1 siis.0.msi=1 hw.em.enable_msix=0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ --------------010301090204020805060905 Content-Type: text/plain; charset=windows-1252; name="ata.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ata.txt" QXVnIDI4IDEwOjIwOjI2IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBUaW1lb3V0IG9uIHNs b3QgMzAKQXVnIDI4IDEwOjIwOjI2IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBzaWlzX3Rp bWVvdXQgaXMgMDAwNjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEg c3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjIwOjI2IGJhY2t1cDMga2Vy bmVsOiBzaWlzY2gzOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEwOjIwOjI2IGJhY2t1 cDMga2VybmVsOiBzaWlzY2gzOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgYzAwMDAw MDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAK QXVnIDI4IDEwOjIwOjI3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBUaW1lb3V0IG9uIHNs b3QgMzAKQXVnIDI4IDEwOjIwOjI3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBzaWlzX3Rp bWVvdXQgaXMgMDAwNjAwMDIgc3MgZTAwMDAwMDAgcnMgNjAwMDAwMDAgZXMgMDAwMDAwMDEg c3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjIwOjI3IGJhY2t1cDMga2Vy bmVsOiBzaWlzY2gzOiAgLi4uIHdhaXRpbmcgZm9yIHNsb3RzIDIwMDAwMDAwCkF1ZyAyOCAx MDoyMDoyNyBiYWNrdXAzIGtlcm5lbDogKGFkYTY6c2lpc2NoMzowOjE6MCk6IFdSSVRFX0ZQ RE1BX1FVRVVFRC4gQUNCOiA2MSA1NiA0NyBiYSAwMCA0MCBhNiAwMCAwMCAwMCAwMCAwMApB dWcgMjggMTA6MjA6MjcgYmFja3VwMyBrZXJuZWw6IChhZGE2OnNpaXNjaDM6MDoxOjApOiBD QU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9yCkF1ZyAyOCAxMDoyMDoyNyBiYWNrdXAzIGtl cm5lbDogKGFkYTY6c2lpc2NoMzowOjE6MCk6IEFUQSBzdGF0dXM6IDAwICgpCkF1ZyAyOCAx MDoyMDoyNyBiYWNrdXAzIGtlcm5lbDogKGFkYTY6c2lpc2NoMzowOjE6MCk6IFJFUzogMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjIwOjI3IGJhY2t1cDMg a2VybmVsOiAoYWRhNjpzaWlzY2gzOjA6MTowKTogUmV0cnlpbmcgY29tbWFuZApBdWcgMjgg MTA6MjA6NTcgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IFRpbWVvdXQgb24gc2xvdCAyOQpB dWcgMjggMTA6MjA6NTcgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IHNpaXNfdGltZW91dCBp cyAwMDA2MDAwMiBzcyBlMDAwMDAwMCBycyA2MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMgMDAx ZTIwMDAgc2VyciAwMDAwMDAwMApBdWcgMjggMTA6MjA6NTcgYmFja3VwMyBrZXJuZWw6IHNp aXNjaDM6ICAuLi4gd2FpdGluZyBmb3Igc2xvdHMgNDAwMDAwMDAKQXVnIDI4IDEwOjIwOjU4 IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEw OjIwOjU4IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAw MDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNl cnIgMDAwMDAwMDAKQXVnIDI4IDEwOjIxOjAwIGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBU aW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEwOjIxOjAwIGJhY2t1cDMga2VybmVsOiBzaWlz Y2gxOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgZjgwMDAwMDAgcnMgNDgwMDAwMDAg ZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjIxOjAw IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiAgLi4uIHdhaXRpbmcgZm9yIHNsb3RzIDA4MDAw MDAwCkF1ZyAyOCAxMDoyMjozMSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzogVGltZW91dCBv biBzbG90IDMwCkF1ZyAyOCAxMDoyMjozMSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzogc2lp c190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAw MDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyMjozMSBiYWNrdXAz IGtlcm5lbDogc2lpc2NoMTogVGltZW91dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyMjozMSBi YWNrdXAzIGtlcm5lbDogc2lpc2NoMTogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMw MDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAw MDAwCkF1ZyAyOCAxMDoyMjozMSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzogVGltZW91dCBv biBzbG90IDMwCkF1ZyAyOCAxMDoyMjozMSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzogc2lp c190aW1lb3V0IGlzIDAwMDAwMDAwIHNzIDQwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAw MDAwIHN0cyA4MDFmMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyMzowMiBiYWNrdXAz IGtlcm5lbDogc2lpc2NoMTogVGltZW91dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyMzowMiBi YWNrdXAzIGtlcm5lbDogc2lpc2NoMTogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMw MDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAw MDAwCkF1ZyAyOCAxMDoyMzowMiBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMDogVGltZW91dCBv biBzbG90IDMwCkF1ZyAyOCAxMDoyMzowMiBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMDogc2lp c190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAw MDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyMzowNCBiYWNrdXAz IGtlcm5lbDogc2lpc2NoMDogVGltZW91dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyMzowNCBi YWNrdXAzIGtlcm5lbDogc2lpc2NoMDogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGY4 MDAwMDAwIHJzIDQ4MDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAw MDAwCkF1ZyAyOCAxMDoyMzowNCBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMDogIC4uLiB3YWl0 aW5nIGZvciBzbG90cyAwODAwMDAwMApBdWcgMjggMTA6MjM6MzQgYmFja3VwMyBrZXJuZWw6 IHNpaXNjaDE6IFRpbWVvdXQgb24gc2xvdCAzMApBdWcgMjggMTA6MjM6MzQgYmFja3VwMyBr ZXJuZWw6IHNpaXNjaDE6IHNpaXNfdGltZW91dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBy cyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMgMDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcg MjggMTA6MjM6MzQgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IFRpbWVvdXQgb24gc2xvdCAz MApBdWcgMjggMTA6MjM6MzQgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IHNpaXNfdGltZW91 dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBycyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMg MDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcgMjggMTA6MjM6MzQgYmFja3VwMyBrZXJuZWw6 IHNpaXNjaDE6IFRpbWVvdXQgb24gc2xvdCAzMApBdWcgMjggMTA6MjM6MzQgYmFja3VwMyBr ZXJuZWw6IHNpaXNjaDE6IHNpaXNfdGltZW91dCBpcyAwMDAwMDAwMCBzcyA0MDAwMDAwMCBy cyA0MDAwMDAwMCBlcyAwMDAwMDAwMCBzdHMgODAxZjIwMDAgc2VyciAwMDAwMDAwMApBdWcg MjggMTA6MjQ6MDUgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDA6IFRpbWVvdXQgb24gc2xvdCAz MApBdWcgMjggMTA6MjQ6MDUgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDA6IHNpaXNfdGltZW91 dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBycyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMg MDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcgMjggMTA6MjQ6MDYgYmFja3VwMyBrZXJuZWw6 IHNpaXNjaDE6IFRpbWVvdXQgb24gc2xvdCAzMApBdWcgMjggMTA6MjQ6MDYgYmFja3VwMyBr ZXJuZWw6IHNpaXNjaDE6IHNpaXNfdGltZW91dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBy cyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMgMDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcg MjggMTA6MjQ6MDcgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDA6IFRpbWVvdXQgb24gc2xvdCAy NgpBdWcgMjggMTA6MjQ6MDcgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDA6IHNpaXNfdGltZW91 dCBpcyAwMDA2MDAwMiBzcyBmZTAwMDAwMCBycyA1NjAwMDAwMCBlcyAwMDAwMDAwMSBzdHMg MDAxYTIwMDAgc2VyciAwMDAwMDAwMApBdWcgMjggMTA6MjQ6MDcgYmFja3VwMyBrZXJuZWw6 IHNpaXNjaDA6ICAuLi4gd2FpdGluZyBmb3Igc2xvdHMgNTIwMDAwMDAKQXVnIDI4IDEwOjI0 OjM3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4 IDEwOjI0OjM3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBzaWlzX3RpbWVvdXQgaXMgMDAw NjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAw IHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI0OjM3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gx OiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEwOjI0OjM3IGJhY2t1cDMga2VybmVsOiBz aWlzY2gxOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAw MDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI1 OjA5IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBUaW1lb3V0IG9uIHNsb3QgMjkKQXVnIDI4 IDEwOjI1OjA5IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBzaWlzX3RpbWVvdXQgaXMgMDAw NjAwMDIgc3MgZTAwMDAwMDAgcnMgNjAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAw IHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI1OjA5IGJhY2t1cDMga2VybmVsOiBzaWlzY2gx OiAgLi4uIHdhaXRpbmcgZm9yIHNsb3RzIDQwMDAwMDAwCkF1ZyAyOCAxMDoyNTowOSBiYWNr dXAzIGtlcm5lbDogc2lpc2NoMTogVGltZW91dCBvbiBzbG90IDI5CkF1ZyAyOCAxMDoyNTow OSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNz IGUwMDAwMDAwIHJzIDIwMDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFkMjAwMCBzZXJyIDAw MDAwMDAwCkF1ZyAyOCAxMDoyNTo0MSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTogVGltZW91 dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyNTo0MSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTog c2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAw MDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyNTo0MSBiYWNr dXAzIGtlcm5lbDogc2lpc2NoMDogVGltZW91dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyNTo0 MSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMDogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNz IGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAw MDAwMDAwCkF1ZyAyOCAxMDoyNjoxMiBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTogVGltZW91 dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyNjoxMiBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTog c2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAw MDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyNjoxMyBiYWNr dXAzIGtlcm5lbDogc2lpc2NoMzogVGltZW91dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyNjox MyBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNz IGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAw MDAwMDAwCkF1ZyAyOCAxMDoyNjo0NCBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzogVGltZW91 dCBvbiBzbG90IDMwCkF1ZyAyOCAxMDoyNjo0NCBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMzog c2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNzIGMwMDAwMDAwIHJzIDQwMDAwMDAwIGVzIDAw MDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyNjo0NCBiYWNr dXAzIGtlcm5lbDogc2lpc2NoMDogVGltZW91dCBvbiBzbG90IDI5CkF1ZyAyOCAxMDoyNjo0 NCBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMDogc2lpc190aW1lb3V0IGlzIDAwMDYwMDAyIHNz IGUwMDAwMDAwIHJzIDYwMDAwMDAwIGVzIDAwMDAwMDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAw MDAwMDAwCkF1ZyAyOCAxMDoyNjo0NCBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMDogIC4uLiB3 YWl0aW5nIGZvciBzbG90cyA0MDAwMDAwMApBdWcgMjggMTA6MjY6NDQgYmFja3VwMyBrZXJu ZWw6IHNpaXNjaDA6IFRpbWVvdXQgb24gc2xvdCAzMApBdWcgMjggMTA6MjY6NDQgYmFja3Vw MyBrZXJuZWw6IHNpaXNjaDA6IHNpaXNfdGltZW91dCBpcyAwMDA2MDAwMiBzcyBlMDAwMDAw MCBycyA2MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMgMDAxZTIwMDAgc2VyciAwMDAwMDAwMApB dWcgMjggMTA6MjY6NDUgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDE6IFRpbWVvdXQgb24gc2xv dCAyOQpBdWcgMjggMTA6MjY6NDUgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDE6IHNpaXNfdGlt ZW91dCBpcyAwMDA2MDAwMiBzcyBlMDAwMDAwMCBycyA2MDAwMDAwMCBlcyAwMDAwMDAwMSBz dHMgMDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcgMjggMTA6MjY6NDUgYmFja3VwMyBrZXJu ZWw6IHNpaXNjaDE6ICAuLi4gd2FpdGluZyBmb3Igc2xvdHMgNDAwMDAwMDAKQXVnIDI4IDEw OjI3OjE1IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVn IDI4IDEwOjI3OjE1IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBzaWlzX3RpbWVvdXQgaXMg MDAwNjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUy MDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI3OjE3IGJhY2t1cDMga2VybmVsOiBzaWlz Y2gxOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEwOjI3OjE3IGJhY2t1cDMga2VybmVs OiBzaWlzY2gxOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAw MDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEw OjI3OjQ3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVn IDI4IDEwOjI3OjQ3IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBzaWlzX3RpbWVvdXQgaXMg MDAwNjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUy MDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI3OjQ3IGJhY2t1cDMga2VybmVsOiBzaWlz Y2gwOiBUaW1lb3V0IG9uIHNsb3QgMjkKQXVnIDI4IDEwOjI3OjQ3IGJhY2t1cDMga2VybmVs OiBzaWlzY2gwOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgZTAwMDAwMDAgcnMgMjAw MDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWQyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEw OjI3OjQ4IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVn IDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBzaWlzX3RpbWVvdXQgaXMg MDAwNjAwMDIgc3MgZmMwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUy MDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVsOiAoYWRh MTpzaWlzY2gxOjA6MTowKTogUkVBRF9GUERNQV9RVUVVRUQuIEFDQjogNjAgMTAgMTAgODYg ZTAgNDAgZTggMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVs OiAoYWRhMTpzaWlzY2gxOjA6MTowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgpB dWcgMjggMTA6Mjc6NDggYmFja3VwMyBrZXJuZWw6IChhZGExOnNpaXNjaDE6MDoxOjApOiBB VEEgc3RhdHVzOiAwMCAoKQpBdWcgMjggMTA6Mjc6NDggYmFja3VwMyBrZXJuZWw6IChhZGEx OnNpaXNjaDE6MDoxOjApOiBSRVM6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CkF1ZyAyOCAxMDoyNzo0OCBiYWNrdXAzIGtlcm5lbDogKGFkYTE6c2lpc2NoMTowOjE6MCk6 IFJldHJ5aW5nIGNvbW1hbmQKQXVnIDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVsOiAoYWRh MTpzaWlzY2gxOjA6MTowKTogUkVBRF9GUERNQV9RVUVVRUQuIEFDQjogNjAgMTAgMTAgODQg ZTAgNDAgZTggMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVs OiAoYWRhMTpzaWlzY2gxOjA6MTowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgpB dWcgMjggMTA6Mjc6NDggYmFja3VwMyBrZXJuZWw6IChhZGExOnNpaXNjaDE6MDoxOjApOiBB VEEgc3RhdHVzOiAwMCAoKQpBdWcgMjggMTA6Mjc6NDggYmFja3VwMyBrZXJuZWw6IChhZGEx OnNpaXNjaDE6MDoxOjApOiBSRVM6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CkF1ZyAyOCAxMDoyNzo0OCBiYWNrdXAzIGtlcm5lbDogKGFkYTE6c2lpc2NoMTowOjE6MCk6 IFJldHJ5aW5nIGNvbW1hbmQKQXVnIDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVsOiAoYWRh MTpzaWlzY2gxOjA6MTowKTogUkVBRF9GUERNQV9RVUVVRUQuIEFDQjogNjAgMTAgMTAgMDIg MDAgNDAgMDAgMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjI3OjQ4IGJhY2t1cDMga2VybmVs OiAoYWRhMTpzaWlzY2gxOjA6MTowKTogQ0FNIHN0YXR1czogQVRBIFN0YXR1cyBFcnJvcgpB dWcgMjggMTA6Mjc6NDggYmFja3VwMyBrZXJuZWw6IChhZGExOnNpaXNjaDE6MDoxOjApOiBB VEEgc3RhdHVzOiAwMCAoKQpBdWcgMjggMTA6Mjc6NDggYmFja3VwMyBrZXJuZWw6IChhZGEx OnNpaXNjaDE6MDoxOjApOiBSRVM6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CkF1ZyAyOCAxMDoyNzo0OCBiYWNrdXAzIGtlcm5lbDogKGFkYTE6c2lpc2NoMTowOjE6MCk6 IFJldHJ5aW5nIGNvbW1hbmQKQXVnIDI4IDEwOjI3OjQ5IGJhY2t1cDMga2VybmVsOiAoYWRh MTU6c2lpc2NoMDowOjI6MCk6IFJFQURfRlBETUFfUVVFVUVELiBBQ0I6IDYwIDEwIDEwIDg2 IGUwIDQwIGU4IDAwIDAwIDAwIDAwIDAwCkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAzIGtlcm5l bDogKGFkYTE1OnNpaXNjaDA6MDoyOjApOiBDQU0gc3RhdHVzOiBBVEEgU3RhdHVzIEVycm9y CkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAzIGtlcm5lbDogKGFkYTE1OnNpaXNjaDA6MDoyOjAp OiBBVEEgc3RhdHVzOiAwMCAoKQpBdWcgMjggMTA6Mjc6NDkgYmFja3VwMyBrZXJuZWw6IChh ZGExNTpzaWlzY2gwOjA6MjowKTogUkVTOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMApBdWcgMjggMTA6Mjc6NDkgYmFja3VwMyBrZXJuZWw6IChhZGExNTpzaWlzY2gwOjA6 MjowKTogUmV0cnlpbmcgY29tbWFuZApBdWcgMjggMTA6Mjc6NDkgYmFja3VwMyBrZXJuZWw6 IChhZGExNTpzaWlzY2gwOjA6MjowKTogUkVBRF9GUERNQV9RVUVVRUQuIEFDQjogNjAgMTAg MTAgODQgZTAgNDAgZTggMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjI3OjQ5IGJhY2t1cDMg a2VybmVsOiAoYWRhMTU6c2lpc2NoMDowOjI6MCk6IENBTSBzdGF0dXM6IEFUQSBTdGF0dXMg RXJyb3IKQXVnIDI4IDEwOjI3OjQ5IGJhY2t1cDMga2VybmVsOiAoYWRhMTU6c2lpc2NoMDow OjI6MCk6IEFUQSBzdGF0dXM6IDAwICgpCkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAzIGtlcm5l bDogKGFkYTE1OnNpaXNjaDA6MDoyOjApOiBSRVM6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwCkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAzIGtlcm5lbDogKGFkYTE1OnNpaXNj aDA6MDoyOjApOiBSZXRyeWluZyBjb21tYW5kCkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAzIGtl cm5lbDogKGFkYTE1OnNpaXNjaDA6MDoyOjApOiBXUklURV9GUERNQV9RVUVVRUQuIEFDQjog NjEgMDEgNGMgZmUgMDIgNDAgYjQgMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjI3OjQ5IGJh Y2t1cDMga2VybmVsOiAoYWRhMTU6c2lpc2NoMDowOjI6MCk6IENBTSBzdGF0dXM6IEFUQSBT dGF0dXMgRXJyb3IKQXVnIDI4IDEwOjI3OjQ5IGJhY2t1cDMga2VybmVsOiAoYWRhMTU6c2lp c2NoMDowOjI6MCk6IEFUQSBzdGF0dXM6IDAwICgpCkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAz IGtlcm5lbDogKGFkYTE1OnNpaXNjaDA6MDoyOjApOiBSRVM6IDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwCkF1ZyAyOCAxMDoyNzo0OSBiYWNrdXAzIGtlcm5lbDogKGFkYTE1 OnNpaXNjaDA6MDoyOjApOiBSZXRyeWluZyBjb21tYW5kCkF1ZyAyOCAxMDoyNzo0OSBiYWNr dXAzIGtlcm5lbDogKGFkYTE1OnNpaXNjaDA6MDoyOjApOiBSRUFEX0ZQRE1BX1FVRVVFRC4g QUNCOiA2MCAxMCAxMCAwMiAwMCA0MCAwMCAwMCAwMCAwMCAwMCAwMApBdWcgMjggMTA6Mjc6 NDkgYmFja3VwMyBrZXJuZWw6IChhZGExNTpzaWlzY2gwOjA6MjowKTogQ0FNIHN0YXR1czog QVRBIFN0YXR1cyBFcnJvcgpBdWcgMjggMTA6Mjc6NDkgYmFja3VwMyBrZXJuZWw6IChhZGEx NTpzaWlzY2gwOjA6MjowKTogQVRBIHN0YXR1czogMDAgKCkKQXVnIDI4IDEwOjI3OjQ5IGJh Y2t1cDMga2VybmVsOiAoYWRhMTU6c2lpc2NoMDowOjI6MCk6IFJFUzogMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKQXVnIDI4IDEwOjI3OjQ5IGJhY2t1cDMga2VybmVsOiAo YWRhMTU6c2lpc2NoMDowOjI6MCk6IFJldHJ5aW5nIGNvbW1hbmQKQXVnIDI4IDEwOjI4OjUw IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEw OjI4OjUwIGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAw MDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNl cnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI4OjUwIGJhY2t1cDMga2VybmVsOiBzaWlzY2gxOiBU aW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEwOjI4OjUwIGJhY2t1cDMga2VybmVsOiBzaWlz Y2gxOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAg ZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI4OjUx IGJhY2t1cDMga2VybmVsOiBzaWlzY2gwOiBUaW1lb3V0IG9uIHNsb3QgMzAKQXVnIDI4IDEw OjI4OjUxIGJhY2t1cDMga2VybmVsOiBzaWlzY2gwOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAw MDIgc3MgYzAwMDAwMDAgcnMgNDAwMDAwMDAgZXMgMDAwMDAwMDEgc3RzIDAwMWUyMDAwIHNl cnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI4OjUxIGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiBU aW1lb3V0IG9uIHNsb3QgMjkKQXVnIDI4IDEwOjI4OjUxIGJhY2t1cDMga2VybmVsOiBzaWlz Y2gzOiBzaWlzX3RpbWVvdXQgaXMgMDAwNjAwMDIgc3MgZmEwMDAwMDAgcnMgMzIwMDAwMDAg ZXMgMDAwMDAwMDEgc3RzIDAwMWQyMDAwIHNlcnIgMDAwMDAwMDAKQXVnIDI4IDEwOjI4OjUx IGJhY2t1cDMga2VybmVsOiBzaWlzY2gzOiAgLi4uIHdhaXRpbmcgZm9yIHNsb3RzIDEyMDAw MDAwCkF1ZyAyOCAxMDoyODo1MSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTogVGltZW91dCBv biBzbG90IDMwCkF1ZyAyOCAxMDoyODo1MSBiYWNrdXAzIGtlcm5lbDogc2lpc2NoMTogc2lp c190aW1lb3V0IGlzIDAwMDcwMDAzIHNzIGQwMDAwMDAwIHJzIDc4MDAwMDAwIGVzIDAwMDAw MDAxIHN0cyAwMDFlMjAwMCBzZXJyIDAwMDAwMDAwCkF1ZyAyOCAxMDoyODo1MSBiYWNrdXAz IGtlcm5lbDogc2lpc2NoMTogIC4uLiB3YWl0aW5nIGZvciBzbG90cyAzODAwMDAwMApBdWcg MjggMTA6Mjk6MjEgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IFRpbWVvdXQgb24gc2xvdCAz MApBdWcgMjggMTA6Mjk6MjEgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IHNpaXNfdGltZW91 dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBycyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMg MDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcgMjggMTA6Mjk6MjEgYmFja3VwMyBrZXJuZWw6 IHNpaXNjaDE6IFRpbWVvdXQgb24gc2xvdCAzMApBdWcgMjggMTA6Mjk6MjEgYmFja3VwMyBr ZXJuZWw6IHNpaXNjaDE6IHNpaXNfdGltZW91dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBy cyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMgMDAxZTIwMDAgc2VyciAwMDAwMDAwMApBdWcg MjggMTA6Mjk6NTIgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IFRpbWVvdXQgb24gc2xvdCAz MApBdWcgMjggMTA6Mjk6NTIgYmFja3VwMyBrZXJuZWw6IHNpaXNjaDM6IHNpaXNfdGltZW91 dCBpcyAwMDA2MDAwMiBzcyBjMDAwMDAwMCBycyA0MDAwMDAwMCBlcyAwMDAwMDAwMSBzdHMg MDAxZTIwMDAgc2VyciAwMDAwMDAwMAoKCiMgY2FtY29udHJvbCBkZXZsaXN0CjxXREMgV0Qy MDAxRkFTUy0wMFUwQjAgMDEuMDAxMDE+ICAgYXQgc2NidXMwIHRhcmdldCAwIGx1biAwIChw YXNzMjAsYWRhMTMpCjxXREMgV0QyMDAxRkFTUy0wMFUwQjAgMDEuMDAxMDE+ICAgYXQgc2Ni dXMwIHRhcmdldCAxIGx1biAwIChwYXNzMTksYWRhMTIpCjxXREMgV0QyMDAxRkFTUy0wMFUw QjAgMDEuMDAxMDE+ICAgYXQgc2NidXMwIHRhcmdldCAyIGx1biAwIChwYXNzMjEsYWRhMTQp CjxXREMgV0QyMDAxRkFTUy0wMFUwQjAgMDEuMDAxMDE+ICAgYXQgc2NidXMwIHRhcmdldCAz IGx1biAwIChwYXNzMjIsYWRhMTUpCjxQb3J0IE11bHRpcGxpZXIgNDcyNjEwOTUgMWYwNj4g ICAgYXQgc2NidXMwIHRhcmdldCAxNSBsdW4gMCAocG1wMixwYXNzMTgpCjxXREMgV0QyMDAy RkFFWC0wMDdCQTAgMDUuMDFEMDU+ICAgYXQgc2NidXMxIHRhcmdldCAwIGx1biAwIChhZGEw LHBhc3MwKQo8V0RDIFdEMjAwMkZBRVgtMDA3QkEwIDA1LjAxRDA1PiAgIGF0IHNjYnVzMSB0 YXJnZXQgMSBsdW4gMCAoYWRhMSxwYXNzMSkKPFdEQyBXRDIwMDJGQUVYLTAwN0JBMCAwNS4w MUQwNT4gICBhdCBzY2J1czEgdGFyZ2V0IDIgbHVuIDAgKGFkYTIscGFzczIpCjxXREMgV0Qy MDAyRkFFWC0wME1KUkEwIDAxLjAxTDAxPiAgYXQgc2NidXMxIHRhcmdldCAzIGx1biAwIChh ZGEzLHBhc3MzKQo8UG9ydCBNdWx0aXBsaWVyIDM4MjYxMDk1IDE3MDY+ICAgIGF0IHNjYnVz MSB0YXJnZXQgMTUgbHVuIDAgKHBhc3M0LHBtcDApCjxXREMgV0QyMDAyRkFFWC0wMDdCQTAg MDUuMDFEMDU+ICAgYXQgc2NidXMzIHRhcmdldCAwIGx1biAwIChhZGE0LHBhc3M1KQo8V0RD IFdEMjAwMkZBRVgtMDA3QkEwIDA1LjAxRDA1PiAgIGF0IHNjYnVzMyB0YXJnZXQgMSBsdW4g MCAoYWRhNSxwYXNzNikKPFdEQyBXRDIwMDJGQUVYLTAwN0JBMCAwNS4wMUQwNT4gICBhdCBz Y2J1czMgdGFyZ2V0IDMgbHVuIDAgKGFkYTYscGFzczcpCjxXREMgV0QyMDAyRkFFWC0wMDdC QTAgMDUuMDFEMDU+ICAgYXQgc2NidXMzIHRhcmdldCA0IGx1biAwIChhZGE3LHBhc3M4KQo8 UG9ydCBNdWx0aXBsaWVyIDM3MjYxMDk1IDE3MDY+ICAgIGF0IHNjYnVzMyB0YXJnZXQgMTUg bHVuIDAgKHBhc3M5LHBtcDEpCjxBcmVjYSB1c3J2YXIgUjAwMT4gICAgICAgICAgICAgICAg YXQgc2NidXM0IHRhcmdldCAwIGx1biAwIChwYXNzMTAsZGEwKQo8QXJlY2EgYmFja3VwMSBS MDAxPiAgICAgICAgICAgICAgIGF0IHNjYnVzNCB0YXJnZXQgMCBsdW4gMSAocGFzczExLGRh MSkKPEFyZWNhIFJBSUQgY29udHJvbGxlciBSMDAxPiAgICAgICBhdCBzY2J1czQgdGFyZ2V0 IDE2IGx1biAwIChwYXNzMTIpCjxBTUNDIDk2NTBTRS0yTFAgRElTSyA0LjEwPiAgICAgICAg YXQgc2NidXM1IHRhcmdldCAwIGx1biAwIChwYXNzMTMsZGEyKQo8V0RDIFdEMTAwMkZBRVgt MDBZOUEwIDA1LjAxRDA1PiAgIGF0IHNjYnVzNiB0YXJnZXQgMCBsdW4gMCAoYWRhOCxwYXNz MTQpCjxXREMgV0QxMDAyRkFFWC0wMFk5QTAgMDUuMDFEMDU+ICAgYXQgc2NidXM3IHRhcmdl dCAwIGx1biAwIChhZGE5LHBhc3MxNSkKPFNUMzEwMDAzNDBBUyBTRDFBPiAgICAgICAgICAg ICAgICBhdCBzY2J1czggdGFyZ2V0IDAgbHVuIDAgKGFkYTEwLHBhc3MxNikKPFdEQyBXRDEw MDJGQUVYLTAwWjNBMCAwNS4wMUQwNT4gICBhdCBzY2J1czExIHRhcmdldCAwIGx1biAwIChh ZGExMSxwYXNzMTcpCgojIHNtYXJ0Y3RsIC1hIC9kZXYvYWRhMTUKc21hcnRjdGwgNi4zIDIw MTQtMDctMjYgcjM5NzYgW0ZyZWVCU0QgMTAuMS1QUkVSRUxFQVNFIGFtZDY0XSAobG9jYWwg YnVpbGQpCkNvcHlyaWdodCAoQykgMjAwMi0xNCwgQnJ1Y2UgQWxsZW4sIENocmlzdGlhbiBG cmFua2UsIHd3dy5zbWFydG1vbnRvb2xzLm9yZwoKPT09IFNUQVJUIE9GIElORk9STUFUSU9O IFNFQ1RJT04gPT09Ck1vZGVsIEZhbWlseTogICAgIFdlc3Rlcm4gRGlnaXRhbCBDYXZpYXIg QmxhY2sKRGV2aWNlIE1vZGVsOiAgICAgV0RDIFdEMjAwMUZBU1MtMDBVMEIwClNlcmlhbCBO dW1iZXI6ICAgIFdELVdNQVVSMDM4NzI1OQpMVSBXV04gRGV2aWNlIElkOiA1IDAwMTRlZSA2 YWFiN2I5ZmYKRmlybXdhcmUgVmVyc2lvbjogMDEuMDAxMDEKVXNlciBDYXBhY2l0eTogICAg MiwwMDAsMzk4LDkzNCwwMTYgYnl0ZXMgWzIuMDAgVEJdClNlY3RvciBTaXplOiAgICAgIDUx MiBieXRlcyBsb2dpY2FsL3BoeXNpY2FsClJvdGF0aW9uIFJhdGU6ICAgIDcyMDAgcnBtCkRl dmljZSBpczogICAgICAgIEluIHNtYXJ0Y3RsIGRhdGFiYXNlIFtmb3IgZGV0YWlscyB1c2U6 IC1QIHNob3ddCkFUQSBWZXJzaW9uIGlzOiAgIEFUQTgtQUNTIChtaW5vciByZXZpc2lvbiBu b3QgaW5kaWNhdGVkKQpTQVRBIFZlcnNpb24gaXM6ICBTQVRBIDIuNiwgMy4wIEdiL3MKTG9j YWwgVGltZSBpczogICAgVGh1IEF1ZyAyOCAxMTowNjo1MSAyMDE0IEVEVApTTUFSVCBzdXBw b3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxpdHkuClNNQVJU IHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERBVEEgU0VD VElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3QgcmVz dWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHg4NCkgT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdhcyBzdXNwZW5kZWQg YnkgYW4gaW50ZXJydXB0aW5nIGNvbW1hbmQgZnJvbSBob3N0LgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQXV0byBPZmZsaW5lIERhdGEgQ29sbGVjdGlvbjog RW5hYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAgIDApIFRoZSBw cmV2aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHdpdGhvdXQgZXJyb3Igb3Igbm8gc2VsZi10ZXN0IGhh cyBldmVyIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmVlbiBy dW4uClRvdGFsIHRpbWUgdG8gY29tcGxldGUgT2ZmbGluZSAKZGF0YSBjb2xsZWN0aW9uOiAg ICAgICAgICAgICAgICAoMzA5MDApIHNlY29uZHMuCk9mZmxpbmUgZGF0YSBjb2xsZWN0aW9u CmNhcGFiaWxpdGllczogICAgICAgICAgICAgICAgICAgICgweDdiKSBTTUFSVCBleGVjdXRl IE9mZmxpbmUgaW1tZWRpYXRlLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQXV0byBPZmZsaW5lIGRhdGEgY29sbGVjdGlvbiBvbi9vZmYgc3VwcG9ydC4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1c3BlbmQgT2ZmbGluZSBj b2xsZWN0aW9uIHVwb24gbmV3CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb21tYW5kLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg T2ZmbGluZSBzdXJmYWNlIHNjYW4gc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2VsZi10ZXN0IHN1cHBvcnRlZC4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENvbnZleWFuY2UgU2VsZi10ZXN0IHN1cHBvcnRl ZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbGVjdGl2ZSBT ZWxmLXRlc3Qgc3VwcG9ydGVkLgpTTUFSVCBjYXBhYmlsaXRpZXM6ICAgICAgICAgICAgKDB4 MDAwMykgU2F2ZXMgU01BUlQgZGF0YSBiZWZvcmUgZW50ZXJpbmcKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHBvd2VyLXNhdmluZyBtb2RlLgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3VwcG9ydHMgU01BUlQgYXV0byBzYXZl IHRpbWVyLgpFcnJvciBsb2dnaW5nIGNhcGFiaWxpdHk6ICAgICAgICAoMHgwMSkgRXJyb3Ig bG9nZ2luZyBzdXBwb3J0ZWQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBHZW5lcmFsIFB1cnBvc2UgTG9nZ2luZyBzdXBwb3J0ZWQuClNob3J0IHNlbGYtdGVz dCByb3V0aW5lIApyZWNvbW1lbmRlZCBwb2xsaW5nIHRpbWU6ICAgICAgICAoICAgMikgbWlu dXRlcy4KRXh0ZW5kZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0 aW1lOiAgICAgICAgKCAzNTMpIG1pbnV0ZXMuCkNvbnZleWFuY2Ugc2VsZi10ZXN0IHJvdXRp bmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAgICAgICAgKCAgIDUpIG1pbnV0ZXMuClND VCBjYXBhYmlsaXRpZXM6ICAgICAgICAgICAgICAoMHgzMDM3KSBTQ1QgU3RhdHVzIHN1cHBv cnRlZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNDVCBGZWF0 dXJlIENvbnRyb2wgc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU0NUIERhdGEgVGFibGUgc3VwcG9ydGVkLgoKU01BUlQgQXR0cmlidXRlcyBE YXRhIFN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXI6IDE2ClZlbmRvciBTcGVjaWZpYyBTTUFS VCBBdHRyaWJ1dGVzIHdpdGggVGhyZXNob2xkczoKSUQjIEFUVFJJQlVURV9OQU1FICAgICAg ICAgIEZMQUcgICAgIFZBTFVFIFdPUlNUIFRIUkVTSCBUWVBFICAgICAgVVBEQVRFRCAgV0hF Tl9GQUlMRUQgUkFXX1ZBTFVFCiAgMSBSYXdfUmVhZF9FcnJvcl9SYXRlICAgICAweDAwMmYg ICAyMDAgICAyMDAgICAwNTEgICAgUHJlLWZhaWwgIEFsd2F5cyAgICAgICAtICAgICAgIDAK ICAzIFNwaW5fVXBfVGltZSAgICAgICAgICAgIDB4MDAyNyAgIDA3MyAgIDA0MCAgIDAyMSAg ICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTMzNzUKICA0IFN0YXJ0X1N0b3Bf Q291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3 YXlzICAgICAgIC0gICAgICAgMTcKICA1IFJlYWxsb2NhdGVkX1NlY3Rvcl9DdCAgIDB4MDAz MyAgIDIwMCAgIDIwMCAgIDE0MCAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAg MAogIDcgU2Vla19FcnJvcl9SYXRlICAgICAgICAgMHgwMDJlICAgMTAwICAgMjUzICAgMDAw ICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCiAgOSBQb3dlcl9Pbl9Ib3Vy cyAgICAgICAgICAweDAwMzIgICAwNTMgICAwNTMgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5 cyAgICAgICAtICAgICAgIDM0ODY4CiAxMCBTcGluX1JldHJ5X0NvdW50ICAgICAgICAweDAw MzIgICAxMDAgICAyNTMgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAg IDAKIDExIENhbGlicmF0aW9uX1JldHJ5X0NvdW50IDB4MDAzMiAgIDEwMCAgIDI1MyAgIDAw MCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAogMTIgUG93ZXJfQ3ljbGVf Q291bnQgICAgICAgMHgwMDMyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdh eXMgICAgICAgLSAgICAgICAxMwoxOTIgUG93ZXItT2ZmX1JldHJhY3RfQ291bnQgMHgwMDMy ICAgMjAwICAgMjAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAx MQoxOTMgTG9hZF9DeWNsZV9Db3VudCAgICAgICAgMHgwMDMyICAgMTM0ICAgMTM0ICAgMDAw ICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAyMDAxNDEKMTk0IFRlbXBlcmF0 dXJlX0NlbHNpdXMgICAgIDB4MDAyMiAgIDExMSAgIDEwNSAgIDAwMCAgICBPbGRfYWdlICAg QWx3YXlzICAgICAgIC0gICAgICAgNDEKMTk2IFJlYWxsb2NhdGVkX0V2ZW50X0NvdW50IDB4 MDAzMiAgIDIwMCAgIDIwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAg ICAgMAoxOTcgQ3VycmVudF9QZW5kaW5nX1NlY3RvciAgMHgwMDMyICAgMjAwICAgMjAwICAg MDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCjE5OCBPZmZsaW5lX1Vu Y29ycmVjdGFibGUgICAweDAwMzAgICAyMDAgICAyMDAgICAwMDAgICAgT2xkX2FnZSAgIE9m ZmxpbmUgICAgICAtICAgICAgIDAKMTk5IFVETUFfQ1JDX0Vycm9yX0NvdW50ICAgIDB4MDAz MiAgIDIwMCAgIDIwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAg MAoyMDAgTXVsdGlfWm9uZV9FcnJvcl9SYXRlICAgMHgwMDA4ICAgMjAwICAgMjAwICAgMDAw ICAgIE9sZF9hZ2UgICBPZmZsaW5lICAgICAgLSAgICAgICAwCgpTTUFSVCBFcnJvciBMb2cg VmVyc2lvbjogMQpObyBFcnJvcnMgTG9nZ2VkCgpTTUFSVCBTZWxmLXRlc3QgbG9nIHN0cnVj dHVyZSByZXZpc2lvbiBudW1iZXIgMQpObyBzZWxmLXRlc3RzIGhhdmUgYmVlbiBsb2dnZWQu ICBbVG8gcnVuIHNlbGYtdGVzdHMsIHVzZTogc21hcnRjdGwgLXRdCgpTTUFSVCBTZWxlY3Rp dmUgc2VsZi10ZXN0IGxvZyBkYXRhIHN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXIgMQogU1BB TiAgTUlOX0xCQSAgTUFYX0xCQSAgQ1VSUkVOVF9URVNUX1NUQVRVUwogICAgMSAgICAgICAg MCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDIgICAgICAgIDAgICAgICAgIDAgIE5vdF90 ZXN0aW5nCiAgICAzICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwogICAgNCAgICAg ICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDUgICAgICAgIDAgICAgICAgIDAgIE5v dF90ZXN0aW5nClNlbGVjdGl2ZSBzZWxmLXRlc3QgZmxhZ3MgKDB4MCk6CiAgQWZ0ZXIgc2Nh bm5pbmcgc2VsZWN0ZWQgc3BhbnMsIGRvIE5PVCByZWFkLXNjYW4gcmVtYWluZGVyIG9mIGRp c2suCklmIFNlbGVjdGl2ZSBzZWxmLXRlc3QgaXMgcGVuZGluZyBvbiBwb3dlci11cCwgcmVz dW1lIGFmdGVyIDAgbWludXRlIGRlbGF5LgoKIyB6cG9vbCBzdGF0dXMKICBwb29sOiB6YmFj a3VwMQogc3RhdGU6IE9OTElORQpzdGF0dXM6IE9uZSBvciBtb3JlIGRldmljZXMgaGFzIGV4 cGVyaWVuY2VkIGFuIHVucmVjb3ZlcmFibGUgZXJyb3IuICBBbgogICAgICAgIGF0dGVtcHQg d2FzIG1hZGUgdG8gY29ycmVjdCB0aGUgZXJyb3IuICBBcHBsaWNhdGlvbnMgYXJlIHVuYWZm ZWN0ZWQuCmFjdGlvbjogRGV0ZXJtaW5lIGlmIHRoZSBkZXZpY2UgbmVlZHMgdG8gYmUgcmVw bGFjZWQsIGFuZCBjbGVhciB0aGUgZXJyb3JzCiAgICAgICAgdXNpbmcgJ3pwb29sIGNsZWFy JyBvciByZXBsYWNlIHRoZSBkZXZpY2Ugd2l0aCAnenBvb2wgcmVwbGFjZScuCiAgIHNlZTog aHR0cDovL2lsbHVtb3Mub3JnL21zZy9aRlMtODAwMC05UAogIHNjYW46IHNjcnViIGluIHBy b2dyZXNzIHNpbmNlIFRodSBBdWcgMjggMTA6NDU6MDUgMjAxNAogICAgICAgIDQ3MEcgc2Nh bm5lZCBvdXQgb2YgMjEuNVQgYXQgMjA5TS9zLCAyOWgyM20gdG8gZ28KICAgICAgICAwIHJl cGFpcmVkLCAyLjEzJSBkb25lCmNvbmZpZzoKCiAgICAgICAgTkFNRSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU1RBVEUgICAgIFJFQUQgV1JJVEUgQ0tTVU0KICAgICAgICB6YmFj a3VwMSAgICAgICAgICAgICAgICAgICAgICAgICBPTkxJTkUgICAgICAgMCAgICAgMCAgICAg MAogICAgICAgICAgcmFpZHoxLTAgICAgICAgICAgICAgICAgICAgICAgIE9OTElORSAgICAg ICAwICAgICAwICAgICAwCiAgICAgICAgICAgIGRpc2tpZC9ESVNLLVdELVdDQVczMjI3NjY5 MiAgT05MSU5FICAgICAgIDAgICAgIDAgICAgIDAKICAgICAgICAgICAgZGlza2lkL0RJU0st V0QtV0NBVFI0NDI3MzQzICBPTkxJTkUgICAgICAgMCAgICAgMCAgICAgMAogICAgICAgICAg ICBkaXNraWQvRElTSy1XRC1XQ0FXMzQyNjU5NzMgIE9OTElORSAgICAgICAwICAgICAwICAg ICAwCiAgICAgICAgICAgIGRpc2tpZC9ESVNLLTlRSjJUUzNTICAgICAgICAgT05MSU5FICAg ICAgIDAgICAgIDAgICAgIDAKICAgICAgICAgIHJhaWR6MS0xICAgICAgICAgICAgICAgICAg ICAgICBPTkxJTkUgICAgICAgMCAgICAgMCAgICAgMAogICAgICAgICAgICBkaXNraWQvRElT Sy1XRC1XTUFVUjAzMzE2MDUgIE9OTElORSAgICAgICAwICAgICAwICAgICAwCiAgICAgICAg ICAgIGRpc2tpZC9ESVNLLVdELVdNQVVSMDM3ODUwOSAgT05MSU5FICAgICAgIDAgICAgIDAg ICAgIDAKICAgICAgICAgICAgZGlza2lkL0RJU0stV0QtV01BVVIwMzI3Njk2ICBPTkxJTkUg ICAgICAgMCAgICAgMCAgICAgMAogICAgICAgICAgICBkaXNraWQvRElTSy1XRC1XTUFVUjAz ODcyNTkgIE9OTElORSAgICAgICAwICAgICAwICAgICAwCiAgICAgICAgICByYWlkejEtMiAg ICAgICAgICAgICAgICAgICAgICAgT05MSU5FICAgICAgIDAgICAgIDAgICAgIDAKICAgICAg ICAgICAgYWRhMyAgICAgICAgICAgICAgICAgICAgICAgICBPTkxJTkUgICAgICAgMCAgICAg MCAgICAgMAogICAgICAgICAgICBhZGEwICAgICAgICAgICAgICAgICAgICAgICAgIE9OTElO RSAgICAgICAwICAgICAwICAgICAwCiAgICAgICAgICAgIGFkYTIgICAgICAgICAgICAgICAg ICAgICAgICAgT05MSU5FICAgICAgIDAgICAgIDAgICAgIDAKICAgICAgICAgICAgYWRhMSAg ICAgICAgICAgICAgICAgICAgICAgICBPTkxJTkUgICAgICAgMCAgICAgMCAgICAgMAogICAg ICAgICAgcmFpZHoxLTMgICAgICAgICAgICAgICAgICAgICAgIE9OTElORSAgICAgICAwICAg ICAxICAgICAwCiAgICAgICAgICAgIGRpc2tpZC9ESVNLLVdELVdNQVdQMDA3OTI5MyAgT05M SU5FICAgICAgIDAgICAgIDAgICAgIDAKICAgICAgICAgICAgZGlza2lkL0RJU0stV0QtV01B WTAzNTEwMzExICBPTkxJTkUgICAgICAgMCAgICAgMCAgICAgMAogICAgICAgICAgICBkaXNr aWQvRElTSy1XRC1XTUFXUDAxMjYwOTMgIE9OTElORSAgICAgICAwICAgICAxICAgICAwCiAg ICAgICAgICAgIGRpc2tpZC9ESVNLLVdELVdNQVdQMDIwMzc3NCAgT05MSU5FICAgICAgIDMg ICAxMjUgICAgIDAKCiMgc21hcnRjdGwgLXggL2Rldi9hZGE2CnNtYXJ0Y3RsIDYuMyAyMDE0 LTA3LTI2IHIzOTc2IFtGcmVlQlNEIDEwLjEtUFJFUkVMRUFTRSBhbWQ2NF0gKGxvY2FsIGJ1 aWxkKQpDb3B5cmlnaHQgKEMpIDIwMDItMTQsIEJydWNlIEFsbGVuLCBDaHJpc3RpYW4gRnJh bmtlLCB3d3cuc21hcnRtb250b29scy5vcmcKCj09PSBTVEFSVCBPRiBJTkZPUk1BVElPTiBT RUNUSU9OID09PQpNb2RlbCBGYW1pbHk6ICAgICBXZXN0ZXJuIERpZ2l0YWwgQmxhY2sKRGV2 aWNlIE1vZGVsOiAgICAgV0RDIFdEMjAwMkZBRVgtMDA3QkEwClNlcmlhbCBOdW1iZXI6ICAg IFdELVdNQVdQMDIwMzc3NApMVSBXV04gRGV2aWNlIElkOiA1IDAwMTRlZSAzYWFiOWRkNzQK RmlybXdhcmUgVmVyc2lvbjogMDUuMDFEMDUKVXNlciBDYXBhY2l0eTogICAgMiwwMDAsMzk4 LDkzNCwwMTYgYnl0ZXMgWzIuMDAgVEJdClNlY3RvciBTaXplOiAgICAgIDUxMiBieXRlcyBs b2dpY2FsL3BoeXNpY2FsCkRldmljZSBpczogICAgICAgIEluIHNtYXJ0Y3RsIGRhdGFiYXNl IFtmb3IgZGV0YWlscyB1c2U6IC1QIHNob3ddCkFUQSBWZXJzaW9uIGlzOiAgIEFUQTgtQUNT IChtaW5vciByZXZpc2lvbiBub3QgaW5kaWNhdGVkKQpTQVRBIFZlcnNpb24gaXM6ICBTQVRB IDMuMCwgNi4wIEdiL3MgKGN1cnJlbnQ6IDMuMCBHYi9zKQpMb2NhbCBUaW1lIGlzOiAgICBU aHUgQXVnIDI4IDExOjI0OjM5IDIwMTQgRURUClNNQVJUIHN1cHBvcnQgaXM6IEF2YWlsYWJs ZSAtIGRldmljZSBoYXMgU01BUlQgY2FwYWJpbGl0eS4KU01BUlQgc3VwcG9ydCBpczogRW5h YmxlZApBQU0gZmVhdHVyZSBpczogICBVbmF2YWlsYWJsZQpBUE0gZmVhdHVyZSBpczogICBV bmF2YWlsYWJsZQpSZCBsb29rLWFoZWFkIGlzOiBFbmFibGVkCldyaXRlIGNhY2hlIGlzOiAg IEVuYWJsZWQKQVRBIFNlY3VyaXR5IGlzOiAgRGlzYWJsZWQsIE5PVCBGUk9aRU4gW1NFQzFd Cld0IENhY2hlIFJlb3JkZXI6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERB VEEgU0VDVElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRl c3QgcmVzdWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEg Y29sbGVjdGlvbiBzdGF0dXM6ICAoMHg4NCkgT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0 aXZpdHkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdhcyBzdXNw ZW5kZWQgYnkgYW4gaW50ZXJydXB0aW5nIGNvbW1hbmQgZnJvbSBob3N0LgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXV0byBPZmZsaW5lIERhdGEgQ29sbGVj dGlvbjogRW5hYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAgIDAp IFRoZSBwcmV2aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGhvdXQgZXJyb3Igb3Igbm8gc2VsZi10 ZXN0IGhhcyBldmVyIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg YmVlbiBydW4uClRvdGFsIHRpbWUgdG8gY29tcGxldGUgT2ZmbGluZSAKZGF0YSBjb2xsZWN0 aW9uOiAgICAgICAgICAgICAgICAoMzE4NjApIHNlY29uZHMuCk9mZmxpbmUgZGF0YSBjb2xs ZWN0aW9uCmNhcGFiaWxpdGllczogICAgICAgICAgICAgICAgICAgICgweDdiKSBTTUFSVCBl eGVjdXRlIE9mZmxpbmUgaW1tZWRpYXRlLgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQXV0byBPZmZsaW5lIGRhdGEgY29sbGVjdGlvbiBvbi9vZmYgc3VwcG9y dC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1c3BlbmQgT2Zm bGluZSBjb2xsZWN0aW9uIHVwb24gbmV3CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjb21tYW5kLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgT2ZmbGluZSBzdXJmYWNlIHNjYW4gc3VwcG9ydGVkLgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2VsZi10ZXN0IHN1cHBvcnRlZC4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbnZleWFuY2UgU2VsZi10ZXN0IHN1 cHBvcnRlZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbGVj dGl2ZSBTZWxmLXRlc3Qgc3VwcG9ydGVkLgpTTUFSVCBjYXBhYmlsaXRpZXM6ICAgICAgICAg ICAgKDB4MDAwMykgU2F2ZXMgU01BUlQgZGF0YSBiZWZvcmUgZW50ZXJpbmcKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvd2VyLXNhdmluZyBtb2RlLgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3VwcG9ydHMgU01BUlQgYXV0 byBzYXZlIHRpbWVyLgpFcnJvciBsb2dnaW5nIGNhcGFiaWxpdHk6ICAgICAgICAoMHgwMSkg RXJyb3IgbG9nZ2luZyBzdXBwb3J0ZWQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBHZW5lcmFsIFB1cnBvc2UgTG9nZ2luZyBzdXBwb3J0ZWQuClNob3J0IHNl bGYtdGVzdCByb3V0aW5lIApyZWNvbW1lbmRlZCBwb2xsaW5nIHRpbWU6ICAgICAgICAoICAg MikgbWludXRlcy4KRXh0ZW5kZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9s bGluZyB0aW1lOiAgICAgICAgKCAzMDgpIG1pbnV0ZXMuCkNvbnZleWFuY2Ugc2VsZi10ZXN0 IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAgICAgICAgKCAgIDUpIG1pbnV0 ZXMuClNDVCBjYXBhYmlsaXRpZXM6ICAgICAgICAgICAgICAoMHgzMDM3KSBTQ1QgU3RhdHVz IHN1cHBvcnRlZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFND VCBGZWF0dXJlIENvbnRyb2wgc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU0NUIERhdGEgVGFibGUgc3VwcG9ydGVkLgoKU01BUlQgQXR0cmli dXRlcyBEYXRhIFN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXI6IDE2ClZlbmRvciBTcGVjaWZp YyBTTUFSVCBBdHRyaWJ1dGVzIHdpdGggVGhyZXNob2xkczoKSUQjIEFUVFJJQlVURV9OQU1F ICAgICAgICAgIEZMQUdTICAgIFZBTFVFIFdPUlNUIFRIUkVTSCBGQUlMIFJBV19WQUxVRQog IDEgUmF3X1JlYWRfRXJyb3JfUmF0ZSAgICAgUE9TUi1LICAgMjAwICAgMjAwICAgMDUxICAg IC0gICAgMjQwCiAgMyBTcGluX1VwX1RpbWUgICAgICAgICAgICBQT1MtLUsgICAyNTMgICAy NTMgICAwMjEgICAgLSAgICA2NzE2CiAgNCBTdGFydF9TdG9wX0NvdW50ICAgICAgICAtTy0t Q0sgICAxMDAgICAxMDAgICAwMDAgICAgLSAgICAyMgogIDUgUmVhbGxvY2F0ZWRfU2VjdG9y X0N0ICAgUE8tLUNLICAgMjAwICAgMjAwICAgMTQwICAgIC0gICAgMAogIDcgU2Vla19FcnJv cl9SYXRlICAgICAgICAgLU9TUi1LICAgMTAwICAgMjUzICAgMDAwICAgIC0gICAgMAogIDkg UG93ZXJfT25fSG91cnMgICAgICAgICAgLU8tLUNLICAgMDc0ICAgMDc0ICAgMDAwICAgIC0g ICAgMTkwNDkKIDEwIFNwaW5fUmV0cnlfQ291bnQgICAgICAgIC1PLS1DSyAgIDEwMCAgIDI1 MyAgIDAwMCAgICAtICAgIDAKIDExIENhbGlicmF0aW9uX1JldHJ5X0NvdW50IC1PLS1DSyAg IDEwMCAgIDI1MyAgIDAwMCAgICAtICAgIDAKIDEyIFBvd2VyX0N5Y2xlX0NvdW50ICAgICAg IC1PLS1DSyAgIDEwMCAgIDEwMCAgIDAwMCAgICAtICAgIDIwCjE5MiBQb3dlci1PZmZfUmV0 cmFjdF9Db3VudCAtTy0tQ0sgICAyMDAgICAyMDAgICAwMDAgICAgLSAgICAxOAoxOTMgTG9h ZF9DeWNsZV9Db3VudCAgICAgICAgLU8tLUNLICAgMjAwICAgMjAwICAgMDAwICAgIC0gICAg MwoxOTQgVGVtcGVyYXR1cmVfQ2Vsc2l1cyAgICAgLU8tLS1LICAgMTEyICAgMDg3ICAgMDAw ICAgIC0gICAgNDAKMTk2IFJlYWxsb2NhdGVkX0V2ZW50X0NvdW50IC1PLS1DSyAgIDIwMCAg IDIwMCAgIDAwMCAgICAtICAgIDAKMTk3IEN1cnJlbnRfUGVuZGluZ19TZWN0b3IgIC1PLS1D SyAgIDIwMCAgIDIwMCAgIDAwMCAgICAtICAgIDAKMTk4IE9mZmxpbmVfVW5jb3JyZWN0YWJs ZSAgIC0tLS1DSyAgIDEwMCAgIDI1MyAgIDAwMCAgICAtICAgIDAKMTk5IFVETUFfQ1JDX0Vy cm9yX0NvdW50ICAgIC1PLS1DSyAgIDIwMCAgIDIwMCAgIDAwMCAgICAtICAgIDE0OTgKMjAw IE11bHRpX1pvbmVfRXJyb3JfUmF0ZSAgIC0tLVItLSAgIDEwMCAgIDI1MyAgIDAwMCAgICAt ICAgIDAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8fHx8fF8gSyBhdXRvLWtlZXAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8fHx8X18gQyBldmVudCBjb3VudAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgfHx8fF9fXyBSIGVycm9yIHJhdGUKICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHx8fF9fX18gUyBzcGVlZC9wZXJmb3JtYW5jZQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgfHxfX19fXyBPIHVwZGF0ZWQgb25saW5lCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8X19fX19fIFAgcHJlZmFpbHVyZSB3YXJuaW5nCgpHZW5l cmFsIFB1cnBvc2UgTG9nIERpcmVjdG9yeSBWZXJzaW9uIDEKU01BUlQgICAgICAgICAgIExv ZyBEaXJlY3RvcnkgVmVyc2lvbiAxIFttdWx0aS1zZWN0b3IgbG9nIHN1cHBvcnRdCkFkZHJl c3MgICAgQWNjZXNzICBSL1cgICBTaXplICBEZXNjcmlwdGlvbgoweDAwICAgICAgIEdQTCxT TCAgUi9PICAgICAgMSAgTG9nIERpcmVjdG9yeQoweDAxICAgICAgICAgICBTTCAgUi9PICAg ICAgMSAgU3VtbWFyeSBTTUFSVCBlcnJvciBsb2cKMHgwMiAgICAgICAgICAgU0wgIFIvTyAg ICAgIDUgIENvbXByZWhlbnNpdmUgU01BUlQgZXJyb3IgbG9nCjB4MDMgICAgICAgR1BMICAg ICBSL08gICAgICA2ICBFeHQuIENvbXByZWhlbnNpdmUgU01BUlQgZXJyb3IgbG9nCjB4MDYg ICAgICAgICAgIFNMICBSL08gICAgICAxICBTTUFSVCBzZWxmLXRlc3QgbG9nCjB4MDcgICAg ICAgR1BMICAgICBSL08gICAgICAxICBFeHRlbmRlZCBzZWxmLXRlc3QgbG9nCjB4MDkgICAg ICAgICAgIFNMICBSL1cgICAgICAxICBTZWxlY3RpdmUgc2VsZi10ZXN0IGxvZwoweDEwICAg ICAgIEdQTCAgICAgUi9PICAgICAgMSAgTkNRIENvbW1hbmQgRXJyb3IgbG9nCjB4MTEgICAg ICAgR1BMICAgICBSL08gICAgICAxICBTQVRBIFBoeSBFdmVudCBDb3VudGVycwoweDgwLTB4 OWYgIEdQTCxTTCAgUi9XICAgICAxNiAgSG9zdCB2ZW5kb3Igc3BlY2lmaWMgbG9nCjB4YTAt MHhhNyAgR1BMLFNMICBWUyAgICAgIDE2ICBEZXZpY2UgdmVuZG9yIHNwZWNpZmljIGxvZwow eGE4LTB4YjUgIEdQTCxTTCAgVlMgICAgICAgMSAgRGV2aWNlIHZlbmRvciBzcGVjaWZpYyBs b2cKMHhiNiAgICAgICBHUEwgICAgIFZTICAgICAgIDEgIERldmljZSB2ZW5kb3Igc3BlY2lm aWMgbG9nCjB4YjcgICAgICAgR1BMLFNMICBWUyAgICAgICAxICBEZXZpY2UgdmVuZG9yIHNw ZWNpZmljIGxvZwoweGJkICAgICAgIEdQTCxTTCAgVlMgICAgICAgMSAgRGV2aWNlIHZlbmRv ciBzcGVjaWZpYyBsb2cKMHhjMCAgICAgICBHUEwsU0wgIFZTICAgICAgIDEgIERldmljZSB2 ZW5kb3Igc3BlY2lmaWMgbG9nCjB4YzEgICAgICAgR1BMICAgICBWUyAgICAgIDI0ICBEZXZp Y2UgdmVuZG9yIHNwZWNpZmljIGxvZwoweGUwICAgICAgIEdQTCxTTCAgUi9XICAgICAgMSAg U0NUIENvbW1hbmQvU3RhdHVzCjB4ZTEgICAgICAgR1BMLFNMICBSL1cgICAgICAxICBTQ1Qg RGF0YSBUcmFuc2ZlcgoKU01BUlQgRXh0ZW5kZWQgQ29tcHJlaGVuc2l2ZSBFcnJvciBMb2cg VmVyc2lvbjogMSAoNiBzZWN0b3JzKQpObyBFcnJvcnMgTG9nZ2VkCgpTTUFSVCBFeHRlbmRl ZCBTZWxmLXRlc3QgTG9nIFZlcnNpb246IDEgKDEgc2VjdG9ycykKTm8gc2VsZi10ZXN0cyBo YXZlIGJlZW4gbG9nZ2VkLiAgW1RvIHJ1biBzZWxmLXRlc3RzLCB1c2U6IHNtYXJ0Y3RsIC10 XQoKU01BUlQgU2VsZWN0aXZlIHNlbGYtdGVzdCBsb2cgZGF0YSBzdHJ1Y3R1cmUgcmV2aXNp b24gbnVtYmVyIDEKIFNQQU4gIE1JTl9MQkEgIE1BWF9MQkEgIENVUlJFTlRfVEVTVF9TVEFU VVMKICAgIDEgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nCiAgICAyICAgICAgICAw ICAgICAgICAwICBOb3RfdGVzdGluZwogICAgMyAgICAgICAgMCAgICAgICAgMCAgTm90X3Rl c3RpbmcKICAgIDQgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nCiAgICA1ICAgICAg ICAwICAgICAgICAwICBOb3RfdGVzdGluZwpTZWxlY3RpdmUgc2VsZi10ZXN0IGZsYWdzICgw eDApOgogIEFmdGVyIHNjYW5uaW5nIHNlbGVjdGVkIHNwYW5zLCBkbyBOT1QgcmVhZC1zY2Fu IHJlbWFpbmRlciBvZiBkaXNrLgpJZiBTZWxlY3RpdmUgc2VsZi10ZXN0IGlzIHBlbmRpbmcg b24gcG93ZXItdXAsIHJlc3VtZSBhZnRlciAwIG1pbnV0ZSBkZWxheS4KClNDVCBTdGF0dXMg VmVyc2lvbjogICAgICAgICAgICAgICAgICAzClNDVCBWZXJzaW9uICh2ZW5kb3Igc3BlY2lm aWMpOiAgICAgICAyNTggKDB4MDEwMikKU0NUIFN1cHBvcnQgTGV2ZWw6ICAgICAgICAgICAg ICAgICAgIDEKRGV2aWNlIFN0YXRlOiAgICAgICAgICAgICAgICAgICAgICAgIEFjdGl2ZSAo MCkKQ3VycmVudCBUZW1wZXJhdHVyZTogICAgICAgICAgICAgICAgICAgIDQwIENlbHNpdXMK UG93ZXIgQ3ljbGUgTWluL01heCBUZW1wZXJhdHVyZTogICAgIDM5LzQxIENlbHNpdXMKTGlm ZXRpbWUgICAgTWluL01heCBUZW1wZXJhdHVyZTogICAgICAwLzY0IENlbHNpdXMKVW5kZXIv T3ZlciBUZW1wZXJhdHVyZSBMaW1pdCBDb3VudDogICAwLzAKClNDVCBUZW1wZXJhdHVyZSBI aXN0b3J5IFZlcnNpb246ICAgICAyClRlbXBlcmF0dXJlIFNhbXBsaW5nIFBlcmlvZDogICAg ICAgICAxIG1pbnV0ZQpUZW1wZXJhdHVyZSBMb2dnaW5nIEludGVydmFsOiAgICAgICAgMSBt aW51dGUKTWluL01heCByZWNvbW1lbmRlZCBUZW1wZXJhdHVyZTogICAgICAwLzYwIENlbHNp dXMKTWluL01heCBUZW1wZXJhdHVyZSBMaW1pdDogICAgICAgICAgIC00MS84NSBDZWxzaXVz ClRlbXBlcmF0dXJlIEhpc3RvcnkgU2l6ZSAoSW5kZXgpOiAgICA0NzggKDE3NCkKCgpEZXZp Y2UgU3RhdGlzdGljcyAoR1AgTG9nIDB4MDQpIG5vdCBzdXBwb3J0ZWQKClNBVEEgUGh5IEV2 ZW50IENvdW50ZXJzIChHUCBMb2cgMHgxMSkKSUQgICAgICBTaXplICAgICBWYWx1ZSAgRGVz Y3JpcHRpb24KMHgwMDAxICAyICAgICAgICAgICAgMCAgQ29tbWFuZCBmYWlsZWQgZHVlIHRv IElDUkMgZXJyb3IKMHgwMDAyICAyICAgICAgICAgICAgMCAgUl9FUlIgcmVzcG9uc2UgZm9y IGRhdGEgRklTCjB4MDAwMyAgMiAgICAgICAgICAgIDAgIFJfRVJSIHJlc3BvbnNlIGZvciBk ZXZpY2UtdG8taG9zdCBkYXRhIEZJUwoweDAwMDQgIDIgICAgICAgICAgICAwICBSX0VSUiBy ZXNwb25zZSBmb3IgaG9zdC10by1kZXZpY2UgZGF0YSBGSVMKMHgwMDA1ICAyICAgICAgICAg ICAgMCAgUl9FUlIgcmVzcG9uc2UgZm9yIG5vbi1kYXRhIEZJUwoweDAwMDYgIDIgICAgICAg ICAgICAwICBSX0VSUiByZXNwb25zZSBmb3IgZGV2aWNlLXRvLWhvc3Qgbm9uLWRhdGEgRklT CjB4MDAwNyAgMiAgICAgICAgICAgIDAgIFJfRVJSIHJlc3BvbnNlIGZvciBob3N0LXRvLWRl dmljZSBub24tZGF0YSBGSVMKMHgwMDA4ICAyICAgICAgICAgICAgMCAgRGV2aWNlLXRvLWhv c3Qgbm9uLWRhdGEgRklTIHJldHJpZXMKMHgwMDA5ICAyICAgICAgICAgICAxMSAgVHJhbnNp dGlvbiBmcm9tIGRyaXZlIFBoeVJkeSB0byBkcml2ZSBQaHlOUmR5CjB4MDAwYSAgMiAgICAg ICAgICAgIDAgIERldmljZS10by1ob3N0IHJlZ2lzdGVyIEZJU2VzIHNlbnQgZHVlIHRvIGEg Q09NUkVTRVQKMHgwMDBiICAyICAgICAgICAgICAgMCAgQ1JDIGVycm9ycyB3aXRoaW4gaG9z dC10by1kZXZpY2UgRklTCjB4MDAwZiAgMiAgICAgICAgICAgIDAgIFJfRVJSIHJlc3BvbnNl IGZvciBob3N0LXRvLWRldmljZSBkYXRhIEZJUywgQ1JDCjB4MDAxMiAgMiAgICAgICAgICAg IDAgIFJfRVJSIHJlc3BvbnNlIGZvciBob3N0LXRvLWRldmljZSBub24tZGF0YSBGSVMsIENS QwoweDgwMDAgIDQgICAgICAgICAyOTg1ICBWZW5kb3Igc3BlY2lmaWMKCgpDb3B5cmlnaHQg KGMpIDE5OTItMjAxNCBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5Nzks IDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQK ICAgICAgICBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBB bGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsg b2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMC4xLVBSRVJFTEVBU0UgIzQg cjI3MDc0NzogVGh1IEF1ZyAyOCAwODo1NDo0NSBFRFQgMjAxNAogICAgbWR0YW5jc2FAYmFj a3VwMy5zZW50ZXguY2E6L2Nyb3NzYnVpbGRzL29iai8xMC9jcm9zc2J1aWxkcy9zcmMvMTAv c3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDMuNC4xICh0YWdzL1JF TEVBU0VfMzQvZG90MS1maW5hbCAyMDgwMzIpIDIwMTQwNTEyCkNQVTogSW50ZWwoUikgQ29y ZShUTSkgaTUgQ1BVICAgICAgICAgNjYwICBAIDMuMzNHSHogKDMzMzMuMzYtTUh6IEs4LWNs YXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDIwNjUyICBGYW1p bHkgPSAweDYgIE1vZGVsID0gMHgyNSAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHhiZmVi ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIs UEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxT U0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4Mjk4ZTNmZjxTU0UzLFBDTE1VTFFE USxEVEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBE Q00sU1NFNC4xLFNTRTQuMixQT1BDTlQsQUVTTkk+CiAgQU1EIEZlYXR1cmVzPTB4MjgxMDA4 MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBW VC14OiAoZGlzYWJsZWQgaW4gQklPUykgUEFULEhMVCxNVEYsUEFVU0UsRVBULFVHLFZQSUQK ICBUU0M6IFAtc3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCnJlYWwg bWVtb3J5ICA9IDEyODg0OTAxODg4ICgxMjI4OCBNQikKYXZhaWwgbWVtb3J5ID0gMTIzNzM5 NjY4NDggKDExODAwIE1CKQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAwCkFDUEkg QVBJQyBUYWJsZTogPElOVEVMICBTMzQyMEdQWD4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2Uocykg eCAyIGNvcmUocykgeCAyIFNNVCB0aHJlYWRzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAog Y3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElEOiAgNAogY3B1MyAo QVApOiBBUElDIElEOiAgNQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1v dGhlcmJvYXJkCmxhcGljMDogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRyaWdnZXIKa2JkMSBh dCBrYmRtdXgwCnJhbmRvbTogPFNvZnR3YXJlLCBZYXJyb3c+IGluaXRpYWxpemVkCmFjcGkw OiA8SU5URUwgUzM0MjBHUFg+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24g KGZpeGVkKQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24g YWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSwweDc0LTB4 NzcgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6 IHF1YWxpdHkgMAphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4 NTMgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDEwMApocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21l bSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZy ZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MApFdmVudCB0aW1lciAiSFBFVCIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNTUwCkV2ZW50IHRpbWVyICJIUEVUMSIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUMiIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUMyIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwCkV2ZW50IHRpbWVyICJIUEVUNCIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwClRpbWVjb3VudGVyICJBQ1BJLWZhc3Qi IGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFjcGlfdGltZXIwOiA8MjQtYml0 IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCnBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBw Y2kxCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDIuMCBvbiBwY2kyCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIzCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMuMCBvbiBw Y2kyCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2k0CnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI1CnNpaXMwOiA8U2lJMzEyNCBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHgzMDAwLTB4 MzAwZiBtZW0gMHhiNDQwODAwMC0weGI0NDA4MDdmLDB4YjQ0MDAwMDAtMHhiNDQwN2ZmZiBp cnEgMTkgYXQgZGV2aWNlIDAuMCBvbiBwY2k1CnNpaXNjaDA6IDxTSUlTIGNoYW5uZWw+IGF0 IGNoYW5uZWwgMCBvbiBzaWlzMApzaWlzY2gxOiA8U0lJUyBjaGFubmVsPiBhdCBjaGFubmVs IDEgb24gc2lpczAKc2lpc2NoMjogPFNJSVMgY2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIHNp aXMwCnNpaXNjaDM6IDxTSUlTIGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBzaWlzMApwY2li NjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpMgpwY2k2OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpiZ2UwOiA8SFBRIDEwLzEwMC8xMDAwIENvcHBlciBC YXNlZCBHaWdhYml0IEFkYXB0ZXIsIEFTSUMgcmV2LiAweDAwNDAwMT4gbWVtIDB4YjQzMDAw MDAtMHhiNDMwZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k2CmJnZTA6IENISVAg SUQgMHgwMDAwNDAwMTsgQVNJQyBSRVYgMHgwNDsgQ0hJUCBSRVYgMHg0MDsgUENJLUUKbWlp YnVzMDogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MDogPEJDTTU3NTAgMTAwMEJBU0UtVCBt ZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5MDogIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJh c2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIsIGF1dG8s IGF1dG8tZmxvdwpiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMDoxODoxNDoyNzpkNQpw Y2liNzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgNi4wIG9uIHBj aTAKcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpYjg6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTcKcGNpODogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjgKYXJjbXNyMDogPEFyZWNhIFNBVEEgM0cgSG9zdCBBZGFwdGVyIFJBSUQgQ29udHJv bGxlciAKYXJjbXNyIHZlcnNpb24gMS4yMC4wMC4yOCAyMDEzLTA5LTEzCj4gbWVtIDB4YjQy MDAwMDAtMHhiNDIwMGZmZiwweGIzYzAwMDAwLTB4YjNmZmZmZmYgaXJxIDE4IGF0IGRldmlj ZSAxNC4wIG9uIHBjaTgKQXJlY2EgUkFJRCBhZGFwdGVyMDogQVJDLTEyMTAgRi9XIHZlcnNp b24gVjEuNDkgMjAxMC0xMi0wMiAKcGNpYjk6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMC4yIG9uIHBjaTcKcGNpOTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjkKZW0wOiA8 SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDcuNC4yPiBwb3J0IDB4NDA0 MC0weDQwNWYgbWVtIDB4YjQ1MDAwMDAtMHhiNDUxZmZmZiwweGI0NTI1MDAwLTB4YjQ1MjVm ZmYgaXJxIDE2IGF0IGRldmljZSAyNS4wIG9uIHBjaTAKZW0wOiBVc2luZyBhbiBNU0kgaW50 ZXJydXB0CmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTU6MTc6ZWQ6Njg6YTUKZWhjaTA6 IDxJbnRlbCBQQ0ggVVNCIDIuMCBjb250cm9sbGVyIFVTQi1CPiBtZW0gMHhiNDUyMjAwMC0w eGI0NTIyM2ZmIGlycSAyMSBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVzYnVzMDogRUhDSSB2 ZXJzaW9uIDEuMAp1c2J1czAgb24gZWhjaTAKcGNpYjEwOiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gaXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpMTA6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIxMApwY2liMTE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2 aWNlIDI4LjQgb24gcGNpMApwY2kxMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjExCmVtMTog PEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA3LjQuMj4gcG9ydCAweDIw MDAtMHgyMDFmIG1lbSAweGI0MTAwMDAwLTB4YjQxMWZmZmYsMHhiNDEyMDAwMC0weGI0MTIz ZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTExCmVtMTogVXNpbmcgYW4gTVNJIGlu dGVycnVwdAplbTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE1OjE3OmVkOjY4OmE0CnBjaWIx MjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxOCBhdCBkZXZpY2UgMjguNiBvbiBwY2kw CnBjaTEyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTIKdmdhcGNpMDogPFZHQS1jb21wYXRp YmxlIGRpc3BsYXk+IG1lbSAweGIyMDAwMDAwLTB4YjJmZmZmZmYsMHhiMzgwMDAwMC0weGIz ODAzZmZmLDB4YjMwMDAwMDAtMHhiMzdmZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBw Y2kxMgp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQpwY2liMTM6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTkgYXQgZGV2aWNlIDI4Ljcgb24gcGNpMApwY2kxMzogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjEzCjN3YXJlIGRldmljZSBkcml2ZXIgZm9yIDkwMDAgc2VyaWVzIHN0 b3JhZ2UgY29udHJvbGxlcnMsIHZlcnNpb246IDMuODAuMDYuMDAzCnR3YTA6IDwzd2FyZSA5 MDAwIHNlcmllcyBTdG9yYWdlIENvbnRyb2xsZXI+IHBvcnQgMHgxMDAwLTB4MTBmZiBtZW0g MHhiMDAwMDAwMC0weGIxZmZmZmZmLDB4YjQwMDAwMDAtMHhiNDAwMGZmZiBpcnEgMTkgYXQg ZGV2aWNlIDAuMCBvbiBwY2kxMwp0d2EwOiBJTkZPOiAoMHgxNTogMHgxMzAwKTogQ29udHJv bGxlciBkZXRhaWxzOjogTW9kZWwgOTY1MFNFLTJMUCwgMiBwb3J0cywgRmlybXdhcmUgRkU5 WCA0LjEwLjAwLjAyMSwgQklPUyBCRTlYIDQuMDguMDAuMDAzCmVoY2kxOiA8SW50ZWwgUENI IFVTQiAyLjAgY29udHJvbGxlciBVU0ItQT4gbWVtIDB4YjQ1MjEwMDAtMHhiNDUyMTNmZiBp cnEgMjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjAK dXNidXMxIG9uIGVoY2kxCnBjaWIxNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzMC4wIG9uIHBjaTAKcGNpMTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxNAppc2FiMDog PFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVz PiBvbiBpc2FiMAphaGNpMDogPEludGVsIDUgU2VyaWVzLzM0MDAgU2VyaWVzIEFIQ0kgU0FU QSBjb250cm9sbGVyPiBwb3J0IDB4NDA2OC0weDQwNmYsMHg0MDc0LTB4NDA3NywweDQwNjAt MHg0MDY3LDB4NDA3MC0weDQwNzMsMHg0MDIwLTB4NDAzZiBtZW0gMHhiNDUyMDAwMC0weGI0 NTIwN2ZmIGlycSAxOCBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmFoY2kwOiBBSENJIHYxLjMw IHdpdGggNiAzR2JwcyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIG5vdCBzdXBwb3J0ZWQKYWhj aWNoMDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGFoY2kwCmFoY2ljaDE6IDxB SENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBhaGNpMAphaGNpY2gyOiA8QUhDSSBjaGFu bmVsPiBhdCBjaGFubmVsIDIgb24gYWhjaTAKYWhjaWNoMzogPEFIQ0kgY2hhbm5lbD4gYXQg Y2hhbm5lbCAzIG9uIGFoY2kwCmFoY2ljaDQ6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwg NCBvbiBhaGNpMAphaGNpY2g1OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDUgb24gYWhj aTAKYWNwaV9idXR0b24wOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMAp1YXJ0MDogPDE2NTUw IG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBh Y3BpMAp1YXJ0MDogY29uc29sZSAoMTE1MjAwLG4sOCwxKQp1YXJ0MTogPDE2NTUwIG9yIGNv bXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNwaTAKb3JtMDogPElTQSBP cHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmLDB4Y2IwMDAtMHhjZmZmZiww eGQwMDAwLTB4ZDFmZmYsMHhkMzgwMC0weGQ1N2ZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNv bnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29u c29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4 M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCnBwYzA6IGNhbm5vdCBy ZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmNvcmV0ZW1wMDogPENQVSBPbi1EaWUgVGhlcm1hbCBT ZW5zb3JzPiBvbiBjcHUwCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENv bnRyb2w+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+ IG9uIGNwdTAKY29yZXRlbXAxOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNw dTEKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1 MQpwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQpjb3Jl dGVtcDI6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Mgplc3QyOiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyCnA0dGNjMjogPENQ VSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUyCmNvcmV0ZW1wMzogPENQVSBP bi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUzCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0 ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTMKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBU aGVybWFsIENvbnRyb2w+IG9uIGNwdTMKKG5vcGVyaXBoOnNpaXNjaDE6MDotMTpmZmZmZmZm Zik6IHJlc2NhbiBhbHJlYWR5IHF1ZXVlZAoobm9wZXJpcGg6c2lpc2NoMzowOi0xOmZmZmZm ZmZmKTogcmVzY2FuIGFscmVhZHkgcXVldWVkClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEu MDAwIG1zZWMKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KdXNidXMwOiA0ODBNYnBzIEhp Z2ggU3BlZWQgVVNCIHYyLjAKdXNidXMxOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAK dWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBFSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6 IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3Mg OS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQpwbXAwIGF0IHNpaXNjaDEg YnVzIDAgc2NidXMxIHRhcmdldCAxNSBsdW4gMApwbXAwOiA8UG9ydCBNdWx0aXBsaWVyIDM4 MjYxMDk1IDE3MDY+IEFUQS0wIGRldmljZQpwbXAwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMg KFNBVEEgMi54LCBOT05FLCBQSU8gODE5MmJ5dGVzKQpwbXAxIGF0IHNpaXNjaDMgYnVzIDAg c2NidXMzIHRhcmdldCAxNSBsdW4gMApwbXAxOiA8UG9ydCBNdWx0aXBsaWVyIDM3MjYxMDk1 IDE3MDY+IEFUQS0wIGRldmljZQpwbXAxOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBOT05FLCBQSU8gODE5MmJ5dGVzKQpwbXAwOiA1IGZhbi1vdXQgcG9ydHMKcG1wMTog NSBmYW4tb3V0IHBvcnRzCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK dWdlbjAuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMAp1aHViMjogPHZlbmRvciAweDgw ODcgcHJvZHVjdCAweDAwMjAsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRkciAyPiBv biB1c2J1czAKdWdlbjEuMjogPHZlbmRvciAweDgwODc+IGF0IHVzYnVzMQp1aHViMzogPHZl bmRvciAweDgwODcgcHJvZHVjdCAweDAwMjAsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwg YWRkciAyPiBvbiB1c2J1czEKZGEwIGF0IGFyY21zcjAgYnVzIDAgc2NidXM0IHRhcmdldCAw IGx1biAwCmRhMDogPEFyZWNhIHVzcnZhciBSMDAxPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktNSBkZXZpY2UgCmRhMDogU2VyaWFsIE51bWJlciAwMDAwMDAyOTkyMzI2MzA0CmRhMDog MjUwLjAwME1CL3MgdHJhbnNmZXJzICgxMjUuMDAwTUh6IERULCBvZmZzZXQgMzIsIDE2Yml0 KQpkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTA6IDc2MjkzTUIgKDE1NjI0OTYw MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDk3MjZDKQpkYTEgYXQgYXJjbXNyMCBi dXMgMCBzY2J1czQgdGFyZ2V0IDAgbHVuIDEKZGExOiA8QXJlY2EgYmFja3VwMSBSMDAxPiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMTogU2VyaWFsIE51bWJlciAw MDAwMDAyNjgwNDkyMDIzCmRhMTogMjUwLjAwME1CL3MgdHJhbnNmZXJzICgxMjUuMDAwTUh6 IERULCBvZmZzZXQgMzIsIDE2Yml0KQpkYTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApk YTE6IDI3ODQ3MjhNQiAoNTcwMzEyMzQ1NiA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9U IDM1NTAwM0MpCmRhMiBhdCB0d2EwIGJ1cyAwIHNjYnVzNSB0YXJnZXQgMCBsdW4gMApkYTI6 IDxBTUNDIDk2NTBTRS0yTFAgRElTSyA0LjEwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0kt NSBkZXZpY2UgCmRhMjogU2VyaWFsIE51bWJlciBTMTA1MTgyMDE1RDQ4NDAwQzJCMgpkYTI6 IDEwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTI6IDY2NzQ3TUIgKDEzNjY5Nzg1NiA1MTIgYnl0 ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDg1MDlDKQphZGEwIGF0IHNpaXNjaDEgYnVzIDAgc2Ni dXMxIHRhcmdldCAwIGx1biAwCmFkYTA6IDxXREMgV0QyMDAyRkFFWC0wMDdCQTAgMDUuMDFE MDU+IEFUQS04IFNBVEEgMi54IGRldmljZQphZGEwOiBTZXJpYWwgTnVtYmVyIFdELVdNQVkw MzUxMzYzNAphZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwg UElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDE5 MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODND KQphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDYKYWRhMSBhdCBzaWlzY2gxIGJ1 cyAwIHNjYnVzMSB0YXJnZXQgMSBsdW4gMAphZGExOiA8V0RDIFdEMjAwMkZBRVgtMDA3QkEw IDA1LjAxRDA1PiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRhMTogU2VyaWFsIE51bWJlciBX RC1XTUFZMDM0NTU3MjUKYWRhMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwg VURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAph ZGExOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9U IDE2MzgzQykKYWRhMTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ3CmFkYTIgYXQgc2lp c2NoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDIgbHVuIDAKYWRhMjogPFdEQyBXRDIwMDJGQUVY LTAwN0JBMCAwNS4wMUQwNT4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTI6IFNlcmlhbCBO dW1iZXIgV0QtV01BWTAyNzU5MTIwCmFkYTI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FU QSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEyOiBDb21tYW5kIFF1ZXVlaW5nIGVu YWJsZWQKYWRhMjogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2 SCA2M1MvVCAxNjM4M0MpCmFkYTMgYXQgc2lpc2NoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDMg bHVuIDAKYWRhMzogPFdEQyBXRDIwMDJGQUVYLTAwTUpSQTAgMDEuMDFMMDE+IEFUQS04IFNB VEEgMy54IGRldmljZQphZGEzOiBTZXJpYWwgTnVtYmVyIFdELVdDQzFQMTAyMzM1NQphZGEz OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRl cykKYWRhMzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTM6IDE5MDc3MjlNQiAoMzkw NzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGE0IGF0IHNp aXNjaDMgYnVzIDAgc2NidXMzIHRhcmdldCAwIGx1biAwCmFkYTQ6IDxXREMgV0QyMDAyRkFF WC0wMDdCQTAgMDUuMDFEMDU+IEFUQS04IFNBVEEgMy54IGRldmljZQphZGE0OiBTZXJpYWwg TnVtYmVyIFdELVdNQVdQMDA3OTI5MwphZGE0OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNB VEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhNDogQ29tbWFuZCBRdWV1ZWluZyBl bmFibGVkCmFkYTQ6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAx NkggNjNTL1QgMTYzODNDKQphZGE0OiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDEwCmFk YTUgYXQgc2lpc2NoMyBidXMgMCBzY2J1czMgdGFyZ2V0IDEgbHVuIDAKYWRhNTogPFdEQyBX RDIwMDJGQUVYLTAwN0JBMCAwNS4wMUQwNT4gQVRBLTggU0FUQSAzLnggZGV2aWNlCmFkYTU6 IFNlcmlhbCBOdW1iZXIgV0QtV01BWTAzNTEwMzExCmFkYTU6IDMwMC4wMDBNQi9zIHRyYW5z ZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGE1OiBDb21tYW5kIFF1 ZXVlaW5nIGVuYWJsZWQKYWRhNTogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNl Y3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTU6IFByZXZpb3VzbHkgd2FzIGtub3duIGFz IGFkMTEKYWRhNiBhdCBzaWlzY2gzIGJ1cyAwIHNjYnVzMyB0YXJnZXQgMyBsdW4gMAphZGE2 OiA8V0RDIFdEMjAwMkZBRVgtMDA3QkEwIDA1LjAxRDA1PiBBVEEtOCBTQVRBIDMueCBkZXZp Y2UKYWRhNjogU2VyaWFsIE51bWJlciBXRC1XTUFXUDAyMDM3NzQKYWRhNjogMzAwLjAwME1C L3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTY6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE2OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEy IGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhNyBhdCBzaWlzY2gzIGJ1cyAw IHNjYnVzMyB0YXJnZXQgNCBsdW4gMAphZGE3OiA8V0RDIFdEMjAwMkZBRVgtMDA3QkEwIDA1 LjAxRDA1PiBBVEEtOCBTQVRBIDMueCBkZXZpY2UKYWRhNzogU2VyaWFsIE51bWJlciBXRC1X TUFXUDAxMjYwOTMKYWRhNzogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURN QTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTc6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE3 OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2 MzgzQykKYWRhOCBhdCBhaGNpY2gwIGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4gMAphZGE4 OiA8V0RDIFdEMTAwMkZBRVgtMDBZOUEwIDA1LjAxRDA1PiBBVEEtOCBTQVRBIDMueCBkZXZp Y2UKYWRhODogU2VyaWFsIE51bWJlciBXRC1XQ0FXMzQyNjU5NzMKYWRhODogMzAwLjAwME1C L3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTg6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE4OiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIg Ynl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGE4OiBQcmV2aW91c2x5IHdhcyBr bm93biBhcyBhZDEyCmFkYTkgYXQgYWhjaWNoMSBidXMgMCBzY2J1czcgdGFyZ2V0IDAgbHVu IDAKYWRhOTogPFdEQyBXRDEwMDJGQUVYLTAwWTlBMCAwNS4wMUQwNT4gQVRBLTggU0FUQSAz LnggZGV2aWNlCmFkYTk6IFNlcmlhbCBOdW1iZXIgV0QtV0NBVzMyMjc2NjkyCmFkYTk6IDMw MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQph ZGE5OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhOTogOTUzODY5TUIgKDE5NTM1MjUx NjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhOTogUHJldmlvdXNs eSB3YXMga25vd24gYXMgYWQxNAphZGExMCBhdCBhaGNpY2gyIGJ1cyAwIHNjYnVzOCB0YXJn ZXQgMCBsdW4gMAphZGExMDogPFNUMzEwMDAzNDBBUyBTRDFBPiBBVEEtOCBTQVRBIDIueCBk ZXZpY2UKYWRhMTA6IFNlcmlhbCBOdW1iZXIgOVFKMlRTM1MKYWRhMTA6IDMwMC4wMDBNQi9z IHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGExMDogQ29t bWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTEwOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIg Ynl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGExMDogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQxNgphZGExMSBhdCBhaGNpY2g1IGJ1cyAwIHNjYnVzMTEgdGFyZ2V0IDAg bHVuIDAKYWRhMTE6IDxXREMgV0QxMDAyRkFFWC0wMFozQTAgMDUuMDFEMDU+IEFUQS04IFNB VEEgMy54IGRldmljZQphZGExMTogU2VyaWFsIE51bWJlciBXRC1XQ0FUUjQ0MjczNDMKYWRh MTE6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5 dGVzKQphZGExMTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTExOiA5NTM4NjlNQiAo MTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGExMTog UHJldmlvdXNseSB3YXMga25vd24gYXMgYWQyMgpwYXNzMTIgYXQgYXJjbXNyMCBidXMgMCBz Y2J1czQgdGFyZ2V0IDE2IGx1biAwCnBhc3MxMjogPEFyZWNhIFJBSUQgY29udHJvbGxlciBS MDAxPiBGaXhlZCBQcm9jZXNzb3IgU0NTSS0wIGRldmljZSAKbGFwaWMxOiBGb3JjaW5nIExJ TlQxIHRvIGVkZ2UgdHJpZ2dlcgpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKbGFwaWM1OiBG b3JjaW5nIExJTlQxIHRvIGVkZ2UgdHJpZ2dlcgpTTVA6IEFQIENQVSAjMyBMYXVuY2hlZCEK bGFwaWM0OiBGb3JjaW5nIExJTlQxIHRvIGVkZ2UgdHJpZ2dlcgpTTVA6IEFQIENQVSAjMiBM YXVuY2hlZCEKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxNjY2NjgwMjYyIEh6 IHF1YWxpdHkgMTAwMAp1aHViMjogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVn ZW4xLjM6IDxBbWVyaWNhbiBNZWdhdHJlbmRzIEluYy4+IGF0IHVzYnVzMQp1a2JkMDogPEtl eWJvYXJkIEludGVyZmFjZT4gb24gdXNidXMxCmtiZDAgYXQgdWtiZDAKdWdlbjAuMzogPEFt ZXJpY2FuIFBvd2VyIENvbnZlcnNpb24+IGF0IHVzYnVzMApSb290IG1vdW50IHdhaXRpbmcg Zm9yOiB1c2J1czEgdXNidXMwCnVnZW4xLjQ6IDxVU0I+IGF0IHVzYnVzMQp1a2JkMjogPFVT QiBVU0IgS2V5a29hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMS4xMCwgYWRkciA0PiBvbiB1 c2J1czEKa2JkMiBhdCB1a2JkMgp1Z2VuMC40OiA8QW1lcmljYW4gUG93ZXIgQ29udmVyc2lv bj4gYXQgdXNidXMwClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMApUcnlpbmcgdG8g bW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2RhMnMxYSBbcnddLi4uCnBtcDIgYXQgc2lpc2No MCBidXMgMCBzY2J1czAgdGFyZ2V0IDE1IGx1biAwCnBtcDI6IDxQb3J0IE11bHRpcGxpZXIg NDcyNjEwOTUgMWYwNj4gQVRBLTAgZGV2aWNlCnBtcDI6IDMwMC4wMDBNQi9zIHRyYW5zZmVy cyAoU0FUQSAyLngsIE5PTkUsIFBJTyA4MTkyYnl0ZXMpCnBtcDI6IDUgZmFuLW91dCBwb3J0 cwpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uOiA1ClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbjog ZmVhdHVyZXMgc3VwcG9ydCAoNTAwMCkKYWRhMTIgYXQgc2lpc2NoMCBidXMgMCBzY2J1czAg dGFyZ2V0IDEgbHVuIDAKYWRhMTI6IDxXREMgV0QyMDAxRkFTUy0wMFUwQjAgMDEuMDAxMDE+ IEFUQS04IFNBVEEgMi54IGRldmljZQphZGExMjogU2VyaWFsIE51bWJlciBXRC1XTUFVUjAz Nzg1MDkKYWRhMTI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQ SU8gODE5MmJ5dGVzKQphZGExMjogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTEyOiAx OTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2Mzgz QykKYWRhMTI6IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkNQphZGExMyBhdCBzaWlzY2gw IGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGExMzogPFdEQyBXRDIwMDFGQVNTLTAw VTBCMCAwMS4wMDEwMT4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTEzOiBTZXJpYWwgTnVt YmVyIFdELVdNQVVSMDMzMTYwNQphZGExMzogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRB IDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTEzOiBDb21tYW5kIFF1ZXVlaW5nIGVu YWJsZWQKYWRhMTM6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAx NkggNjNTL1QgMTYzODNDKQphZGExMzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0CmFk YTE0IGF0IHNpaXNjaDAgYnVzIDAgc2NidXMwIHRhcmdldCAyIGx1biAwCmFkYTE0OiA8V0RD IFdEMjAwMUZBU1MtMDBVMEIwIDAxLjAwMTAxPiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRh MTQ6IFNlcmlhbCBOdW1iZXIgV0QtV01BVVIwMzI3Njk2CmFkYTE0OiAzMDAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMTQ6IENvbW1h bmQgUXVldWVpbmcgZW5hYmxlZAphZGExNDogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBi eXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTE1IGF0IHNpaXNjaDAgYnVzIDAg c2NidXMwIHRhcmdldCAzIGx1biAwCmFkYTE1OiA8V0RDIFdEMjAwMUZBU1MtMDBVMEIwIDAx LjAwMTAxPiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRhMTU6IFNlcmlhbCBOdW1iZXIgV0Qt V01BVVIwMzg3MjU5CmFkYTE1OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBV RE1BNiwgUElPIDgxOTJieXRlcykKYWRhMTU6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAph ZGExNTogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1Mv VCAxNjM4M0MpCnVtczA6IDxNb3VzZSBJbnRlcmZhY2U+IG9uIHVzYnVzMQp1bXMwOiAzIGJ1 dHRvbnMgYW5kIFtaXSBjb29yZGluYXRlcyBJRD0wCnVoaWQwOiA8VVNCIFVTQiBLZXlrb2Fy ZCwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjEwLCBhZGRyIDQ+IG9uIHVzYnVzMQplbTA6IGxp bmsgc3RhdGUgY2hhbmdlZCB0byBVUAplbTE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAoK IyBwY2ljb25mIC1sdmNiIHNpaXMwCnNpaXMwQHBjaTA6NTowOjA6ICAgICAgIGNsYXNzPTB4 MDEwNDAwIGNhcmQ9MHg3MTI0MTA5NSBjaGlwPTB4MzEyNDEwOTUgcmV2PTB4MDIgaGRyPTB4 MDAKICAgIHZlbmRvciAgICAgPSAnU2lsaWNvbiBJbWFnZSwgSW5jLicKICAgIGRldmljZSAg ICAgPSAnU2lJIDMxMjQgUENJLVggU2VyaWFsIEFUQSBDb250cm9sbGVyJwogICAgY2xhc3Mg ICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IFJBSUQKICAgIGJhciAgIFsx MF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhiNDQwODAwMCwgc2l6ZSAxMjgs IGVuYWJsZWQKICAgIGJhciAgIFsxOF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2Ug MHhiNDQwMDAwMCwgc2l6ZSAzMjc2OCwgZW5hYmxlZAogICAgYmFyICAgWzIwXSA9IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MzAwMCwgc2l6ZSAxNiwgZW5hYmxlZAogICAg Y2FwIDAxWzY0XSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVu dCBEMAogICAgY2FwIDA3WzQwXSA9IFBDSS1YIDY0LWJpdCBzdXBwb3J0cyAxMzNNSHosIDIw NDggYnVyc3QgcmVhZCwgMTIgc3BsaXQgdHJhbnNhY3Rpb25zCiAgICBjYXAgMDVbNTRdID0g TVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0IGVuYWJsZWQgd2l0aCAxIG1lc3NhZ2UK Cgo= --------------010301090204020805060905-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 20:38:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E427F189; Thu, 28 Aug 2014 20:38:32 +0000 (UTC) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "erg.verweg.com", Issuer "Verweg Dot Com CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 78EFA1D88; Thu, 28 Aug 2014 20:38:32 +0000 (UTC) Received: from [192.168.0.103] (a83-161-163-101.mobile.xs4all.nl [83.161.163.101]) (authenticated bits=0) by erg.verweg.com (8.14.9/8.14.9) with ESMTP id s7SKcQMP066274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Aug 2014 20:38:28 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host a83-161-163-101.mobile.xs4all.nl [83.161.163.101] claimed to be [192.168.0.103] From: Ruben van Staveren Content-Type: multipart/signed; boundary="Apple-Mail=_EBC2E949-C3FE-4B7A-A17D-3A411061B409"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <5E3A5BCA-B3CA-45BA-B067-D3C5A50F7D19@verweg.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mounting fdescfs in a nested/hierarchical jail? Date: Thu, 28 Aug 2014 22:38:20 +0200 References: <3CB0C5BC-3864-418E-A59F-467D39B7E1EA@verweg.com> <53F55F7E.4010309@gritton.org> <3D042FC9-7CD9-4842-8D18-8354F9E1BB80@verweg.com> To: "freebsd-stable@FreeBSD.org Stable" , freebsd-jail@freebsd.org In-Reply-To: <3D042FC9-7CD9-4842-8D18-8354F9E1BB80@verweg.com> X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (erg.verweg.com [94.142.245.8]); Thu, 28 Aug 2014 20:38:29 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:38:33 -0000 --Apple-Mail=_EBC2E949-C3FE-4B7A-A17D-3A411061B409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Aug 2014, at 20:04, Ruben van Staveren wrote: > Ok, I=92ve written a little patch for that. Seems to work on r268794 More complete patch filed as = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192951 Bash seems to be just happy about it (it requires fdescfs) and I see = little harm to have the knob there. it is still off by default. --Apple-Mail=_EBC2E949-C3FE-4B7A-A17D-3A411061B409 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP/kzwACgkQZ88+mcQxRw1JRgCfcdE/ZAAGSrccj35mFCggaZOA hNsAniRoGNyGCCgBjBTEt0oBwI2Sx1+L =24dP -----END PGP SIGNATURE----- --Apple-Mail=_EBC2E949-C3FE-4B7A-A17D-3A411061B409-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 21:50:13 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83FC3F23; Thu, 28 Aug 2014 21:50:13 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28E5C15AD; Thu, 28 Aug 2014 21:50:13 +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 s7SLo2mK069412; Thu, 28 Aug 2014 14:50:06 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408282150.s7SLo2mK069412@gw.catspoiler.org> Date: Thu, 28 Aug 2014 14:50:02 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: ian@FreeBSD.org In-Reply-To: <1409238596.1150.134.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:50:13 -0000 On 28 Aug, Ian Lepore wrote: > On Wed, 2014-08-27 at 18:45 -0700, Don Lewis wrote: >> I'm trying to create an 8.4-STABLE i386 poudriere jail on a host that is >> running 10.0-STABLE amd64. I'm running the following commmand: >> >> poudriere jail -c -j 84STABLEi386 -m svn -v stable/8 -a i386 -p default >> >> Unfortuantely, I'm getting stuck at this point: >> >> ===> gnu/usr.bin/gperf/doc (obj) >> /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc created for /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc >> rm -f .depend >> mkdep -f .depend -a -I/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/include -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /var/poudriere/jails/84STABLEi386/usr/s! r! > c/! >> gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc >> echo gperf: /usr/lib/libc.a /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend >> echo gperf: /usr/lib/libstdc++.a >> .depend >> ===> gnu/usr.bin/gperf/doc (depend) >> make: don't know how to make /usr/lib/libstdc++.a. Stop >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error >> *** [buildworld] Error code 2 >> 1 error >> ====>> Error: Failed to 'make buildworld' >> ====>> Error while creating jail, cleaning up. >> ====>> Removing 84STABLEi386 jail... done >> >> >> There's no /usr/lib/libstdc++.a on this machine because libstdc++ has >> been removed from /usr/src on FreeBSD 10. If I set WITH_GCC=yes in >> /etc/src.conf, I get /usr/bin/gcc, but no g++ or libstdc++. And why are >> gperf and groff bootstrap tools anyway??? >> > > Try adding WITH_GNUCXX. That worked, thanks! I missed that knob in src.conf(5). I'd also forgotten that the Makefile for libstdc++ lives over under src/gnu/lib. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 23:36:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25FC1F9A for ; Thu, 28 Aug 2014 23:36:43 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7CEC11D0 for ; Thu, 28 Aug 2014 23:36:42 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s7SNaZc0011302 for ; Thu, 28 Aug 2014 19:36:40 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53FFBD03.1040304@m5p.com> Date: Thu, 28 Aug 2014 19:36:35 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: OpenOffice 4 on 10-STABLE References: <53FF0F5B.6050300@m5p.com> <20140828122305.GB25916@satori.lan> In-Reply-To: <20140828122305.GB25916@satori.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 28 Aug 2014 19:36:41 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:36:43 -0000 On 08/28/14 08:23, Chris Nehren wrote: > On Thu, Aug 28, 2014 at 07:15:39 -0400, George Mitchell wrote: >> Is anyone able to get an editors/openoffice-5 compile to complete? Of >> late, something name unopkg.bin keeps getting a seg fault during the >> build process (but doesn't leave a core file). If I run it with no >> arguments under the base system gdb (after setting LD_LIBRARY_PATH to >> /usr/ports/editors/openoffice-4/work/aoo-4.1.0/main/solver/410/unxfbsdx.pro/lib) >> it crashes in getCascadeMapping in main/cppu/source/uno/cascade_mapping.cxx >> but according to gdb from ports, it crashes in >> _GLOBAL__sub_I_cascade_mapping.cxx(void). > > Any specific reason you're sticking with openoffice instead of > libreoffice? The latter is receiving far more developer > attention and is making greater strides in features. > Because I didn't know about libreoffice. Today I did compile it, though it pulled in 45 dependencies I wasn't using before. -- George From owner-freebsd-stable@FreeBSD.ORG Thu Aug 28 23:37:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB80C11D for ; Thu, 28 Aug 2014 23:37:52 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65D7B11FA for ; Thu, 28 Aug 2014 23:37:52 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s7SNbjAS011315 for ; Thu, 28 Aug 2014 19:37:50 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <53FFBD49.1080404@m5p.com> Date: Thu, 28 Aug 2014 19:37:45 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: OpenOffice 4 on 10-STABLE References: <201408281613.s7SGDNwp068879@gw.catspoiler.org> In-Reply-To: <201408281613.s7SGDNwp068879@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 28 Aug 2014 19:37:51 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:37:52 -0000 On 08/28/14 12:13, Don Lewis wrote: > On 28 Aug, George Mitchell wrote: >> Is anyone able to get an editors/openoffice-5 compile to complete? Of >> late, something name unopkg.bin keeps getting a seg fault during the >> build process (but doesn't leave a core file). If I run it with no >> arguments under the base system gdb (after setting LD_LIBRARY_PATH to >> /usr/ports/editors/openoffice-4/work/aoo-4.1.0/main/solver/410/unxfbsdx.pro/lib) >> it crashes in getCascadeMapping in main/cppu/source/uno/cascade_mapping.cxx >> but according to gdb from ports, it crashes in >> _GLOBAL__sub_I_cascade_mapping.cxx(void). > > Sounds like you are trying to build the r364119 version of the port. I > tracked down the build problem in that version to both libc++ and > libstdc++ getting linked in to the executables. Revision r366163 fixes > the problem, but you should probably upgrade to r366281, which is > OpenOffice 4.1.1. According to the release announcement, it has some > critical bug fixes, including some security fixes. > [...] Thanks; I will do this. -- George From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 00:43:01 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45014BAC for ; Fri, 29 Aug 2014 00:43:01 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27BCA1988 for ; Fri, 29 Aug 2014 00:43:00 +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 s7T0fbYQ069647; Thu, 28 Aug 2014 17:41:41 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408290041.s7T0fbYQ069647@gw.catspoiler.org> Date: Thu, 28 Aug 2014 17:41:37 -0700 (PDT) From: Don Lewis Subject: Re: OpenOffice 4 on 10-STABLE To: george+freebsd@m5p.com In-Reply-To: <53FFBD49.1080404@m5p.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 00:43:01 -0000 On 28 Aug, George Mitchell wrote: > On 08/28/14 12:13, Don Lewis wrote: >> On 28 Aug, George Mitchell wrote: >>> Is anyone able to get an editors/openoffice-5 compile to complete? Of >>> late, something name unopkg.bin keeps getting a seg fault during the >>> build process (but doesn't leave a core file). If I run it with no >>> arguments under the base system gdb (after setting LD_LIBRARY_PATH to >>> /usr/ports/editors/openoffice-4/work/aoo-4.1.0/main/solver/410/unxfbsdx.pro/lib) >>> it crashes in getCascadeMapping in main/cppu/source/uno/cascade_mapping.cxx >>> but according to gdb from ports, it crashes in >>> _GLOBAL__sub_I_cascade_mapping.cxx(void). >> >> Sounds like you are trying to build the r364119 version of the port. I >> tracked down the build problem in that version to both libc++ and >> libstdc++ getting linked in to the executables. Revision r366163 fixes >> the problem, but you should probably upgrade to r366281, which is >> OpenOffice 4.1.1. According to the release announcement, it has some >> critical bug fixes, including some security fixes. >> [...] > > Thanks; I will do this. -- George portsmon says that the new OpenOffice binary packages for FreeBSD 10 are available: The packages for other releases should be along shortly. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 01:22:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6900E342; Fri, 29 Aug 2014 01:22:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 58D0B1D05; Fri, 29 Aug 2014 01:22:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 82CB9309; Fri, 29 Aug 2014 01:22:54 +0000 (UTC) Date: Fri, 29 Aug 2014 01:22:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, gjb@FreeBSD.org Message-ID: <1932958741.15.1409275374484.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #688 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 01:22:54 -0000 See Changes: [gjb] Minor wording changes. Sponsored by: The FreeBSD Foundation [gjb] FDP style nits. Sponsored by: The FreeBSD Foundation [gjb] Minor rewording to a few sections. Sponsored by: The FreeBSD Foundation [gjb] We do not differentiate the SMP from GENERIC kernel anymore, so remove mention of it. Sponsored by: The FreeBSD Foundation [gjb] Use and in a few places where needed. Minor rewording to r264732 entry. Sponsored by: The FreeBSD Foundation ------------------------------------------ [...truncated 220867 lines...] --- cleandir_subdir_ksyms --- ===> ksyms (cleandir) --- cleandir_subdir_khelp --- --- _sub.cleandir --- ===> khelp/h_ertt (cleandir) --- cleandir_subdir_drm2 --- --- cleanobj --- ===> drm2/radeonkmsfw/VERDE_mc (cleandir) --- cleandir_subdir_krpc --- --- cleanobj --- --- cleandir_subdir_ksyms --- --- cleanobj --- --- cleandir_subdir_le --- --- cleandir_subdir_khelp --- --- cleanobj --- --- cleandir_subdir_le --- ===> le (cleandir) --- cleandir_subdir_lge --- ===> lge (cleandir) --- cleandir_subdir_libalias --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias (cleandir) --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_me (cleandir) --- cleandir_subdir_le --- --- cleanobj --- --- cleandir_subdir_libalias --- --- _sub.cleandir --- ===> libalias/libalias (cleandir) --- cleandir_subdir_lge --- --- cleanobj --- --- cleandir_subdir_libiconv --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_libiconv --- ===> libiconv (cleandir) --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_pfp (cleandir) --- cleandir_subdir_libmbpool --- ===> libmbpool (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_libiconv --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias/modules (cleandir) --- cleandir_subdir_drm2 --- ===> drm2/radeonkmsfw/VERDE_rlc (cleandir) --- cleandir_subdir_libmbpool --- --- cleanobj --- --- cleandir_subdir_libmchain --- ===> libmchain (cleandir) --- cleandir_subdir_lindev --- --- cleandir_subdir_drm2 --- --- cleanobj --- --- cleandir_subdir_lindev --- ===> lindev (cleandir) --- cleandir_subdir_libalias --- --- _sub.cleandir --- ===> libalias/modules/cuseeme (cleandir) --- cleandir_subdir_linprocfs --- ===> linprocfs (cleandir) --- cleandir_subdir_libmchain --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_lindev --- --- cleanobj --- --- cleandir_subdir_libalias --- ===> libalias/modules/dummy (cleandir) --- cleandir_subdir_linsysfs --- ===> linsysfs (cleandir) --- cleandir_subdir_linux --- --- cleandir_subdir_linprocfs --- --- cleanobj --- --- cleandir_subdir_linux --- ===> linux (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_linsysfs --- --- cleanobj --- --- cleandir_subdir_lmc --- --- cleandir_subdir_libalias --- ===> libalias/modules/ftp (cleandir) --- cleandir_subdir_lmc --- ===> lmc (cleandir) --- cleandir_subdir_linux --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_lpt --- ===> lpt (cleandir) --- cleandir_subdir_libalias --- ===> libalias/modules/irc (cleandir) --- cleandir_subdir_lmc --- --- cleanobj --- --- cleandir_subdir_mac_biba --- ===> mac_biba (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- ===> libalias/modules/nbt (cleandir) --- cleandir_subdir_mac_biba --- --- cleanobj --- --- cleandir_subdir_lpt --- --- cleanobj --- --- cleandir_subdir_mac_bsdextended --- ===> mac_bsdextended (cleandir) --- cleandir_subdir_mac_ifoff --- ===> mac_ifoff (cleandir) --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_lomac --- ===> mac_lomac (cleandir) --- cleandir_subdir_libalias --- ===> libalias/modules/pptp (cleandir) --- cleandir_subdir_mac_bsdextended --- --- cleanobj --- --- cleandir_subdir_mac_ifoff --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_lomac --- --- cleanobj --- --- cleandir_subdir_mac_mls --- --- cleandir_subdir_libalias --- ===> libalias/modules/skinny (cleandir) --- cleandir_subdir_mac_mls --- ===> mac_mls (cleandir) --- cleandir_subdir_mac_none --- ===> mac_none (cleandir) --- cleandir_subdir_mac_partition --- ===> mac_partition (cleandir) --- cleandir_subdir_mac_none --- --- cleanobj --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_mls --- --- cleanobj --- --- cleandir_subdir_mac_portacl --- --- cleandir_subdir_libalias --- ===> libalias/modules/smedia (cleandir) --- cleandir_subdir_mac_portacl --- ===> mac_portacl (cleandir) --- cleandir_subdir_mac_seeotheruids --- ===> mac_seeotheruids (cleandir) --- cleandir_subdir_mac_partition --- --- cleanobj --- --- cleandir_subdir_mac_stub --- --- cleandir_subdir_libalias --- --- cleanobj --- --- cleandir_subdir_mac_stub --- ===> mac_stub (cleandir) --- cleandir_subdir_mac_test --- ===> mac_test (cleandir) --- cleandir_subdir_mac_portacl --- --- cleanobj --- --- cleandir_subdir_mac_seeotheruids --- --- cleanobj --- --- cleandir_subdir_malo --- ===> malo (cleandir) --- cleandir_subdir_mac_stub --- --- cleanobj --- --- cleandir_subdir_mcd --- ===> mcd (cleandir) --- cleandir_subdir_md --- --- cleandir_subdir_mac_test --- --- cleanobj --- --- cleandir_subdir_md --- ===> md (cleandir) --- cleandir_subdir_malo --- --- cleanobj --- --- cleandir_subdir_mem --- ===> mem (cleandir) --- cleandir_subdir_mcd --- --- cleanobj --- --- cleandir_subdir_mfi --- ===> mfi (cleandir) --- cleandir_subdir_md --- --- cleanobj --- --- cleandir_subdir_mii --- ===> mii (cleandir) --- cleandir_subdir_mem --- --- cleanobj --- --- cleandir_subdir_mlx --- ===> mlx (cleandir) --- cleandir_subdir_mfi --- --- cleanobj --- --- _sub.cleandir --- ===> mfi/mfip (cleandir) --- cleandir_subdir_mii --- --- cleanobj --- --- cleandir_subdir_mfi --- --- cleanobj --- --- cleandir_subdir_mlx --- --- cleanobj --- --- cleandir_subdir_mfi --- ===> mfi/mfi_linux (cleandir) --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[4]: stopped in --- cleandir_subdir_mlx --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [cleandir_subdir_mlx] Error code 2 make[3]: stopped in --- cleandir_subdir_mfi --- --- _sub.cleandir --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.cleandir] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in *** [cleandir_subdir_mfi] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [modules-cleandir] Error code 2 make[2]: stopped in /usr/obj 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 05:15:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 559B7A77; Fri, 29 Aug 2014 05:15:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 435961327; Fri, 29 Aug 2014 05:15:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 162CB372; Fri, 29 Aug 2014 05:15:41 +0000 (UTC) Date: Fri, 29 Aug 2014 05:15:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, gjb@FreeBSD.org, ngie@FreeBSD.org Message-ID: <1629513851.16.1409289340474.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1932958741.15.1409275374484.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1932958741.15.1409275374484.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #689 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 05:15:42 -0000 See From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 07:09:10 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E8E62C1; Fri, 29 Aug 2014 07:09:10 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C60C01E84; Fri, 29 Aug 2014 07:09:09 +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 s7T77kah070122; Fri, 29 Aug 2014 00:07:50 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408290707.s7T77kah070122@gw.catspoiler.org> Date: Fri, 29 Aug 2014 00:07:46 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: ian@FreeBSD.org In-Reply-To: <201408282150.s7SLo2mK069412@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 07:09:10 -0000 On 28 Aug, To: ian@freebsd.org wrote: > On 28 Aug, Ian Lepore wrote: >> On Wed, 2014-08-27 at 18:45 -0700, Don Lewis wrote: >>> I'm trying to create an 8.4-STABLE i386 poudriere jail on a host that is >>> running 10.0-STABLE amd64. I'm running the following commmand: >>> >>> poudriere jail -c -j 84STABLEi386 -m svn -v stable/8 -a i386 -p default >>> >>> Unfortuantely, I'm getting stuck at this point: >>> >>> ===> gnu/usr.bin/gperf/doc (obj) >>> /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc created for /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc >>> rm -f .depend >>> mkdep -f .depend -a -I/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/include -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /var/poudriere/jails/84STABLEi386/usr/! s! > r! >> c/! >>> gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc >>> echo gperf: /usr/lib/libc.a /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend >>> echo gperf: /usr/lib/libstdc++.a >> .depend >>> ===> gnu/usr.bin/gperf/doc (depend) >>> make: don't know how to make /usr/lib/libstdc++.a. Stop >>> *** Error code 2 >>> 1 error >>> *** Error code 2 >>> 1 error >>> *** [buildworld] Error code 2 >>> 1 error >>> ====>> Error: Failed to 'make buildworld' >>> ====>> Error while creating jail, cleaning up. >>> ====>> Removing 84STABLEi386 jail... done >>> >>> >>> There's no /usr/lib/libstdc++.a on this machine because libstdc++ has >>> been removed from /usr/src on FreeBSD 10. If I set WITH_GCC=yes in >>> /etc/src.conf, I get /usr/bin/gcc, but no g++ or libstdc++. And why are >>> gperf and groff bootstrap tools anyway??? >>> >> >> Try adding WITH_GNUCXX. > > That worked, thanks! Spoke too soon B-( ===> usr.sbin/wpa/hostapd_cli (depend) rm -f .depend mkdep -f .depend -a -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/! usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//hostapd/hostapd_cli.c /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/common/wpa_ctrl.c /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/utils/os_unix.c echo hostapd_cli: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/wpa/ndis_events (depend) rm -f .depend mkdep -f .depend -a -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/ndis_events.c echo ndis_events: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/lib/libc.a >> .depend 1 error *** Error code 2 1 error *** [buildworld] Error code 2 1 error ====>> Error: Failed to 'make buildworld' ====>> Error while creating jail, cleaning up. ====>> Removing 84STABLEi386 jail... done Nothing obvious went wrong. That last echo command succeeded: %cat /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/.depend # -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/ndis_events.c ndis_events.o: \ /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/ndis_events.c \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/cdefs.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/types.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/endian.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_types.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/_types.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_pthreadtypes.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/select.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_sigset.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_timeval.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/timespec.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/param.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_null.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/syslimits.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/signal.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/_limits.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/signal.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/trap.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/param.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/limits.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/socket.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_iovec.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/ioctl.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/ioccom.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/filio.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/sockio.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/ttycom.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/errno.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/sysctl.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/queue.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/if.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/time.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/time.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/if_dl.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/if_var.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/lock.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_lock.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/mutex.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_mutex.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/mutex.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/rwlock.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_rwlock.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/lock_profile.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/lockstat.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/sx.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_sx.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/event.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_task.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/altq/if_altq.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/netinet/in.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/netinet6/in6.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/arpa/inet.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/netdb.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/route.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/radix.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/stdio.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/string.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/strings.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/stdlib.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/unistd.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/unistd.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/err.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/syslog.h \ /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/stdarg.h ndis_events: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/lib/libc.a The next thing should have been "make depend" for ypbind. I actually see a correct looking .depend file there, but why wasn't that logged? All the rest rest of the yp* directories have valid-looking .depend files as well, as do zic/zdump and zic/zic. There's not a zzz/.depend file, though. Looks like this is optional, but spkrtest is under the same switch and I do see a .depend for that. Oh ... probably because zzz is a shell script. There's also a bunch of SUBDIR+='s, the last of which is pkg and I see a valid pkg/.depend. The stage 4.4 command that is supposed to be doing this stuff is: cd /var/poudriere/jails/84STABLEi386/usr/src; MAKEOBJDIRPREFIX=/usr/obj/i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 10.0-STABLE amd64 1000714" INSTALL="sh /var/poudriere/jails/84STABLEi386/usr/src/tools/install.sh" PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/sbin:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/bin:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/games:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/sbin:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/bin:/! usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/obj/var/poudriere/jails/84STABLEi386/usr/src/make.amd64/make -f Makefile.inc1 DESTDIR=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp par-depend If I try to run it manually, I don't even get this far: "/var/poudriere/jails/84STABLEi386/usr/src/Makefile.inc1", line 361: Malformed conditional (${MK_BIND_LIBS} != "no") "/var/poudriere/jails/84STABLEi386/usr/src/Makefile.inc1", line 364: if-less endif make: fatal errors encountered -- cannot continue From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 10:26:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00B03BC6 for ; Fri, 29 Aug 2014 10:26:24 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D234917A4 for ; Fri, 29 Aug 2014 10:26:24 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XNJ65-0005Ny-MF for freebsd-stable@freebsd.org; Fri, 29 Aug 2014 03:07:57 -0700 Date: Fri, 29 Aug 2014 03:07:57 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1409306877668-5943385.post@n5.nabble.com> In-Reply-To: <53FFBD03.1040304@m5p.com> References: <53FF0F5B.6050300@m5p.com> <20140828122305.GB25916@satori.lan> <53FFBD03.1040304@m5p.com> Subject: Re: OpenOffice 4 on 10-STABLE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 10:26:25 -0000 FWIW, the difference is due to LibreOffice port striving to use generic port dependencies, in spite of OpenOffice using their own versions shipped with it. -- View this message in context: http://freebsd.1045724.n5.nabble.com/OpenOffice-4-on-10-STABLE-tp5943103p5943385.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 13:19:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 792B2BE for ; Fri, 29 Aug 2014 13:19:00 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 307691BE1 for ; Fri, 29 Aug 2014 13:18:59 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XNM4s-00040V-Kz for freebsd-stable@freebsd.org; Fri, 29 Aug 2014 15:18:54 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Aug 2014 15:18:54 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Aug 2014 15:18:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Subject: Re: 10.0 interaction with vmware Date: Fri, 29 Aug 2014 15:18:32 +0200 Lines: 48 Message-ID: References: <20140826171657.0c79c54d@akips.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IkhK9Lp3McvEtADMp4GfS50OlBgBd06X5" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <20140826171657.0c79c54d@akips.com> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:19:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IkhK9Lp3McvEtADMp4GfS50OlBgBd06X5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 26/08/2014 09:16, Paul Koch wrote: > How does this work actually work ? Does it only take back what > FreeBSD considers to be "free" memory or can the host start taking > back "inactive", "wired", "zfs arc" memory ? We tend to rely on > stuff being in inactive and zfs arc. If we start swapping, we > are dead. Under memory pressure, VMWare's Balooning will cause internal FreeBSD's "memory low" triggers to fire, which will release ARC memory, which will probably degrade your performance. But from what I've seen, for some reason, it's pretty hard to actually see the VMWare host activate balooning, at least on FreeBSD servers. I've been using this combination for years and I only saw it once, for a trivial amount of memory. It's probably a last-resort measure. Also, VMWare will manage guest memory even without any guest software at all. It keeps track of recently active memory pages and may swap the unused ones out. FWIW, I think ZFS's crazy memory footprint makes it unsuitable for VMs (or actually most non-file-server workflows...), but I'm sure most people here will not agree with me :D If you have the opportunity to try it out in production, just run a regular UFS2+SU in your VM for a couple of days and see the difference. --IkhK9Lp3McvEtADMp4GfS50OlBgBd06X5 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 iKYEARECAGYFAlQAfbJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSzaIQCcDckkPKXpN1iAbWTiGdS612mb LtwAn0eeuMy0289AHgRXPMf6lCmVnA8p =UVu0 -----END PGP SIGNATURE----- --IkhK9Lp3McvEtADMp4GfS50OlBgBd06X5-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 17:07:09 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73285ACC; Fri, 29 Aug 2014 17:07:09 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E14221919; Fri, 29 Aug 2014 17:07:08 +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 s7TH6wTV072468; Fri, 29 Aug 2014 10:07:02 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408291707.s7TH6wTV072468@gw.catspoiler.org> Date: Fri, 29 Aug 2014 10:06:58 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: ian@FreeBSD.org In-Reply-To: <201408290707.s7T77kah070122@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:07:09 -0000 On 29 Aug, To: ian@freebsd.org wrote: > On 28 Aug, To: ian@freebsd.org wrote: >> On 28 Aug, Ian Lepore wrote: >>> On Wed, 2014-08-27 at 18:45 -0700, Don Lewis wrote: >>>> I'm trying to create an 8.4-STABLE i386 poudriere jail on a host that is >>>> running 10.0-STABLE amd64. I'm running the following commmand: >>>> >>>> poudriere jail -c -j 84STABLEi386 -m svn -v stable/8 -a i386 -p default >>>> >>>> Unfortuantely, I'm getting stuck at this point: >>>> >>>> ===> gnu/usr.bin/gperf/doc (obj) >>>> /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc created for /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/doc >>>> rm -f .depend >>>> mkdep -f .depend -a -I/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/include -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /var/poudriere/jails/84STABLEi386/usr! /! > s! >> r! >>> c/! >>>> gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc >>>> echo gperf: /usr/lib/libc.a /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend >>>> echo gperf: /usr/lib/libstdc++.a >> .depend >>>> ===> gnu/usr.bin/gperf/doc (depend) >>>> make: don't know how to make /usr/lib/libstdc++.a. Stop >>>> *** Error code 2 >>>> 1 error >>>> *** Error code 2 >>>> 1 error >>>> *** [buildworld] Error code 2 >>>> 1 error >>>> ====>> Error: Failed to 'make buildworld' >>>> ====>> Error while creating jail, cleaning up. >>>> ====>> Removing 84STABLEi386 jail... done >>>> >>>> >>>> There's no /usr/lib/libstdc++.a on this machine because libstdc++ has >>>> been removed from /usr/src on FreeBSD 10. If I set WITH_GCC=yes in >>>> /etc/src.conf, I get /usr/bin/gcc, but no g++ or libstdc++. And why are >>>> gperf and groff bootstrap tools anyway??? >>>> >>> >>> Try adding WITH_GNUCXX. >> >> That worked, thanks! > > Spoke too soon B-( > > ===> usr.sbin/wpa/hostapd_cli (depend) > rm -f .depend > mkdep -f .depend -a -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi38! 6/! > usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//hostapd/hostapd_cli.c /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/common/wpa_ctrl.c /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/hostapd_cli/../../../contrib/wpa//src/utils/os_unix.c > echo hostapd_cli: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/lib/libc.a >> .depend > ===> usr.sbin/wpa/ndis_events (depend) > rm -f .depend > mkdep -f .depend -a -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/ndis_events.c > echo ndis_events: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/lib/libc.a >> .depend > 1 error > *** Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > ====>> Error: Failed to 'make buildworld' > ====>> Error while creating jail, cleaning up. > ====>> Removing 84STABLEi386 jail... done > > > Nothing obvious went wrong. That last echo command succeeded: > > %cat /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/.depend > # -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/common -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/crypto -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/l2_packet -I/var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/ndis_events.c > ndis_events.o: \ > /var/poudriere/jails/84STABLEi386/usr/src/usr.sbin/wpa/ndis_events/ndis_events.c \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/cdefs.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/types.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/endian.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_types.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/_types.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_pthreadtypes.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/select.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_sigset.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_timeval.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/timespec.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/param.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_null.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/syslimits.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/signal.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/_limits.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/signal.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/trap.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/param.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/limits.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/socket.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_iovec.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/ioctl.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/ioccom.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/filio.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/sockio.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/ttycom.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/errno.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/sysctl.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/queue.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/if.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/time.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/time.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/if_dl.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/if_var.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/lock.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_lock.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/mutex.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_mutex.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/machine/mutex.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/rwlock.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_rwlock.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/lock_profile.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/lockstat.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/sx.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_sx.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/event.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/_task.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/altq/if_altq.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/netinet/in.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/netinet6/in6.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/arpa/inet.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/netdb.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/route.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/net/radix.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/stdio.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/string.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/strings.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/stdlib.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/unistd.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/sys/unistd.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/err.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/syslog.h \ > /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/include/stdarg.h > ndis_events: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/lib/libc.a > > > The next thing should have been "make depend" for ypbind. I actually > see a correct looking .depend file there, but why wasn't that logged? > All the rest rest of the yp* directories have valid-looking .depend > files as well, as do zic/zdump and zic/zic. There's not a zzz/.depend > file, though. Looks like this is optional, but spkrtest is under the > same switch and I do see a .depend for that. Oh ... probably because > zzz is a shell script. There's also a bunch of SUBDIR+='s, the last of > which is pkg and I see a valid pkg/.depend. > > The stage 4.4 command that is supposed to be doing this stuff is: > > cd /var/poudriere/jails/84STABLEi386/usr/src; MAKEOBJDIRPREFIX=/usr/obj/i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 10.0-STABLE amd64 1000714" INSTALL="sh /var/poudriere/jails/84STABLEi386/usr/src/tools/install.sh" PATH=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/sbin:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/bin:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/legacy/usr/games:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/sbin:/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/bin! :/! > usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/obj/var/poudriere/jails/84STABLEi386/usr/src/make.amd64/make -f Makefile.inc1 DESTDIR=/usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp par-depend > > If I try to run it manually, I don't even get this far: > > "/var/poudriere/jails/84STABLEi386/usr/src/Makefile.inc1", line 361: Malformed conditional (${MK_BIND_LIBS} != "no") > "/var/poudriere/jails/84STABLEi386/usr/src/Makefile.inc1", line 364: if-less endif > make: fatal errors encountered -- cannot continue If I add the -m option to the make command line to get the 8.4-STABLE versions of bsd.*.mk, then I see the actual error: patch -s -b .orig -o context.c < /var/poudriere/jails/84STABLEi386/usr/src/gnu/u sr.bin/diff/context.c.diff /var/poudriere/jails/84STABLEi386/usr/src/gnu/usr.bin /diff/../../../contrib/diff/src/context.c I can't seem to find a patch in there anywhere. *** Error code 2 1 error *** Error code 2 ===> kerberos5 (depend) I also see the same in the buildworld that poudriere does, but for some reason the "make depend" phase continues on much longer. I don't see any problem with the patch file. This appears to be an incompatibility between GNU patch and BSD patch. The -b option to GNU patch takes an argument that is interpreted as the extension for the backup file. The default is .orig, so why are we specifying it? The -b option to BSD patch does not take an argument, and tells patch to make a backup copy, and is also the default. Because -b does not take an argument, then the argument list parsing is getting messed up and patch probably thinks that one of the other arguments is the patch file instead of stdin. I removed the "-o .orig" arguments from the patch command in gnu/usr.bin/diff/Makefile and discovered that the same issue is present in for diff3 and sdiff. Fixing all of those allows me to get all the way through "make depend". Now how do I fix this for poudriere since it wants to do a clean checkout of src from svn every time I run it to create the jail? From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 17:14:19 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78C2DE57; Fri, 29 Aug 2014 17:14:18 +0000 (UTC) Date: Fri, 29 Aug 2014 13:14:13 -0400 From: Glen Barber To: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host Message-ID: <20140829171413.GJ1200@hub.FreeBSD.org> References: <201408290707.s7T77kah070122@gw.catspoiler.org> <201408291707.s7TH6wTV072468@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ev7mvGV+3JQuI2Eo" Content-Disposition: inline In-Reply-To: <201408291707.s7TH6wTV072468@gw.catspoiler.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:14:19 -0000 --ev7mvGV+3JQuI2Eo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2014 at 10:06:58AM -0700, Don Lewis wrote: > Now how do I fix this for poudriere since it wants to do a clean > checkout of src from svn every time I run it to create the jail? >=20 'poudriere jail' accepts a '-P ' flag, which will patch the src/ tree before the build. If you are able to generate a diff with your fix, you can drop that patch in the poudriere.d directory, and use 'poudriere jail -P ./my.diff [...]'. Glen --ev7mvGV+3JQuI2Eo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUALTlAAoJELls3eqvi17Qc5MP+wa8hD2psEWsYm4LlhDcT3YH ooUZcVCG4VhUKcDIRWCnbpezaZCSqj7tDHf7DY7Cr9jbm7WrJOBvbgFDpAJFtQaH oTWlPHJSVpP2N+bzTU1MLZFNX/qSSwQ5j3cFfTbXzuoFTlLAj1h/v5xAvD2Bnit4 tZZt74tC3tBttSv6JEpX4ZcW8R3TEzM6Y/IwjKCK3KX2Wp2DgvXHy8r2yncxL50O mjNPEypRRdf7JZVbMv1BGvznQaQvEK77tjUEgnT2goh+Ax+RFkVQSA/a3p2A8jgY 0aj7DkYnOpGzcLEhJQnCx2PlY0DA0oynH3MLFPq/Onpo/y35G+LKTNN8OC/BMJW+ bxDQMsWT5GrWpehozYIZCl3dk+dCwdkq1c64Qy92izjTbZx3d88R9N8jTywoB+6O z0WpQPiBRPUrkBcGYiw7T69dnDtk5R7SE6etwuxjTLAhhAX2NHnhU+fULifKfQCj WODeNqW26+PYnEGQ8R3bDpjdHhNh31WDEfGqsjrcK749aQY35XJyl5pOOaj6l/Fi vxl2Q8Wg6XLv/UBfnqtJx/PWaP8gTX5NBhCP4qhFTuc2J+QdeTH8XatfMtoQkb3t RKRhCZQ/NWGja0D/OlL+MbFPx30UFIYkFOZgrTBrVHLAgnnxNg/hJLW29Zfd7VdN 93hjNHEo054EtNJSRTtn =OPRC -----END PGP SIGNATURE----- --ev7mvGV+3JQuI2Eo-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 18:16:44 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC7FF40A; Fri, 29 Aug 2014 18:16:44 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BC821198; Fri, 29 Aug 2014 18:16:42 +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 s7TIGQNn072878; Fri, 29 Aug 2014 11:16:30 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408291816.s7TIGQNn072878@gw.catspoiler.org> Date: Fri, 29 Aug 2014 11:16:26 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: gjb@FreeBSD.org In-Reply-To: <20140829171413.GJ1200@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:16:45 -0000 On 29 Aug, Glen Barber wrote: > On Fri, Aug 29, 2014 at 10:06:58AM -0700, Don Lewis wrote: >> Now how do I fix this for poudriere since it wants to do a clean >> checkout of src from svn every time I run it to create the jail? >> > > 'poudriere jail' accepts a '-P ' flag, which will patch the src/ > tree before the build. If you are able to generate a diff with your > fix, you can drop that patch in the poudriere.d directory, and use > 'poudriere jail -P ./my.diff [...]'. That option isn't documented in the man page, but it is mentioned in poudriere's usage message. When I tried it, ./my.diff seemed to be interpreted relative to my current directory. I got further ... cc -O2 -pipe -I/var/poudriere/jails/84STABLEi386/usr/src/sbin/hastctl/../hastd -DINET -DINET6 -DYY_NO_UNPUT -DHAVE_CRYPTO -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -Wno-format -c token.c cc1: warnings being treated as errors :753: warning: redundant redeclaration of 'yylex' /var/poudriere/jails/84STABLEi386/usr/src/sbin/hastctl/../hastd/hast.h:270: warning: previous declaration of 'yylex' was here ... adding to my patch. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 29 23:20:23 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8CA2A54; Fri, 29 Aug 2014 23:20:22 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C348418F9; Fri, 29 Aug 2014 23:20:22 +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 s7TNIjMI073287; Fri, 29 Aug 2014 16:18:49 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408292318.s7TNIjMI073287@gw.catspoiler.org> Date: Fri, 29 Aug 2014 16:18:45 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: gjb@FreeBSD.org In-Reply-To: <201408291816.s7TIGQNn072878@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 23:20:23 -0000 On 29 Aug, To: gjb@freebsd.org wrote: > On 29 Aug, Glen Barber wrote: >> On Fri, Aug 29, 2014 at 10:06:58AM -0700, Don Lewis wrote: >>> Now how do I fix this for poudriere since it wants to do a clean >>> checkout of src from svn every time I run it to create the jail? >>> >> >> 'poudriere jail' accepts a '-P ' flag, which will patch the src/ >> tree before the build. If you are able to generate a diff with your >> fix, you can drop that patch in the poudriere.d directory, and use >> 'poudriere jail -P ./my.diff [...]'. > > That option isn't documented in the man page, but it is mentioned in > poudriere's usage message. When I tried it, ./my.diff seemed to be > interpreted relative to my current directory. > > I got further ... > > cc -O2 -pipe -I/var/poudriere/jails/84STABLEi386/usr/src/sbin/hastctl/../hastd -DINET -DINET6 -DYY_NO_UNPUT -DHAVE_CRYPTO -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -Wno-format -c token.c > cc1: warnings being treated as errors > :753: warning: redundant redeclaration of 'yylex' > /var/poudriere/jails/84STABLEi386/usr/src/sbin/hastctl/../hastd/hast.h:270: warning: previous declaration of 'yylex' was here > > ... adding to my patch. With the patch below, I get further, but now lint is core getting SIGBUS. ===> usr.bin/xlint/llib (all) lint -cghapbx -Cposix /var/poudriere/jails/84STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix llib-lposix: lint: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/libexec/lint1 got signal 10 *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** [buildworld] Error code 2 1 error ====>> Error: Failed to 'make buildworld' This is the stack trace: # gdb /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/libexec/lint1 lint1.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `lint1'. Program terminated with signal 10, Bus error. #0 0x000000000040b061 in getcnode () (gdb) bt #0 0x000000000040b061 in getcnode () #1 0x0000000000401717 in yyparse () #2 0x0000000000406676 in main () Index: gnu/usr.bin/diff/Makefile =================================================================== --- gnu/usr.bin/diff/Makefile (revision 269955) +++ gnu/usr.bin/diff/Makefile (working copy) @@ -29,7 +29,7 @@ .for f in diff.c context.c ${f}: ${DIFFSRC}/${f} ${.CURDIR}/${f}.diff - patch -s -b .orig -o ${.TARGET} < ${.CURDIR}/${f}.diff ${DIFFSRC}/${f} + patch -s -o ${.TARGET} < ${.CURDIR}/${f}.diff ${DIFFSRC}/${f} CLEANFILES+= ${f} .endfor Index: gnu/usr.bin/diff3/Makefile =================================================================== --- gnu/usr.bin/diff3/Makefile (revision 269955) +++ gnu/usr.bin/diff3/Makefile (working copy) @@ -20,7 +20,7 @@ .for f in diff3.c ${f}: ${DIFFSRC}/${f} ${.CURDIR}/${f}.diff - patch -s -b .orig -o ${.TARGET} < ${.CURDIR}/${f}.diff ${DIFFSRC}/${f} + patch -s -o ${.TARGET} < ${.CURDIR}/${f}.diff ${DIFFSRC}/${f} CLEANFILES+= ${f} .endfor Index: gnu/usr.bin/sdiff/Makefile =================================================================== --- gnu/usr.bin/sdiff/Makefile (revision 269955) +++ gnu/usr.bin/sdiff/Makefile (working copy) @@ -21,7 +21,7 @@ .for f in sdiff.c ${f}: ${DIFFSRC}/${f} ${.CURDIR}/${f}.diff - patch -s -b .orig -o ${.TARGET} < ${.CURDIR}/${f}.diff ${DIFFSRC}/${f} + patch -s -o ${.TARGET} < ${.CURDIR}/${f}.diff ${DIFFSRC}/${f} CLEANFILES+= ${f} .endfor Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 269955) +++ Makefile.inc1 (working copy) @@ -948,7 +948,7 @@ _ar= usr.bin/ar .endif -.if ${BOOTSTRAPPING} < 802000 +.if ${BOOTSTRAPPING} < 802000 || ${BOOTSTRAPPING} > 1000032 _lex= usr.bin/lex .endif From owner-freebsd-stable@FreeBSD.ORG Sat Aug 30 00:43:30 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98E5185C; Sat, 30 Aug 2014 00:43:30 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26D831081; Sat, 30 Aug 2014 00:43:30 +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 s7U0hIXf073387; Fri, 29 Aug 2014 17:43:22 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408300043.s7U0hIXf073387@gw.catspoiler.org> Date: Fri, 29 Aug 2014 17:43:18 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: gjb@FreeBSD.org In-Reply-To: <201408292318.s7TNIjMI073287@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 00:43:30 -0000 On 29 Aug, Don Lewis wrote: > With the patch below, I get further, but now lint is core getting > SIGBUS. > > ===> usr.bin/xlint/llib (all) > lint -cghapbx -Cposix /var/poudriere/jails/84STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix > llib-lposix: > lint: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/libexec/lint1 got signal 10 > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > ====>> Error: Failed to 'make buildworld' I simplified things a bit and am now just doing normal crossbuilds. I'm still seeing core dumps, even on amd64 -> amd64 crossbuilds. I'm not seeing a reason, though ... # gdb /usr/obj/tmp/stable8/tmp/usr/libexec/lint1 /usr/obj/tmp/stable8/usr.bin/xlint/llib/lint1.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `lint1'. Program terminated with signal 10, Bus error. #0 0x000000000040b061 in getcnode (tp=0x800c1f400, v=0x800c08160) at /tmp/stable8/usr.bin/xlint/lint1/tree.c:260 260 n->tn_val->v_u = v->v_u; (gdb) list 255 n->tn_op = CON; 256 n->tn_type = tp; 257 n->tn_val = tgetblk(sizeof (val_t)); 258 n->tn_val->v_tspec = tp->t_tspec; 259 n->tn_val->v_ansiu = v->v_ansiu; 260 n->tn_val->v_u = v->v_u; 261 free(v); 262 return (n); 263 } 264 (gdb) print n $1 = (tnode_t *) 0x80068f000 (gdb) print v $2 = (val_t *) 0x800c08160 (gdb) print *n $3 = {tn_op = CON, tn_type = 0x800c1f400, tn_lvalue = 0, tn_cast = 0, tn_parn = 0, tn_u = {tn_s = {_tn_left = 0x80068f028, _tn_right = 0x0}, _tn_sym = 0x80068f028, _tn_val = 0x80068f028, _tn_strg = 0x80068f028}} (gdb) print *v $4 = {v_tspec = INT, v_ansiu = 0, v_u = {_v_quad = 128, _v_ldbl = 4.6658554008095674912363595950328574e-4949}} (gdb) print *n->tn_u._tn_val $5 = {v_tspec = INT, v_ansiu = 0, v_u = {_v_quad = 0, _v_ldbl = 0}} (gdb) print v->v_u $6 = {_v_quad = 128, _v_ldbl = 4.6658554008095674912363595950328574e-4949} (gdb) print n->tn_u._tn_val->v_u $7 = {_v_quad = 0, _v_ldbl = 0} Looks like all the pointers are OK, so why the SIGBUS? From owner-freebsd-stable@FreeBSD.ORG Sat Aug 30 02:43:01 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBD5F89D; Sat, 30 Aug 2014 02:43:00 +0000 (UTC) Date: Fri, 29 Aug 2014 22:42:55 -0400 From: Glen Barber To: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host Message-ID: <20140830024255.GL1200@hub.FreeBSD.org> References: <201408292318.s7TNIjMI073287@gw.catspoiler.org> <201408300043.s7U0hIXf073387@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ogUXNSQj4OI1q3LQ" Content-Disposition: inline In-Reply-To: <201408300043.s7U0hIXf073387@gw.catspoiler.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 02:43:01 -0000 --ogUXNSQj4OI1q3LQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2014 at 05:43:18PM -0700, Don Lewis wrote: > I simplified things a bit and am now just doing normal crossbuilds. I'm > still seeing core dumps, even on amd64 -> amd64 crossbuilds. I'm not > seeing a reason, though ... >=20 > [gdb backtrace] >=20 > [...] >=20 > Looks like all the pointers are OK, so why the SIGBUS? >=20 Pardon any incoherency in what follows, because it is mostly based off smashed-together recollection from a text file of notes with the 8.x (and prior) cross builds. The TL;DR is, there's probably not much information I can provide that will be useful to you in debugging this. Sorry. :( (And Warner, if you're listening, I know your stance on the topic, so no need to re-enlighten me.) :-) While it may sounds like I'm going in a different direction than what you're try to solve, there actually is a reason for it, and a possible solution for your case. The issues you are running into are 80% of the reason that after 8.4 was released, there were no 8.4-STABLE snapshots produced. The other 20% is split up with 10% because of how the release builds for 8.x and earlier work, and 10% because it was not reasonable to implement "special" code in the scripts I use for a single branch. If this was a few years ago, and 7.x (and possibly 6.x) was still supported, I may have considered it. That said, when I say "8.x" below, I really mean "8.x and prior branches." My primary issue with how the 8.x release builds worked is that it would use chroot(8) by default, specifically: 1) buildworld 2) installworld DESTDIR=3D/blah 3) chroot /blah make -C /usr/src buildworld buildkernel 4) chroot /blah make -C /usr/src/release release The 9.x and later release builds do not do this. You specify the target directory for the resulting build, and a bunch of magic happens, and when it's done, you have all the things to install FreeBSD. The major benefit to this is that it does *not* use chroot(8) by default. The 8.4-RELEASE was built on a machine running 9-STABLE, so make(1), gcc(1), and so on were not that far diverged for there to be any real issues (such as what you're seeing). The snapshot builder in use now, at that time was running 10-CURRENT. Several "hacks" were in place, such as WITH_GNUCXX (which somehow turned into 4 or more src.conf(5) entries by now), which would allow building 8.x on 10-CURRENT to somewhat work. That did not last long, though. I think it was around when bmake became the default in -CURRENT that I stopped spending time trying to build 8.x snapshots -- at that point, the time spent debugging the build failures and updating the scripts to "fix" the build became increasingly less beneficial. Now, having said all that, I have a possible solution that, quite honestly, may or may not work (I have no idea at this point). You can grab the 8.4-RELEASE distribution set from FTP, and extract it into a scratch directory, check out the stable/8/ tree into the scratch directory usr/src/, then do: # chroot /scratch make -C /usr/src buildworld [...] That would at least provide you with the binary bits you want for your package builds. I *think* this is somewhat what the cluster package builders do, but then again, I do not know off-hand if packages for 8.x are build for pkg(8) - they may be only pkg_install(1). Again, sorry that I do not provide a "just do $this" kind of magic wand in this case, especially since I've been in the same painful situation you are in. But I hope at least some of this information is useful to you. Glen --ogUXNSQj4OI1q3LQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUATovAAoJELls3eqvi17QOAwP/1Wr4+vVipyvs9Q5B4fHQtEc Ffw/uaQt31d9GW+WXyQLhr6r5kWE6iCEuVTwCMp1vSeBh4v7pwZFQlb/aUpDVJ59 zoci+0gsru2S88D/FuuAd3I6RNHerm/pfZ2DtoDUC4eUIXeUy4yWRqbPQFpcFz6y KSNYg2QeRsfg+YD9EKI8TmddY8Ijq7otJpvA0YRWXW3k9Yc241pFZAElQUqDntUT KMgD3MvpY8g8SVf05pMcnlvbolrzPzdwkHYdpvpxM9ITpD0dDIAqM683H9tYW4c9 nKxy7wqdzW3F2zfP+ywkhNucUlSZGX5qmPwCDva1IDZjdxa3ff+kesKfAGxNPh1a +XNwo8OQELvf8A2veouOUkXZj7+uxtkMMB1k5fqOYZqndXkl/rgvl2Bny9qqsjdq Q4b86kzF6Zl2lD6DuJDnZXGxPMFmfRRW/k2x528LLjcDaw9Mc0RSdvkYR4BFcUQS QYWD/UAsv7qFkQgsoK9L2Kd82pGNhAOoHjIaGFrh7WyKse+1whwPn88lfXh5wMv/ JHm7NgkwjPubEQbnyHnsVd7+jmSYkcnPlMMnQBdqLYzUj0lR+E2z/fnz4ISBNUBd 93voUZqE2tOHwCFTutBS+vAIdt9F79z0FYuzBS6qdD21rJBuO5DCPssWTlVUJH9v wsJkJ0xRQxz8xfuNdQJh =mQZS -----END PGP SIGNATURE----- --ogUXNSQj4OI1q3LQ-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 30 04:24:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1931C914; Sat, 30 Aug 2014 04:24:15 +0000 (UTC) Date: Sat, 30 Aug 2014 00:24:10 -0400 From: Glen Barber To: Mike Tancsa Subject: Re: controller errors from RELENG_9 to RELENG_10 upgrade Message-ID: <20140830042410.GN1200@hub.FreeBSD.org> References: <53FF7722.2010309@sentex.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EOHJn1TVIJfeVXv2" Content-Disposition: inline In-Reply-To: <53FF7722.2010309@sentex.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 04:24:16 -0000 --EOHJn1TVIJfeVXv2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 28, 2014 at 02:38:26PM -0400, Mike Tancsa wrote: > I upgraded one of our file servers to RELENG_10 this AM and noticed the b= ox > started throwing a lot of errors all of a sudden on different disks and p= ort > multipliers. The disks do not have any errors according to smartctl. Now > zfs detected write errors and forced a scrub on ada6 >=20 > Any idea how to track this down ? dmesg and the errors attached in the t= xt > file. >=20 > loader is simple and is the same from before. >=20 > hint.siis.0.msi=3D1 > siis.0.msi=3D1 > hw.em.enable_msix=3D0 >=20 I am suspicious of the CAM changes between stable/9 and stable/10. Did you rebuild all ports on this system after the upgrade? smartctl(8) reflects 10.1-PRERELEASE, so I am particularly curious of anything that uses hald(8) or dbus(8). Glen --EOHJn1TVIJfeVXv2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUAVHqAAoJELls3eqvi17QavsP/1cBB3WjFj6i/+AQUhwFPf9M x6ldJWiOLj/MTr4apsZBR18ov0GaeC3AxES/Y7oBJB+vENNg3GNOdKD/6XVq5Tkk PUqK557KAz3eGQkybRz/lqJVju5f64/FULhEyjcLwz0jWyag+9wazympbJmjQ1F3 exDATczpBqeY8oY5lk8aniGXPxvtZwX3ucgJvGFGuLqWE82BnUFTtDFTUYEQqQFw 5jw4kaz5HM4m0RW4UOj0860S6aid+NtDPzFmip3tHuTOmQPKst8FZJG8rGtfTeky dBZ5jwaqvMaONc+9UopuPY6E9n566Rw0tIb8OQgFwrw+iSCrTbGV89sn7lxMzHSl zWpbSbivFqW2Z4HmMo9HvGKj307qSfpLFKI4M7gFC2gX0J/La5wc/r/80rirw5BI MIDiLaium+j8nmx9PGaoJpDOunfOboeGGubVQUvjrhEEk8xFv7o0/H3+V4hgWkWC I1lViA9TScaFCQgHtBInYfdkqZtXPEIFRRCT1qfG37BKKclESyf1bGP2YLSNj6lK iLc7ZAH42VqX01Mddw96GZD9FcXJHuejluw8p2c2W4EMCrcuqBl2FErjSkl97JdV 7634nMNHc0noVVjxBrofPUuDMXH4NxjLFGSTJccnxqAFtLn+yhq6vWDptgLxPNUT 3SplF0H029Q0IRo4tW+d =XaHA -----END PGP SIGNATURE----- --EOHJn1TVIJfeVXv2-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 30 06:38:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D040BE7 for ; Sat, 30 Aug 2014 06:38:43 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D882612E6 for ; Sat, 30 Aug 2014 06:38:42 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q59so3082921wes.7 for ; Fri, 29 Aug 2014 23:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=96xqcIEkVuQ8HKBkDK1lVCrClN5S23G26602X2ghg54=; b=WAV7JQkR7W8SakJV44OuHtOrjHLRO+JItYmFT4HKzEkrZCECDzoOI2fSi3Ey1/tp5T BDyHj/fx9b9uoKp9x5Byqs2YPKLyjHGN1VevSy1QkyKYV/yLkvBZYaD1JXfsjEic4fe1 LBOpZe4pA0S/ikR60D1mwBgqOJhl+zLWHFX8lZKKTXNKTTZV6mIl7v/RWVD0tfS8kxRo bvZkd4djidAdiC4TII6DbTjxnWgX9CXYSsjnErlIr+h4TaavqBsEhICp4EVl2792XZyY R2mCZ1foPGkpKJ5pRT+nvyJEOC6kN4ELKL9IdocY4dT7HUBA3Gh46uQFlumPZW12OyR+ ubVA== X-Received: by 10.194.200.74 with SMTP id jq10mr164711wjc.110.1409380721132; Fri, 29 Aug 2014 23:38:41 -0700 (PDT) Received: from kontrol.kode5.net (host81-157-206-146.range81-157.btcentralplus.com. [81.157.206.146]) by mx.google.com with ESMTPSA id r19sm3971094wik.0.2014.08.29.23.38.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Aug 2014 23:38:40 -0700 (PDT) Message-ID: <5401716F.9030504@gmail.com> Date: Sat, 30 Aug 2014 07:38:39 +0100 From: Jamie Griffin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD Questions Subject: Re: Mod_Load_Init error (Vesa) References: <5400C42D.4030709@gmail.com> In-Reply-To: <5400C42D.4030709@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 06:38:43 -0000 On 29/08/2014 19:19, Jamie Griffin wrote: > I've seen the following in dmesg: > > module_register_init: MOD_LOAD (vesa, 0xffffffff80d69720, 0) error 19 > > and i'm wondering why this is happening. Having searched on Google, it > seems it may be due to my BIOS needing flashing. Is this correct? > > As i'm using FreeBSD 10-STABLE amd64, how would I do that? Is it a > case of booting a windows iso and doing it from that? Removing the options to load the vt console driver stops this, fyi. Posting to stable for information reasons. From owner-freebsd-stable@FreeBSD.ORG Sat Aug 30 07:20:58 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B25366F1; Sat, 30 Aug 2014 07:20:58 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57FFB17CA; Sat, 30 Aug 2014 07:20:58 +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 s7U7KkDk073975; Sat, 30 Aug 2014 00:20:50 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201408300720.s7U7KkDk073975@gw.catspoiler.org> Date: Sat, 30 Aug 2014 00:20:46 -0700 (PDT) From: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host To: gjb@FreeBSD.org In-Reply-To: <20140830024255.GL1200@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 07:20:58 -0000 On 29 Aug, Glen Barber wrote: > On Fri, Aug 29, 2014 at 05:43:18PM -0700, Don Lewis wrote: >> I simplified things a bit and am now just doing normal crossbuilds. I'm >> still seeing core dumps, even on amd64 -> amd64 crossbuilds. I'm not >> seeing a reason, though ... >> >> [gdb backtrace] >> >> [...] >> >> Looks like all the pointers are OK, so why the SIGBUS? >> > > Pardon any incoherency in what follows, because it is mostly based off > smashed-together recollection from a text file of notes with the 8.x > (and prior) cross builds. > > The TL;DR is, there's probably not much information I can provide that > will be useful to you in debugging this. Sorry. :( > > (And Warner, if you're listening, I know your stance on the topic, so > no need to re-enlighten me.) :-) > > While it may sounds like I'm going in a different direction than what > you're try to solve, there actually is a reason for it, and a possible > solution for your case. > > The issues you are running into are 80% of the reason that after 8.4 was > released, there were no 8.4-STABLE snapshots produced. The other 20% is > split up with 10% because of how the release builds for 8.x and earlier > work, and 10% because it was not reasonable to implement "special" code > in the scripts I use for a single branch. If this was a few years ago, > and 7.x (and possibly 6.x) was still supported, I may have considered > it. That said, when I say "8.x" below, I really mean "8.x and prior > branches." > > My primary issue with how the 8.x release builds worked is that it would > use chroot(8) by default, specifically: > > 1) buildworld > 2) installworld DESTDIR=/blah > 3) chroot /blah make -C /usr/src buildworld buildkernel > 4) chroot /blah make -C /usr/src/release release I did a lot of release builds in the days of 4.x and that sounds familiar ... > The 9.x and later release builds do not do this. You specify the target > directory for the resulting build, and a bunch of magic happens, and > when it's done, you have all the things to install FreeBSD. The major > benefit to this is that it does *not* use chroot(8) by default. > > The 8.4-RELEASE was built on a machine running 9-STABLE, so make(1), > gcc(1), and so on were not that far diverged for there to be any real > issues (such as what you're seeing). Interestingly enough, make and clang don't seem to be an issue so far as I can tell. I do have the fmake port installed because poudriere told me that it was necessary, but if I just cd to the directory containing the source for 8-STABLE, "make buildworld" mostly seems to work. The incompatibility of the patch -b option was the first problem that I ran into, and that just required a few individual Makefile edits. The second problem was the lex upgrade during sometime after 10 was branched, I worked around that by making lex a bootstrap tool using the existing knob. Yacc was already a bootstrap tool. The final problem that is vexing me is that the cross-tool version of lint. The source for lint is basically unchanged between 8-STABLE and 10-STABLE. The only significant change that I noticed was a one line patch to lint1/tree.c (and lint1 is the SIGBUS victim) documented here: and fixed in r224702. I applied that patch and saw no change. If I run the cross version of lint with the -B option to get it to use the host version of lint1, then things work. It's just the cross version of lint1 that is broken. Both the host and cross versions of lint1 are compiled with clang, from nearly identical source code, though the cross version was built with a parser and lexer gernerated using the bootstrap versions of lex and yacc. What's really maddening is that I don't see anything wrong if I point gdb at the core file. The next thing I'm going to try is to try to run lint1 under gdb and single step it. That's tricky because lint1 is run from lint and I need to figure out how to set up its arguments and input file. Oh, and I discovered that neither "truss -fa" nor ktrace output anything for exec*() calls. > The snapshot builder in use now, at that time was running 10-CURRENT. > Several "hacks" were in place, such as WITH_GNUCXX (which somehow turned > into 4 or more src.conf(5) entries by now), which would allow building > 8.x on 10-CURRENT to somewhat work. That did not last long, though. Oh yeah ... I stumbled across that problem as well. I think I only needed WITH_GCC and WITH_GNUCXX. > I think it was around when bmake became the default in -CURRENT that > I stopped spending time trying to build 8.x snapshots -- at that point, > the time spent debugging the build failures and updating the scripts to > "fix" the build became increasingly less beneficial. > > Now, having said all that, I have a possible solution that, quite > honestly, may or may not work (I have no idea at this point). > > You can grab the 8.4-RELEASE distribution set from FTP, and extract it > into a scratch directory, check out the stable/8/ tree into the scratch > directory usr/src/, then do: > > # chroot /scratch make -C /usr/src buildworld [...] > > That would at least provide you with the binary bits you want for your > package builds. I've actually got a couple of 8-STABLE boxes here already. They are just underpowered for mass building packages, which is why I'm not just running "poudriere bulk" on one of them. The other missing piece is going from there to a working poudriere jail while not using the "jail -c" command. Hmn ... maybe I could build the jail on one of my 8.4-STABLE machines and just copy the jail bits over ... > I *think* this is somewhat what the cluster package builders do, but > then again, I do not know off-hand if packages for 8.x are build for > pkg(8) - they may be only pkg_install(1). I think they are building pkg(8) packages, but they just use 8.4-RELEASE, plus security updates I imagine. I've been able to do that here for testing individual package builds on 8.x. > Again, sorry that I do not provide a "just do $this" kind of magic wand > in this case, especially since I've been in the same painful situation > you are in. But I hope at least some of this information is useful to > you. > > Glen > From owner-freebsd-stable@FreeBSD.ORG Sat Aug 30 08:00:37 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF2E7C7B; Sat, 30 Aug 2014 08:00:36 +0000 (UTC) Date: Sat, 30 Aug 2014 04:00:31 -0400 From: Glen Barber To: Don Lewis Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host Message-ID: <20140830080031.GP1200@hub.FreeBSD.org> References: <20140830024255.GL1200@hub.FreeBSD.org> <201408300720.s7U7KkDk073975@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="keoAwTxaagou87Dg" Content-Disposition: inline In-Reply-To: <201408300720.s7U7KkDk073975@gw.catspoiler.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: stable@FreeBSD.org, ian@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 08:00:37 -0000 --keoAwTxaagou87Dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 30, 2014 at 12:20:46AM -0700, Don Lewis wrote: > On 29 Aug, Glen Barber wrote: > > The 8.4-RELEASE was built on a machine running 9-STABLE, so make(1), > > gcc(1), and so on were not that far diverged for there to be any real > > issues (such as what you're seeing). >=20 > Interestingly enough, make and clang don't seem to be an issue so far as > I can tell. Behavior in make(1) between fmake(1) and bmake(1) have been subtle enough over the transition, but in a longer jump (i.e., 8-STABLE to 10-STABLE), it is actually quite significant. Clang is an entirely different situation, as you have seen from the libstdc++. This is not entirely fault of the clang(1) switch, however; it is effectively the behavior of the build was broken prior to the switch, at least, as far as I understand it. That is, ar(1) files were being used from the host environment, instead from outside of .OBJDIR. > I do have the fmake port installed because poudriere told > me that it was necessary, but if I just cd to the directory containing > the source for 8-STABLE, "make buildworld" mostly seems to work. The > incompatibility of the patch -b option was the first problem that I ran > into, and that just required a few individual Makefile edits. The > second problem was the lex upgrade during sometime after 10 was > branched, I worked around that by making lex a bootstrap tool using the > existing knob. Yacc was already a bootstrap tool. >=20 > The final problem that is vexing me is that the cross-tool version of > lint. The source for lint is basically unchanged between 8-STABLE and > 10-STABLE. The only significant change that I noticed was a one line > patch to lint1/tree.c (and lint1 is the SIGBUS victim) documented > here: and > fixed in r224702. I applied that patch and saw no change. >=20 > If I run the cross version of lint with the -B option to get it to use > the host version of lint1, then things work. It's just the cross > version of lint1 that is broken. Both the host and cross versions of > lint1 are compiled with clang, from nearly identical source code, though > the cross version was built with a parser and lexer gernerated using the > bootstrap versions of lex and yacc. What's really maddening is that I > don't see anything wrong if I point gdb at the core file. The next > thing I'm going to try is to try to run lint1 under gdb and single step > it. That's tricky because lint1 is run from lint and I need to figure > out how to set up its arguments and input file. >=20 > Oh, and I discovered that neither "truss -fa" nor ktrace output anything > for exec*() calls. > =20 > > The snapshot builder in use now, at that time was running 10-CURRENT. > > Several "hacks" were in place, such as WITH_GNUCXX (which somehow turned > > into 4 or more src.conf(5) entries by now), which would allow building > > 8.x on 10-CURRENT to somewhat work. That did not last long, though. >=20 > Oh yeah ... I stumbled across that problem as well. I think I only > needed WITH_GCC and WITH_GNUCXX. >=20 In that case, I was mostly pointing out the differences between "just two branches." It actually gets much worse than that. For ARM builds, on 11-CURRENT, for example, here's what is exported: export XDEV_FLAGS=3D"WITH_GCC=3D1 WITH_GCC_BOOTSTRAP=3D1 WITHOUT_CLANG_IS_= CC=3D1" =20 Compared to 10-STABLE: export XDEV_FLAGS=3D"WITH_GCC=3D1 WITH_GNUCXX=3D1 WITHOUT_CLANG_IS_CC=3D1" I'm not suggesting this is the problem in your case, however, just illustrating how things can differ between two otherwise-similar branches can have a huge impact. Somewhat related, I am heavily considering adding WITH_SCRABBLE=3D1 knob, which will try to guess the intended result is based on arbitrary alpha matches in the defined() pattern. I am about 40% joking, but the other 60% of me thinks it is more sane than some of the things we have in the build toolchain now. :-) > > I think it was around when bmake became the default in -CURRENT that > > I stopped spending time trying to build 8.x snapshots -- at that point, > > the time spent debugging the build failures and updating the scripts to > > "fix" the build became increasingly less beneficial. > >=20 > > Now, having said all that, I have a possible solution that, quite > > honestly, may or may not work (I have no idea at this point). > >=20 > > You can grab the 8.4-RELEASE distribution set from FTP, and extract it > > into a scratch directory, check out the stable/8/ tree into the scratch > > directory usr/src/, then do: > >=20 > > # chroot /scratch make -C /usr/src buildworld [...] > >=20 > > That would at least provide you with the binary bits you want for your > > package builds. >=20 > I've actually got a couple of 8-STABLE boxes here already. They are > just underpowered for mass building packages, which is why I'm not just > running "poudriere bulk" on one of them. The other missing piece is > going from there to a working poudriere jail while not using the "jail > -c" command. >=20 > Hmn ... maybe I could build the jail on one of my 8.4-STABLE machines > and just copy the jail bits over ... >=20 This is where my suggestion about 'bootstrapping' the build jail comes in; if you get the 8.x userland in place, you can check out the src/ tree within it, chroot(8) to the 8.x userland, and then do the normal buildworld/installworld dance. Or, if you are a ZFS consumer, 'zfs send | zfs recv' sounds like an equally good solution. > > I *think* this is somewhat what the cluster package builders do, but > > then again, I do not know off-hand if packages for 8.x are build for > > pkg(8) - they may be only pkg_install(1). >=20 > I think they are building pkg(8) packages, but they just use > 8.4-RELEASE, plus security updates I imagine. I've been able to do > that here for testing individual package builds on 8.x. >=20 I think you may be right about the pkg(8) conversion for 8.x. I am getting myself confused with the exp-builders versus the production pkg(8) builders, which yes, they do use the -RELEASE (and subsequent patchsets). Glen --keoAwTxaagou87Dg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUAYSfAAoJELls3eqvi17QBykQAKpllJ/gU3J4yyDi1QO3622T jHQZIfEVeBLI8jwX5IpM9VJmeNmj6lQvfLwNOW9iK84IcAPCX68Z5VPXRls0yJSs +8dANehff+97omhEkuh0lMZwzJniexktpyOZ+PIQOlLbkZyrSWM8jp6vmdcnrLhO DtrIXFBczCvS5GED/4a8+AqMDO+KRX+13mIk+/ueONddusmKX+KZfNloY1La49DZ NVL9RyqzejrN289v6zAVyNzuDkKZNG58Uw2Rlmb1llMYqOhCpmmWwdbl9/7XKuMO MQg97ZGqe877acPRsjYY5T4aQ0KyQ+2zuT3tAGEeNmH745k2lX6jufQSMzoZ8O46 mcJRdUM/B6uYiyaQHqOHVzSPKkvdPsppmCBWoggIJjwDuAZlNSZ06h7XOiM7hDcG O1tcxXcnB5Tl7vnwOPWhO79hTTyygd9L/yR6+1fdYpKmW/SFmoItqguW8If4dfdc 1A7lg3Vj7eS0sGjHROxc+D2+wGtEKx93PuVYwUJ3SySUo3cDMFDKAZgY7FAXAKf7 0H5HxQOQBP99LAaJxDgFpHOp4zfeP+OaFwOWa8QoLelr2tkSubsIK7IXbRUK2kGi yKa2Ek7jHy8Eb4I+FKmgMxScu2BCkh4+tpAU+BOJD/TsRXmYxdKvsU/t64yc5Ajz 1xxPnhW6XQoXqe6Rclvg =/vwe -----END PGP SIGNATURE----- --keoAwTxaagou87Dg--