From owner-freebsd-stable@FreeBSD.ORG Sun May 20 04:11:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E998C1065674; Sun, 20 May 2012 04:11:25 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id CE7588FC0A; Sun, 20 May 2012 04:11:24 +0000 (UTC) Received: by wibhm6 with SMTP id hm6so1835641wib.1 for ; Sat, 19 May 2012 21:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dHTwS0BhR2XwqF9V/kuD1ne3qIAS47u94HyhCO3k10w=; b=mtKS/zgRzhYx23LeXZr1gQQFRk/sfuD48gvwm1U3x6j0DBY/3Nw5zMb0Or39x6NNhI F6Ts9/xzV9YkoxuGj4SP4pAZPszjqi83Zyrq+mt8Co/sD6WRHv6qnZLUgueIv7rn8zUl yDgj7Cl8QQxf4fIq1iYuN+CfHNisDzfdunKdTXAII7XznV8WzXtOaeeBhyokeDIw/6/n Bc/e1RgvdLWtUPZwMJcOvGEn4B32Nk8yYTxHP94ibMMHxFui7PdD/P/niOwUsK0TJTnM sDt4QLcaztBlii2wDcliApvp9FImKL3nTygOPqF4aDeh9W9e4jvmouEHbg87ru/UQVK0 IueQ== MIME-Version: 1.0 Received: by 10.180.85.129 with SMTP id h1mr14125784wiz.2.1337487078322; Sat, 19 May 2012 21:11:18 -0700 (PDT) Received: by 10.223.155.80 with HTTP; Sat, 19 May 2012 21:11:18 -0700 (PDT) In-Reply-To: <139340614.20120520000831@serebryakov.spb.ru> References: <139340614.20120520000831@serebryakov.spb.ru> Date: Sat, 19 May 2012 21:11:18 -0700 Message-ID: From: Kevin Oberman To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9-STABLE: "sh /etc/rc autoboot" could not finish X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 04:11:26 -0000 On Sat, May 19, 2012 at 1:08 PM, Lev Serebryakov wrote: > Hello, Freebsd-stable. > > I've noticed, that after rebuilding system (fresh 9-STABLE, rebuild to > get latest ffs MFCs) something strange happens on boot: > > > root@blob:/ # ps -ax | grep rc > =A0 18 =A0v0- IE+ =A0 0:00,04 sh /etc/rc autoboot > =A01937 =A0 0 =A0S+ =A0 =A00:00,00 grep rc > root@blob:/ # uptime > =A00:08 =A0up 33 mins, 1 user, load averages: 0,00 0,00 0,00 > root@blob:/ # > > =A0What happens? Why /etc/rc could not finish? Take a look at http://lists.freebsd.org/pipermail/freebsd-stable/2011-Decem= ber/065198.html --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun May 20 13:23:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A71801065675 for ; Sun, 20 May 2012 13:23:37 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E086A8FC0C for ; Sun, 20 May 2012 13:23:36 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4539699bkv.13 for ; Sun, 20 May 2012 06:23:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=baYuuGEzhSRmBLYlBTT0vEd3dHFpmPr98crCN+fV1QI=; b=MnyoJZAigWSMtlnlioSEMygQDCARisleKo4VTnHTtJ37kFGgmnuFgNoGQPgkeMV2mV jSn2f+ZNcogZLtjn+MWtF9d0rMjRsOUGi/JrF9zRpUOZsF2DcbhBEEbDIfy9o+H4Pksz djDKuNnNRtLCvp3X/Pc4Yvf5OAvkO6pFGiH5tKZx6OIdqNHOXNsNVPA01hhYQ/7Ov631 rF4pBXTWxQPEa82IXYSo/+WOhHCUlL7znbV3qpE7DOYn0wyHgrvKCY6zdiUPFsOaU7oq rK3VCQYvJYC6sW7J4nuTPagcCV75sPNU0H7A6VSyMDJlK2TSQkNgKnclHSnMa3SGMwB+ TxQA== Received: by 10.204.156.150 with SMTP id x22mr6289369bkw.55.1337520215630; Sun, 20 May 2012 06:23:35 -0700 (PDT) Received: from zont-osx.local (ppp95-165-141-253.pppoe.spdop.ru. [95.165.141.253]) by mx.google.com with ESMTPS id e20sm23245058bkw.3.2012.05.20.06.23.34 (version=SSLv3 cipher=OTHER); Sun, 20 May 2012 06:23:35 -0700 (PDT) Message-ID: <4FB8F055.9080700@zonov.org> Date: Sun, 20 May 2012 17:23:33 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-stable References: <4FAFEEEF.3040706@zonov.org> <20120513202920.GA18238@dft-labs.eu> <4FB177EE.7030808@zonov.org> In-Reply-To: <4FB177EE.7030808@zonov.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkPkBiPi1XL6u0Y+IAodDGNXPg15WDt0KHtc6exK3pzdWACfWnXV4ycNOUJwK8PLQHHZ6Im Cc: Mateusz Guzik , trasz@freebsd.org Subject: Re: panic with overcommit and RACCT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 13:23:37 -0000 On 5/15/12 1:23 AM, Andrey Zonov wrote: > On 5/14/12 12:29 AM, Mateusz Guzik wrote: >> On Sun, May 13, 2012 at 09:27:11PM +0400, Andrey Zonov wrote: >>> Hi, >>> >>> I've got a repeatable panic on latest 9.0-STABLE and HEAD with >>> turned on overcommit (vm.overcommit=1) and RACCT. >>> >>> kgdb trace on today's HEAD: >>> >>> #10 0xffffffff80bc3513 in calltrap () >>> at /usr/src/sys/amd64/amd64/exception.S:228 >>> #11 0xffffffff808aab71 in racct_set_locked (p=0xfffffe0005d684a0, >>> resource=0, >>> amount=2680) at /usr/src/sys/kern/kern_racct.c:372 >>> #12 0xffffffff808ab645 in racct_proc_exit (p=0xfffffe0005d684a0) >>> at /usr/src/sys/kern/kern_racct.c:615 >>> #13 0xffffffff80880d69 in fork1 (td=0xfffffe0005b2c460, flags=20, >>> pages=4, >>> procp=0xffffff811a36bb00, procdescp=Variable "procdescp" is not >>> available. >>> ) at /usr/src/sys/kern/kern_fork.c:943 >>> #14 0xffffffff80882362 in sys_fork (td=0xfffffe0005b2c460, >>> uap=Variable "uap" is not available. >>> ) >>> at /usr/src/sys/kern/kern_fork.c:110 >>> #15 0xffffffff80bd7a89 in amd64_syscall (td=0xfffffe0005b2c460, >>> traced=0) >>> at subr_syscall.c:135 >>> #16 0xffffffff80bc37f7 in Xfast_syscall () >>> at /usr/src/sys/amd64/amd64/exception.S:387 >>> #17 0x00000008024729fc in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) >>> >>> Unread portion of the kernel message buffer: >>> Kernel page fault with the following non-sleepable locks held: >>> exclusive sleep mutex racct lock (racct lock) r = 0 >>> (0xffffffff8128a7c0) locked @ /usr/src/sys/kern/kern_racct.c:614 >>> exclusive sleep mutex process lock (process lock) r = 0 >>> (0xfffffe0005d68598) locked @ /usr/src/sys/kern/kern_racct.c:603 >>> >> >> It looks like racct_proc_exit can be called for processes without >> properly initialized racct structure, which in turn results in this >> panic. >> >> Can you please test this patch: >> http://student.agh.edu.pl/~mjguzik/patches/racct-fork.patch >> >> ? >> >> I was unable to reproduce panic you describe, so it was tested only by >> manually injecting error. Nevertheless I think you should try it. :) >> > > Thanks, your patch fixes the panic. Can anyone commit this fix? > > How to repeat: > 1. add options RACCT and options RCTL to kernel config, rebuild and > install kernel, reboot > 2. set sysctl vm.overcommit=1 > 3. run as none root something that eats memory (I just run malloc() > until it returns NULL) > 4. swapoff -a > 5. panic after sometime > > With patch applied instead of panic I got: "fork: Cannot allocate > memory". Looks like a bug in overcommit code. > -- Andrey Zonov From owner-freebsd-stable@FreeBSD.ORG Sun May 20 16:45:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4CD01065741 for ; Sun, 20 May 2012 16:45:58 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 60AB58FC1B for ; Sun, 20 May 2012 16:45:58 +0000 (UTC) Received: by werg1 with SMTP id g1so3577778wer.13 for ; Sun, 20 May 2012 09:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AJnyrfbYHpX/hfC/JTSvu0A/BphhGSgdYqFj04IlRug=; b=wvHAvm2RlUleZp4hCCPq6J184KCJvoX28M0eYztWdvv/80FtGMhxGRE4AYsCXZCdAk cvSvbiW4zh3c7hh3vzOQM21g7eMQrCOAibAnzoET3WT1a8Jf2NiL1meNPVkZrKhZaGl0 5JUzBR7zoclWBdeT32CXKq4l2RHloS33dUWD5e7vFJ4m09C8IqFCRHz4pmhRwtTVwmAe DQs6fiLCA9BAhYwlD0quxEcmz9YFFrUbrLMQQW+OCcevzv9/XVAzWKYxtXl30B4UcSdN Ge+iKVlfXdrBv1BhwpYn+cJBMqJInlXGBzYGnAyZHiPm7Y0EzV3dqjwHWuIl9YMAeqzj Kk/w== Received: by 10.216.212.234 with SMTP id y84mr11492133weo.81.1337532357183; Sun, 20 May 2012 09:45:57 -0700 (PDT) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id j3sm29713184wiw.1.2012.05.20.09.45.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 May 2012 09:45:56 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <4FB8F055.9080700@zonov.org> Date: Sun, 20 May 2012 18:45:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9686F975-17FF-4F8B-A103-543EB2DA34B1@freebsd.org> References: <4FAFEEEF.3040706@zonov.org> <20120513202920.GA18238@dft-labs.eu> <4FB177EE.7030808@zonov.org> <4FB8F055.9080700@zonov.org> To: Andrey Zonov X-Mailer: Apple Mail (2.1278) Cc: Mateusz Guzik , freebsd-stable Subject: Re: panic with overcommit and RACCT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 16:45:59 -0000 Wiadomo=B6=E6 napisana przez Andrey Zonov w dniu 20 maj 2012, o godz. = 15:23: > On 5/15/12 1:23 AM, Andrey Zonov wrote: >> On 5/14/12 12:29 AM, Mateusz Guzik wrote: >>> On Sun, May 13, 2012 at 09:27:11PM +0400, Andrey Zonov wrote: >>>> Hi, >>>>=20 >>>> I've got a repeatable panic on latest 9.0-STABLE and HEAD with >>>> turned on overcommit (vm.overcommit=3D1) and RACCT. >>>>=20 >>>> kgdb trace on today's HEAD: >>>>=20 >>>> #10 0xffffffff80bc3513 in calltrap () >>>> at /usr/src/sys/amd64/amd64/exception.S:228 >>>> #11 0xffffffff808aab71 in racct_set_locked (p=3D0xfffffe0005d684a0, >>>> resource=3D0, >>>> amount=3D2680) at /usr/src/sys/kern/kern_racct.c:372 >>>> #12 0xffffffff808ab645 in racct_proc_exit (p=3D0xfffffe0005d684a0) >>>> at /usr/src/sys/kern/kern_racct.c:615 >>>> #13 0xffffffff80880d69 in fork1 (td=3D0xfffffe0005b2c460, flags=3D20,= >>>> pages=3D4, >>>> procp=3D0xffffff811a36bb00, procdescp=3DVariable "procdescp" is not >>>> available. >>>> ) at /usr/src/sys/kern/kern_fork.c:943 >>>> #14 0xffffffff80882362 in sys_fork (td=3D0xfffffe0005b2c460, >>>> uap=3DVariable "uap" is not available. >>>> ) >>>> at /usr/src/sys/kern/kern_fork.c:110 >>>> #15 0xffffffff80bd7a89 in amd64_syscall (td=3D0xfffffe0005b2c460, >>>> traced=3D0) >>>> at subr_syscall.c:135 >>>> #16 0xffffffff80bc37f7 in Xfast_syscall () >>>> at /usr/src/sys/amd64/amd64/exception.S:387 >>>> #17 0x00000008024729fc in ?? () >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>>=20 >>>> Unread portion of the kernel message buffer: >>>> Kernel page fault with the following non-sleepable locks held: >>>> exclusive sleep mutex racct lock (racct lock) r =3D 0 >>>> (0xffffffff8128a7c0) locked @ /usr/src/sys/kern/kern_racct.c:614 >>>> exclusive sleep mutex process lock (process lock) r =3D 0 >>>> (0xfffffe0005d68598) locked @ /usr/src/sys/kern/kern_racct.c:603 >>>>=20 >>>=20 >>> It looks like racct_proc_exit can be called for processes without >>> properly initialized racct structure, which in turn results in this >>> panic. >>>=20 >>> Can you please test this patch: >>> http://student.agh.edu.pl/~mjguzik/patches/racct-fork.patch >>>=20 >>> ? >>>=20 >>> I was unable to reproduce panic you describe, so it was tested only = by >>> manually injecting error. Nevertheless I think you should try it. :) >>>=20 >>=20 >> Thanks, your patch fixes the panic. >=20 > Can anyone commit this fix? Yup, I'm reviewing it. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-stable@FreeBSD.ORG Mon May 21 14:51:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C64F7106566C for ; Mon, 21 May 2012 14:51:46 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 904AE8FC0C for ; Mon, 21 May 2012 14:51:46 +0000 (UTC) Received: by dadv36 with SMTP id v36so7440531dad.13 for ; Mon, 21 May 2012 07:51:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:organization :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole:x-gm-message-state; bh=28gfhoquktIxHA74fKUJp7Pci1/b9hB3s9CroLyTMEI=; b=T3fMEBqlikA0tDtz9KBY0M0Dts0+QuS4sgIiY0uEC/Xe8vEemEyN5ZSwQFcaCfdgGn aYtp1J1Qv5g+BgznpKCVGuv9Xp4I81NAVzxE30vB1/9ACZIAdqj8t4DkVmQQoqkE0lBL nKjL7DCiUPa1pkiqlns6eo3YWbJ76RpRywJzFYndvKTDCRxlf6t5AWUVNh6RFRerV5w8 sNTgVK1vEetV8WanCP2OGE1yfj7l/QNlI364UoGBYPbmxPtUyeKvcmWQrKPQ5sro/r2l wePtcbNQjfs1wvmTrShzoOk8cMIHj5gnJqRC+v6xkkgcrzABBSYRiM8FEWw/wB84FaBC r+3w== Received: by 10.68.136.65 with SMTP id py1mr69058841pbb.81.1337611906140; Mon, 21 May 2012 07:51:46 -0700 (PDT) Received: from CMOTUM25PC ([187.210.81.114]) by mx.google.com with ESMTPS id pw10sm23320993pbb.61.2012.05.21.07.51.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 07:51:44 -0700 (PDT) Message-ID: <4515A2B87E0F4364BC089D80F8B6F600@CMOTUM25PC> From: =?UTF-8?Q?Efra=C3=ADn_D=C3=A9ctor?= To: "Ollivier Robert" , References: <32D637C53E8B47AC80752B2EF61075E4@CMOTUM25PC> <20120518164829.GD89308@lonrach.local> In-Reply-To: <20120518164829.GD89308@lonrach.local> Date: Mon, 21 May 2012 09:51:37 -0500 Organization: =?UTF-8?Q?HESA_T=C3=A9cnica?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Gm-Message-State: ALoCoQl07kkTopERQcAPyMCw5Vi8oTJZTVKEmdyY7SBWQITMNwTS4oZRrFVhaSmrigxU9BXUk7vf Cc: Subject: Re: FreeBSD 9 and PERC H200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:51:46 -0000 -----Mensaje original----- From: Ollivier Robert Sent: Friday, May 18, 2012 11:48 AM To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 and PERC H200 According to Efraín Déctor: > Today we got a Dell R210 II server with RAID controller PERC H200A, > unfortunately I can’t install FreeBSD 9.0 on it, it appears that doesn’t > recognize the RAID Controller. I’ve been looking and the solution is to > disable de controller and make a RAID using software, however this doesn’t > seem right to us (we want to test the controller itself). Do any of you > guys know if the new FreeBSD 8.3 supports this controller?. If you are installing 9.0-R, the only driver in there is the mpt one and yes, the hardware raid in not supported, you need to put the drives in passthrough and use gmirror or ZFS. In 9-STABLE, there is a new driver from LSI themselves which should support RAID. You could try to install a 9 snapshot and see whether it works. I'd suggest going the passthrough mode and install ZFS, at least, that what I did on my own R210 server. -----Final Mensaje original----- Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is compatible with PERC H200?. Thanks in advance. From owner-freebsd-stable@FreeBSD.ORG Mon May 21 15:53:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E79A1065690 for ; Mon, 21 May 2012 15:53:03 +0000 (UTC) (envelope-from roberto@keltia.net) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 1058D8FC0C for ; Mon, 21 May 2012 15:53:02 +0000 (UTC) Received: from [10.139.197.129] (37-8-176-105.coucou-networks.fr [37.8.176.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 57EF010D8E; Mon, 21 May 2012 17:52:59 +0200 (CEST) References: <32D637C53E8B47AC80752B2EF61075E4@CMOTUM25PC> <20120518164829.GD89308@lonrach.local> <4515A2B87E0F4364BC089D80F8B6F600@CMOTUM25PC> In-Reply-To: <4515A2B87E0F4364BC089D80F8B6F600@CMOTUM25PC> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <11499176-01DA-4374-B1EC-A134C6EFE2B5@keltia.net> X-Mailer: iPhone Mail (9B206) From: Ollivier Robert Date: Mon, 21 May 2012 17:53:03 +0200 To: =?utf-8?Q?Efra=C3=ADn_D=C3=A9ctor?= Cc: "" Subject: Re: FreeBSD 9 and PERC H200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 15:53:03 -0000 Le 21 mai 2012 =C3=A0 16:51, Efra=C3=ADn D=C3=A9ctor a =C3=A9crit=20 > Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is compati= ble with PERC H200?. It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should wo= rk= From owner-freebsd-stable@FreeBSD.ORG Mon May 21 16:27:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B0971065674 for ; Mon, 21 May 2012 16:27:17 +0000 (UTC) (envelope-from info@obn24news.com) Received: from obn24news.com (93-189-28-146.rev.ipax.at [93.189.28.146]) by mx1.freebsd.org (Postfix) with ESMTP id B0E4A8FC21 for ; Mon, 21 May 2012 16:27:16 +0000 (UTC) Received: from SBS15 (93-189-28-146.rev.ipax.at [93.189.28.146]) by obn24news.com (Postfix) with ESMTPA id 93202A02ED3 for ; Mon, 21 May 2012 18:27:15 +0200 (CEST) Organization: Oxford Business News Message-ID: From: "Oxford Business News" To: Date: Mon, 21 May 2012 18:17:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 20% bei Strom und Gas sparen! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@obn24news.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:27:17 -0000 Oxford Business News Wenn diese E-Mail nicht richtig angezeigt wird, klicken Sie bitte hier.       Jetzt Strom und Gas bis zu 20 Prozent günstiger sichern! Gerade in wirtschaftlich herausfordernden Zeiten überprüfen clevere Unternehmer ihre laufenden Kosten auf Einsparpotenziale. Ein besonders großer Dorn im Auge der Entscheider: die jährlich steigenden Energiekosten verbunden mit unerfreulichen Nachzahlungen. >>>mehr...     So wehren Sie sich gegen die Beitragsanpassungen der privaten Krankenversicherungen Viele privat Krankenversicherte kennen die Situation bestens! Jedes Jahr flattert eine neue Beitragsanpassung ins Haus. Die finanzielle Belastung wird jedes Jahr höher und höher. >>>mehr...     Der Schlüssel zu mehr Umsatz Mit Sicherheit ein Hit: Wenn Sie mit Ihren Mailings eine höhere Responsequote erzielen wollen als bisher, dann ist das einfacher als Sie denken. Die erfolgversprechendste Methode ist, die Neugier der Angeschriebenen zu wecken. >>>mehr...     Warum eignen sich Sachwerte zum Vermögensaufbau? Wer sich heutzutage auf die Suche nach einer Geldanlageform ist, steht oft vor einem großen Problem. Denn das Bestreben ist natürlich zum einen, so viel Zinsen wie nur irgend möglich zu erwirtschaften, trotzdem das Geld verfügbar zu halten. Zusätzlich sollte das Kapital sicher sein, also nicht Gefahr laufen an Wert zu verlieren. >>>mehr...     Ihr Unternehmen durch die Hintertür auf Platz 1 bei Google Clevere Strategie um neue Kunden zu gewinnen: Videos auf Webseiten werden immer wichtiger." Das ist nicht nur eine Aussage von Google, sondern Realität. >>>mehr...     Eine Tasse Tee, die begeistert. USABILITEA ist Teegenuss mit sympathischer Werbewirkung. Hierbei handelt es sich um eine ausgefallene Idee, welche die allseits bekannte, beruhigende Wirkung einer Tasse Tee mit einem witzigen Gruß verbindet. >>>mehr...     Elegante Business-Limousine und praktischer Raumgigant: Wechseln Sie jetzt auf die Überholspur! Gerade clevere Unternehmer, die beruflich viel Zeit auf der Autobahn verbringen, werden sich umgehend in die neuen Lancia-Modelle vergucken. Denn die traditionsreiche Edelmarke aus Turin zeigt mit dem neuen Lancia Thema eine hochelegante Luxuslimousine, die mit einzigartigem Design und edlem Interieur überzeugt. >>>mehr...     Laserschneiden von Materialien präzise, schnell und günstig. Immer wieder müssen Materialien zugeschnitten oder graviert werden. Unter Fachleuten hat es sich herumgesprochen, dass dieses mit Lasern nicht nur besonders präzise sondern auch sehr schnell geht. >>>mehr...   In dieser Ausgabe: Jetzt Strom und Gas bis zu 20 Prozent günstiger sichern! So wehren Sie sich gegen die Beitragsanpassungen der privaten Krankenversicherungen Der Schlüssel zu mehr Umsatz Warum eignen sich Sachwerte zum Vermögensaufbau? Ihr Unternehmen durch die Hintertür auf Platz 1 bei Google Eine Tasse Tee, die begeistert. Elegante Business-Limousine und praktischer Raumgigant: Wechseln Sie jetzt auf die Überholspur! Laserschneiden von Materialien präzise, schnell und günstig.   © 2012 Oxford Business News, www.obn-24.com Oxford Business News ist eine Publikation der Eureka Consultancy Ltd., 147-155 St John Street, London EC1V 4PY, United Kingdom Wenn Sie keine Newsletter mehr wünschen, dann klicken Sie hier. Um die Zusendung des Newsletters, insbesondere bei Freemail-Diensten wie GMX, WEB.DE oder AOL zu garantieren, bitten wir Sie, unsere Absender-Adresse in Ihr Adressbuch aufzunehmen. Dazu markieren Sie bitte die E-Mail Adresse und kopieren diese in Ihr Adressbuch. Herzlichen Dank! From owner-freebsd-stable@FreeBSD.ORG Mon May 21 16:41:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 244C31065677; Mon, 21 May 2012 16:41:57 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E76418FC1F; Mon, 21 May 2012 16:41:56 +0000 (UTC) Received: by dadv36 with SMTP id v36so7585102dad.13 for ; Mon, 21 May 2012 09:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=xKtPay+agdjIV6e7j6OYFkg1svxCrHDSthDs08OIL4w=; b=WiKQ7H3rpN9vz3R+loIhXwkA6fhEhz0c/8to6wfNzauAOgR2wLsUtsVcAIPEy4YaAB Y+0ZjHx64ZQdPI/Uz5IsbYzLdWKuFf2AWdF8D3p6QCtIPbCM9Bi/DFg8MbPh8Z47vAA/ Hpt1sG/FlL9edEgQO6WNqdU1ZEchMYwQeluFUkT3rPkAUR+SdvbCh1wHKfLrZSYlq73C z6Tfsi2NmLCAPq98GmnunjzT+jUI0/ZufoK5wUXW1Wa8ZDkTAZ0ohw5yZPnd7XUgRv1R 2szEGdSmcnxB9xhuhF3FYdjIH+sTPSJQfQGxDNiDjrULRMKUUgwcfwVaBPmoObC6kBhz Js3A== MIME-Version: 1.0 Received: by 10.68.240.71 with SMTP id vy7mr12283326pbc.78.1337618516389; Mon, 21 May 2012 09:41:56 -0700 (PDT) Received: by 10.142.149.5 with HTTP; Mon, 21 May 2012 09:41:56 -0700 (PDT) Date: Tue, 22 May 2012 00:41:56 +0800 Message-ID: From: Yanhui Shen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Something wrong with curs_threads(3X) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 16:41:57 -0000 Hi, In curs_threads(3X), at the beginning of the manual: typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int > (*NCURSES_SCREEN_CB)(SCREEN *, void *); > int set_escdelay(int size); > int set_tabsize(int size); > int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); > int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); use_screen => NCURSES_WINDOW_CB use_window = > NCURSES_SCREEN_CB Target is not matched, I'm really confused. So I open /usr/include/curses.h, and find these: extern NCURSES_EXPORT(int) use_screen (SCREEN *, NCURSES_SCREEN_CB, void *); > extern NCURSES_EXPORT(int) use_window (WINDOW *, NCURSES_WINDOW_CB, void > *); Seems much proper. So is this a bug? -- Best regards, Yanhui Shen From owner-freebsd-stable@FreeBSD.ORG Mon May 21 19:27:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BD5C1065791 for ; Mon, 21 May 2012 19:27:59 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5430C8FC0C for ; Mon, 21 May 2012 19:27:59 +0000 (UTC) Received: by mail-pz0-f54.google.com with SMTP id v36so7789614dad.13 for ; Mon, 21 May 2012 12:27:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :organization:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole :x-gm-message-state; bh=vKG7PcmamwLWXuKBdujM4IRLt1tatOlbezyb7GZ+H3A=; b=USQk8a2tX+jNujIXMeqqm6qbz8fQZGat0vaq7KDYpcIOyZo29ldPchBX1TGnmsQzhh sTukcCC7rs/Uej6HQ/cO8CKnr8/+0MzzQQ3JnvbQM1vs9OU2ohGPpIGDWvtlzvu6Op6D N4fsRX0gnBzCNiXqLAvNlSj8OXonSm+tOyOl+YFQEUBvChmXGiJtNYi5jR61fUc5cnP3 nAuBewlrS3qqrorc5J+d/TJjS8M3Y53m1CUogZYXGpH8V0uRCxPysB1hsJ+I2dY58lpo LnNxwPSnxktnn2NUI8xXRov366OKz+hfZQISM+TKep8DCFX56+0w0Sfnyv5B/MPTCD5X aGbw== Received: by 10.68.233.193 with SMTP id ty1mr9391531pbc.47.1337628474772; Mon, 21 May 2012 12:27:54 -0700 (PDT) Received: from CMOTUM25PC ([187.210.81.114]) by mx.google.com with ESMTPS id ub8sm23979687pbc.44.2012.05.21.12.27.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 12:27:53 -0700 (PDT) Message-ID: <2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC> From: =?UTF-8?Q?Efra=C3=ADn_D=C3=A9ctor?= To: References: <32D637C53E8B47AC80752B2EF61075E4@CMOTUM25PC> <20120518164829.GD89308@lonrach.local> <4515A2B87E0F4364BC089D80F8B6F600@CMOTUM25PC> <11499176-01DA-4374-B1EC-A134C6EFE2B5@keltia.net> In-Reply-To: <11499176-01DA-4374-B1EC-A134C6EFE2B5@keltia.net> Date: Mon, 21 May 2012 14:27:50 -0500 Organization: =?UTF-8?Q?HESA_T=C3=A9cnica?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Gm-Message-State: ALoCoQm6Qq/4G+x/fULY5KBRIU3CNYbezMHv5mxXgFCGsYE+EDtmtQWOABfzPhlW1Y1g0V/eZDFV Cc: Ollivier Robert Subject: Re: FreeBSD 9 and PERC H200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:27:59 -0000 -----Mensaje original----- From: Ollivier Robert Sent: Monday, May 21, 2012 10:53 AM To: Efraín Déctor Cc: Ollivier Robert ; Subject: Re: FreeBSD 9 and PERC H200 Le 21 mai 2012 à 16:51, Efraín Déctor a écrit > Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is > compatible with PERC H200?. It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should work -----Mensaje original----- Cool, I'll give it a try. Thank you so much. From owner-freebsd-stable@FreeBSD.ORG Mon May 21 22:45:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41F681065670 for ; Mon, 21 May 2012 22:45:24 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id E08248FC1A for ; Mon, 21 May 2012 22:45:23 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 55B0F1CC48; Mon, 21 May 2012 22:39:03 -0300 (BRT) Received: from 187.114.205.80 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Mon, 21 May 2012 22:39:03 -0300 Message-ID: Date: Mon, 21 May 2012 22:39:03 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: siiis + port multiplier + 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:45:24 -0000 hail, I have a problem using a port multiplier on 9.0R: pci SATA card: siis0@pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x01 hdr=0x00 vendor = 'Silicon Image, Inc.' device = 'SiI 3124 PCI-X Serial ATA Controller' class = mass storage subclass = RAID multiplier: pmp0 at siisch1 bus 0 scbus1 target 15 lun 0 pmp0: ATA-0 device pmp0: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes) pmp0: 5 fan-out ports FreeBSD: FreeBSD lamneth 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 the error is: dmesg: May 21 22:20:45 lamneth kernel: siisch1: ... waiting for slots 40000000 May 21 22:20:45 lamneth kernel: siisch1: Timeout on slot 30 May 21 22:20:45 lamneth kernel: siisch1: siis_timeout is 00040000 ss 40812000 rs 40812000 es 00000000 sts 801e2000 serr 00000000 May 21 22:21:17 lamneth kernel: siisch1: Timeout on slot 26 May 21 22:21:17 lamneth kernel: siisch1: siis_timeout is 00040000 ss 64400000 rs 64400000 es 00000000 sts 801e2000 serr 00000000 May 21 22:21:17 lamneth kernel: siisch1: ... waiting for slots 60400000 May 21 22:21:17 lamneth kernel: siisch1: Timeout on slot 22 May 21 22:21:17 lamneth kernel: siisch1: siis_timeout is 00040000 ss 64400000 rs 64400000 es 00000000 sts 801e2000 serr 00000000 May 21 22:21:17 lamneth kernel: siisch1: ... waiting for slots 60000000 May 21 22:21:47 lamneth kernel: siisch1: Timeout on slot 29 May 21 22:21:47 lamneth kernel: siisch1: siis_timeout is 00040000 ss 64400000 rs 64400000 es 00000000 sts 801e2000 serr 00000000 May 21 22:21:47 lamneth kernel: siisch1: ... waiting for slots 40000000 May 21 22:21:47 lamneth kernel: siisch1: Timeout on slot 30 May 21 22:21:47 lamneth kernel: siisch1: siis_timeout is 00040000 ss 64400000 rs 64400000 es 00000000 sts 801e2000 serr 00000000 using the card without the multiplier, gets me around 7MB/s for ZFS+Geli. Using both, I get a great speed (almost this) and then I begin to see those messages above, and copy speed drops to hundreads of KB/s. I've used this multiplier with this card: ahci1@pci0:13:0:0: class=0x010601 card=0x10601b21 chip=0x06121b21 rev=0x01 hdr=0x00 vendor = 'ASMedia Technology Inc.' class = mass storage subclass = SATA on another box, no error. but the performance is too low using geli (soekris net6501-70). any reason for this, is a bug ? I'm looking forward on buying this: http://www.hwtools.net/Adapter/PM362.html or http://www.hwtools.net/adapter/pm2c.html, if the first would support multiplier, then all is fine. else, the latter would let me use the eSATA pcie card I use on soekris, and I think all would be fine also. if anyone would have any words of advice. My goal is to have a FreeBSD capable of ZFS, geli and lots of disks. My mainboard is intel d525mw and 4GB ram. so far, just using 4 disks performance is what I need. thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Tue May 22 01:05:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 919CD106564A for ; Tue, 22 May 2012 01:05:19 +0000 (UTC) (envelope-from MGamble@primustel.ca) Received: from mail1.primustel.ca (webex.primustel.ca [216.254.142.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0DEBC8FC1A for ; Tue, 22 May 2012 01:05:18 +0000 (UTC) Received: from PRIEXCHANGE01.ca.primus ([10.10.3.36]) by priexchange01 ([10.10.3.36]) with mapi id 14.01.0289.001; Mon, 21 May 2012 21:04:09 -0400 From: Matthew Gamble To: "freebsd-stable@freebsd.org" Thread-Topic: siis_timeout with port multiplier on 9.0R Thread-Index: AQHNN7bKgWHnidVF20qG8Khg+P4gyw== Date: Tue, 22 May 2012 01:04:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.201.183.65] x-exclaimer-md-config: 82dec062-a613-49a1-8ae1-be0919f8e5e1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: siis_timeout with port multiplier on 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 01:05:19 -0000 V2UgaGF2ZSBhIGJveCB3aXRoIDMgU2lJMzEyNCBTQVRBIGNvbnRyb2xsZXJzIGFuZCA5IENGSS1C NTNQTSA1IFBvcnQgQmFja3BsYW5lIHBvcnQgbXVsdGlwbGllcnMgKHRoZSAiYmFja2JsYXplIHN0 b3JhZ2UgcG9kIikuICBVbmRlciBpbnRlbnNlIElPIChaRlMgcmVidWlsZCwgcHJlc2VudGx5KSB0 aGUgc3lzdGVtIHdpbGwgbG9jayB1cCBhbGwgSU8gZm9yIDMtNCBtaW51dGVzIGFuZCB0aGUgZm9s bG93aW5nIGVudHJ5IGFwcGVhcnMgaW4gdGhlIGRtZXNnOg0KDQpzaWlzY2gxMTogVGltZW91dCBv biBzbG90IDMwDQpzaWlzY2gxMTogc2lpc190aW1lb3V0IGlzIDAwMDQwMDAwIHNzIDY1MDAwMDAw IHJzIDY1MDAwMDAwIGVzIDAwMDAwMDAwIHN0cyA4MDE5MjAwMCBzZXJyIDAwMDAwMDAwDQpzaWlz Y2gxMTogIC4uLiB3YWl0aW5nIGZvciBzbG90cyAyNTAwMDAwMA0Kc2lpc2NoMTE6IFRpbWVvdXQg b24gc2xvdCAyNg0Kc2lpc2NoMTE6IHNpaXNfdGltZW91dCBpcyAwMDA0MDAwMCBzcyA2NTAwMDAw MCBycyA2NTAwMDAwMCBlcyAwMDAwMDAwMCBzdHMgODAxOTIwMDAgc2VyciAwMDAwMDAwMA0Kc2lp c2NoMTE6ICAuLi4gd2FpdGluZyBmb3Igc2xvdHMgMjEwMDAwMDANCnNpaXNjaDExOiBUaW1lb3V0 IG9uIHNsb3QgMjkNCnNpaXNjaDExOiBzaWlzX3RpbWVvdXQgaXMgMDAwNDAwMDAgc3MgNjUwMDAw MDAgcnMgNjUwMDAwMDAgZXMgMDAwMDAwMDAgc3RzIDgwMTkyMDAwIHNlcnIgMDAwMDAwMDANCnNp aXNjaDExOiAgLi4uIHdhaXRpbmcgZm9yIHNsb3RzIDAxMDAwMDAwDQpzaWlzY2gxMTogVGltZW91 dCBvbiBzbG90IDI0DQpzaWlzY2gxMTogc2lpc190aW1lb3V0IGlzIDAwMDQwMDAwIHNzIDY1MDAw MDAwIHJzIDY1MDAwMDAwIGVzIDAwMDAwMDAwIHN0cyA4MDE5MjAwMCBzZXJyIDAwMDAwMDAwDQoN ClRoZSBlcnJvcnMgYXJlIG9uIGRpZmZlcmVudCBzaWlzY2ggZGV2aWNlcyBzbyBpdHMgbm90IGxp a2VseSB0byBiZSBhIFNBVEEgY2FibGUgaXNzdWUgdW5sZXNzIG11bHRpcGxlIGNhYmxlcyBhbGwg d2VudCBiYWQgYXQgdGhlIHNhbWUgdGltZS4gIE9uIHRoZSBhZHZpY2Ugb2Ygc29tZSBvdGhlciBw b3N0cyB0byB0aGUgbWFpbGluZyBsaXN0IEkndmUgYWxyZWFkeSB0cmllZCBsb2NraW5nIHRoZSBT QVRBIHJldiB0byBvbmUgd2l0aCB0aGUgZm9sbG93aW5nIGluIC9ib290L2xvYWRlci5jb25mIHdo aWNoIGRpZG4ndA0KDQpoaW50LnNpaXNjaC4wLnNhdGFfcmV2PTENCmhpbnQuc2lpc2NoLjEuc2F0 YV9yZXY9MQ0KaGludC5zaWlzY2guMi5zYXRhX3Jldj0xDQpoaW50LnNpaXNjaC4zLnNhdGFfcmV2 PTENCmhpbnQuc2lpc2NoLjQuc2F0YV9yZXY9MQ0KaGludC5zaWlzY2guNS5zYXRhX3Jldj0xDQpo aW50LnNpaXNjaC42LnNhdGFfcmV2PTENCmhpbnQuc2lpc2NoLjcuc2F0YV9yZXY9MQ0KaGludC5z aWlzY2guOC5zYXRhX3Jldj0xDQpoaW50LnNpaXNjaC45LnNhdGFfcmV2PTENCmhpbnQuc2lpc2No LjEwLnNhdGFfcmV2PTENCmhpbnQuc2lpc2NoLjExLnNhdGFfcmV2PTENCg0KRnJvbSB0aW1lIHRv IHRpbWUgdGhpcyBpcyBhbHNvIGNhdXNpbmcgb25lIG9mIHRoZSBhdHRhY2hlZCBkcml2ZXMgdG8g Z28gb2ZmbGluZToNCg0Kc2lpc2NoMDogc2lpc190aW1lb3V0IGlzIDAwMDQwMDAwIHNzIDQwMDAw MDAwIHJzIDQwMDAwMDAwIGVzIDAwMDAwMDAwIHN0cyA4MDFmMjAwMCBzZXJyIDAwMDAwMDAwDQoo YWRhMDpzaWlzY2gwOjA6MDowKTogbG9zdCBkZXZpY2UNCihhZGEwOnNpaXNjaDA6MDowOjApOiBy ZW1vdmluZyBkZXZpY2UgZW50cnkNCmFkYTAgYXQgc2lpc2NoMCBidXMgMCBzY2J1czAgdGFyZ2V0 IDAgbHVuIDANCmFkYTA6IDxXREMgV0QzMEVaUlgtMDBNTU1CMCA4MC4wMEE4MD4gQVRBLTggU0FU QSAzLnggZGV2aWNlDQphZGEwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1B NiwgUElPIDgxOTJieXRlcykNCmFkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KYWRhMDog Mjg2MTU4OE1CICg1ODYwNTMzMTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0Mp DQphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDQNCnNpaXNjaDExOiBUaW1lb3V0IG9u IHNsb3QgMzANCg0KV2hlbiB0aGUgZHJpdmUgZ29lcyBvZmZsaW5lIHRoYXQgY2F1c2VzIHRoZSBa RlMgcmVidWlsZCB0byByZXN0YXJ0LCBhbmQgc28gaXQncyBuZXZlciBmaW5pc2hpbmcgdGhlIHJl YnVpbGQgb2YgdGhlIGFycmF5LiAgRG9lcyBhbnlvbmUgaGF2ZSBhbnkgaW5zaWdodCBpbnRvIHdo YXQgY291bGQgYmUgY2F1c2luZyB0aGUgdGltZW91dHMgYW5kIHdoYXQgd2UgY2FuIGRvIHRvIHJl c29sdmUgdGhlbT8gIFJpZ2h0IG5vdyBteSBwcmlvcml0eSBpcyB0byBnZXQgdGhlIHN5c3RlbSBh IGJpdCBtb3JlIHN0YWJsZSBzbyB0aGUgY3VycmVudCBaRlMgcmVidWlsZCBjYW4gY29tcGxldGUg 4oCTIHJpZ2h0IG5vdyBpdCdzIGJlZW4gZG9pbmcgdGhlIHNhbWUgcmVidWlsZCBmb3IganVzdCBv dmVyIDYgZGF5cyBhbmQgdGhlIHRpbWVvdXRzIGFuZCBkcml2ZSBkcm9wIG9mZnMgYXJlIGNhdXNp bmcgaXQgdG8gcmVzdGFydCBjb25zdGFudGx5Lg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZv cm1hdGlvbiBmcm9tIFByaW11cyBUZWxlY29tbXVuaWNhdGlvbnMgQ2FuYWRhIEluYy4gKCJQUklN VVMiKSAsIHdoaWNoIG1heSBiZSBsZWdhbGx5IHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbC4g VGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlz dHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSB0ZWxlcGhvbmUgb3IgZS1tYWlsICh0byB0aGUg bnVtYmVyIG9yIGFkZHJlc3MgYWJvdmUpIGltbWVkaWF0ZWx5LiBBbnkgdmlld3MsIG9waW5pb25z IG9yIGFkdmljZSBleHByZXNzZWQgaW4gdGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYXJlIG5vdCBu ZWNlc3NhcmlseSB0aGUgdmlld3MsIG9waW5pb25zIG9yIGFkdmljZSBvZiBQUklNVVMuIEl0IGlz IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgcmVjaXBpZW50IHRvIGVuc3VyZSB0aGF0IGFueSBh dHRhY2htZW50cyBhcmUgdmlydXMgZnJlZSBhbmQgUFJJTVVTIGJlYXJzIG5vIHJlc3BvbnNpYmls aXR5IGZvciBhbnkgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBpbiBhbnkgd2F5IGZyb20gdGhlIHVz ZSB0aGVyZW9mLlRoZSB0ZXJtICJQUklNVVMiIGluY2x1ZGVzIGl0cyBhZmZpbGlhdGVzLg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KIFBvdXIgbGEgdmVyc2lvbiBlbiBmcmFu w6dhaXMgZGUgY2UgbWVzc2FnZSwgdmV1aWxsZXogdm9pcg0KaHR0cDovL3d3dy5wcmltdXN0ZWwu Y2EvZnIvbGVnYWwvY3MuaHRtDQo= From owner-freebsd-stable@FreeBSD.ORG Tue May 22 06:29:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DD91065674; Tue, 22 May 2012 06:29:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3CF8FC22; Tue, 22 May 2012 06:29:58 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 286CDA7071; Tue, 22 May 2012 08:29:39 +0200 (CEST) Message-ID: <4FBB3268.5070105@FreeBSD.org> Date: Tue, 22 May 2012 08:30:00 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120512 Thunderbird/13.0 MIME-Version: 1.0 To: Yanhui Shen References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Something wrong with curs_threads(3X) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 06:29:58 -0000 On 2012-05-21 18:41, Yanhui Shen wrote: > In curs_threads(3X), at the beginning of the manual: > > typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int >> (*NCURSES_SCREEN_CB)(SCREEN *, void *); >> int set_escdelay(int size); >> int set_tabsize(int size); >> int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); >> int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); That's indeed a documentation error. Fixed in r235773, thanks! From owner-freebsd-stable@FreeBSD.ORG Tue May 22 11:06:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C69D106564A for ; Tue, 22 May 2012 11:06:16 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [84.201.187.147]) by mx1.freebsd.org (Postfix) with ESMTP id AFC0B8FC28 for ; Tue, 22 May 2012 11:06:15 +0000 (UTC) Received: from web24h.yandex.ru (web24h.yandex.ru [84.201.187.158]) by forward2h.mail.yandex.net (Yandex) with ESMTP id AFC95701818 for ; Tue, 22 May 2012 15:04:59 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1337684699; bh=rmsCryShg8F/CG5OK8bcbIqNI9u1V4CI63nofmQS3dI=; h=From:To:MIME-Version:Message-Id:Date:Content-Transfer-Encoding: Content-Type; b=fBqP8XRTUR65LqtQYaRd+b064MTC56nAKsv7WH2OTvuigV5fCT8siRnxTgbHiCBL7 KDrBRnfGf1CWBtxCHREN/Bg8lqG1IP9RAUY6GPoIE5VDCdISh+Wsy0c5qvDK35LB65 KSDHJzJpknjQqSgrcwAudJGkHdElnouEAgK/S9yQ= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web24h.yandex.ru (Yandex) with ESMTP id 7A35E3218001; Tue, 22 May 2012 15:04:59 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1337684699; bh=rmsCryShg8F/CG5OK8bcbIqNI9u1V4CI63nofmQS3dI=; h=From:To:MIME-Version:Message-Id:Date:Content-Transfer-Encoding: Content-Type; b=fBqP8XRTUR65LqtQYaRd+b064MTC56nAKsv7WH2OTvuigV5fCT8siRnxTgbHiCBL7 KDrBRnfGf1CWBtxCHREN/Bg8lqG1IP9RAUY6GPoIE5VDCdISh+Wsy0c5qvDK35LB65 KSDHJzJpknjQqSgrcwAudJGkHdElnouEAgK/S9yQ= Received: from [188.134.22.116] ([188.134.22.116]) by web24h.yandex.ru with HTTP; Tue, 22 May 2012 15:04:59 +0400 From: S.N.Grigoriev To: FreeBSD Stable MIME-Version: 1.0 Message-Id: <619131337684699@web24h.yandex.ru> Date: Tue, 22 May 2012 15:04:59 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Subject: (no subject) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:06:16 -0000 Hi list, I tried to build world and kernel with CLang on my 9-stable amd64 system. The following errors occured: mv -f term.h.new term.h cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/curses.tail >> curses.h.new mv -f curses.h.new curses.h cc -o make_keys -O2 -pipe -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_keys.c cc -o make_hash -O2 -pipe -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -DMAIN_PROGRAM /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/comp_hash.c cc: unrecognized option '-Qunused-arguments' cc: unrecognized option '-Qunused-arguments' cc1: error: unrecognized command line option "-Wno-empty-body" cc1: error: unrecognized command line option "-Wno-empty-body" cc1: error: unrecognized command line option "-Wno-string-plus-int" cc1: error: unrecognized command line option "-Wno-tautological-compare" cc1: error: unrecognized command line option "-Wno-parentheses-equality" cc1: error: unrecognized command line option "-Wno-string-plus-int" cc1: error: unrecognized command line option "-Wno-tautological-compare" cc1: error: unrecognized command line option "-Wno-parentheses-equality" *** Error code 1 *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error The only statement in my /etc/src.conf is `WITH_CLANG_IS_CC=yes'. Should I use additional configuration options to successfully build the system with CLang? Thanks, Serguey. From owner-freebsd-stable@FreeBSD.ORG Tue May 22 11:27:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54F38106564A for ; Tue, 22 May 2012 11:27:35 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id CCEF38FC0C for ; Tue, 22 May 2012 11:27:34 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SWnFP-0002Kl-A2 for freebsd-stable@freebsd.org; Tue, 22 May 2012 13:27:27 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SWnFP-0002x0-MD for freebsd-stable@freebsd.org; Tue, 22 May 2012 13:27:27 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <619131337684699@web24h.yandex.ru> Date: Tue, 22 May 2012 13:27:25 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <619131337684699@web24h.yandex.ru> User-Agent: Opera Mail/11.64 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.1 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_05 autolearn=disabled version=3.2.5 X-Scan-Signature: 3ced5df4177ef3a93a84b902ce7c160e Subject: Re: BuildingFreeBSDWithClang (was: Re: (no subject)) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:27:35 -0000 On Tue, 22 May 2012 13:04:59 +0200, S.N.Grigoriev wrote: > Hi list, > > I tried to build world and kernel with CLang on my 9-stable amd64 system. > The following errors occured: > > mv -f term.h.new term.h > cat > /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/curses.tail > >> curses.h.new > mv -f curses.h.new curses.h > cc -o make_keys -O2 -pipe -I. > -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses > -I/usr/src/lib/ncurses/ncurses/../ncurses > -I/usr/src/lib/ncurses/ncurses/../ncurses > -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include > -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall > -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-conversion > /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_keys.c > cc -o make_hash -O2 -pipe -I. > -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses > -I/usr/src/lib/ncurses/ncurses/../ncurses > -I/usr/src/lib/ncurses/ncurses/../ncurses > -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include > -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall > -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 > -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-conversion > -DMAIN_PROGRAM > /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/comp_hash.c > cc: unrecognized option '-Qunused-arguments' > cc: unrecognized option '-Qunused-arguments' > cc1: error: unrecognized command line option "-Wno-empty-body" > cc1: error: unrecognized command line option "-Wno-empty-body" > cc1: error: unrecognized command line option "-Wno-string-plus-int" > cc1: error: unrecognized command line option "-Wno-tautological-compare" > cc1: error: unrecognized command line option "-Wno-parentheses-equality" > cc1: error: unrecognized command line option "-Wno-string-plus-int" > cc1: error: unrecognized command line option "-Wno-tautological-compare" > cc1: error: unrecognized command line option "-Wno-parentheses-equality" > *** Error code 1 > *** Error code 1 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > The only statement in my /etc/src.conf is `WITH_CLANG_IS_CC=yes'. > Should I use additional configuration options to successfully > build the system with CLang? > > Thanks, > Serguey. http://wiki.freebsd.org/BuildingFreeBSDWithClang From owner-freebsd-stable@FreeBSD.ORG Tue May 22 14:24:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AB301065674 for ; Tue, 22 May 2012 14:24:29 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id A31E38FC12 for ; Tue, 22 May 2012 14:24:28 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id CF16CE650B; Tue, 22 May 2012 15:24:50 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=m9II/y8yRCO0 oRX2k07iG15Y2Yg=; b=FbmNcvm1kkXZQsTFu2asDduPuct2/pO1qnCh2kLkQeHt Juu/UXUVlMNdt2k12uI1PQae6H3Saxb2EhTqVe2N2e1SFgXcKWueZBJ+sYL2rh7D hFVaC5V6872fDLBS63lpVaWAWLkc6gcV6Cb6z6/dQJRMVLOrayC+4Q+4KEUr2OU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=P29zqF pFGLvp5xtHQqMsj1FLYaPAyIlGCFXE/sygJq1Tpaut0jjuHzLPEkP1i1SCZlFgZt tkPuv2Kp/BpZJC3RdF4ClCfKXQ3qHgbvMqnYktorjnpkjHR37MTZB9YAB39TiKqi lwFeUoT5qDauKn474MQhRgupqgDF7zoD9uWsQ= Received: from [192.168.2.115] (unknown [109.249.209.5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 2C3A8E64BA; Tue, 22 May 2012 15:24:48 +0100 (BST) Message-ID: <4FBBA191.30500@cran.org.uk> Date: Tue, 22 May 2012 15:24:17 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ronald Klop References: <619131337684699@web24h.yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: serguey-grigoriev@yandex.ru, freebsd-stable@freebsd.org Subject: Re: BuildingFreeBSDWithClang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:24:29 -0000 On 22/05/2012 12:27, Ronald Klop wrote: > On Tue, 22 May 2012 13:04:59 +0200, S.N.Grigoriev > wrote: > >> The only statement in my /etc/src.conf is `WITH_CLANG_IS_CC=yes'. >> Should I use additional configuration options to successfully >> build the system with CLang? The first time around clang isn't cc, so you have to also set CC=clang, CXX=clang++ and CPP=clang-cpp in src.conf . -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Tue May 22 16:04:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0847A1065674 for ; Tue, 22 May 2012 16:04:20 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 87F898FC17 for ; Tue, 22 May 2012 16:04:19 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so6359029wgb.31 for ; Tue, 22 May 2012 09:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FTpZ2yWPTFZtkSTI46SnQoBuQvC/fBONCZyON/cIhxk=; b=iDHnoY/K+XTxWf7jFh0hnXb12PKk4wTviqXJkJipXSmd53pkZUtfqW7D+XYdipnQ27 CUwmOGXj+YelZ68NFYGXvyQN+euplJEt8E44sSnbNefgCZn1DttuUNAWfqlvUusApUFY mNTvrPu5kqgO97RHK5sGo1wjiTl5KMkuj43EGbD3GXtTgcKWV+rKQcOOckF9yMSM4HiF ujpGTB9qTx88rS478/tpInK02atLhu91tLkLGwe8EIDHws8K5CC0xejeNRbWUpuDwqsy XiZNGr2hQpUmZRx9mzDaDII2eX2B2p0rtDoyu3rW3oGnhsCtKDzZc7BmZw4sr6vBfYGD Moeg== Received: by 10.180.78.233 with SMTP id e9mr36526214wix.5.1337702658469; Tue, 22 May 2012 09:04:18 -0700 (PDT) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id f19sm53083926wiw.11.2012.05.22.09.04.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 09:04:16 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <4FB8F055.9080700@zonov.org> Date: Tue, 22 May 2012 18:04:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09BCC731-0060-400D-8A25-4FB5268FA00D@freebsd.org> References: <4FAFEEEF.3040706@zonov.org> <20120513202920.GA18238@dft-labs.eu> <4FB177EE.7030808@zonov.org> <4FB8F055.9080700@zonov.org> To: Andrey Zonov X-Mailer: Apple Mail (2.1278) Cc: Mateusz Guzik , freebsd-stable Subject: Re: panic with overcommit and RACCT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 16:04:20 -0000 Wiadomo=B6=E6 napisana przez Andrey Zonov w dniu 20 maj 2012, o godz. = 15:23: > On 5/15/12 1:23 AM, Andrey Zonov wrote: >> On 5/14/12 12:29 AM, Mateusz Guzik wrote: >>> On Sun, May 13, 2012 at 09:27:11PM +0400, Andrey Zonov wrote: >>>> Hi, >>>>=20 >>>> I've got a repeatable panic on latest 9.0-STABLE and HEAD with >>>> turned on overcommit (vm.overcommit=3D1) and RACCT. >>>>=20 >>>> kgdb trace on today's HEAD: >>>>=20 >>>> #10 0xffffffff80bc3513 in calltrap () >>>> at /usr/src/sys/amd64/amd64/exception.S:228 >>>> #11 0xffffffff808aab71 in racct_set_locked (p=3D0xfffffe0005d684a0, >>>> resource=3D0, >>>> amount=3D2680) at /usr/src/sys/kern/kern_racct.c:372 >>>> #12 0xffffffff808ab645 in racct_proc_exit (p=3D0xfffffe0005d684a0) >>>> at /usr/src/sys/kern/kern_racct.c:615 >>>> #13 0xffffffff80880d69 in fork1 (td=3D0xfffffe0005b2c460, flags=3D20,= >>>> pages=3D4, >>>> procp=3D0xffffff811a36bb00, procdescp=3DVariable "procdescp" is not >>>> available. >>>> ) at /usr/src/sys/kern/kern_fork.c:943 >>>> #14 0xffffffff80882362 in sys_fork (td=3D0xfffffe0005b2c460, >>>> uap=3DVariable "uap" is not available. >>>> ) >>>> at /usr/src/sys/kern/kern_fork.c:110 >>>> #15 0xffffffff80bd7a89 in amd64_syscall (td=3D0xfffffe0005b2c460, >>>> traced=3D0) >>>> at subr_syscall.c:135 >>>> #16 0xffffffff80bc37f7 in Xfast_syscall () >>>> at /usr/src/sys/amd64/amd64/exception.S:387 >>>> #17 0x00000008024729fc in ?? () >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>>=20 >>>> Unread portion of the kernel message buffer: >>>> Kernel page fault with the following non-sleepable locks held: >>>> exclusive sleep mutex racct lock (racct lock) r =3D 0 >>>> (0xffffffff8128a7c0) locked @ /usr/src/sys/kern/kern_racct.c:614 >>>> exclusive sleep mutex process lock (process lock) r =3D 0 >>>> (0xfffffe0005d68598) locked @ /usr/src/sys/kern/kern_racct.c:603 >>>>=20 >>>=20 >>> It looks like racct_proc_exit can be called for processes without >>> properly initialized racct structure, which in turn results in this >>> panic. >>>=20 >>> Can you please test this patch: >>> http://student.agh.edu.pl/~mjguzik/patches/racct-fork.patch >>>=20 >>> ? >>>=20 >>> I was unable to reproduce panic you describe, so it was tested only = by >>> manually injecting error. Nevertheless I think you should try it. :) >>>=20 >>=20 >> Thanks, your patch fixes the panic. >=20 > Can anyone commit this fix? I've committed a slightly different fix (previous one would leak RCTL structures) in 235787; it's also attached below. Could you please test = it? I plan to MFC it in two weeks from now. Index: kern_racct.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kern_racct.c (revision 235699) +++ kern_racct.c (working copy) @@ -594,6 +594,9 @@ out: PROC_UNLOCK(child); PROC_UNLOCK(parent); =20 + if (error !=3D 0) + racct_proc_exit(child); + return (error); } =20 Index: kern_fork.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kern_fork.c (revision 235699) +++ kern_fork.c (working copy) @@ -939,8 +939,8 @@ fail: #ifdef MAC mac_proc_destroy(newproc); #endif + racct_proc_exit(newproc); fail1: - racct_proc_exit(newproc); if (vm2 !=3D NULL) vmspace_free(vm2); uma_zfree(proc_zone, newproc); --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-stable@FreeBSD.ORG Tue May 22 17:26:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87BE0106566B for ; Tue, 22 May 2012 17:26:59 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [84.201.187.147]) by mx1.freebsd.org (Postfix) with ESMTP id 293F28FC12 for ; Tue, 22 May 2012 17:26:59 +0000 (UTC) Received: from web19h.yandex.ru (web19h.yandex.ru [84.201.186.48]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 4F7497015C9; Tue, 22 May 2012 21:26:57 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1337707617; bh=Mp2QqWZxuJbLP05NXDZwuMD1g4cJqG8Ia7e6W/9TQKA=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=OzIF+IqI8qhgawNi1klfnCWWGMgDA9VYD2DR4S5808Y5eFlYEHLKnOXEG63IX0//e OxVbRJC5XrgKB42e8Chn9s8FlERRXZ4xuQ8QytWfWr14L8XW+Dnpb7J74LuPu9GYE6 fG5RfQfsgqxt6a4ypR9QwhmUce+2tsEY0ioZvDSw= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web19h.yandex.ru (Yandex) with ESMTP id E96E819A888F; Tue, 22 May 2012 21:26:56 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1337707617; bh=Mp2QqWZxuJbLP05NXDZwuMD1g4cJqG8Ia7e6W/9TQKA=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=OzIF+IqI8qhgawNi1klfnCWWGMgDA9VYD2DR4S5808Y5eFlYEHLKnOXEG63IX0//e OxVbRJC5XrgKB42e8Chn9s8FlERRXZ4xuQ8QytWfWr14L8XW+Dnpb7J74LuPu9GYE6 fG5RfQfsgqxt6a4ypR9QwhmUce+2tsEY0ioZvDSw= Received: from [188.134.22.116] ([188.134.22.116]) by web19h.yandex.ru with HTTP; Tue, 22 May 2012 21:26:56 +0400 From: S.N.Grigoriev To: Bruce Cran In-Reply-To: <4FBBA191.30500@cran.org.uk> References: <619131337684699@web24h.yandex.ru> <4FBBA191.30500@cran.org.uk> MIME-Version: 1.0 Message-Id: <877701337707616@web19h.yandex.ru> Date: Tue, 22 May 2012 21:26:56 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-stable@freebsd.org" Subject: Re: BuildingFreeBSDWithClang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:26:59 -0000 22.05.2012, 18:24, "Bruce Cran" : > On 22/05/2012 12:27, Ronald Klop wrote: > >> šOn Tue, 22 May 2012 13:04:59 +0200, S.N.Grigoriev >> š wrote: >>> šThe only statement in my /etc/src.conf is `WITH_CLANG_IS_CC=yes'. >>> šShould I use additional configuration options to successfully >>> šbuild the system with CLang? > > The first time around clang isn't cc, so you have to also set CC=clang, > CXX=clang++ and CPP=clang-cpp in src.conf . > > -- > Bruce Cran Hi Bruce, thank you for your response. Settings above have solved my problem. -- Regards, Serguey. From owner-freebsd-stable@FreeBSD.ORG Tue May 22 18:10:33 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DACEA1065678; Tue, 22 May 2012 18:10:33 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 7800F8FC0C; Tue, 22 May 2012 18:10:33 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4MIAEa5083482; Tue, 22 May 2012 11:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337710215; bh=hY9tcuw/j3DIPV8ECZk2DuyOC2EC9aFQDs/mmFjVn6o=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=Sym5+Z8bqaMXL1j7lNMUspp05AUrZtwU1vh++gvDjYbGg2+aYP0bOosPNR9vXYhi4 PjAgDOVGvOaKs8zMiulgwX1uOxZxjiJ2pr+kc44N8ALS1nsczD95Dvk47a/0X2WD1M KH20RVvEaK8ZSvZjCaZYt6wV29aw9X87g5PiGH4g= From: Sean Bruno To: Jung-uk Kim In-Reply-To: <4FB6765A.2050307@FreeBSD.org> References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 May 2012 11:10:14 -0700 Message-ID: <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 710214004 Cc: "sbruno@FreeBSD.org" , freebsd-stable Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 18:10:33 -0000 On Fri, 2012-05-18 at 09:18 -0700, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2012-05-18 01:32:09 -0400, Sean Bruno wrote: > > Looks like my AMD box isn't quite working correctly with regards > > to P-states. I noted this repeating periodically: hwpstate0: set > > freq failed, err 6 > > > > > > I noted these errors when setting the hwpstate verbose systctl on: > > > > May 17 22:28:32 Alice kernel: hwpstate0: set freq failed, err 6 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu0 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu0 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu1 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu1 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu2 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu2 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu3 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu3 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu4 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu4 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu5 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu5 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu6 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu6 May > > 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu7 May > > 17 22:28:32 Alice kernel: hwpstate0: result P1-state on cpu7 > > > > > > Sean > > > > ref this machine: http://forums.pcbsd.org/showthread.php?t=16733 > > I briefly looked at the dmesg. You have a Family 15h processor > (Bulldozer with Turbo Core) and I believe it isn't supported (yet). > It won't be too hard to implement, though. > > Jung-uk Kim I'm assuming, something like this to start? http://people.freebsd.org/~sbruno/bulldozer.txt I'm reading the AMD spec, and that *seems* to be right? But, chances are I have no idea what I'm doing. :-) Sean From owner-freebsd-stable@FreeBSD.ORG Tue May 22 19:47:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5A25106567D; Tue, 22 May 2012 19:47:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 43C338FC15; Tue, 22 May 2012 19:47:27 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q4MJlQi5008841; Tue, 22 May 2012 19:47:26 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q4MJlQwQ008840; Tue, 22 May 2012 19:47:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 22 May 2012 19:47:26 GMT Message-Id: <201205221947.q4MJlQwQ008840@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 19:47:27 -0000 TB --- 2012-05-22 17:55:15 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-05-22 17:55:15 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-05-22 17:55:15 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2012-05-22 17:55:15 - cleaning the object tree TB --- 2012-05-22 17:55:15 - cvsupping the source tree TB --- 2012-05-22 17:55:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/ia64/ia64/supfile TB --- 2012-05-22 17:56:17 - building world TB --- 2012-05-22 17:56:17 - CROSS_BUILD_TESTING=YES TB --- 2012-05-22 17:56:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-22 17:56:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-22 17:56:17 - SRCCONF=/dev/null TB --- 2012-05-22 17:56:17 - TARGET=ia64 TB --- 2012-05-22 17:56:17 - TARGET_ARCH=ia64 TB --- 2012-05-22 17:56:17 - TZ=UTC TB --- 2012-05-22 17:56:17 - __MAKE_CONF=/dev/null TB --- 2012-05-22 17:56:17 - cd /src TB --- 2012-05-22 17:56:17 - /usr/bin/make -B buildworld >>> World build started on Tue May 22 17:56:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 22 19:42:47 UTC 2012 TB --- 2012-05-22 19:42:47 - generating LINT kernel config TB --- 2012-05-22 19:42:47 - cd /src/sys/ia64/conf TB --- 2012-05-22 19:42:47 - /usr/bin/make -B LINT TB --- 2012-05-22 19:42:47 - cd /src/sys/ia64/conf TB --- 2012-05-22 19:42:47 - /usr/sbin/config -m LINT TB --- 2012-05-22 19:42:47 - building LINT kernel TB --- 2012-05-22 19:42:47 - CROSS_BUILD_TESTING=YES TB --- 2012-05-22 19:42:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-22 19:42:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-22 19:42:47 - SRCCONF=/dev/null TB --- 2012-05-22 19:42:47 - TARGET=ia64 TB --- 2012-05-22 19:42:47 - TARGET_ARCH=ia64 TB --- 2012-05-22 19:42:47 - TZ=UTC TB --- 2012-05-22 19:42:47 - __MAKE_CONF=/dev/null TB --- 2012-05-22 19:42:47 - cd /src TB --- 2012-05-22 19:42:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 22 19:42:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything -------------------------------------------------------------- cd /obj/ia64.ia64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/ia64.ia64 MACHINE_ARCH=ia64 MACHINE=ia64 CPUTYPE= GROFF_BIN_PATH=/obj/ia64.ia64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/ia64.ia64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/ia64.ia64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/ia64.ia64/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/ia64.ia64/src/tmp/legacy/usr/sbin:/obj/ia64.ia64/src/tmp/legacy/usr/bin:/obj/ia64.ia64/src/tmp/legacy/usr/games:/obj/ia64.ia64/src/tmp/usr/sbin:/obj/ia64.ia64/src/tmp/usr/bin:/obj/ia64.ia64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/locore.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror aic7xxx_reg_print.c In file included from /src/sys/sys/types.h:41, from /src/sys/sys/param.h:86, from /src/sys/dev/aic7xxx/aic7xxx_osm.h:42, from aic7xxx_reg_print.c:9: /src/sys/sys/cdefs.h:312:5: error: "__cplusplus" is not defined *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-22 19:47:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-22 19:47:26 - ERROR: failed to build LINT kernel TB --- 2012-05-22 19:47:26 - 4437.92 user 715.30 system 6731.02 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue May 22 19:56:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17B2106567C for ; Tue, 22 May 2012 19:56:12 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0E48FC1B for ; Tue, 22 May 2012 19:56:12 +0000 (UTC) Received: by laai10 with SMTP id i10so6654259laa.13 for ; Tue, 22 May 2012 12:56:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=K706xEoD4VGKEpsa78WlnzmlChk1avmS1MtFGVgc1Ms=; b=GcH815HPpIuzI6+9WH12bTHPzwV5SeluWJh8tzpPo2fPU40E75PczpCmg6R/f58a5Q 5axg+rUOyT0e8FzWA25cgXaG8X2w5adrva4471QU4wqvd3AGw9+O91sRZtpf0BoSzN2T ZbOIrJevyg4sjIHrRLgQiGzBVPxQcKwJ+c3eCBXVHqI5BS9sHFuRNyaZrKxF1Q72ojvh 2CA3VCZYqVwEl3e5UXo5T65lj2mR/ib+5HKkHvT9J9BFcUUI8Ac81qzMqkluGmw+pTWB haoGbgD54AP8UH+eBzlALhdUzA7/oMnbKFWWAm78bBR0WGd/NAdJ2QHLH+8HnaIe8dPA UL9g== Received: by 10.112.36.163 with SMTP id r3mr10571184lbj.87.1337716571119; Tue, 22 May 2012 12:56:11 -0700 (PDT) Received: from zont-osx.local (ppp95-165-130-190.pppoe.spdop.ru. [95.165.130.190]) by mx.google.com with ESMTPS id ta2sm32498232lab.15.2012.05.22.12.56.09 (version=SSLv3 cipher=OTHER); Tue, 22 May 2012 12:56:10 -0700 (PDT) Message-ID: <4FBBEF58.6060604@zonov.org> Date: Tue, 22 May 2012 23:56:08 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= References: <4FAFEEEF.3040706@zonov.org> <20120513202920.GA18238@dft-labs.eu> <4FB177EE.7030808@zonov.org> <4FB8F055.9080700@zonov.org> <09BCC731-0060-400D-8A25-4FB5268FA00D@freebsd.org> In-Reply-To: <09BCC731-0060-400D-8A25-4FB5268FA00D@freebsd.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnvkKQJjIC6S802CE9MA03TN0TxDwCxGwY4JHEjfdgsn0avWuchABXg1Nd8YMuf1GXTFyYH Cc: Mateusz Guzik , freebsd-stable Subject: Re: panic with overcommit and RACCT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 19:56:12 -0000 On 5/22/12 8:04 PM, Edward Tomasz Napiera³a wrote: > Wiadomo¶æ napisana przez Andrey Zonov w dniu 20 maj 2012, o godz. 15:23: >> On 5/15/12 1:23 AM, Andrey Zonov wrote: >>> On 5/14/12 12:29 AM, Mateusz Guzik wrote: >>>> On Sun, May 13, 2012 at 09:27:11PM +0400, Andrey Zonov wrote: >>>>> Hi, >>>>> >>>>> I've got a repeatable panic on latest 9.0-STABLE and HEAD with >>>>> turned on overcommit (vm.overcommit=1) and RACCT. >>>>> >>>>> kgdb trace on today's HEAD: >>>>> >>>>> #10 0xffffffff80bc3513 in calltrap () >>>>> at /usr/src/sys/amd64/amd64/exception.S:228 >>>>> #11 0xffffffff808aab71 in racct_set_locked (p=0xfffffe0005d684a0, >>>>> resource=0, >>>>> amount=2680) at /usr/src/sys/kern/kern_racct.c:372 >>>>> #12 0xffffffff808ab645 in racct_proc_exit (p=0xfffffe0005d684a0) >>>>> at /usr/src/sys/kern/kern_racct.c:615 >>>>> #13 0xffffffff80880d69 in fork1 (td=0xfffffe0005b2c460, flags=20, >>>>> pages=4, >>>>> procp=0xffffff811a36bb00, procdescp=Variable "procdescp" is not >>>>> available. >>>>> ) at /usr/src/sys/kern/kern_fork.c:943 >>>>> #14 0xffffffff80882362 in sys_fork (td=0xfffffe0005b2c460, >>>>> uap=Variable "uap" is not available. >>>>> ) >>>>> at /usr/src/sys/kern/kern_fork.c:110 >>>>> #15 0xffffffff80bd7a89 in amd64_syscall (td=0xfffffe0005b2c460, >>>>> traced=0) >>>>> at subr_syscall.c:135 >>>>> #16 0xffffffff80bc37f7 in Xfast_syscall () >>>>> at /usr/src/sys/amd64/amd64/exception.S:387 >>>>> #17 0x00000008024729fc in ?? () >>>>> Previous frame inner to this frame (corrupt stack?) >>>>> (kgdb) >>>>> >>>>> Unread portion of the kernel message buffer: >>>>> Kernel page fault with the following non-sleepable locks held: >>>>> exclusive sleep mutex racct lock (racct lock) r = 0 >>>>> (0xffffffff8128a7c0) locked @ /usr/src/sys/kern/kern_racct.c:614 >>>>> exclusive sleep mutex process lock (process lock) r = 0 >>>>> (0xfffffe0005d68598) locked @ /usr/src/sys/kern/kern_racct.c:603 >>>>> >>>> >>>> It looks like racct_proc_exit can be called for processes without >>>> properly initialized racct structure, which in turn results in this >>>> panic. >>>> >>>> Can you please test this patch: >>>> http://student.agh.edu.pl/~mjguzik/patches/racct-fork.patch >>>> >>>> ? >>>> >>>> I was unable to reproduce panic you describe, so it was tested only by >>>> manually injecting error. Nevertheless I think you should try it. :) >>>> >>> >>> Thanks, your patch fixes the panic. >> >> Can anyone commit this fix? > > I've committed a slightly different fix (previous one would leak RCTL > structures) in 235787; it's also attached below. Could you please test it? Thanks, it works! > I plan to MFC it in two weeks from now. Much appreciate. > > Index: kern_racct.c > =================================================================== > --- kern_racct.c (revision 235699) > +++ kern_racct.c (working copy) > @@ -594,6 +594,9 @@ out: > PROC_UNLOCK(child); > PROC_UNLOCK(parent); > > + if (error != 0) > + racct_proc_exit(child); > + > return (error); > } > > Index: kern_fork.c > =================================================================== > --- kern_fork.c (revision 235699) > +++ kern_fork.c (working copy) > @@ -939,8 +939,8 @@ fail: > #ifdef MAC > mac_proc_destroy(newproc); > #endif > + racct_proc_exit(newproc); > fail1: > - racct_proc_exit(newproc); > if (vm2 != NULL) > vmspace_free(vm2); > uma_zfree(proc_zone, newproc); > -- Andrey Zonov From owner-freebsd-stable@FreeBSD.ORG Tue May 22 20:27:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7F8D106564A; Tue, 22 May 2012 20:27:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCCE8FC14; Tue, 22 May 2012 20:27:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 7B39EA7071; Tue, 22 May 2012 22:27:36 +0200 (CEST) Message-ID: <4FBBF6CB.3060107@FreeBSD.org> Date: Tue, 22 May 2012 22:27:55 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120512 Thunderbird/13.0 MIME-Version: 1.0 To: FreeBSD Tinderbox References: <201205221947.q4MJlQwQ008840@freebsd-stable.sentex.ca> In-Reply-To: <201205221947.q4MJlQwQ008840@freebsd-stable.sentex.ca> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, David Chisnall , ia64@freebsd.org Subject: Re: [releng_9 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 20:27:56 -0000 On 2012-05-22 21:47, FreeBSD Tinderbox wrote: ... > In file included from /src/sys/sys/types.h:41, > from /src/sys/sys/param.h:86, > from /src/sys/dev/aic7xxx/aic7xxx_osm.h:42, > from aic7xxx_reg_print.c:9: > /src/sys/sys/cdefs.h:312:5: error: "__cplusplus" is not defined Should now be fixed in r235806, by MFCing just one more change... :) From owner-freebsd-stable@FreeBSD.ORG Tue May 22 22:35:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61F7106564A; Tue, 22 May 2012 22:35:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 584FF8FC08; Tue, 22 May 2012 22:35:52 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q4MMZpef079711; Tue, 22 May 2012 22:35:51 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q4MMZphA079692; Tue, 22 May 2012 22:35:51 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 22 May 2012 22:35:51 GMT Message-Id: <201205222235.q4MMZphA079692@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 22:35:53 -0000 TB --- 2012-05-22 19:47:26 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-05-22 19:47:26 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-05-22 19:47:26 - starting RELENG_9 tinderbox run for powerpc/powerpc TB --- 2012-05-22 19:47:26 - cleaning the object tree TB --- 2012-05-22 19:47:26 - cvsupping the source tree TB --- 2012-05-22 19:47:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/powerpc/powerpc/supfile TB --- 2012-05-22 19:48:07 - building world TB --- 2012-05-22 19:48:07 - CROSS_BUILD_TESTING=YES TB --- 2012-05-22 19:48:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-22 19:48:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-22 19:48:07 - SRCCONF=/dev/null TB --- 2012-05-22 19:48:07 - TARGET=powerpc TB --- 2012-05-22 19:48:07 - TARGET_ARCH=powerpc TB --- 2012-05-22 19:48:07 - TZ=UTC TB --- 2012-05-22 19:48:07 - __MAKE_CONF=/dev/null TB --- 2012-05-22 19:48:07 - cd /src TB --- 2012-05-22 19:48:07 - /usr/bin/make -B buildworld >>> World build started on Tue May 22 19:48:08 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 22 22:30:54 UTC 2012 TB --- 2012-05-22 22:30:54 - generating LINT kernel config TB --- 2012-05-22 22:30:54 - cd /src/sys/powerpc/conf TB --- 2012-05-22 22:30:54 - /usr/bin/make -B LINT TB --- 2012-05-22 22:30:54 - cd /src/sys/powerpc/conf TB --- 2012-05-22 22:30:54 - /usr/sbin/config -m LINT TB --- 2012-05-22 22:30:54 - building LINT kernel TB --- 2012-05-22 22:30:54 - CROSS_BUILD_TESTING=YES TB --- 2012-05-22 22:30:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-22 22:30:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-22 22:30:54 - SRCCONF=/dev/null TB --- 2012-05-22 22:30:54 - TARGET=powerpc TB --- 2012-05-22 22:30:54 - TARGET_ARCH=powerpc TB --- 2012-05-22 22:30:54 - TZ=UTC TB --- 2012-05-22 22:30:54 - __MAKE_CONF=/dev/null TB --- 2012-05-22 22:30:54 - cd /src TB --- 2012-05-22 22:30:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 22 22:30:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything -------------------------------------------------------------- cd /obj/powerpc.powerpc/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc MACHINE_ARCH=powerpc MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc/src/tmp/legacy/usr/games:/obj/powerpc.powerpc/src/tmp/usr/sbin:/obj/powerpc.powerpc/src/tmp/usr/bin:/obj/powerpc.powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/locore.S In file included from ./machine/asm.h:38, from /src/sys/powerpc/aim/locore32.S:66, from /src/sys/powerpc/aim/locore.S:6: /src/sys/sys/cdefs.h:312:5: error: "__cplusplus" is not defined *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-22 22:35:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-22 22:35:51 - ERROR: failed to build LINT kernel TB --- 2012-05-22 22:35:51 - 6776.07 user 956.64 system 10104.88 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue May 22 23:29:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B098E1065672; Tue, 22 May 2012 23:29:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 55F048FC16; Tue, 22 May 2012 23:29:06 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q4MNT5Hx065002; Tue, 22 May 2012 23:29:05 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q4MNT5qn065001; Tue, 22 May 2012 23:29:05 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 22 May 2012 23:29:05 GMT Message-Id: <201205222329.q4MNT5qn065001@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 23:29:06 -0000 TB --- 2012-05-22 20:29:49 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-05-22 20:29:49 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-05-22 20:29:49 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2012-05-22 20:29:49 - cleaning the object tree TB --- 2012-05-22 20:29:49 - cvsupping the source tree TB --- 2012-05-22 20:29:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/powerpc64/powerpc/supfile TB --- 2012-05-22 20:30:53 - building world TB --- 2012-05-22 20:30:53 - CROSS_BUILD_TESTING=YES TB --- 2012-05-22 20:30:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-22 20:30:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-22 20:30:53 - SRCCONF=/dev/null TB --- 2012-05-22 20:30:53 - TARGET=powerpc TB --- 2012-05-22 20:30:53 - TARGET_ARCH=powerpc64 TB --- 2012-05-22 20:30:53 - TZ=UTC TB --- 2012-05-22 20:30:53 - __MAKE_CONF=/dev/null TB --- 2012-05-22 20:30:53 - cd /src TB --- 2012-05-22 20:30:53 - /usr/bin/make -B buildworld >>> World build started on Tue May 22 20:30:54 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue May 22 23:26:25 UTC 2012 TB --- 2012-05-22 23:26:25 - generating LINT kernel config TB --- 2012-05-22 23:26:25 - cd /src/sys/powerpc/conf TB --- 2012-05-22 23:26:25 - /usr/bin/make -B LINT TB --- 2012-05-22 23:26:25 - cd /src/sys/powerpc/conf TB --- 2012-05-22 23:26:25 - /usr/sbin/config -m LINT TB --- 2012-05-22 23:26:25 - building LINT kernel TB --- 2012-05-22 23:26:25 - CROSS_BUILD_TESTING=YES TB --- 2012-05-22 23:26:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-22 23:26:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-22 23:26:25 - SRCCONF=/dev/null TB --- 2012-05-22 23:26:25 - TARGET=powerpc TB --- 2012-05-22 23:26:25 - TARGET_ARCH=powerpc64 TB --- 2012-05-22 23:26:25 - TZ=UTC TB --- 2012-05-22 23:26:25 - __MAKE_CONF=/dev/null TB --- 2012-05-22 23:26:25 - cd /src TB --- 2012-05-22 23:26:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 22 23:26:25 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything -------------------------------------------------------------- cd /obj/powerpc.powerpc64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/locore.S In file included from ./machine/asm.h:38, from /src/sys/powerpc/aim/locore64.S:66, from /src/sys/powerpc/aim/locore.S:4: /src/sys/sys/cdefs.h:312:5: error: "__cplusplus" is not defined *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-22 23:29:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-22 23:29:05 - ERROR: failed to build LINT kernel TB --- 2012-05-22 23:29:05 - 7646.73 user 1127.56 system 10756.12 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Wed May 23 09:29:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 300C8106566B; Wed, 23 May 2012 09:29:58 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9BF8FC14; Wed, 23 May 2012 09:29:56 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.5/8.14.5) with ESMTP id q4N9Trj3033921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2012 11:29:53 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.5/8.14.5/Submit) with ESMTP id q4N9Tq7w033918; Wed, 23 May 2012 11:29:53 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 23 May 2012 11:29:52 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable , theraven@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-598042349-1337765393=:84474" X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SUBJ_OBFU_PUNCT_FEW,SUBJ_OBFU_PUNCT_MANY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: Subject: RELENG_9 fails to compile with WITH_LIBCPLUSPLUS=yes in /etc/src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 09:29:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-598042349-1337765393=:84474 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Error messages produced during make buildworld, run with serial execution: ===> lib/libc++ (depend) rm -f .depend CC='gcc' mkdep -f .depend -a -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp! /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:591, from /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/functional:462, from /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/chrono:254, from /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/chrono:254, from /usr/src/lib/libc++/../../contrib/libc++/include/__mutex_base:15, from /usr/src/lib/libc++/../../contrib/libc++/include/condition_variable:111, from /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/functional:462, from /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp:13: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/exception:81, from /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp:11: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/system_error:222, from /usr/src/lib/libc++/../../contrib/libc++/include/future:366, from /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/memory:589, from /usr/src/lib/libc++/../../contrib/libc++/include/__hash_table:16, from /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:591, from /usr/src/lib/libc++/../../contrib/libc++/include/string:434, from /usr/src/lib/libc++/../../contrib/libc++/include/__locale:15, from /usr/src/lib/libc++/../../contrib/libc++/include/ios:216, from /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:591, from /usr/src/lib/libc++/../../contrib/libc++/include/string:434, from /usr/src/lib/libc++/../../contrib/libc++/include/__locale:15, from /usr/src/lib/libc++/../../contrib/libc++/include/ios:216, from /usr/src/lib/libc++/../../contrib/libc++/include/ostream:130, from /usr/src/lib/libc++/../../contrib/libc++/include/__std_stream:15, from /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:591, from /usr/src/lib/libc++/../../contrib/libc++/include/string:434, from /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:16: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/memory:589, from /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/chrono:254, from /usr/src/lib/libc++/../../contrib/libc++/include/__mutex_base:15, from /usr/src/lib/libc++/../../contrib/libc++/include/mutex:176, from /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/exception:81, from /usr/src/lib/libc++/../../contrib/libc++/include/new:56, from /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp:12: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/random:1637, from /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/exception:81, from /usr/src/lib/libc++/../../contrib/libc++/include/stdexcept:46, from /usr/src/lib/libc++/../../contrib/libc++/include/regex:725, from /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/exception:81, from /usr/src/lib/libc++/../../contrib/libc++/include/stdexcept:46, from /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:591, from /usr/src/lib/libc++/../../contrib/libc++/include/string:434, from /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:591, from /usr/src/lib/libc++/../../contrib/libc++/include/string:434, from /usr/src/lib/libc++/../../contrib/libc++/include/__locale:15, from /usr/src/lib/libc++/../../contrib/libc++/include/ios:216, from /usr/src/lib/libc++/../../contrib/libc++/include/ostream:130, from /usr/src/lib/libc++/../../contrib/libc++/include/strstream:131, from /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/system_error:222, from /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/__functional_base:15, from /usr/src/lib/libc++/../../contrib/libc++/include/thread:90, from /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/exception:81, from /usr/src/lib/libc++/../../contrib/libc++/include/typeinfo:61, from /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp:14: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/__tuple:16, from /usr/src/lib/libc++/../../contrib/libc++/include/utility:125, from /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp:11: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. In file included from /usr/src/lib/libc++/../../contrib/libc++/include/cmath:302, from /usr/src/lib/libc++/../../contrib/libc++/include/valarray:344, from /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp:10: /usr/src/lib/libc++/../../contrib/libc++/include/type_traits:731:2: error: #error is_base_of not implemented. mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libc++. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Script done on Wed May 23 10:50:34 2012 I'm probably missing something as make buildworld runs smoothly without WITH_LIBCPLUSPLUS=yes in /etc/src.conf. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. dir. 61 14 54 39, | Office.....: +47 61 14 54 39, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-598042349-1337765393=:84474-- From owner-freebsd-stable@FreeBSD.ORG Wed May 23 09:32:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229CA106567E for ; Wed, 23 May 2012 09:32:58 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id E77EA8FC1B for ; Wed, 23 May 2012 09:32:57 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust790.5-4.cable.virginmedia.com [86.26.15.23]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q4N9WEDF071226 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO) for ; Wed, 23 May 2012 09:32:57 GMT (envelope-from theraven@freebsd.org) From: David Chisnall Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 23 May 2012 10:32:56 +0100 Message-Id: To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Subject: libc++ has landed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 09:32:58 -0000 Hi Everyone, I have just finished merging libc++ and all of the things that it = depends on into 9-STABLE. Since 9.1 is due to branch Real Soon Now=99, = it would be good if it could see a bit of testing before then. Because = it uses C++11, libc++ will only work if built with clang, so it is = disabled in the default build for now. To build it, you will need to = add the following to your /etc/src.conf: CC=3Dclang CXX=3Dclang++ CPP=3Dclang-cpp WITH_LIBCPLUSPLUS=3Dyes You can then just make && make install in lib/libcxxrt and lib/libc++. = This requires a (very) recent libc, containing the xlocale APIs, so = you'll also need to reinstall lib/libc and include. If you want to try = mixing libstdc++ and libc++, then you will need to also recompile / = install libstdc++ from stable. This depends on some rtld-elf fixes, so = it's probably worth rebuilding world to make sure that you have = everything. =20 Once all of this is installed, there are two things you can test. The = simplest is the libstdc++ / libcxxrt combination. To do this, just add = this to /etc/libmap.conf: libsupc++.so.1 libcxxrt.so.1 This will use libcxxrt instead of libsupc++. These libraries implement = the low-level parts of C++ (RTTI, exceptions, and so on). The other = thing that you can try is compiling other C++ code using libc++. This = is trivial to do with clang++, just add -stdlib=3Dlibc++ to both your = CXXFLAGS and LDFLAGS. David= From owner-freebsd-stable@FreeBSD.ORG Wed May 23 09:33:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CEFF106564A for ; Wed, 23 May 2012 09:33:00 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id B29CB8FC14 for ; Wed, 23 May 2012 09:32:59 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust790.5-4.cable.virginmedia.com [86.26.15.23]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q4N9WEDE071226 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 23 May 2012 09:32:16 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: Date: Wed, 23 May 2012 10:32:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Trond_Endrest=F8l?= X-Mailer: Apple Mail (2.1257) Cc: FreeBSD stable Subject: Re: RELENG_9 fails to compile with WITH_LIBCPLUSPLUS=yes in /etc/src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 09:33:00 -0000 On 23 May 2012, at 10:29, Trond Endrest=F8l wrote: > CC=3D'gcc'=20 > something as make buildworld runs smoothly=20 > without WITH_LIBCPLUSPLUS=3Dyes in /etc/src.conf. You are trying to build C++11 code with a C++98 compiler. If you want = to build libc++, you must be using clang++. There is a reason it's not = enabled by default... David= From owner-freebsd-stable@FreeBSD.ORG Wed May 23 12:39:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77E591065778; Wed, 23 May 2012 12:39:34 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id ECF998FC0C; Wed, 23 May 2012 12:39:33 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.5/8.14.5) with ESMTP id q4NCdRNu036997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2012 14:39:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.5/8.14.5/Submit) with ESMTP id q4NCdQAF036994; Wed, 23 May 2012 14:39:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 23 May 2012 14:39:26 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: David Chisnall In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-753880139-1337776767=:84474" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: FreeBSD stable Subject: Re: RELENG_9 fails to compile with WITH_LIBCPLUSPLUS=yes in /etc/src.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 12:39:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-753880139-1337776767=:84474 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 23 May 2012 10:32+0100, David Chisnall wrote: > You are trying to build C++11 code with a C++98 compiler. If you > want to build libc++, you must be using clang++. There is a reason > it's not enabled by default... Right, my bad. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. dir. 61 14 54 39, | Office.....: +47 61 14 54 39, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-753880139-1337776767=:84474-- From owner-freebsd-stable@FreeBSD.ORG Wed May 23 13:11:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6B8106564A for ; Wed, 23 May 2012 13:11:50 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id C36348FC19 for ; Wed, 23 May 2012 13:11:49 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SXBLw-000Fgt-FK for freebsd-stable@freebsd.org; Wed, 23 May 2012 14:11:48 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXBLw-000AZw-Ee for freebsd-stable@freebsd.org; Wed, 23 May 2012 14:11:48 +0100 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Wed, 23 May 2012 14:11:48 +0100 Subject: VirtualBox, AIO and zvol's - a cautionary tale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:11:50 -0000 Am posting this to stable not really as a question, but more in case anyone else hits the same problem. Last patch tuesday one of my virtual Windows machines running under VirtualBox started crashing. By which I mean that VirtualBox would quit. This had been running tsably for a long tine, so it puzzled me. First thought was it was sme patch from patch-tuesday. But rolling back to an earlier version of the disc showed it wasn't - the crashes were occurring before the patch had been applied. I'll skip the hours of puzzlement which followed - it turrned out that the indirect cause was that a few weeks ago I had installed Samba onto the same server. In doing so I had enabled AIO, as this improves Samba performance. What I didn't realise is that if VirtualBox finds AIO loaded it proceeds to use it. So by doing that I had switched on AIO inside my virtual machines as well. The disc I use for my virtual machines are all zvols (it performs better, and it seems that VirtualBox has a problem using AIO to access zvols. But this didn;t show up for weeks because in the normal scheme of things my virtual machines dont acccess the local dirve very much. It was only when they started downloading patches that the crash happened. Solution is simple - disable AIO. All then goes back to being nice and stable again. But it did take a while to find. Hope someone else finds the info usefull! -pete. From owner-freebsd-stable@FreeBSD.ORG Wed May 23 14:22:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A52111065687 for ; Wed, 23 May 2012 14:22:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 548468FC19 for ; Wed, 23 May 2012 14:22:56 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q4NEMsmY073480; Wed, 23 May 2012 10:22:54 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4FBCF2B6.1060200@sentex.net> Date: Wed, 23 May 2012 10:22:46 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matthew Gamble References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: "freebsd-stable@freebsd.org" Subject: Re: siis_timeout with port multiplier on 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:22:56 -0000 On 5/21/2012 9:04 PM, Matthew Gamble wrote: > We have a box with 3 SiI3124 SATA controllers and 9 CFI-B53PM 5 Port Backplane port multipliers (the "backblaze storage pod"). Under intense IO (ZFS rebuild, presently) the system will lock up all IO for 3-4 minutes and the following entry appears in the dmesg: > > siisch11: Timeout on slot 30 > siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr 00000000 > siisch11: ... waiting for slots 25000000 > siisch11: Timeout on slot 26 > siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr 00000000 > siisch11: ... waiting for slots 21000000 > siisch11: Timeout on slot 29 > siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr 00000000 > siisch11: ... waiting for slots 01000000 > siisch11: Timeout on slot 24 > siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr 00000000 > > The errors are on different siisch devices so its not likely to be a SATA cable issue unless multiple cables all went bad at the same time. On the advice of some other posts to the mailing list I've already tried locking the SATA rev to one with the following in /boot/loader.conf which didn't If they are on different siisch devices then yes, it does not sound like a bad cable. However, I have had that issue with similar errors above that were fixed by using new cables. If you are using 9.0R, I would suggest upgrading to stable. There have been a few bug fixes / improvements to the drivers as well as various parts of the disk subsystem. I have RELENG8 right now and its quite stable for me on a 25TB system which is for the most part similar to 9.x # zpool status pool: zbackup1 state: ONLINE scan: scrub repaired 0 in 11h11m with 0 errors on Mon Jul 25 19:51:11 2011 config: NAME STATE READ WRITE CKSUM zbackup1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada14 ONLINE 0 0 0 ada16 ONLINE 0 0 0 ada13 ONLINE 0 0 0 ada15 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada7 ONLINE 0 0 0 raidz1-3 ONLINE 0 0 0 ada9 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada11 ONLINE 0 0 0 ada12 ONLINE 0 0 0 errors: No known data errors # zpool get all zbackup1 NAME PROPERTY VALUE SOURCE zbackup1 size 25.4T - zbackup1 capacity 68% - zbackup1 altroot - default zbackup1 health ONLINE - zbackup1 guid 917659042733882722 default zbackup1 version 28 default zbackup1 bootfs - default zbackup1 delegation on default zbackup1 autoreplace off default zbackup1 cachefile - default zbackup1 failmode wait default zbackup1 listsnapshots on local zbackup1 autoexpand off default zbackup1 dedupditto 0 default zbackup1 dedupratio 1.00x - zbackup1 free 7.95T - zbackup1 allocated 17.4T - zbackup1 readonly off - zbackup1 comment - default This is on an adonics adaptor. ---Mike > > hint.siisch.0.sata_rev=1 > hint.siisch.1.sata_rev=1 > hint.siisch.2.sata_rev=1 > hint.siisch.3.sata_rev=1 > hint.siisch.4.sata_rev=1 > hint.siisch.5.sata_rev=1 > hint.siisch.6.sata_rev=1 > hint.siisch.7.sata_rev=1 > hint.siisch.8.sata_rev=1 > hint.siisch.9.sata_rev=1 > hint.siisch.10.sata_rev=1 > hint.siisch.11.sata_rev=1 > > From time to time this is also causing one of the attached drives to go offline: > > siisch0: siis_timeout is 00040000 ss 40000000 rs 40000000 es 00000000 sts 801f2000 serr 00000000 > (ada0:siisch0:0:0:0): lost device > (ada0:siisch0:0:0:0): removing device entry > ada0 at siisch0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > siisch11: Timeout on slot 30 > > When the drive goes offline that causes the ZFS rebuild to restart, and so it's never finishing the rebuild of the array. Does anyone have any insight into what could be causing the timeouts and what we can do to resolve them? Right now my priority is to get the system a bit more stable so the current ZFS rebuild can complete – right now it's been doing the same rebuild for just over 6 days and the timeouts and drive drop offs are causing it to restart constantly. > > > > > > ________________________________ > > This electronic message contains information from Primus Telecommunications Canada Inc. ("PRIMUS") , which may be legally privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or advice expressed in this electronic message are not necessarily the views, opinions or advice of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use thereof.The term "PRIMUS" includes its affiliates. > > ________________________________ > Pour la version en français de ce message, veuillez voir > http://www.primustel.ca/fr/legal/cs.htm > > > > _______________________________________________ > 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" -- ------------------- 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/ From owner-freebsd-stable@FreeBSD.ORG Wed May 23 15:54:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F4E106564A for ; Wed, 23 May 2012 15:54:44 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 82BB18FC08 for ; Wed, 23 May 2012 15:54:44 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id B90B71CC48; Wed, 23 May 2012 12:54:36 -0300 (BRT) Received: from 187.114.205.118 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Wed, 23 May 2012 12:54:36 -0300 Message-ID: <460e1bd626613f125b878f5be65a6b6e.squirrel@eternamente.info> In-Reply-To: <4FBCF2B6.1060200@sentex.net> References: <4FBCF2B6.1060200@sentex.net> Date: Wed, 23 May 2012 12:54:36 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: siis_timeout with port multiplier on 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:54:44 -0000 On Wed, May 23, 2012 11:22, Mike Tancsa wrote: > On 5/21/2012 9:04 PM, Matthew Gamble wrote: >> We have a box with 3 SiI3124 SATA controllers and 9 CFI-B53PM 5 Port Backplane port multipliers >> (the "backblaze storage pod"). Under intense IO (ZFS rebuild, presently) the system will lock >> up all IO for 3-4 minutes and the following entry appears in the dmesg: >> >> siisch11: Timeout on slot 30 >> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >> 00000000 >> siisch11: ... waiting for slots 25000000 >> siisch11: Timeout on slot 26 >> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >> 00000000 >> siisch11: ... waiting for slots 21000000 >> siisch11: Timeout on slot 29 >> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >> 00000000 >> siisch11: ... waiting for slots 01000000 >> siisch11: Timeout on slot 24 >> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >> 00000000 >> >> The errors are on different siisch devices so its not likely to be a SATA cable issue unless >> multiple cables all went bad at the same time. On the advice of some other posts to the mailing >> list I've already tried locking the SATA rev to one with the following in /boot/loader.conf >> which didn't > > If they are on different siisch devices then yes, it does not sound like > a bad cable. However, I have had that issue with similar errors above > that were fixed by using new cables. If you are using 9.0R, I would > suggest upgrading to stable. There have been a few bug fixes / > improvements to the drivers as well as various parts of the disk > subsystem. I have RELENG8 right now and its quite stable for me on a > 25TB system which is for the most part similar to 9.x > > # zpool status > pool: zbackup1 > state: ONLINE > scan: scrub repaired 0 in 11h11m with 0 errors on Mon Jul 25 19:51:11 2011 > config: > > NAME STATE READ WRITE CKSUM > zbackup1 ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > ada14 ONLINE 0 0 0 > ada16 ONLINE 0 0 0 > ada13 ONLINE 0 0 0 > ada15 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > ada0 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > raidz1-2 ONLINE 0 0 0 > ada4 ONLINE 0 0 0 > ada5 ONLINE 0 0 0 > ada6 ONLINE 0 0 0 > ada7 ONLINE 0 0 0 > raidz1-3 ONLINE 0 0 0 > ada9 ONLINE 0 0 0 > ada10 ONLINE 0 0 0 > ada11 ONLINE 0 0 0 > ada12 ONLINE 0 0 0 > > errors: No known data errors > # zpool get all zbackup1 > NAME PROPERTY VALUE SOURCE > zbackup1 size 25.4T - > zbackup1 capacity 68% - > zbackup1 altroot - default > zbackup1 health ONLINE - > zbackup1 guid 917659042733882722 default > zbackup1 version 28 default > zbackup1 bootfs - default > zbackup1 delegation on default > zbackup1 autoreplace off default > zbackup1 cachefile - default > zbackup1 failmode wait default > zbackup1 listsnapshots on local > zbackup1 autoexpand off default > zbackup1 dedupditto 0 default > zbackup1 dedupratio 1.00x - > zbackup1 free 7.95T - > zbackup1 allocated 17.4T - > zbackup1 readonly off - > zbackup1 comment - default > > This is on an adonics adaptor. my adapter is this adonics as well, and my lucky is not the same. the host card is also sis3124 PCI ? I will upgrade to 9-STABLE and try. thanks, matheus > ---Mike >> >> hint.siisch.0.sata_rev=1 >> hint.siisch.1.sata_rev=1 >> hint.siisch.2.sata_rev=1 >> hint.siisch.3.sata_rev=1 >> hint.siisch.4.sata_rev=1 >> hint.siisch.5.sata_rev=1 >> hint.siisch.6.sata_rev=1 >> hint.siisch.7.sata_rev=1 >> hint.siisch.8.sata_rev=1 >> hint.siisch.9.sata_rev=1 >> hint.siisch.10.sata_rev=1 >> hint.siisch.11.sata_rev=1 >> >> From time to time this is also causing one of the attached drives to go offline: >> >> siisch0: siis_timeout is 00040000 ss 40000000 rs 40000000 es 00000000 sts 801f2000 serr 00000000 >> (ada0:siisch0:0:0:0): lost device >> (ada0:siisch0:0:0:0): removing device entry >> ada0 at siisch0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 3.x device >> ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) >> ada0: Previously was known as ad4 >> siisch11: Timeout on slot 30 >> >> When the drive goes offline that causes the ZFS rebuild to restart, and so it's never finishing >> the rebuild of the array. Does anyone have any insight into what could be causing the timeouts >> and what we can do to resolve them? Right now my priority is to get the system a bit more >> stable so the current ZFS rebuild can complete – right now it's been doing the same rebuild >> for just over 6 days and the timeouts and drive drop offs are causing it to restart constantly. >> >> >> >> >> >> ________________________________ >> >> This electronic message contains information from Primus Telecommunications Canada Inc. >> ("PRIMUS") , which may be legally privileged and confidential. The information is intended to >> be for the use of the individual(s) or entity named above. If you are not the intended >> recipient, be aware that any disclosure, copying, distribution or use of the contents of this >> information is prohibited. If you have received this electronic message in error, please notify >> us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or >> advice expressed in this electronic message are not necessarily the views, opinions or advice >> of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus >> free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use >> thereof.The term "PRIMUS" includes its affiliates. >> >> ________________________________ >> Pour la version en français de ce message, veuillez voir >> http://www.primustel.ca/fr/legal/cs.htm >> >> >> >> _______________________________________________ >> 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" > > > -- > ------------------- > 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/ > _______________________________________________ > 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" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Wed May 23 20:07:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3858B106564A for ; Wed, 23 May 2012 20:07:11 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id CC9698FC16 for ; Wed, 23 May 2012 20:07:10 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 8BBFA1CC48; Wed, 23 May 2012 17:07:02 -0300 (BRT) Received: from 187.114.205.118 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Wed, 23 May 2012 17:07:02 -0300 Message-ID: In-Reply-To: <460e1bd626613f125b878f5be65a6b6e.squirrel@eternamente.info> References: <4FBCF2B6.1060200@sentex.net> <460e1bd626613f125b878f5be65a6b6e.squirrel@eternamente.info> Date: Wed, 23 May 2012 17:07:02 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: siis_timeout with port multiplier on 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 20:07:11 -0000 On Wed, May 23, 2012 12:54, Nenhum_de_Nos wrote: > > On Wed, May 23, 2012 11:22, Mike Tancsa wrote: >> On 5/21/2012 9:04 PM, Matthew Gamble wrote: >>> We have a box with 3 SiI3124 SATA controllers and 9 CFI-B53PM 5 Port Backplane port multipliers >>> (the "backblaze storage pod"). Under intense IO (ZFS rebuild, presently) the system will lock >>> up all IO for 3-4 minutes and the following entry appears in the dmesg: >>> >>> siisch11: Timeout on slot 30 >>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>> 00000000 >>> siisch11: ... waiting for slots 25000000 >>> siisch11: Timeout on slot 26 >>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>> 00000000 >>> siisch11: ... waiting for slots 21000000 >>> siisch11: Timeout on slot 29 >>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>> 00000000 >>> siisch11: ... waiting for slots 01000000 >>> siisch11: Timeout on slot 24 >>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>> 00000000 >>> >>> The errors are on different siisch devices so its not likely to be a SATA cable issue unless >>> multiple cables all went bad at the same time. On the advice of some other posts to the >>> mailing >>> list I've already tried locking the SATA rev to one with the following in /boot/loader.conf >>> which didn't >> >> If they are on different siisch devices then yes, it does not sound like >> a bad cable. However, I have had that issue with similar errors above >> that were fixed by using new cables. If you are using 9.0R, I would >> suggest upgrading to stable. There have been a few bug fixes / >> improvements to the drivers as well as various parts of the disk >> subsystem. I have RELENG8 right now and its quite stable for me on a >> 25TB system which is for the most part similar to 9.x >> >> # zpool status >> pool: zbackup1 >> state: ONLINE >> scan: scrub repaired 0 in 11h11m with 0 errors on Mon Jul 25 19:51:11 2011 >> config: >> >> NAME STATE READ WRITE CKSUM >> zbackup1 ONLINE 0 0 0 >> raidz1-0 ONLINE 0 0 0 >> ada14 ONLINE 0 0 0 >> ada16 ONLINE 0 0 0 >> ada13 ONLINE 0 0 0 >> ada15 ONLINE 0 0 0 >> raidz1-1 ONLINE 0 0 0 >> ada0 ONLINE 0 0 0 >> ada1 ONLINE 0 0 0 >> ada2 ONLINE 0 0 0 >> ada3 ONLINE 0 0 0 >> raidz1-2 ONLINE 0 0 0 >> ada4 ONLINE 0 0 0 >> ada5 ONLINE 0 0 0 >> ada6 ONLINE 0 0 0 >> ada7 ONLINE 0 0 0 >> raidz1-3 ONLINE 0 0 0 >> ada9 ONLINE 0 0 0 >> ada10 ONLINE 0 0 0 >> ada11 ONLINE 0 0 0 >> ada12 ONLINE 0 0 0 >> >> errors: No known data errors >> # zpool get all zbackup1 >> NAME PROPERTY VALUE SOURCE >> zbackup1 size 25.4T - >> zbackup1 capacity 68% - >> zbackup1 altroot - default >> zbackup1 health ONLINE - >> zbackup1 guid 917659042733882722 default >> zbackup1 version 28 default >> zbackup1 bootfs - default >> zbackup1 delegation on default >> zbackup1 autoreplace off default >> zbackup1 cachefile - default >> zbackup1 failmode wait default >> zbackup1 listsnapshots on local >> zbackup1 autoexpand off default >> zbackup1 dedupditto 0 default >> zbackup1 dedupratio 1.00x - >> zbackup1 free 7.95T - >> zbackup1 allocated 17.4T - >> zbackup1 readonly off - >> zbackup1 comment - default >> >> This is on an adonics adaptor. > > my adapter is this adonics as well, and my lucky is not the same. the host card is also sis3124 > PCI ? > > I will upgrade to 9-STABLE and try. > > thanks, > > matheus Mike, I saw FreeBSD webcvs info on siis.c. The only change in 9-STABLE is this: Revision 1.43.2.2: download - view: text, markup, annotated - select for diffs Sat Dec 31 15:31:34 2011 UTC (4 months, 3 weeks ago) by hselasky Branches: RELENG_9 Diff to: previous 1.43.2.1: preferred, colored; branchpoint 1.43: preferred, colored; next MAIN 1.44: preferred, colored Changes since revision 1.43.2.1: +2 -7 lines SVN rev 229118 on 2011-12-31 15:31:34Z by hselasky MFC r227701, r227847 and r227849: Move the device_delete_all_children() function from usb_util.c to kern/subr_bus.c. Simplify this function so that it no longer depends on malloc() to execute. Rename device_delete_all_children() into device_delete_children(). Identify a few other places where it makes sense to use device_delete_children(). all others, 9.0R has it. As i don't know this stuff, I can't tell how much it would affect my issue (and the other Matheus/Matthew as well), but I imagine not much as it says something usb on it :) as I'm not at home, will try the cabling thing when I get home. thanks, matheus >> ---Mike >>> >>> hint.siisch.0.sata_rev=1 >>> hint.siisch.1.sata_rev=1 >>> hint.siisch.2.sata_rev=1 >>> hint.siisch.3.sata_rev=1 >>> hint.siisch.4.sata_rev=1 >>> hint.siisch.5.sata_rev=1 >>> hint.siisch.6.sata_rev=1 >>> hint.siisch.7.sata_rev=1 >>> hint.siisch.8.sata_rev=1 >>> hint.siisch.9.sata_rev=1 >>> hint.siisch.10.sata_rev=1 >>> hint.siisch.11.sata_rev=1 >>> >>> From time to time this is also causing one of the attached drives to go offline: >>> >>> siisch0: siis_timeout is 00040000 ss 40000000 rs 40000000 es 00000000 sts 801f2000 serr >>> 00000000 >>> (ada0:siisch0:0:0:0): lost device >>> (ada0:siisch0:0:0:0): removing device entry >>> ada0 at siisch0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-8 SATA 3.x device >>> ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) >>> ada0: Previously was known as ad4 >>> siisch11: Timeout on slot 30 >>> >>> When the drive goes offline that causes the ZFS rebuild to restart, and so it's never finishing >>> the rebuild of the array. Does anyone have any insight into what could be causing the timeouts >>> and what we can do to resolve them? Right now my priority is to get the system a bit more >>> stable so the current ZFS rebuild can complete – right now it's been doing the same rebuild >>> for just over 6 days and the timeouts and drive drop offs are causing it to restart constantly. >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> This electronic message contains information from Primus Telecommunications Canada Inc. >>> ("PRIMUS") , which may be legally privileged and confidential. The information is intended to >>> be for the use of the individual(s) or entity named above. If you are not the intended >>> recipient, be aware that any disclosure, copying, distribution or use of the contents of this >>> information is prohibited. If you have received this electronic message in error, please notify >>> us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or >>> advice expressed in this electronic message are not necessarily the views, opinions or advice >>> of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus >>> free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use >>> thereof.The term "PRIMUS" includes its affiliates. >>> >>> ________________________________ >>> Pour la version en français de ce message, veuillez voir >>> http://www.primustel.ca/fr/legal/cs.htm >>> >>> >>> >>> _______________________________________________ >>> 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" >> >> >> -- >> ------------------- >> 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/ >> _______________________________________________ >> 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" >> > > > -- > We will call you Cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style > _______________________________________________ > 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" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Wed May 23 20:18:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9EF91065675 for ; Wed, 23 May 2012 20:18:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C79F8FC14 for ; Wed, 23 May 2012 20:18:02 +0000 (UTC) Received: by dadv36 with SMTP id v36so11083869dad.13 for ; Wed, 23 May 2012 13:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A0/5HTRXKE+ZZwrRGXVCYy8IkqOb1qgP9iJD2qP39bQ=; b=YWCeUZlzFvMLTukHsQHoLosb4hEylUNE6wPSXMRp3MtjcP87WaDMcxMgUMgFwXWNFb F5TQ84WnXO6xSF3D8+bl0bOFRTyxhNb1ZPBIMoyy0GYX9icMydAEJyGMuoB5dq6ceoVO jGQfK0W07dj7EhN3joIpLq/gXlv1aKB4fG8yuxUpEOXsaShEFpHaH5wWatqLW+NxZk2j TQ+RQMBTf/3Uy8pqO2T4XiEgUq2ehTemwjBuf0wGhBxcKowcS+Eh95JRDIJI37Tbvoqj zFck5YOK2ytNnJnOO/37jXd6ZBTmK2iEGUfskxp84G6ftKUf6vye5QWIwVSfOe1iXc3f pKKg== MIME-Version: 1.0 Received: by 10.68.234.35 with SMTP id ub3mr13882730pbc.8.1337804282085; Wed, 23 May 2012 13:18:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Wed, 23 May 2012 13:18:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 May 2012 13:18:02 -0700 X-Google-Sender-Auth: jYMBPWInwt8lChpm1OXbYP4TS3o Message-ID: From: Adrian Chadd To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: VirtualBox, AIO and zvol's - a cautionary tale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 20:18:02 -0000 Hi, Can you please file a PR? Having broken AIO and ZFS would be .. bad. adrian On 23 May 2012 06:11, Pete French wrote: > Am posting this to stable not really as a question, but more in case anyo= ne > else hits the same problem. Last patch tuesday one of my virtual Windows > machines =A0running under VirtualBox started crashing. By which I mean > that VirtualBox would quit. This had been running tsably for a long > tine, so it puzzled me. > > First thought was it was sme patch from patch-tuesday. But rolling back > to an earlier version of the disc showed it wasn't - the crashes were > occurring before the patch had been applied. > > I'll skip the hours of puzzlement which followed - it turrned out that > the indirect cause was that a few weeks ago I had installed Samba > onto the same server. In doing so I had enabled AIO, as this improves > Samba performance. > > What I didn't realise is that if VirtualBox finds AIO loaded it proceeds > to use it. =A0So by doing that I had switched on AIO inside my virtual > machines as well. The disc I use for my virtual machines are all zvols (i= t > performs better, and it seems that VirtualBox has a problem using AIO > to access zvols. > > But this didn;t show up for weeks because in the normal scheme of things > my virtual machines dont acccess the local dirve very much. It was only > when they started downloading patches that the crash happened. > > Solution is simple - disable AIO. All then goes back to being nice > and stable again. But it did take a while to find. > > Hope someone else finds the info usefull! > > -pete. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed May 23 20:19:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3435106566C for ; Wed, 23 May 2012 20:19:49 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id 929B48FC22 for ; Wed, 23 May 2012 20:19:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan04.get.basefarm.net ([10.5.16.4]) by get-mta-out03.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0M4H003NXSGUHC10@get-mta-out03.get.basefarm.net> for freebsd-stable@freebsd.org; Wed, 23 May 2012 22:19:42 +0200 (MEST) Received: from get-mta-scan04.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7F17C1EF9EFD_FBD465EB for ; Wed, 23 May 2012 20:19:42 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan04.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id 651491EF9EE5_FBD465EF for ; Wed, 23 May 2012 20:19:42 +0000 (GMT) Date: Wed, 23 May 2012 22:19:42 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120523221942.ba7fbe1c.torfinn.ingolfsen@getmail.no> In-reply-to: References: X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Subject: Re: VirtualBox, AIO and zvol's - a cautionary tale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 20:19:50 -0000 On Wed, 23 May 2012 14:11:48 +0100 Pete French wrote: > Solution is simple - disable AIO. All then goes back to being nice > and stable again. But it did take a while to find. > > Hope someone else finds the info usefull! Useful - thanks! -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Wed May 23 20:29:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2620106578A for ; Wed, 23 May 2012 20:29:25 +0000 (UTC) (envelope-from miyamoto.31b@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 609908FC14 for ; Wed, 23 May 2012 20:29:23 +0000 (UTC) Received: by obcni5 with SMTP id ni5so15580503obc.13 for ; Wed, 23 May 2012 13:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WXS9N4a5XxZ0dDN6kUeFRzF8UqZ+R8vGNELgmj4mOps=; b=ZGx/cqfresAAmkA4nsU7zWHEiej5SX5v0PsA6WYYr2VUBnYD5Bqy+DJ79VzBqHCIcY 7KewOssij6SLK6o1M5BCBAk8b5AA8nsFevFkcpgFbP5m6L3hr8e2oKNn/NZR8vqnsv0e Hwh10CRlAS5LLL7o1i0OhdCaXoBAzYB5RBxQHZ+1Bdk8cAVQw+/ufxbLzCr+LgmNMFlP 3fwnrxTM52Jf+kYEHZbvls6DTgbuaL5qMe4ynr+AfIHMgKeFa/pKpiTclcT/kmeiSVPX MetM2lH2n3gkV0p6xZvaNJ0HcdN94V7M48RsR+WQSpEj+E7l2oNwB4R+sg5NmJuz7YBf fPbw== MIME-Version: 1.0 Received: by 10.182.36.102 with SMTP id p6mr27433367obj.77.1337804962566; Wed, 23 May 2012 13:29:22 -0700 (PDT) Received: by 10.182.70.4 with HTTP; Wed, 23 May 2012 13:29:22 -0700 (PDT) Date: Wed, 23 May 2012 21:29:22 +0100 Message-ID: From: miyamoto moesasji To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Wacom Touchscreen of a Toshiba M750 not detected properly? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 20:29:25 -0000 I'm working on getting FreeBSD Stable (svn rev 235652, AMD64) running to my satisfaction on a Toshiba M750. The challenge is that it contains a builtin Wacom touchscreen. People report it working under Linux using the linuxwacom driver also present in ports. Unfortunately I fail to get it working under FreeBSD and find no reports on the web of anyone that succeeded for FreeBSD. I have the impression that it is related to the kernel not detecting it properly, which is why I ask the question on the Stable mailing list. My apologies if it should have gone elsewhere. Below a short summary of what I did in trying to get this to work. I've installed the x11-drivers/input-wacom port and enabled it by using wacom_enable in /etc/rc.conf. Upon a reboot I get the message that /boot/modules/uwacom.ko can not be loaded in dmesg. This is correct as this file doesn't exist, but it highlights the problem as this driver is only needed for Wacom tablets connected through USB. Yet this is a builtin tablet which is connected by a serial connection. There is no other mention of anything wacom related in dmesg -a. Enabling webcamd which is often mentioned for USB connect tablets as being important makes no difference. Moreover building x11-drivers/input-wacom with the USB flag set also doesn't build the driver. I then explored further using devinfo -v, which indeed shows the presence of the tablet giving the following message: unknown pnpinfo _HID=WACF009 _UID=0 at handle=\_SB_.PCI0.FNC0.TBLT This according to the inputwacom wiki is indeed the device I'm trying to get working, see http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Device_IDs but it doesn't appear in dmesg at all. If I grep through the FreeBSD source I only find a mention of the older Wacom Tablet generation (WACF004 in this case) in the serial driver files, i.e. /sys/dev/uart/uart_acpi.c Unfortunately that is the point at which I am completely stuck as I don't directly see how I can ensure that the Wacom Tablet is picked up correctly, so any suggestion how to proceed would be highly appreciated. Note that it might simply be that I don't understand how I should enable the appropriate serial connection?. From owner-freebsd-stable@FreeBSD.ORG Thu May 24 10:55:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 040A0106567F; Thu, 24 May 2012 10:55:30 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id BBBDC8FC15; Thu, 24 May 2012 10:55:29 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SXVhN-0003hj-6v; Thu, 24 May 2012 11:55:17 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXVhN-000GUb-6E; Thu, 24 May 2012 11:55:17 +0100 To: adrian@freebsd.org, petefrench@ingresso.co.uk In-Reply-To: Message-Id: From: Pete French Date: Thu, 24 May 2012 11:55:17 +0100 Cc: freebsd-stable@freebsd.org Subject: Re: VirtualBox, AIO and zvol's - a cautionary tale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 10:55:30 -0000 > Can you please file a PR? Having broken AIO and ZFS would be .. bad. OK: http://www.freebsd.org/cgi/query-pr.cgi?pr=168298 I thought it was most likely a bug in VirtualBox to be honest - broken AIO and ZFS would be bad, but also highly noticeable in other configurations, and this only seems to affect VBox. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Thu May 24 17:28:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A6F106566C for ; Thu, 24 May 2012 17:28:42 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE1F8FC0A for ; Thu, 24 May 2012 17:28:41 +0000 (UTC) Received: by obcni5 with SMTP id ni5so29603obc.13 for ; Thu, 24 May 2012 10:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=254iqfsnN3LaO2b6X4C1KvGPRoe/Lr9rzpMSWBu4I00=; b=kxyfhS4ee0k1nrfMBZR7IFKf1aD/aDJTha+ieQGSBZwmELR+0fkAO+JfJfh0G8qI47 2QDBjVXRaVVKgsZYaKvGcOczPOnxfM/05oxBfOTV7b6lg36B4oft4vOrQYcpXQeBLGEC CzFm+o4xVwoOEjHYigg9GjuozWI1KOv5H/LZEh6zpFOKevzA+d21R/r4XVp+kjD9jQHD fKg5HsVZGaXC6ju0L0teldners7xgdDltvSpLJo+z3BOLCMUWgrNNfZjs3r7hvWCsmCY SpMJOTA02RUBLVs+ijyjCOAW4gWPET6LkDRTCmLYWtx7fk4eJYcRPrr4TxMRUE10Q1+b xAFw== MIME-Version: 1.0 Received: by 10.182.131.2 with SMTP id oi2mr171323obb.43.1337880520635; Thu, 24 May 2012 10:28:40 -0700 (PDT) Received: by 10.182.53.39 with HTTP; Thu, 24 May 2012 10:28:40 -0700 (PDT) Date: Thu, 24 May 2012 19:28:40 +0200 Message-ID: From: Oliver Pinter To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: gdb coredump on 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 17:28:42 -0000 Script started on Thu May 24 19:25:44 2012 op has logged on :0 from local. root has logged on ttyv1 from local. ESC[1mopESC[m@ESC[4mopnESC[24m ~> gdb sleep ^M 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)... (gdb) run 100 Starting program: /bin/sleep 100 (no debugging symbols found)...(no debugging symbols found)...^C Program received signal SIGINT, Interrupt. 0x00000008012211fc in nanosleep () from /lib/libc.so.7 (gdb) q The program is running. Exit anyway? (y or n) a Please answer y or n. Segmentation fault (core dumped) ESC[1mopESC[m@ESC[4mopnESC[24m ~> exit Script done on Thu May 24 19:26:11 2012 -------------------- op@opn ~> gdb gdb gdb.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 `gdb'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.8 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800d26887 in strlen () from /lib/libc.so.7 (gdb) bt full #0 0x0000000800d26887 in strlen () from /lib/libc.so.7 No symbol table info available. #1 0x0000000800d1f662 in open () from /lib/libc.so.7 No symbol table info available. #2 0x0000000800cd0af4 in vasprintf () from /lib/libc.so.7 No symbol table info available. #3 0x0000000000486fe9 in xvasprintf () No symbol table info available. #4 0x00000000004884c3 in warning () No symbol table info available. #5 0x0000000000488d0b in query () No symbol table info available. #6 0x00000000004953bb in quit_confirm () No symbol table info available. #7 0x0000000000466018 in quit_command () No symbol table info available. #8 0x00000000004960f5 in execute_command () No symbol table info available. #9 0x0000000000452b63 in push_prompt () No symbol table info available. #10 0x0000000000453797 in display_gdb_prompt () No symbol table info available. #11 0x000000080d26ff87 in rl_callback_read_char () from /lib/libreadline.so.8 No symbol table info available. #12 0x0000000000452d29 in push_prompt () No symbol table info available. #13 0x0000000000453d9f in delete_async_signal_handler () No symbol table info available. #14 0x0000000000454686 in gdb_do_one_event () No symbol table info available. #15 0x000000000049665e in throw_exception () No symbol table info available. #16 0x00000000004966b3 in catch_errors () No symbol table info available. #17 0x000000000052ddba in _initialize_tui_interp () No symbol table info available. #18 0x0000000000439869 in gdb_main () No symbol table info available. #19 0x000000000049665e in throw_exception () No symbol table info available. #20 0x00000000004966b3 in catch_errors () No symbol table info available. ---Type to continue, or q to quit--- #21 0x000000000043924d in gdb_main () No symbol table info available. #22 0x000000000049665e in throw_exception () No symbol table info available. #23 0x00000000004966b3 in catch_errors () No symbol table info available. #24 0x0000000000438bc4 in gdb_main () No symbol table info available. #25 0x0000000000438b96 in main () No symbol table info available. (gdb) q ------------------ FreeBSD opn 9.0-STABLE FreeBSD 9.0-STABLE #59 r235633+a40b20b: Sat May 19 16:23:04 CEST 2012 root@opn:/usr/obj/usr/src/sys/stable amd64 From owner-freebsd-stable@FreeBSD.ORG Thu May 24 18:21:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8A77106566C for ; Thu, 24 May 2012 18:21:05 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 677778FC12 for ; Thu, 24 May 2012 18:21:05 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4OIKYS1033966 for ; Thu, 24 May 2012 11:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337883635; bh=ly9JEwy/o7xIH6uZbS5rW9UdRkGg0dkKBNEUpHlJO+4=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=WFbJ8xBP6NvW+j5noh1L8HgJmWK3OpCiI+zAsUjbOfirsOHu4vgHcxrB5bq4STdu+ Gvse8iIfsDOQNWJhNSBrbtRfFkom2xmwNGubcW8uGWB/shxytgaueko1dLMw9v8/k4 Ttwp8Zch2fQxm8EnHCYSisXOR99eGdvUv/fLceUg= From: Sean Bruno To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 May 2012 11:20:34 -0700 Message-ID: <1337883634.2709.7.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 883635000 Subject: ports devel/tkcvs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:21:05 -0000 Probably doing something wrong, but when I install tkcvs to get tkdiff on my box, the only thing it does is fire up and display a "wish" window. Did I do it wrong? :-) sean pkg_info |grep ^tk tk-8.5.11 Graphical toolkit for Tcl tk-wrapper-1.1_1 Shell wrapper for wish (Tk) tkcvs-8.2.3 Tcl/Tk frontends to CVS and Subversion tkdiff-4.2 A Tk frontend for diff(1) From owner-freebsd-stable@FreeBSD.ORG Thu May 24 19:27:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AD7106566C for ; Thu, 24 May 2012 19:27:10 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 39D868FC1A for ; Thu, 24 May 2012 19:27:10 +0000 (UTC) Received: from [172.16.10.123] (unknown [172.16.10.123]) by mail.intertainservices.com (Postfix) with ESMTPSA id 963A9564EC for ; Thu, 24 May 2012 15:18:54 -0400 (EDT) Message-ID: <1337887134.1908.20.camel@mike-PC> From: Mike Jakubik To: "freebsd-stable@freebsd.org" Date: Thu, 24 May 2012 15:18:54 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 963A9564EC.A073F X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Subject: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:27:10 -0000 Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. root@jail.local:~# uname -a FreeBSD jail.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu May 24 12:50:04 EDT 2012 root@jail.local:/usr/obj/usr/src/sys/JAIL amd64 Boot: ezJailConfiguring jails:. Starting jails: cannot start jail "game": -1 cannot start jail "app": -1 /var/log/messages: May 24 15:05:30 jail kernel: pid 1276 (jail), uid 0: exited on signal 11 May 24 15:05:30 jail kernel: pid 1343 (jail), uid 0: exited on signal 11 root@jail.local:~# jls JID IP Address Hostname Path root@jail.local:~# /usr/local/etc/rc.d/ezjail start ezjailConfiguring jails:. Starting jails: game.local app.local. (notice that jails start at #3) root@jail.local:~# jls JID IP Address Hostname Path 3 10.57.227.100 game.local /jails/game 4 10.57.227.99 app.local /jails/app (can not stop jails now) root@jail.local:~# /usr/local/etc/rc.d/ezjail stop ezjailStopping jails: app.local game.local. root@jail.local:~# jls JID IP Address Hostname Path 3 10.57.227.100 game.local /jails/game 4 10.57.227.99 app.local /jails/app root@jail.local:~# /usr/local/etc/rc.d/ezjail stop ezjailStopping jails: cannot stop jail app. No jail id in /var/run cannot stop jail game. No jail id in /var/run (same behaviour occurs when i use the base /etc/rc.d script to start/stop the jails) Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu May 24 20:08:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3EE0106566C; Thu, 24 May 2012 20:08:19 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id AF39A8FC08; Thu, 24 May 2012 20:08:19 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4OK7tAm011124; Thu, 24 May 2012 13:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337890076; bh=lK2Cp/dbOxgq63difINMjdBhYBhK70ohrUNPxgASa9I=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=Ke497yqxfJRk1RuaGnlhM/6HsZOdRxv6ZxIKzBsr00AbSIzuTg7g3vSdT04EVnHse nJmE5DU3Z85YTF7Slks1B5QeGYgwd1W2i5qN/RhF2DPpWh8Rfm4PaPeyIfem1OiPoR /Dt90Dqf2CvdL4xCqSF1+BO0FXtyORBWJUsNCYbo= From: Sean Bruno To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 May 2012 13:07:55 -0700 Message-ID: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 890076000 Subject: bash 4.2 patchlevel 28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:08:20 -0000 Noted that the following syntax is broken somewhere between 4.2 patchlevel 10 and 28. I'm sure its because we shouldn't be doing that over here at big purple, but we do ... and its a PITA. I'm bisecting to find out what is going on. test: VARIABLE="$(uname)" bash: command substitution: line 3: syntax error near unexpected token `)' bash: command substitution: line 3: `uname)"' Odd, but his works at patchlevel 10 sean From owner-freebsd-stable@FreeBSD.ORG Thu May 24 20:15:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D75A61065670; Thu, 24 May 2012 20:15:21 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0898FC0C; Thu, 24 May 2012 20:15:21 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4OKEtNL013657; Thu, 24 May 2012 13:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337890496; bh=Wx07R0EuWfvvglvRIfTp2CdZjelAZXzfGqaIgD42n7w=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=NtxRro0C6MRRBbnSu0GGrNrOPkoGg6Vrgw6md/CUlT12+oFlArL6Xq2JQVKpWj+Xo QIzWqrNKjCcreO8C/9pV44wJE+lGUEs0JQAJ7+N6fI+6w++n+Mbpa77EJGFGhNRS5q uYKFocDz+OyJzsPz9nJDnnVAwjyBfFpOb/lF8NoY= From: Sean Bruno To: "sbruno@freebsd.org" In-Reply-To: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> References: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 May 2012 13:14:54 -0700 Message-ID: <1337890494.2709.18.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 890495004 Cc: "freebsd-stable@freebsd.org" Subject: Re: bash 4.2 patchlevel 28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:15:21 -0000 On Thu, 2012-05-24 at 13:07 -0700, Sean Bruno wrote: > Noted that the following syntax is broken somewhere between 4.2 > patchlevel 10 and 28. I'm sure its because we shouldn't be doing that > over here at big purple, but we do ... and its a PITA. I'm bisecting to > find out what is going on. > > test: > VARIABLE="$(uname)" > bash: command substitution: line 3: syntax error near unexpected token > `)' > bash: command substitution: line 3: `uname)"' > > Odd, but his works at patchlevel 10 > > sean At least that was easy. It's patch level 12. Sequential sort pays dividends today. Sean From owner-freebsd-stable@FreeBSD.ORG Thu May 24 20:53:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB24F1065673; Thu, 24 May 2012 20:53:58 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 86FB38FC0C; Thu, 24 May 2012 20:53:58 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4OKrOWU029254; Thu, 24 May 2012 13:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337892805; bh=1zclvbFsIdkRyB2A0f4+ueA1BRxSLWpRhJLTLGzmhws=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=JznRafgc3xecL2ZjRmYcDtTO6qkVbyAazfvE29luH5YZdrNZRU5If3/ZKxSdCK5Ls DWhrKiw2jC88Tez4ehWVXW5rT2BwmxsSOlCf8Nd2NSga5xUBckiehLKur5E5H6OzGd 9uJGTJykSvq8JxOopPjpkV61qKAcv6W5m4/FlAKg= From: Sean Bruno To: "sbruno@freebsd.org" In-Reply-To: <1337890494.2709.18.camel@powernoodle-l7.corp.yahoo.com> References: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> <1337890494.2709.18.camel@powernoodle-l7.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 May 2012 13:53:24 -0700 Message-ID: <1337892804.2709.20.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 892804003 Cc: "freebsd-stable@freebsd.org" Subject: Re: bash 4.2 patchlevel 28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:53:58 -0000 On Thu, 2012-05-24 at 13:14 -0700, Sean Bruno wrote: > > On Thu, 2012-05-24 at 13:07 -0700, Sean Bruno wrote: > > Noted that the following syntax is broken somewhere between 4.2 > > patchlevel 10 and 28. I'm sure its because we shouldn't be doing that > > over here at big purple, but we do ... and its a PITA. I'm bisecting to > > find out what is going on. > > > > test: > > VARIABLE="$(uname)" > > bash: command substitution: line 3: syntax error near unexpected token > > `)' > > bash: command substitution: line 3: `uname)"' > > > > Odd, but his works at patchlevel 10 > > > > sean > > At least that was easy. It's patch level 12. Sequential sort pays > dividends today. > > Sean > Hrm ... and it also appears that if I use bison + m4 I don't have this issue, but if I let the configure scripts use /usr/bin/yacc alone this problem manifests itself. odd. sean From owner-freebsd-stable@FreeBSD.ORG Thu May 24 21:22:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65025106564A for ; Thu, 24 May 2012 21:22:33 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E47C78FC0C for ; Thu, 24 May 2012 21:22:32 +0000 (UTC) Received: by werg1 with SMTP id g1so202653wer.13 for ; Thu, 24 May 2012 14:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=v3vF6CQhvOOWocmMMPpQF4ioRisR4O4SAU4GIeEPgsw=; b=bubXPd2sdtSqtBFM4eOfVjEFCq/2mjzmTDcOKn1sI8q5CzxD0hAX4kKfDNnyUws7iY YMw1KMT2lcbBCLsm4V5p8hatQizV3WUc2f6SE5zHAUIyK/Fp90K5Czhn7hi5Bwk74MWP IqD6xfW+Q+1b654jpa5Ouevb5l2WeCJxMsE7weiLdml+kUPLbuGddegb1EZ6bCv6dyjQ zTZHqKb4Ra2kIzJDI1RLUZsh2Fr5/cstB8t07Y6eaCjlffG7q6j2qwIDQZ8UnJ1WXDRc D2n1G13I9FUSIQj2fiPRqcFUDg43AHOjOKkaRX+jb/5xAPzsNThlfJxM6ObLGlaW/fYz yEWg== Received: by 10.180.106.137 with SMTP id gu9mr1871153wib.8.1337894551881; Thu, 24 May 2012 14:22:31 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id e20sm45359334wiv.7.2012.05.24.14.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 14:22:30 -0700 (PDT) Date: Thu, 24 May 2012 23:22:19 +0200 From: Mateusz Guzik To: Mike Jakubik Message-ID: <20120524212219.GA17579@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1337887134.1908.20.camel@mike-PC> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:22:33 -0000 On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: > Hello, > > Latest 9-STABLE has introduced some changes that break the ezjail rc > script. On bootup it fails to start, but when i log in via ssh and > manually start it, it works. However i am unable to shut them down > afterwards. > > > root@jail.local:~# uname -a > FreeBSD jail.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu May 24 12:50:04 > EDT 2012 root@jail.local:/usr/obj/usr/src/sys/JAIL amd64 > > > Boot: > > ezJailConfiguring jails:. > Starting jails: cannot start jail "game": > -1 > cannot start jail "app": > -1 > > /var/log/messages: > > May 24 15:05:30 jail kernel: pid 1276 (jail), uid 0: exited on signal 11 > May 24 15:05:30 jail kernel: pid 1343 (jail), uid 0: exited on signal 11 > [..] > > root@jail.local:~# jls > JID IP Address Hostname Path > 3 10.57.227.100 game.local /jails/game > 4 10.57.227.99 app.local /jails/app > > > (can not stop jails now) > > root@jail.local:~# /usr/local/etc/rc.d/ezjail stop > ezjailStopping jails: app.local game.local. > > root@jail.local:~# jls > JID IP Address Hostname Path > 3 10.57.227.100 game.local /jails/game > 4 10.57.227.99 app.local /jails/app > > root@jail.local:~# /usr/local/etc/rc.d/ezjail stop > ezjailStopping jails: cannot stop jail app. No jail id in /var/run > cannot stop jail game. No jail id in /var/run > > (same behaviour occurs when i use the base /etc/rc.d script to start/stop the jails) > Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src && patch -p1 < patch && cd usr.sbin/jail && make && make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:06:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096CE106566C for ; Thu, 24 May 2012 22:06:53 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id D16928FC1B for ; Thu, 24 May 2012 22:06:52 +0000 (UTC) Received: from [172.16.10.123] (unknown [172.16.10.123]) by mail.intertainservices.com (Postfix) with ESMTPSA id A92BC5647D; Thu, 24 May 2012 18:06:49 -0400 (EDT) Message-ID: <1337897210.1908.24.camel@mike-PC> From: Mike Jakubik To: Mateusz Guzik Date: Thu, 24 May 2012 18:06:50 -0400 In-Reply-To: <20120524212219.GA17579@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: A92BC5647D.A067F X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:06:53 -0000 On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: > On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: > > Hello, > > > > Latest 9-STABLE has introduced some changes that break the ezjail rc > > script. On bootup it fails to start, but when i log in via ssh and > > manually start it, it works. However i am unable to shut them down > > afterwards. > > > Try this: > http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch > > cd /usr/src && patch -p1 < patch && cd usr.sbin/jail && make && make install > > /usr/src/etc/rc.d/jail script can be just copied over. > > Note that your /var/run/jail_* files have broken content (some line from > /etc/rc's output instead of jail id). > Mateusz, Thanks for the patch, it fixes the startup issue on boot, however shutting down the jails still does not work. The /var/run files have garbage in them as you mentioned. root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:12:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 587381065675 for ; Thu, 24 May 2012 22:12:31 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2695E8FC12 for ; Thu, 24 May 2012 22:12:31 +0000 (UTC) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.42]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 7435CA71400 for ; Thu, 24 May 2012 18:12:30 -0400 (EDT) Received: (qmail 30565 invoked from network); 24 May 2012 22:12:29 -0000 Received: by simscan 1.4.0 ppid: 25935, pid: 5327, t: 0.2352s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from unknown (HELO P9X79.tddhome) (tomdean@[24.113.107.31]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 May 2012 22:12:29 -0000 Message-ID: <4FBEB24D.5070208@speakeasy.org> Date: Thu, 24 May 2012 15:12:29 -0700 From: "Thomas D. Dean" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120310 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> In-Reply-To: <1337897210.1908.24.camel@mike-PC> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail3.sea5 X-Spam-Level: X-Spam-Status: No, score=0.9 required=8.0 tests=FORGED_RCVD_HELO, RATWARE_GECKO_BUILD autolearn=disabled version=3.0.4 Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:12:31 -0000 On 05/24/12 15:06, Mike Jakubik wrote: > On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: > > root@jail.local:~# cat /var/run/jail_app.id > /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). > > > Hostname is set in /etc/rc.conf. > > I had this same issue - see my post on jails Rebooting the host cleared the problem for some time. I think it comes back... Tom Dean From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:13:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E512B1065674 for ; Thu, 24 May 2012 22:13:33 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by mx1.freebsd.org (Postfix) with ESMTP id 26ECB8FC0C for ; Thu, 24 May 2012 22:13:33 +0000 (UTC) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.52]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 93C4CA70B97 for ; Thu, 24 May 2012 18:13:32 -0400 (EDT) Received: (qmail 24971 invoked from network); 24 May 2012 22:13:32 -0000 Received: by simscan 1.4.0 ppid: 21953, pid: 28116, t: 0.1304s scanners: clamav: 0.88.2/m:52/d:13513 spam: 3.0.4 Received: from unknown (HELO P9X79.tddhome) (tomdean@[24.113.107.31]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 May 2012 22:13:31 -0000 Message-ID: <4FBEB28B.1010604@speakeasy.org> Date: Thu, 24 May 2012 15:13:31 -0700 From: "Thomas D. Dean" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120310 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> In-Reply-To: <1337897210.1908.24.camel@mike-PC> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail7.sea5 X-Spam-Level: X-Spam-Status: No, score=0.9 required=8.0 tests=FORGED_RCVD_HELO, RATWARE_GECKO_BUILD autolearn=disabled version=3.0.4 Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:13:34 -0000 On 05/24/12 15:06, Mike Jakubik wrote: > Sorry, I was going too fast. > uname -a FreeBSD P9X79.tddhome 9.0-STABLE FreeBSD 9.0-STABLE #2: Fri May 11 20:41:54 PDT 2012 tomdean@P9X79.tddhome:/usr/src/sys/GENERIC amd64 Tom Dean From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:14:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 143911065680 for ; Thu, 24 May 2012 22:14:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9273A8FC0A for ; Thu, 24 May 2012 22:14:11 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so229562wib.13 for ; Thu, 24 May 2012 15:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FistCCTEvJSwPvLXnaCw/jDok6/q+qOXnMwnYQwxdGE=; b=di1misSaiSS1A9G/GfI1Pi3Yc7qxlaLpba/cnCCoSA0+VF2mxcztiCsltgs4LBiVk1 F88pntlmztCQsvkPkGlMTjB+sAavp8ArTkVCQx3069Vx2X5EyCNAo7UefGFmfNwX0mUz BikhQimqeIR5gdlky8kyr7CkC2wY18AFk1lfWjDN7wirVyNqJavBNyZ5nYkRG0I5ZWvM Y7x/jXUnpyHUztg2qOyYXcqhGE6zM6ZnPCyqeiGW/Cmny1BkRBl3F7F/yGbtc25Dbod2 5k2H4+uknroHx/TsHZ4mXR0RzkV+yAyUfGfuFu1iivP5pqIYKPN1rf7J8Y4RL0TJ+9lo CRuQ== Received: by 10.180.99.195 with SMTP id es3mr2104119wib.12.1337897644995; Thu, 24 May 2012 15:14:04 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id az1sm11597294wib.0.2012.05.24.15.14.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 15:14:03 -0700 (PDT) Date: Fri, 25 May 2012 00:13:53 +0200 From: Mateusz Guzik To: Mike Jakubik Message-ID: <20120524221353.GB17579@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1337897210.1908.24.camel@mike-PC> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:14:12 -0000 On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: > On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: > > On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: > > > Hello, > > > > > > Latest 9-STABLE has introduced some changes that break the ezjail rc > > > script. On bootup it fails to start, but when i log in via ssh and > > > manually start it, it works. However i am unable to shut them down > > > afterwards. > > > > > Try this: > > http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch > > > > cd /usr/src && patch -p1 < patch && cd usr.sbin/jail && make && make install > > > > /usr/src/etc/rc.d/jail script can be just copied over. > > > > Note that your /var/run/jail_* files have broken content (some line from > > /etc/rc's output instead of jail id). > > > > Mateusz, > > Thanks for the patch, it fixes the startup issue on boot, however > shutting down the jails still does not work. The /var/run files have > garbage in them as you mentioned. > > root@jail.local:~# cat /var/run/jail_app.id > /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). > > > Hostname is set in /etc/rc.conf. This message is about rc.conf from your jail. This should be fixed by my change to etc/rc.d/jail, are you sure that you are running patched version? -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:20:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888B2106564A for ; Thu, 24 May 2012 22:20:16 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB3C8FC0A for ; Thu, 24 May 2012 22:20:16 +0000 (UTC) Received: from [172.16.10.123] (unknown [172.16.10.123]) by mail.intertainservices.com (Postfix) with ESMTPSA id 55C465644B; Thu, 24 May 2012 18:20:15 -0400 (EDT) Message-ID: <1337898015.1908.27.camel@mike-PC> From: Mike Jakubik To: Mateusz Guzik Date: Thu, 24 May 2012 18:20:15 -0400 In-Reply-To: <20120524221353.GB17579@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 55C465644B.ADD15 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:20:16 -0000 On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote: > On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: > > On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: > > > On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: > > > > Hello, > > > > > > > > Latest 9-STABLE has introduced some changes that break the ezjail rc > > > > script. On bootup it fails to start, but when i log in via ssh and > > > > manually start it, it works. However i am unable to shut them down > > > > afterwards. > > > > > > > Try this: > > > http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch > > > > > > cd /usr/src && patch -p1 < patch && cd usr.sbin/jail && make && make install > > > > > > /usr/src/etc/rc.d/jail script can be just copied over. > > > > > > Note that your /var/run/jail_* files have broken content (some line from > > > /etc/rc's output instead of jail id). > > > > > > > Mateusz, > > > > Thanks for the patch, it fixes the startup issue on boot, however > > shutting down the jails still does not work. The /var/run files have > > garbage in them as you mentioned. > > > > root@jail.local:~# cat /var/run/jail_app.id > > /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). > > > > > > Hostname is set in /etc/rc.conf. > > This message is about rc.conf from your jail. > > This should be fixed by my change to etc/rc.d/jail, are you sure that > you are running patched version? > Right, i just realized this. I set the hostname in the jailed rc.conf, now the file contains this: root@jail.local:~# cat /var/run/jail_app.id Setting hostname: app.local. I do not see a link to your jail rc.d script, just the patch. From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:25:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0ECF106564A for ; Thu, 24 May 2012 22:25:05 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 81B508FC19 for ; Thu, 24 May 2012 22:25:05 +0000 (UTC) Received: from [172.16.10.123] (unknown [172.16.10.123]) by mail.intertainservices.com (Postfix) with ESMTPSA id DB37D5645C; Thu, 24 May 2012 18:25:04 -0400 (EDT) Message-ID: <1337898305.1908.29.camel@mike-PC> From: Mike Jakubik To: Mateusz Guzik Date: Thu, 24 May 2012 18:25:05 -0400 In-Reply-To: <1337898015.1908.27.camel@mike-PC> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: DB37D5645C.A114B X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Cc: "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:25:05 -0000 On Thu, 2012-05-24 at 18:20 -0400, Mike Jakubik wrote: > I do not see a link to your jail rc.d script, just the patch. > Sigh, sorry, it's been a long day. I didnt look at the patch :P It works perfectly now, thanks again, hope someone can commit this soon. From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:30:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76E111065673 for ; Thu, 24 May 2012 22:30:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F28398FC08 for ; Thu, 24 May 2012 22:30:17 +0000 (UTC) Received: by werg1 with SMTP id g1so244958wer.13 for ; Thu, 24 May 2012 15:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9N+B08E9IFqEBq3RseiOhbFjPVdmKr+7qqqUOLGdW1M=; b=Dq44x2oTpBbaTM41QYRCWMyxjYXxZz+yvbmGO0FipmbGfRhQ245QUkOMCkoCcNE1Vw aNZd07OwSa90c0jfBwxkCraUg1A9vafe2+VJa3zVpyqDeTaRDqNwCHlHDFO3ihf4pw1l 87xYcXYBq/GukUHKk7zIpNdmmmHfreouTbcGaO/YVXcf6W7HdhzT/OcRum/RkHmFiRZN Y2i+FBZ4C9I/Uaf0LRo3j3dvEGfZ82Oc8gNxS69IIPOGPAq9m3pFdWZkqjFHBpbYJq6r XOCr6VVnuz+Ygqb6gs+2IrXw3EqVKaDAyTmJRxJduqdEs926rXHbYSW88YLJsau7+aag idZw== Received: by 10.180.92.8 with SMTP id ci8mr58190568wib.15.1337898616938; Thu, 24 May 2012 15:30:16 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id fo7sm50523569wib.9.2012.05.24.15.30.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 15:30:15 -0700 (PDT) Date: Fri, 25 May 2012 00:30:05 +0200 From: Mateusz Guzik To: Mike Jakubik Message-ID: <20120524223004.GC17579@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1337898015.1908.27.camel@mike-PC> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:30:18 -0000 On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote: > On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote: > > On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: > > > On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: > > > > On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: > > > > > Hello, > > > > > > > > > > Latest 9-STABLE has introduced some changes that break the ezjail rc > > > > > script. On bootup it fails to start, but when i log in via ssh and > > > > > manually start it, it works. However i am unable to shut them down > > > > > afterwards. > > > > > > > > > Try this: > > > > http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch > > > > > > > > cd /usr/src && patch -p1 < patch && cd usr.sbin/jail && make && make install > > > > > > > > /usr/src/etc/rc.d/jail script can be just copied over. > > > > > > > > Note that your /var/run/jail_* files have broken content (some line from > > > > /etc/rc's output instead of jail id). > > > > > > > > > > Mateusz, > > > > > > Thanks for the patch, it fixes the startup issue on boot, however > > > shutting down the jails still does not work. The /var/run files have > > > garbage in them as you mentioned. > > > > > > root@jail.local:~# cat /var/run/jail_app.id > > > /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). > > > > > > > > > Hostname is set in /etc/rc.conf. > > > > This message is about rc.conf from your jail. > > > > This should be fixed by my change to etc/rc.d/jail, are you sure that > > you are running patched version? > > > > Right, i just realized this. I set the hostname in the jailed rc.conf, > now the file contains this: > > root@jail.local:~# cat /var/run/jail_app.id > Setting hostname: app.local. > > I do not see a link to your jail rc.d script, just the patch. > > Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail. Assuming that the patch is still applied to your source tree, just do: cp /usr/src/etc/rc.d/jail /etc/rc.d/jail This fixes the jail script to actually store jail id instead of messages from /etc/rc. That is, you should be able to stop jails started by new etc/rc.d/jail script. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:46:59 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA841106566B for ; Thu, 24 May 2012 22:46:59 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6A63F8FC0A for ; Thu, 24 May 2012 22:46:59 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id q4OMkvjB071058; Thu, 24 May 2012 16:46:57 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4FBEBA5C.7050804@FreeBSD.org> Date: Thu, 24 May 2012 16:46:52 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: Mateusz Guzik References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> <20120524223004.GC17579@dft-labs.eu> In-Reply-To: <20120524223004.GC17579@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:46:59 -0000 On 05/24/12 16:30, Mateusz Guzik wrote: > On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote: >> On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote: >>> On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: >>>> On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: >>>>> On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: >>>>>> Hello, >>>>>> >>>>>> Latest 9-STABLE has introduced some changes that break the ezjail rc >>>>>> script. On bootup it fails to start, but when i log in via ssh and >>>>>> manually start it, it works. However i am unable to shut them down >>>>>> afterwards. >>>>>> >>>>> Try this: >>>>> http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch >>>>> >>>>> cd /usr/src&& patch -p1< patch&& cd usr.sbin/jail&& make&& make install >>>>> >>>>> /usr/src/etc/rc.d/jail script can be just copied over. >>>>> >>>>> Note that your /var/run/jail_* files have broken content (some line from >>>>> /etc/rc's output instead of jail id). >>>>> >>>> >>>> Mateusz, >>>> >>>> Thanks for the patch, it fixes the startup issue on boot, however >>>> shutting down the jails still does not work. The /var/run files have >>>> garbage in them as you mentioned. >>>> >>>> root@jail.local:~# cat /var/run/jail_app.id >>>> /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). >>>> >>>> >>>> Hostname is set in /etc/rc.conf. >>> >>> This message is about rc.conf from your jail. >>> >>> This should be fixed by my change to etc/rc.d/jail, are you sure that >>> you are running patched version? >>> >> >> Right, i just realized this. I set the hostname in the jailed rc.conf, >> now the file contains this: >> >> root@jail.local:~# cat /var/run/jail_app.id >> Setting hostname: app.local. >> >> I do not see a link to your jail rc.d script, just the patch. >> >> > > Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail. > > Assuming that the patch is still applied to your source tree, just do: > cp /usr/src/etc/rc.d/jail /etc/rc.d/jail > > This fixes the jail script to actually store jail id instead of messages > from /etc/rc. > > That is, you should be able to stop jails started by new etc/rc.d/jail > script. I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. - Jamie From owner-freebsd-stable@FreeBSD.ORG Thu May 24 22:59:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A6BF106566B; Thu, 24 May 2012 22:59:46 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id C43878FC14; Thu, 24 May 2012 22:59:45 +0000 (UTC) Received: by wibhj8 with SMTP id hj8so5180770wib.13 for ; Thu, 24 May 2012 15:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=a1xk0hbpGywL/Xu+vadGTo7Sg842kR/L9u/bWNTyD7c=; b=YrXu/VIEsUfWj+vKuAmxndRAvyyDG3QWeW8GSWCHVTu7jgzLKWzRVLHF6GM6Q++Hlp 6XEFEehH5Ce12PAEEBdO0zCwQXyfuv4DzyKoaJDLndT9DGPh3IXU5SgHEeauru0HHuFx O0By31i8VMA37J8u6aHNXOYC7vG+4a43yC3UQRsgB494Ip/kpWCTjUGdDIAQ30E/noFb RYSmqgARdn4hLKPToRxiqQ8molFFXoRgyICd+WZZOj/gRQ0vzrjAg7a6/1Y+hv7qAMRW GIj6geE0Nj0tAe+FGm6I9UdEr4sEV5mK7djPtlGLxcuch+MUGlTtmxLOwIBvaSJs+vAK LNqA== Received: by 10.216.30.213 with SMTP id k63mr620638wea.59.1337900383605; Thu, 24 May 2012 15:59:43 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id d10sm13172360wiy.3.2012.05.24.15.59.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 15:59:42 -0700 (PDT) Date: Fri, 25 May 2012 00:59:31 +0200 From: Mateusz Guzik To: Jamie Gritton Message-ID: <20120524225931.GD17579@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> <20120524223004.GC17579@dft-labs.eu> <4FBEBA5C.7050804@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FBEBA5C.7050804@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mike Jakubik , "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:59:46 -0000 On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: > I'll get the patch to jail(8) in - thanks for catching that. But I > wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm > going to see if it's /etc/rc.d/jail that needs changing, or if my recent > changes to jail(8) have changed the order in which things are written. > Yeah, was not sure whether I should change the order or the script. :) Would not it be better to just create empty persistent jail as first step? Since in this case only one line will be generated (jid), rc.d script will be able to just take the output - this seems much less fragile than the current method. Then of course it would proceed with jexec running /etc/rc and in the end drop persist flag. It looks like rc.d script still uses old syntax so this actually may be less trivial than it sounds. That being said, if this is idea sounds okay, I can try to come up with a patch this weekend. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Thu May 24 23:14:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 694CE106566B; Thu, 24 May 2012 23:14:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 0DCA28FC15; Thu, 24 May 2012 23:14:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4ONEHXB056915; Thu, 24 May 2012 17:14:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4ONEHhH056912; Thu, 24 May 2012 17:14:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 24 May 2012 17:14:17 -0600 (MDT) From: Warren Block To: sbruno@freebsd.org In-Reply-To: <1337883634.2709.7.camel@powernoodle-l7.corp.yahoo.com> Message-ID: References: <1337883634.2709.7.camel@powernoodle-l7.corp.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 24 May 2012 17:14:17 -0600 (MDT) Cc: "freebsd-stable@freebsd.org" Subject: Re: ports devel/tkcvs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 23:14:18 -0000 On Thu, 24 May 2012, Sean Bruno wrote: > Probably doing something wrong, but when I install tkcvs to get tkdiff > on my box, the only thing it does is fire up and display a "wish" > window. > > Did I do it wrong? :-) No idea, but devel/diffuse might be alternative. From owner-freebsd-stable@FreeBSD.ORG Fri May 25 00:47:35 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 192EC106566C for ; Fri, 25 May 2012 00:47:35 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 800158FC0A for ; Fri, 25 May 2012 00:47:34 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-208.hsd1.ut.comcast.net [174.52.130.208]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id q4P0lWNn072118; Thu, 24 May 2012 18:47:32 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4FBED6A2.2060602@FreeBSD.org> Date: Thu, 24 May 2012 18:47:30 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Mateusz Guzik References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> <20120524223004.GC17579@dft-labs.eu> <4FBEBA5C.7050804@FreeBSD.org> <20120524225931.GD17579@dft-labs.eu> In-Reply-To: <20120524225931.GD17579@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 00:47:35 -0000 On 05/24/12 16:59, Mateusz Guzik wrote: > On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: >> I'll get the patch to jail(8) in - thanks for catching that. But I >> wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm >> going to see if it's /etc/rc.d/jail that needs changing, or if my recent >> changes to jail(8) have changed the order in which things are written. >> > > Yeah, was not sure whether I should change the order or the script. :) > > Would not it be better to just create empty persistent jail as first step? > Since in this case only one line will be generated (jid), rc.d script > will be able to just take the output - this seems much less fragile > than the current method. Then of course it would proceed with jexec > running /etc/rc and in the end drop persist flag. > > It looks like rc.d script still uses old syntax so this actually may be > less trivial than it sounds. That being said, if this is idea sounds > okay, I can try to come up with a patch this weekend. There definitely is a difference between old and new jail behavior, not just in the order of things: glorfindel# jail -i -c name=foo command="foo" 5 jail: execvp: foo: No such file or directory vs glorfindel# /usr/obj`pwd`/jail -i -c name=foo command="foo" jail: exec foo: No such file or directory jail: foo: failed -1 The jail id given back used to correspond to a jail that was created but no longer exists by the time it's printed (or shortly thereafter). Now it's a -1 indicating that no jail exists. I think the -1 is more correct, but perhaps better for CURRENT but not STABLE? And the extra "foo: failed" is printed by jail, as a generic message when a command doesn't work out (for the case where the command itself doesn't print a message). Hmm ... I'll be pondering this one while I get a bite to eat :-). - Jamie From owner-freebsd-stable@FreeBSD.ORG Fri May 25 01:23:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 009F3106564A; Fri, 25 May 2012 01:23:33 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5BFA08FC17; Fri, 25 May 2012 01:23:32 +0000 (UTC) Received: by werg1 with SMTP id g1so323932wer.13 for ; Thu, 24 May 2012 18:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6AWsls2g+YZKUXpV7Mbnz1G6tNrd56qkvQ1cU5D2zaA=; b=noHHPLiro5GUYrIiaEAo7yAVnvkuZGQRZ1wr+L3PSGBcN8xNx/NJuTIeWDoQ8jNq43 wctGW+HNE5C/6DfwzfdF9JF+9iQXE+fz87z6wJZYPDbfFFOY6PgBI+udDyDuZyqz5Wil TnR1ty6nZd6zGAQvGmNXGOoYX3TWYJLL3rVNj8jXBpnsRIvLL9ZGBnrCXZeY626fB+GP UnRTT3biZ+9FwAkFk6vLXkG8tiWkdR6gdQxgGhUaW/qm/LWYSVvYSlH8xqkQQBXgBo+D OR7/j3OKhSP9nn60YY3kZP71Qzl47OE4yVfMBP23WanHmMerWXkEKoSJTQTngykssSVG KpeQ== Received: by 10.180.85.129 with SMTP id h1mr3074373wiz.2.1337909011385; Thu, 24 May 2012 18:23:31 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id dg2sm14379051wib.4.2012.05.24.18.23.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 May 2012 18:23:30 -0700 (PDT) Date: Fri, 25 May 2012 03:23:27 +0200 From: Mateusz Guzik To: Jamie Gritton Message-ID: <20120525012326.GA27314@dft-labs.eu> References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> <20120524223004.GC17579@dft-labs.eu> <4FBEBA5C.7050804@FreeBSD.org> <20120524225931.GD17579@dft-labs.eu> <4FBED6A2.2060602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FBED6A2.2060602@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mike Jakubik , "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:23:33 -0000 On Thu, May 24, 2012 at 06:47:30PM -0600, Jamie Gritton wrote: > On 05/24/12 16:59, Mateusz Guzik wrote: > >On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: > >>I'll get the patch to jail(8) in - thanks for catching that. But I > >>wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm > >>going to see if it's /etc/rc.d/jail that needs changing, or if my recent > >>changes to jail(8) have changed the order in which things are written. > >> > > > >Yeah, was not sure whether I should change the order or the script. :) > > > >Would not it be better to just create empty persistent jail as first step? > >Since in this case only one line will be generated (jid), rc.d script > >will be able to just take the output - this seems much less fragile > >than the current method. Then of course it would proceed with jexec > >running /etc/rc and in the end drop persist flag. > > > >It looks like rc.d script still uses old syntax so this actually may be > >less trivial than it sounds. That being said, if this is idea sounds > >okay, I can try to come up with a patch this weekend. > > > There definitely is a difference between old and new jail behavior, not > just in the order of things: > > glorfindel# jail -i -c name=foo command="foo" > 5 > jail: execvp: foo: No such file or directory > > vs > > glorfindel# /usr/obj`pwd`/jail -i -c name=foo command="foo" > jail: exec foo: No such file or directory > jail: foo: failed > -1 > > The jail id given back used to correspond to a jail that was created but > no longer exists by the time it's printed (or shortly thereafter). Now > it's a -1 indicating that no jail exists. I think the -1 is more > correct, but perhaps better for CURRENT but not STABLE? And the extra > "foo: failed" is printed by jail, as a generic message when a command > doesn't work out (for the case where the command itself doesn't print > a message). > > Hmm ... I'll be pondering this one while I get a bite to eat :-). > Note that my proposal with persistent jail creation as first step doesn't conflict with new behavior of jail(8) regarding jid printing. Also, I think that head -> tail change for rc.d script that I proposed is broken. I think that as a short-term solution you should restore old behavior (jid printed before everything else) for -STABLE. The reason is that currently you have to take the jid from the last line, but you cannot be sure that jailed processes didn't mess with the output, so you actually cannot trust the last line, so you don't know the actual jid. That is: rc.d/jail reads the last line jail(8) just writes jid to very same file that contains output of jailed /etc/rc. So if the last line written by jailed processes doesn't end with newline character, jail(8) will just append jid to the line, so the actual content of /var/run/jail_foo.id will consist of characters written by possibly malicious script and jid. This could be used to store jid of another jail (assuming jid 2, /etc/rc consisting of echo -n 1 would result in stored jid 12 etc.) or random content that in some conditions could lead to code execution. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Fri May 25 02:39:12 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 336EE1065670 for ; Fri, 25 May 2012 02:39:12 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 076D58FC0C for ; Fri, 25 May 2012 02:39:11 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-208.hsd1.ut.comcast.net [174.52.130.208]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id q4P2d9Qc072990; Thu, 24 May 2012 20:39:09 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4FBEF0CB.8090005@FreeBSD.org> Date: Thu, 24 May 2012 20:39:07 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Mateusz Guzik References: <1337887134.1908.20.camel@mike-PC> <20120524212219.GA17579@dft-labs.eu> <1337897210.1908.24.camel@mike-PC> <20120524221353.GB17579@dft-labs.eu> <1337898015.1908.27.camel@mike-PC> <20120524223004.GC17579@dft-labs.eu> <4FBEBA5C.7050804@FreeBSD.org> <20120524225931.GD17579@dft-labs.eu> <4FBED6A2.2060602@FreeBSD.org> <20120525012326.GA27314@dft-labs.eu> In-Reply-To: <20120525012326.GA27314@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , "freebsd-stable@freebsd.org" Subject: Re: Jail startup/shutdown broken on latest 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 02:39:12 -0000 On 05/24/12 19:23, Mateusz Guzik wrote: > On Thu, May 24, 2012 at 06:47:30PM -0600, Jamie Gritton wrote: >> On 05/24/12 16:59, Mateusz Guzik wrote: >>> On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: >>>> I'll get the patch to jail(8) in - thanks for catching that. But I >>>> wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm >>>> going to see if it's /etc/rc.d/jail that needs changing, or if my recent >>>> changes to jail(8) have changed the order in which things are written. >>>> >>> >>> Yeah, was not sure whether I should change the order or the script. :) >>> >>> Would not it be better to just create empty persistent jail as first step? >>> Since in this case only one line will be generated (jid), rc.d script >>> will be able to just take the output - this seems much less fragile >>> than the current method. Then of course it would proceed with jexec >>> running /etc/rc and in the end drop persist flag. >>> >>> It looks like rc.d script still uses old syntax so this actually may be >>> less trivial than it sounds. That being said, if this is idea sounds >>> okay, I can try to come up with a patch this weekend. >> >> >> There definitely is a difference between old and new jail behavior, not >> just in the order of things: >> >> glorfindel# jail -i -c name=foo command="foo" >> 5 >> jail: execvp: foo: No such file or directory >> >> vs >> >> glorfindel# /usr/obj`pwd`/jail -i -c name=foo command="foo" >> jail: exec foo: No such file or directory >> jail: foo: failed >> -1 >> >> The jail id given back used to correspond to a jail that was created but >> no longer exists by the time it's printed (or shortly thereafter). Now >> it's a -1 indicating that no jail exists. I think the -1 is more >> correct, but perhaps better for CURRENT but not STABLE? And the extra >> "foo: failed" is printed by jail, as a generic message when a command >> doesn't work out (for the case where the command itself doesn't print >> a message). >> >> Hmm ... I'll be pondering this one while I get a bite to eat :-). >> > > Note that my proposal with persistent jail creation as first step doesn't > conflict with new behavior of jail(8) regarding jid printing. > > Also, I think that head -> tail change for rc.d script that I proposed is > broken. > > I think that as a short-term solution you should restore old behavior > (jid printed before everything else) for -STABLE. The reason is that > currently you have to take the jid from the last line, but you cannot be > sure that jailed processes didn't mess with the output, so you actually > cannot trust the last line, so you don't know the actual jid. > > That is: > rc.d/jail reads the last line > > jail(8) just writes jid to very same file that contains output of jailed > /etc/rc. So if the last line written by jailed processes doesn't end with > newline character, jail(8) will just append jid to the line, so > the actual content of /var/run/jail_foo.id will consist of characters > written by possibly malicious script and jid. > > This could be used to store jid of another jail (assuming jid 2, /etc/rc > consisting of echo -n 1 would result in stored jid 12 etc.) or random > content that in some conditions could lead to code execution. I think I should restore the old behavior for CURRENT as well. The -i option really only exists for /etc/rc.d/jail, and should behave the way it expects it to. And if anything else uses it, all the more reason not to change it. - Jamie From owner-freebsd-stable@FreeBSD.ORG Fri May 25 03:46:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F12FB106566B; Fri, 25 May 2012 03:46:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B27918FC0A; Fri, 25 May 2012 03:46:03 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so1267472pbb.13 for ; Thu, 24 May 2012 20:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=thJ5Gputl3SVZhU4jG4Us81/b3675qc5U2Fhb3e3gHA=; b=fDZehqoolly24MxVxxZR4taBEmyDBGR960jDk5b5kXmRJ9rMlZgOGhsK9M5E5w8loX GxFNCSuwE8VbqmjLQFs/NoXc+ilBAqiKhSUQvwdiEeZcf0o0jNv9mA+csb8O9+g0NqT0 N6zY4lmOEVbMXhno5xtXNBbuSYIAejYngDzupv6eYMBEeKOlXjP9w7EB+0Q3LQSYX+OR zoHmv6hdbmXSTf37n5W9/wB0gBD+gQ5BmLRBK7KF3G2QCRMOCWl4cJkgJDOo597h86p3 IvecaLZC/IJ1y/ba76uTfyNcxu/IINNBeZXpbj9Jg7oLieut/GmE6chv5PiC26haMXXt q9ZA== MIME-Version: 1.0 Received: by 10.68.211.170 with SMTP id nd10mr28312420pbc.68.1337917563280; Thu, 24 May 2012 20:46:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Thu, 24 May 2012 20:46:03 -0700 (PDT) Date: Thu, 24 May 2012 20:46:03 -0700 X-Google-Sender-Auth: UGoXfQE-eXrtqexVfMQbMXM7DAg Message-ID: From: Adrian Chadd To: freebsd-mobile@freebsd.org, FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: jkim@freebsd.org, Mitsuru IWASAKI Subject: STABLE/9 SMP ACPI suspend/resume - video mode not being restored X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 03:46:04 -0000 Hi, I'm toying with the SMP/i386 ACPI suspend/resume patches in -9. Thanks so much for this! I've noticed though that the video backlight stays off after resume. A common problem on -9, so I set hw.acpi.reset_video=1. That restores the backlight. However, the video mode isn't restored. I have my console set to VGA_80x60 and the resume seems to set it up "wrong". I get half or so of each line displayed. A vidcontrol VGA_80x60 restores things to proper working order. Is there a shortcoming somewhere in syscons/ACPI video restore on -9 that doesn't properly restore the configured mode? Thanks again for all your hard work! Now that you've done that, I'll go off and work on fixing up ath(4) suspend/resume for PCI devices. :) Adrian From owner-freebsd-stable@FreeBSD.ORG Fri May 25 04:07:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA8461065672; Fri, 25 May 2012 04:07:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6988C8FC0A; Fri, 25 May 2012 04:07:01 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q4P470hO016035; Thu, 24 May 2012 21:07:00 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q4P470t2016034; Thu, 24 May 2012 21:07:00 -0700 (PDT) (envelope-from david) Date: Thu, 24 May 2012 21:07:00 -0700 From: David Wolfskill To: Adrian Chadd Message-ID: <20120525040700.GH2446@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Adrian Chadd , freebsd-mobile@freebsd.org, FreeBSD Stable Mailing List , jkim@freebsd.org, Mitsuru IWASAKI References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYYhpFXgKVw71fwr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Mitsuru IWASAKI , FreeBSD Stable Mailing List , jkim@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 04:07:01 -0000 --mYYhpFXgKVw71fwr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 24, 2012 at 08:46:03PM -0700, Adrian Chadd wrote: > Hi, >=20 > I'm toying with the SMP/i386 ACPI suspend/resume patches in -9. Thanks > so much for this! Note that enough of those patches have been committed (at least as of r235891) that I was able to perform suspend/resume properly on my laptop (a Dell Precision M4400; video is "NVIDIA GPU Quadro FX 770M (G96GL)", and I use the nVidia driver (ports/x11/nvidia-driver)) without adding more patches. > I've noticed though that the video backlight stays off after resume. A > common problem on -9, so I set hw.acpi.reset_video=3D1. That restores > the backlight. I do not see that behavior, and: g1-227(8.3-S)[7] sysctl hw.acpi.reset_video hw.acpi.reset_video: 0 (Yes, I'm running stable/8 on the present slice. I have stable/9 on another slice. And the experiment I did was with a slice where I had built stable/9 (i386) using clang.) > However, the video mode isn't restored. I have my console set to > VGA_80x60 and the resume seems to set it up "wrong". I get half or so > of each line displayed. That is another issue that I have not observed (in my case). > ... > Is there a shortcoming somewhere in syscons/ACPI video restore on -9 > that doesn't properly restore the configured mode? I believe that my experience is evidence that if such a shortciming exists, it is not a general one. For me, suspend/resume in stable/9 Just Works (thanks to the hard work of others (such as iwasaki@), of course). > Thanks again for all your hard work! Now that you've done that, I'll > go off and work on fixing up ath(4) suspend/resume for PCI devices. :) Cool! :-) (Adrian, next BAFUG, perhaps we could compare notes/behaviors in person, if that might be of use?) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --mYYhpFXgKVw71fwr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+/BWMACgkQmprOCmdXAD3hxQCfRnE08WTGdP/3czZSu3LRnWL4 YZ4An3oFAvDDNTX/F9Q3TgtMbiT7vsyN =VObg -----END PGP SIGNATURE----- --mYYhpFXgKVw71fwr-- From owner-freebsd-stable@FreeBSD.ORG Fri May 25 04:49:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 394E5106564A; Fri, 25 May 2012 04:49:14 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id DC89F8FC0C; Fri, 25 May 2012 04:49:12 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4P4n5sc083244; Fri, 25 May 2012 13:49:06 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Fri, 25 May 2012 13:49:03 +0900 (JST) Message-Id: <20120525.134903.05583594.iwasaki@jp.FreeBSD.org> To: adrian@freebsd.org From: Mitsuru IWASAKI In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: iwasaki@freebsd.org, freebsd-stable@freebsd.org, jkim@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 04:49:14 -0000 Hi, thanks for reporting! > However, the video mode isn't restored. I have my console set to > VGA_80x60 and the resume seems to set it up "wrong". I get half or so > of each line displayed. > > A vidcontrol VGA_80x60 restores things to proper working order. > > Is there a shortcoming somewhere in syscons/ACPI video restore on -9 > that doesn't properly restore the configured mode? Do you have vesa(4) in your kernel? It seems dev/fv/vesa.c:vesa_bios_post() restore the mode when resuming, but it's maybe incomplete in some cases... I think great work was done in this area, and we can improve this more. How about switching vty to other different mode vty and switching back in order to force changing video mode? I think it's better than re-run vidcontrol. > Thanks again for all your hard work! Now that you've done that, I'll > go off and work on fixing up ath(4) suspend/resume for PCI devices. :) This is my pleasure :) Thanks! From owner-freebsd-stable@FreeBSD.ORG Fri May 25 05:31:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48770106564A for ; Fri, 25 May 2012 05:31:55 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id D6B598FC0C for ; Fri, 25 May 2012 05:31:54 +0000 (UTC) Received: (qmail 52486 invoked by uid 907); 25 May 2012 05:25:11 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (202.68.173.218) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Fri, 25 May 2012 15:25:11 +1000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jan Mikkelsen In-Reply-To: Date: Fri, 25 May 2012 15:25:09 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pete French X-Mailer: Apple Mail (2.1278) Cc: freebsd-stable@freebsd.org Subject: Re: VirtualBox, AIO and zvol's - a cautionary tale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 05:31:55 -0000 Hi, On 23/05/2012, at 11:11 PM, Pete French wrote: > Am posting this to stable not really as a question, but more in case = anyone > else hits the same problem. Last patch tuesday one of my virtual = Windows > machines running under VirtualBox started crashing. By which I mean > that VirtualBox would quit. This had been running tsably for a long > tine, so it puzzled me. >=20 > First thought was it was sme patch from patch-tuesday. But rolling = back > to an earlier version of the disc showed it wasn't - the crashes were > occurring before the patch had been applied. >=20 > I'll skip the hours of puzzlement which followed - it turrned out that > the indirect cause was that a few weeks ago I had installed Samba > onto the same server. In doing so I had enabled AIO, as this improves > Samba performance. >=20 > What I didn't realise is that if VirtualBox finds AIO loaded it = proceeds > to use it. So by doing that I had switched on AIO inside my virtual > machines as well. The disc I use for my virtual machines are all zvols = (it > performs better, and it seems that VirtualBox has a problem using AIO > to access zvols. >=20 > But this didn;t show up for weeks because in the normal scheme of = things > my virtual machines dont acccess the local dirve very much. It was = only > when they started downloading patches that the crash happened. >=20 > Solution is simple - disable AIO. All then goes back to being nice > and stable again. But it did take a while to find. I have seen similar behaviour, but I did not disable AIO to solve it. = Instead, in the VirtualBox VM, I made sure that the storage controller = was created with the "--hostiocache on" option. Without that, the = virtual machines were unreliable on ZFS with the same behaviour you saw. Do you have the hostiocache enabled or disabled in your VM? Does it make = a difference? Regards, Jan. From owner-freebsd-stable@FreeBSD.ORG Fri May 25 05:44:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFFF3106566B; Fri, 25 May 2012 05:44:55 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id 313F68FC08; Fri, 25 May 2012 05:44:54 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.5/8.14.5) with ESMTP id q4P5iicI071005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 07:44:44 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.5/8.14.5/Submit) with ESMTP id q4P5iiQJ071002; Fri, 25 May 2012 07:44:44 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 25 May 2012 07:44:39 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: sbruno@freebsd.org In-Reply-To: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> Message-ID: References: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-446179856-1337924684=:84474" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: "freebsd-stable@freebsd.org" Subject: Re: bash 4.2 patchlevel 28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 05:44:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-446179856-1337924684=:84474 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 24 May 2012 13:07-0700, Sean Bruno wrote: > Noted that the following syntax is broken somewhere between 4.2 > patchlevel 10 and 28. I'm sure its because we shouldn't be doing that > over here at big purple, but we do ... and its a PITA. I'm bisecting to > find out what is going on. > > test: > VARIABLE="$(uname)" > bash: command substitution: line 3: syntax error near unexpected token > `)' > bash: command substitution: line 3: `uname)"' > > Odd, but his works at patchlevel 10 I'm unable to reproduce this behaviour on one of my systems: trond@enterprise:~>bash --version GNU bash, version 4.2.28(0)-release (amd64-portbld-freebsd9.0) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. trond@enterprise:~>my_var="$(uname)" trond@enterprise:~>echo $my_var FreeBSD trond@enterprise:~> I'm not sure what's going on in your case. - -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. dir. 61 14 54 39, | Office.....: +47 61 14 54 39, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk+/HEwACgkQbYWZalUoElvZYwCeLq5IHGp2dLyf+pcbzC1jk3RK us4An1AX5SelbwMEEVmooiopPmF9SAlI =9bTW -----END PGP SIGNATURE----- --2055831798-446179856-1337924684=:84474-- From owner-freebsd-stable@FreeBSD.ORG Fri May 25 07:51:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E9661065672; Fri, 25 May 2012 07:51:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id F0A5E8FC0A; Fri, 25 May 2012 07:51:38 +0000 (UTC) Received: by dadv36 with SMTP id v36so954299dad.13 for ; Fri, 25 May 2012 00:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6BneaLmeDisiqUVRXbPjHRW3C2hUUIr3OVj4ejgb+hc=; b=XWBNYKcxsUbngXvTFC1ptx1Jh13wKvEaQQOdpo3JkEnCezgc9tJoC22nTcJq74NEub pN1E6hZO76kLoyHZ2DnNoT74QJ6COZa8OJtGIVp3/+DHLWP1oMncWVNqcnCeJUtrYMGw SxVi/wvBXz3FYUW0oVLJZAuj2uChWM+gmE+RT7rYAenQPYi986UXZnAxSFS3aITUsWAW ut5pqejKVrsoBFH50n84d2I79EDracWmxSVyXtqIxPEAO2uRNI+Pg4t6NQtdxfBZHvv/ lGKexzt27nXmeqih0szd67jB+MV0lauJexTqv7T0zLxP3FORvfyumcW9mzF9H/CDSxLC bqnA== MIME-Version: 1.0 Received: by 10.68.211.170 with SMTP id nd10mr30281167pbc.68.1337932298474; Fri, 25 May 2012 00:51:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Fri, 25 May 2012 00:51:38 -0700 (PDT) In-Reply-To: <20120525.134903.05583594.iwasaki@jp.FreeBSD.org> References: <20120525.134903.05583594.iwasaki@jp.FreeBSD.org> Date: Fri, 25 May 2012 00:51:38 -0700 X-Google-Sender-Auth: Y26KdQr7qoCOHpGpcLBQfPr10X8 Message-ID: From: Adrian Chadd To: Mitsuru IWASAKI Content-Type: text/plain; charset=ISO-8859-1 Cc: iwasaki@freebsd.org, freebsd-stable@freebsd.org, jkim@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 07:51:39 -0000 Hi, No, I didn't have vesa loaded. I'll load that now and try tomorrow after a reboot. Yes, I tried switching VTYs, each VTY had the same issue. I guess the driver isn't doing a VGA mode change when I switch VTYs unless the screens are in different modes? FWIW, Xorg suspend/resume via the "switch to VTY before suspending" hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Adrian From owner-freebsd-stable@FreeBSD.ORG Fri May 25 10:01:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789D61065675 for ; Fri, 25 May 2012 10:01:14 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id 142688FC0A for ; Fri, 25 May 2012 10:01:14 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SXrKK-000Fmj-5l; Fri, 25 May 2012 11:00:56 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXrKK-000M5Y-53; Fri, 25 May 2012 11:00:56 +0100 To: janm@transactionware.com, petefrench@ingresso.co.uk In-Reply-To: Message-Id: From: Pete French Date: Fri, 25 May 2012 11:00:56 +0100 Cc: freebsd-stable@freebsd.org Subject: Re: VirtualBox, AIO and zvol's - a cautionary tale X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:01:14 -0000 > I have seen similar behaviour, but I did not disable AIO to solve it. Instead, in the VirtualBox VM, I made sure that the storage controller was created with the "--hostiocache on" option. Without that, the virtual machines were unreliable on ZFS with the same behaviour you saw. Interesting. I have this setting "Off" - but my machines were perfectly reliable until AIO was added to the mix. Are yours directly on top of a zvol as the underlying disc, or using files on ZFS ? Will try enabling that setting - thoigh as it is stable anyway it wont make a lot of diffeernce I hope! cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Fri May 25 10:38:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C11D4106564A for ; Fri, 25 May 2012 10:38:35 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 877F88FC0C for ; Fri, 25 May 2012 10:38:35 +0000 (UTC) Received: by obcni5 with SMTP id ni5so1391970obc.13 for ; Fri, 25 May 2012 03:38:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=CQva4bfe04Hg0zjkK7eTZmmjyTMob/SwEMhgWWio0vU=; b=SkVaeRJemo71sbe9ak1qSiFerilAH5KkkAE8mUb27erbgOqwAUEd8CJSoEVMCeVHYL ytLm9DoEh6bAd5NngkRdJyKju9I7J5xxw9TDX5bMlOLUhMxU935tyOgaJf4H2g7cmsIR Ls0PHBgkWqsvg+zllUxoFrTzoM/irc4qZvwGbUjU5yy9YgNY1S+MXjfYSQ6UBKJnetaI PMThDGRppDVECaM3bqAwsuj1uQHL6p1xvctupbDC+HiTOZUy2+J/Xe7SflCl61l4Ebyz 6Scuwo+REg4sW1i/mHCSpsdiPcCN9rrUWpCJ8MuSKP8OD5FiK64Pf6S9Q33AtGY+udHz vd4Q== Received: by 10.182.145.4 with SMTP id sq4mr2511288obb.76.1337942314919; Fri, 25 May 2012 03:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.171.84 with HTTP; Fri, 25 May 2012 03:38:14 -0700 (PDT) From: "Manuel Trujillo (TooManySecrets)" Date: Fri, 25 May 2012 12:38:14 +0200 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnRL78NLbNRkeG+61yAcH8b7d7bauMGaS/1bITqnYTJZM5uXMwjCyoXKKbD6QA4KT1kGvIZ Subject: Problem with sub-path (or sub-url) in smbfs. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:38:35 -0000 Hi! I don't know if this is the right list for this question, but I cannot find anything related about "cifs" or "samba". By the way I would apologize about my bad english... My system is a FreeBSD 9-RELEASE i386. The windows server at office have a large path to the shares (sub-path), e.= g. //teide/recursos/usuarios/myuser where "recursos" is a share, and inside it, "myuser" is another share from "usuarios" (users). This runs fine in any linux. In FreeBSD this is my fstab entry: //mtrujillo@teide/recursos/usuarios/myuser /media/personal smbfs noauto,rw,-u=3Dmyuser,-g=3Dmyuser,-N 0 0 I have also an /etc/nsmb.conf configured. All runs fine... except because I only can mount up to "recursos" (from the line teide/recursos/usuarios/myuser), and NOT the share "myuser" (the last part of the PATH). Anybody could help me please? Thank you very much! --=20 ---------------------------------------------------------------------------= ------------ Have a nice day=C2=A0 ;-) TooManySecrets /"\=C2=A0=C2=A0 ASCII Ribbon Campaign=C2=A0 | FreeBSD Since 4.1 \ / - NO HTML/RTF in e-mail=C2=A0 | GNU/Linux Since 1993. =C2=A0X=C2=A0 - NO Word docs in e-mail | OpenBSD User / \=C2=A0 - http://www.toomany.net | http://twitter.com/toomanysecrets ---------------------------------------------------------------------------= ------------ From owner-freebsd-stable@FreeBSD.ORG Fri May 25 14:37:51 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FD10106566B; Fri, 25 May 2012 14:37:51 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1918FC17; Fri, 25 May 2012 14:37:48 +0000 (UTC) Received: from maka.home.yamagi.org (pD9522939.dip.t-dialin.net [217.82.41.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 0E9A81666334; Fri, 25 May 2012 16:37:02 +0200 (CEST) Date: Fri, 25 May 2012 16:36:53 +0200 From: Yamagi Burmeister To: seanbru@yahoo-inc.com Message-Id: <20120525163653.b61a08e2.lists@yamagi.org> In-Reply-To: <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__25_May_2012_16_36_53_+0200_1q4ByDzg_.J3ETYT" Cc: sbruno@FreeBSD.org, freebsd-stable@FreeBSD.org, jkim@FreeBSD.org Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:37:51 -0000 --Signature=_Fri__25_May_2012_16_36_53_+0200_1q4ByDzg_.J3ETYT Content-Type: multipart/mixed; boundary="Multipart=_Fri__25_May_2012_16_36_53_+0200_A1+Vw_9qRJb/a2WP" --Multipart=_Fri__25_May_2012_16_36_53_+0200_A1+Vw_9qRJb/a2WP Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, a user at BSDForen.de had the same problem and I helped him to track it down. While I was unable to find a solution I found the cause of the problems. The problem is (all files and line numbers relative to FreeBSD 9.0-RELEASE): 1. When a new p-state is requested (by powerd or by changing the sysctl) in kern/kern_cpu.c the function cf_set_method() is invoked.=20 2. In line 335 the driver depended function is called. For newer AMD CPU it's hwpstate_set() in x86/cpufreq/hwpstate.c 3. In x86/cpufreq/hwpstate.c line 227 hwpstate_goto_pstate() is called which does the actual magic. 4. In line 199 "if (msr !=3D id)" triggers, returns ENXIO. The error is send back to cf_set_method(), which prints the "hwpstate0: set freq failed". powerd translates the error to "Device not configured" After some further investigation and looking at the linux driver [0] I changed the loop at x86/cpufreq/hwpstate.c 188ff from 100 iterations to 250. It lessend the problem but didn't solve it. The next step was to rewrite the logic between line 183 and 203 and adding a lot of debug printf. The patch (non style(9) compliant) is attached. With the new logic every 100 usec the new p-state is set again, until it's accepted. After 100 tries ENXIO is returned. This lessend the problem even more and showed that - On an old Phenom II X4 940 (K10 / Deneb) the new p-state is always accepted at the first try. At a test run for about 3 hours there was not a single failure. - On the Bulldozer CPU in about 9 in 10 times the new p-state is=20 accepted at the first try. At most other times the new p-state is accepted after 1 to 10 tries. And there is a ~0,25% chance that the new p-state is never accepted, leading to "hwpstate0: set freq failed". At the next call to cf_set_method() (about 500ms to 1s later) the new p-state it's most likely set successfull. This can be seen at the log (full log attached): =20 # First call, failed after 102 iterations hwpstate0: MSR: 0 ID: 1 hwpstate0: Setting failed! hwpstate0: Iterations: 102 # Second call, successfull hwpstate0: setting P1-state on cpu1 hwpstate0: MSR: 1 ID: 1 hwpstate0: Iterations: 1 So the big question is: Why is the new p-state sometimes not accepted? And why does this only happen on Bulldozer CPUs and not at the old=20 K10 (Barcelona, Deneb), etc? Reading the "BIOS and kernel developer guide" for Bulldozer didn't show anything, but I may have overlooked it. One solution may be to change hwpstate not to set p-states but=20 "Frequency IDs" (FID) and "Voltage ID" (VID) like the linux driver does. 0: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f= =3Ddrivers/cpufreq/powernow-k8.c;h=3Dc0e816468e300f242735f4825d09b9d291a9b5= 22;hb=3DHEAD 1: http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Multipart=_Fri__25_May_2012_16_36_53_+0200_A1+Vw_9qRJb/a2WP Content-Type: text/x-diff; name="hwpstate.patch" Content-Disposition: attachment; filename="hwpstate.patch" Content-Transfer-Encoding: quoted-printable Index: hwpstate.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- hwpstate.c (Revision 229372) +++ hwpstate.c (Arbeitskopie) @@ -68,16 +68,17 @@ #include "acpi_if.h" #include "cpufreq_if.h" =20 -#define MSR_AMD_10H_11H_LIMIT 0xc0010061 -#define MSR_AMD_10H_11H_CONTROL 0xc0010062 -#define MSR_AMD_10H_11H_STATUS 0xc0010063 -#define MSR_AMD_10H_11H_CONFIG 0xc0010064 +#define MSR_AMD_10H_11H_LIMIT 0xc0010061 // Maximal p-state (0) +#define MSR_AMD_10H_11H_CONTROL 0xc0010062 // Control register +#define MSR_AMD_10H_11H_STATUS 0xc0010063 // Status register +#define MSR_AMD_10H_11H_CONFIG 0xc0010064 // Config register =20 -#define AMD_10H_11H_MAX_STATES 16 +#define AMD_10H_11H_MAX_STATES 16 // K10 =3D< 6 ; K15 =3D< 7 =20 /* for MSR_AMD_10H_11H_LIMIT C001_0061 */ #define AMD_10H_11H_GET_PSTATE_MAX_VAL(msr) (((msr) >> 4) & 0x7) -#define AMD_10H_11H_GET_PSTATE_LIMIT(msr) (((msr)) & 0x7) +#define AMD_10H_11H_GET_PSTATE_LIMIT(msr) (((msr)) & 0x7) // Same as Linux= HW_PSTATE_MASK + /* for MSR_AMD_10H_11H_CONFIG 10h:C001_0064:68 / 11h:C001_0064:6B */ #define AMD_10H_11H_CUR_VID(msr) (((msr) >> 9) & 0x7F) #define AMD_10H_11H_CUR_DID(msr) (((msr) >> 6) & 0x07) @@ -159,29 +160,67 @@ { int i; uint64_t msr; - int j; + //int j; int limit; int id =3D pstate; int error; + int y; =09 /* get the current pstate limit */ msr =3D rdmsr(MSR_AMD_10H_11H_LIMIT); limit =3D AMD_10H_11H_GET_PSTATE_LIMIT(msr); + + HWPSTATE_DEBUG(dev, "LIMIT: %d, ID: %d\n", limit, id); + + // Incorrect (too low) p-state requested? if(limit > id) + { id =3D limit; + HWPSTATE_DEBUG(dev, "LIMIT HIT!\n"); + } =20 /* * We are going to the same Px-state on all cpus. * Probably should take _PSD into account. */ error =3D 0; + CPU_FOREACH(i) { /* Bind to each cpu. */ thread_lock(curthread); sched_bind(curthread, i); thread_unlock(curthread); + HWPSTATE_DEBUG(dev, "setting P%d-state on cpu%d\n", - id, PCPU_GET(cpuid)); + id, PCPU_GET(cpuid)); + + y =3D 0; + + do { + // Linux sets a FID and a VID + wrmsr(MSR_AMD_10H_11H_CONTROL, id); + + // 100 tries + if (y++ > 100) + { + HWPSTATE_DEBUG(dev, "Setting failed!\n"); + error =3D ENXIO; + break; + } + + // 100 usec + DELAY(100); + + // Read current p-state + msr =3D rdmsr(MSR_AMD_10H_11H_STATUS); + HWPSTATE_DEBUG(dev, "MSR: %ld ID: %d\n", msr, id); + + } while(msr !=3D id); + + HWPSTATE_DEBUG(dev, "Iterations: %d\n", y); + } + +#if 0 /* Go To Px-state */ wrmsr(MSR_AMD_10H_11H_CONTROL, id); /* wait loop (100*100 usec is enough ?) */ @@ -201,6 +240,8 @@ error =3D ENXIO; } } +#endif + thread_lock(curthread); sched_unbind(curthread); thread_unlock(curthread); --Multipart=_Fri__25_May_2012_16_36_53_+0200_A1+Vw_9qRJb/a2WP Content-Type: application/octet-stream; name="hwpstate.log" Content-Disposition: attachment; filename="hwpstate.log" Content-Transfer-Encoding: base64 Y3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDE5MDAgbGV2ZWwK Y3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTY2MgpjcHVmcmVx OiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBk dXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNjYyIGFmdGVyIDE5MDAKY3B1ZnJlcTogZXhw YW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMTY2MiBsZXZlbApjcHVmcmVxOiBkdXAg c2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNDI1CmNwdWZyZXE6IHJlbW92ZWQgbGFz dCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNl cnRpbmcgbmV3IGxldmVsIDE0MjUgYWZ0ZXIgMTY2MgpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVk IHJlbCBzZXR0aW5nIDc1JSB0byAxNDI1IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJp bmcgZGVyaXZlZCBzZXR0aW5nIDExODcKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRy aXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMTE4NyAoYWJz IHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMTE4NyAobm90IG9w dGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAyMzAw IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDIwMTIK Y3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1 ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjAxMiBhZnRlciAyMzAwCmNwdWZy ZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDIwMTIgbGV2ZWwKY3B1ZnJl cTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTcyNQpjcHVmcmVxOiByZW1v dmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0 IHJlamVjdGluZyAxNzI1IChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5l dyBsZXZlbCAxNzI1IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwg c2V0dGluZyAxMDAlIHRvIDI4MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBk ZXJpdmVkIHNldHRpbmcgMjQ1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVy OiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAy NDUwIGFmdGVyIDI4MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUg dG8gMjQ1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyAyMTAwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0 bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDIxMDAgKGFicyB0b28gYmlnKQpjcHVmcmVx OiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDIxMDAgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBl eHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMzEwMCBsZXZlbApjcHVmcmVxOiBk dXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyNzEyCmNwdWZyZXE6IHJlbW92ZWQg bGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVq ZWN0aW5nIDI3MTIgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxl dmVsIDI3MTIgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBhZGRpbmcgOCByZWxhdGl2ZSBzZXR0aW5n cwpjcHVmcmVxOiBza2lwcGluZyBpbmZvLW9ubHkgZHJpdmVyIGFjcGlfcGVyZjAKY3B1ZnJlcTog YWRkaW5nIGFicyBzZXR0aW5nIDMxMDAgYXQgaGVhZApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRp bmcgMjgwMCBhZnRlciAzMTAwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAyMzAwIGFmdGVy IDI4MDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE5MDAgYWZ0ZXIgMjMwMApjcHVmcmVx OiBhZGRpbmcgYWJzIHNldHRpbmcgMTQwMCBhZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBzZXQg YWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxNDAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29u c2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEyMjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0 aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBu ZXcgbGV2ZWwgMTIyNSBhZnRlciAxNDAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNl dHRpbmcgODclIHRvIDEyMjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJp dmVkIHNldHRpbmcgMTA1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBh Y3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxMDUw IGFmdGVyIDEyMjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA3NSUgdG8g MTA1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA4 NzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAK Y3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgODc1IGFmdGVyIDEwNTAKY3B1 ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA2MiUgdG8gODc1IGxldmVsCmNwdWZy ZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDcwMApjcHVmcmVxOiByZW1v dmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9u ZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA3MDAgYWZ0ZXIgODc1CmNwdWZyZXE6IGV4cGFuZCBzZXQg YWRkZWQgcmVsIHNldHRpbmcgNTAlIHRvIDcwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNp ZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA1MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZl IGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcg bGV2ZWwgNTI1IGFmdGVyIDcwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5n IDM3JSB0byA1MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNl dHRpbmcgMzUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhy b3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDM1MCBhZnRlciA1 MjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAyNSUgdG8gMzUwIGxldmVs CmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE3NQpjcHVmcmVx OiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBk dXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNzUgYWZ0ZXIgMzUwCmNwdWZyZXE6IGV4cGFu ZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTIlIHRvIDE3NSBsZXZlbApjcHVmcmVxOiBleHBhbmQg c2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMTkwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0 IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNjYyCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCBy ZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRp bmcgbmV3IGxldmVsIDE2NjIgYWZ0ZXIgMTkwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJl bCBzZXR0aW5nIDg3JSB0byAxNjYyIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcg ZGVyaXZlZCBzZXR0aW5nIDE0MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZl cjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwg MTQyNSBhZnRlciAxNjYyCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNzUl IHRvIDE0MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRp bmcgMTE4NwpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90 dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAxMTg3IChhYnMgdG9vIGJpZykKY3B1ZnJl cTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAxMTg3IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTog ZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDIzMDAgbGV2ZWwKY3B1ZnJlcTog ZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjAxMgpjcHVmcmVxOiByZW1vdmVk IGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwg aW5zZXJ0aW5nIG5ldyBsZXZlbCAyMDEyIGFmdGVyIDIzMDAKY3B1ZnJlcTogZXhwYW5kIHNldCBh ZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMjAxMiBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNp ZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNzI1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2 ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDE3MjUg KGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDE3MjUgKG5v dCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8g MjgwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAy NDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUw CmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDI0NTAgYWZ0ZXIgMjgwMApj cHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAyNDUwIGxldmVsCmNw dWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDIxMDAKY3B1ZnJlcTog cmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVw IHNldCByZWplY3RpbmcgMjEwMCAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWlu ZyBuZXcgbGV2ZWwgMjEwMCAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQg cmVsIHNldHRpbmcgMTAwJSB0byAzMTAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJp bmcgZGVyaXZlZCBzZXR0aW5nIDI3MTIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRy aXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMjcxMiAoYWJz IHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMjcxMiAobm90IG9w dGltYWwpCmNwdWZyZXE6IGdldCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGdl dCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGdldCByZXR1cm5pbmcga25vd24g ZnJlcSAzMTAwCmNwdWZyZXE6IGdldCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6 IGdldCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGFkZGluZyA4IHJlbGF0aXZl IHNldHRpbmdzCmNwdWZyZXE6IHNraXBwaW5nIGluZm8tb25seSBkcml2ZXIgYWNwaV9wZXJmMApj cHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMzEwMCBhdCBoZWFkCmNwdWZyZXE6IGFkZGluZyBh YnMgc2V0dGluZyAyODAwIGFmdGVyIDMxMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDIz MDAgYWZ0ZXIgMjgwMApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTkwMCBhZnRlciAyMzAw CmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAxNDAwIGFmdGVyIDE5MDAKY3B1ZnJlcTogZXhw YW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDE0MDAgbGV2ZWwKY3B1ZnJlcTogZHVw IHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTIyNQpjcHVmcmVxOiByZW1vdmVkIGxh c3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5z ZXJ0aW5nIG5ldyBsZXZlbCAxMjI1IGFmdGVyIDE0MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRl ZCByZWwgc2V0dGluZyA4NyUgdG8gMTIyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVy aW5nIGRlcml2ZWQgc2V0dGluZyAxMDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBk cml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxl dmVsIDEwNTAgYWZ0ZXIgMTIyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5n IDc1JSB0byAxMDUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBz ZXR0aW5nIDg3NQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Ro cm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA4NzUgYWZ0ZXIg MTA1MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDYyJSB0byA4NzUgbGV2 ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgNzAwCmNwdWZy ZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6 IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDcwMCBhZnRlciA4NzUKY3B1ZnJlcTogZXhw YW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA1MCUgdG8gNzAwIGxldmVsCmNwdWZyZXE6IGR1cCBz ZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDUyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3Qg cmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0 aW5nIG5ldyBsZXZlbCA1MjUgYWZ0ZXIgNzAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVs IHNldHRpbmcgMzclIHRvIDUyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRl cml2ZWQgc2V0dGluZyAzNTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjog YWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMzUw IGFmdGVyIDUyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDI1JSB0byAz NTAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTc1 CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNw dWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE3NSBhZnRlciAzNTAKY3B1ZnJl cTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMiUgdG8gMTc1IGxldmVsCmNwdWZyZXE6 IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxOTAwIGxldmVsCmNwdWZyZXE6 IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE2NjIKY3B1ZnJlcTogcmVtb3Zl ZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUs IGluc2VydGluZyBuZXcgbGV2ZWwgMTY2MiBhZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBzZXQg YWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDE2NjIgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25z aWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTQyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRp dmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5l dyBsZXZlbCAxNDI1IGFmdGVyIDE2NjIKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0 dGluZyA3NSUgdG8gMTQyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2 ZWQgc2V0dGluZyAxMTg3CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFj cGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDExODcgKGFicyB0b28gYmln KQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDExODcgKG5vdCBvcHRpbWFsKQpj cHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMjMwMCBsZXZlbApj cHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyMDEyCmNwdWZyZXE6 IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1 cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDIwMTIgYWZ0ZXIgMjMwMApjcHVmcmVxOiBleHBh bmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAyMDEyIGxldmVsCmNwdWZyZXE6IGR1cCBz ZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE3MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0 IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3Rp bmcgMTcyNSAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwg MTcyNSAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcg MTAwJSB0byAyODAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBz ZXR0aW5nIDI0NTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90 aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjQ1MCBhZnRl ciAyODAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDI0NTAg bGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjEwMApj cHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVm cmVxOiBkdXAgc2V0IHJlamVjdGluZyAyMTAwIChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNl dCBmcmVlaW5nIG5ldyBsZXZlbCAyMTAwIChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNl dCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDMxMDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBj b25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjcxMgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVs YXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAy NzEyIChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAyNzEy IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogc2tpcHBpbmcgZnJlcSAzMTAwLCBzYW1lIGFzIGN1cnJl bnQgbGV2ZWwgMzEwMApjcHVmcmVxOiBnZXQgcmV0dXJuaW5nIGtub3duIGZyZXEgMzEwMApjcHVm cmVxOiBhZGRpbmcgOCByZWxhdGl2ZSBzZXR0aW5ncwpjcHVmcmVxOiBza2lwcGluZyBpbmZvLW9u bHkgZHJpdmVyIGFjcGlfcGVyZjAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDMxMDAgYXQg aGVhZApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMjgwMCBhZnRlciAzMTAwCmNwdWZyZXE6 IGFkZGluZyBhYnMgc2V0dGluZyAyMzAwIGFmdGVyIDI4MDAKY3B1ZnJlcTogYWRkaW5nIGFicyBz ZXR0aW5nIDE5MDAgYWZ0ZXIgMjMwMApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTQwMCBh ZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAx NDAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEy MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAK Y3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTIyNSBhZnRlciAxNDAwCmNw dWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDEyMjUgbGV2ZWwKY3B1 ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTA1MApjcHVmcmVxOiBy ZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAg ZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxMDUwIGFmdGVyIDEyMjUKY3B1ZnJlcTogZXhwYW5k IHNldCBhZGRlZCByZWwgc2V0dGluZyA3NSUgdG8gMTA1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0 IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA4NzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJl bGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGlu ZyBuZXcgbGV2ZWwgODc1IGFmdGVyIDEwNTAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwg c2V0dGluZyA2MiUgdG8gODc1IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVy aXZlZCBzZXR0aW5nIDcwMApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBh Y3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA3MDAg YWZ0ZXIgODc1CmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNTAlIHRvIDcw MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA1MjUK Y3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1 ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgNTI1IGFmdGVyIDcwMApjcHVmcmVx OiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDM3JSB0byA1MjUgbGV2ZWwKY3B1ZnJlcTog ZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMzUwCmNwdWZyZXE6IHJlbW92ZWQg bGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBp bnNlcnRpbmcgbmV3IGxldmVsIDM1MCBhZnRlciA1MjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRl ZCByZWwgc2V0dGluZyAyNSUgdG8gMzUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJp bmcgZGVyaXZlZCBzZXR0aW5nIDE3NQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJp dmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZl bCAxNzUgYWZ0ZXIgMzUwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTIl IHRvIDE3NSBsZXZlbApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUg dG8gMTkwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyAxNjYyCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0 bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE2NjIgYWZ0ZXIgMTkw MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAxNjYyIGxldmVs CmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE0MjUKY3B1ZnJl cTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTog ZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTQyNSBhZnRlciAxNjYyCmNwdWZyZXE6IGV4 cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNzUlIHRvIDE0MjUgbGV2ZWwKY3B1ZnJlcTogZHVw IHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTE4NwpjcHVmcmVxOiByZW1vdmVkIGxh c3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVj dGluZyAxMTg3IChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZl bCAxMTg3IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGlu ZyAxMDAlIHRvIDIzMDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVk IHNldHRpbmcgMjAxMgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3Bp X3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAyMDEyIGFm dGVyIDIzMDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMjAx MiBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNzI1 CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNw dWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDE3MjUgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAg c2V0IGZyZWVpbmcgbmV3IGxldmVsIDE3MjUgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQg c2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMjgwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0 IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyNDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCBy ZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRp bmcgbmV3IGxldmVsIDI0NTAgYWZ0ZXIgMjgwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJl bCBzZXR0aW5nIDg3JSB0byAyNDUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcg ZGVyaXZlZCBzZXR0aW5nIDIxMDAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZl cjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMjEwMCAoYWJzIHRv byBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMjEwMCAobm90IG9wdGlt YWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAzMTAwIGxl dmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI3MTIKY3B1 ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJl cTogZHVwIHNldCByZWplY3RpbmcgMjcxMiAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQg ZnJlZWluZyBuZXcgbGV2ZWwgMjcxMiAobm90IG9wdGltYWwpCmNwdWZyZXE6IHNldHRpbmcgYWJz IGZyZXEgMjgwMCBvbiBod3BzdGF0ZTAgKGNwdSAwKQpod3BzdGF0ZTA6IExJTUlUOiAwLCBJRDog MQpod3BzdGF0ZTA6IHNldHRpbmcgUDEtc3RhdGUgb24gY3B1MApod3BzdGF0ZTA6IE1TUjogMSBJ RDogMQpod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0 ZSBvbiBjcHUxCmh3cHN0YXRlMDogTVNSOiAxIElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46 IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAxLXN0YXRlIG9uIGNwdTIKaHdwc3RhdGUwOiBNU1I6IDEg SUQ6IDEKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpod3BzdGF0ZTA6IHNldHRpbmcgUDEtc3Rh dGUgb24gY3B1Mwpod3BzdGF0ZTA6IE1TUjogMSBJRDogMQpod3BzdGF0ZTA6IEl0ZXJhdGlvbmVu OiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0ZSBvbiBjcHU0Cmh3cHN0YXRlMDogTVNSOiAx IElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAxLXN0 YXRlIG9uIGNwdTUKaHdwc3RhdGUwOiBNU1I6IDEgSUQ6IDEKaHdwc3RhdGUwOiBJdGVyYXRpb25l bjogMQpod3BzdGF0ZTA6IHNldHRpbmcgUDEtc3RhdGUgb24gY3B1Ngpod3BzdGF0ZTA6IE1TUjog MSBJRDogMQpod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMS1z dGF0ZSBvbiBjcHU3Cmh3cHN0YXRlMDogTVNSOiAxIElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9u ZW46IDEKY3B1ZnJlcTogc2V0dGluZyByZWwgZnJlcSAxMDAwMCBvbiBhY3BpX3Rocm90dGxlMCAo Y3B1IDApCmNwdWZyZXE6IGdldCByZXR1cm5pbmcga25vd24gZnJlcSAyODAwCmNwdWZyZXE6IGFk ZGluZyA4IHJlbGF0aXZlIHNldHRpbmdzCmNwdWZyZXE6IHNraXBwaW5nIGluZm8tb25seSBkcml2 ZXIgYWNwaV9wZXJmMApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMzEwMCBhdCBoZWFkCmNw dWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAyODAwIGFmdGVyIDMxMDAKY3B1ZnJlcTogYWRkaW5n IGFicyBzZXR0aW5nIDIzMDAgYWZ0ZXIgMjgwMApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcg MTkwMCBhZnRlciAyMzAwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAxNDAwIGFmdGVyIDE5 MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDE0MDAgbGV2 ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTIyNQpjcHVm cmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVx OiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxMjI1IGFmdGVyIDE0MDAKY3B1ZnJlcTog ZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMTIyNSBsZXZlbApjcHVmcmVxOiBk dXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxMDUwCmNwdWZyZXE6IHJlbW92ZWQg bGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBp bnNlcnRpbmcgbmV3IGxldmVsIDEwNTAgYWZ0ZXIgMTIyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFk ZGVkIHJlbCBzZXR0aW5nIDc1JSB0byAxMDUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lk ZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDg3NQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUg ZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBs ZXZlbCA4NzUgYWZ0ZXIgMTA1MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5n IDYyJSB0byA4NzUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNl dHRpbmcgNzAwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhy b3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDcwMCBhZnRlciA4 NzUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA1MCUgdG8gNzAwIGxldmVs CmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDUyNQpjcHVmcmVx OiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBk dXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA1MjUgYWZ0ZXIgNzAwCmNwdWZyZXE6IGV4cGFu ZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMzclIHRvIDUyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0 IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAzNTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJl bGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGlu ZyBuZXcgbGV2ZWwgMzUwIGFmdGVyIDUyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBz ZXR0aW5nIDI1JSB0byAzNTAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJp dmVkIHNldHRpbmcgMTc1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFj cGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE3NSBh ZnRlciAzNTAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMiUgdG8gMTc1 IGxldmVsCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxOTAw IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE2NjIK Y3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1 ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTY2MiBhZnRlciAxOTAwCmNwdWZy ZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDE2NjIgbGV2ZWwKY3B1ZnJl cTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTQyNQpjcHVmcmVxOiByZW1v dmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9u ZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNDI1IGFmdGVyIDE2NjIKY3B1ZnJlcTogZXhwYW5kIHNl dCBhZGRlZCByZWwgc2V0dGluZyA3NSUgdG8gMTQyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNv bnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxMTg3CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxh dGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDEx ODcgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDExODcg KG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUg dG8gMjMwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyAyMDEyCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0 bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDIwMTIgYWZ0ZXIgMjMw MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAyMDEyIGxldmVs CmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE3MjUKY3B1ZnJl cTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTog ZHVwIHNldCByZWplY3RpbmcgMTcyNSAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJl ZWluZyBuZXcgbGV2ZWwgMTcyNSAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRk ZWQgcmVsIHNldHRpbmcgMTAwJSB0byAyODAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lk ZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI0NTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZl IGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcg bGV2ZWwgMjQ1MCBhZnRlciAyODAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRp bmcgODclIHRvIDI0NTAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVk IHNldHRpbmcgMjEwMApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3Bp X3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAyMTAwIChhYnMgdG9vIGJpZykK Y3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAyMTAwIChub3Qgb3B0aW1hbCkKY3B1 ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDMxMDAgbGV2ZWwKY3B1 ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjcxMgpjcHVmcmVxOiBy ZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAg c2V0IHJlamVjdGluZyAyNzEyIChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5n IG5ldyBsZXZlbCAyNzEyIChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogc2V0dGluZyBhYnMgZnJlcSAz MTAwIG9uIGh3cHN0YXRlMCAoY3B1IDApCmh3cHN0YXRlMDogTElNSVQ6IDAsIElEOiAwCmh3cHN0 YXRlMDogc2V0dGluZyBQMC1zdGF0ZSBvbiBjcHUwCmh3cHN0YXRlMDogTVNSOiAwIElEOiAwCmh3 cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAwLXN0YXRlIG9uIGNw dTEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDAKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpod3Bz dGF0ZTA6IHNldHRpbmcgUDAtc3RhdGUgb24gY3B1Mgpod3BzdGF0ZTA6IE1TUjogMCBJRDogMApo d3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMC1zdGF0ZSBvbiBj cHUzCmh3cHN0YXRlMDogTVNSOiAwIElEOiAwCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdw c3RhdGUwOiBzZXR0aW5nIFAwLXN0YXRlIG9uIGNwdTQKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDAK aHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpod3BzdGF0ZTA6IHNldHRpbmcgUDAtc3RhdGUgb24g Y3B1NQpod3BzdGF0ZTA6IE1TUjogMCBJRDogMApod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3 cHN0YXRlMDogc2V0dGluZyBQMC1zdGF0ZSBvbiBjcHU2Cmh3cHN0YXRlMDogTVNSOiAwIElEOiAw Cmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAwLXN0YXRlIG9u IGNwdTcKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDAKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpj cHVmcmVxOiBzZXR0aW5nIHJlbCBmcmVxIDEwMDAwIG9uIGFjcGlfdGhyb3R0bGUwIChjcHUgMCkK Y3B1ZnJlcTogYWRkaW5nIDggcmVsYXRpdmUgc2V0dGluZ3MKY3B1ZnJlcTogc2tpcHBpbmcgaW5m by1vbmx5IGRyaXZlciBhY3BpX3BlcmYwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAzMTAw IGF0IGhlYWQKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDI4MDAgYWZ0ZXIgMzEwMApjcHVm cmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMjMwMCBhZnRlciAyODAwCmNwdWZyZXE6IGFkZGluZyBh YnMgc2V0dGluZyAxOTAwIGFmdGVyIDIzMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE0 MDAgYWZ0ZXIgMTkwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUg dG8gMTQwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyAxMjI1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0 bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDEyMjUgYWZ0ZXIgMTQw MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAxMjI1IGxldmVs CmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEwNTAKY3B1ZnJl cTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTog ZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTA1MCBhZnRlciAxMjI1CmNwdWZyZXE6IGV4 cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNzUlIHRvIDEwNTAgbGV2ZWwKY3B1ZnJlcTogZHVw IHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgODc1CmNwdWZyZXE6IHJlbW92ZWQgbGFz dCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNl cnRpbmcgbmV3IGxldmVsIDg3NSBhZnRlciAxMDUwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQg cmVsIHNldHRpbmcgNjIlIHRvIDg3NSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5n IGRlcml2ZWQgc2V0dGluZyA3MDAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZl cjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwg NzAwIGFmdGVyIDg3NQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDUwJSB0 byA3MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcg NTI1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUw CmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDUyNSBhZnRlciA3MDAKY3B1 ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAzNyUgdG8gNTI1IGxldmVsCmNwdWZy ZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDM1MApjcHVmcmVxOiByZW1v dmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9u ZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAzNTAgYWZ0ZXIgNTI1CmNwdWZyZXE6IGV4cGFuZCBzZXQg YWRkZWQgcmVsIHNldHRpbmcgMjUlIHRvIDM1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNp ZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZl IGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcg bGV2ZWwgMTc1IGFmdGVyIDM1MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5n IDEyJSB0byAxNzUgbGV2ZWwKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAx MDAlIHRvIDE5MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNl dHRpbmcgMTY2MgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Ro cm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNjYyIGFmdGVy IDE5MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMTY2MiBs ZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNDI1CmNw dWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZy ZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE0MjUgYWZ0ZXIgMTY2MgpjcHVmcmVx OiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDc1JSB0byAxNDI1IGxldmVsCmNwdWZyZXE6 IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDExODcKY3B1ZnJlcTogcmVtb3Zl ZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCBy ZWplY3RpbmcgMTE4NyAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcg bGV2ZWwgMTE4NyAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNl dHRpbmcgMTAwJSB0byAyMzAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVy aXZlZCBzZXR0aW5nIDIwMTIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjog YWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjAx MiBhZnRlciAyMzAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRv IDIwMTIgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcg MTcyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxl MApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAxNzI1IChhYnMgdG9vIGJpZykKY3B1ZnJlcTog ZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAxNzI1IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhw YW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDI4MDAgbGV2ZWwKY3B1ZnJlcTogZHVw IHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjQ1MApjcHVmcmVxOiByZW1vdmVkIGxh c3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5z ZXJ0aW5nIG5ldyBsZXZlbCAyNDUwIGFmdGVyIDI4MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRl ZCByZWwgc2V0dGluZyA4NyUgdG8gMjQ1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVy aW5nIGRlcml2ZWQgc2V0dGluZyAyMTAwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBk cml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDIxMDAgKGFi cyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDIxMDAgKG5vdCBv cHRpbWFsKQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMzEw MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyNzEy CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNw dWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDI3MTIgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAg c2V0IGZyZWVpbmcgbmV3IGxldmVsIDI3MTIgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBhZGRpbmcg OCByZWxhdGl2ZSBzZXR0aW5ncwpjcHVmcmVxOiBza2lwcGluZyBpbmZvLW9ubHkgZHJpdmVyIGFj cGlfcGVyZjAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDMxMDAgYXQgaGVhZApjcHVmcmVx OiBhZGRpbmcgYWJzIHNldHRpbmcgMjgwMCBhZnRlciAzMTAwCmNwdWZyZXE6IGFkZGluZyBhYnMg c2V0dGluZyAyMzAwIGFmdGVyIDI4MDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE5MDAg YWZ0ZXIgMjMwMApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTQwMCBhZnRlciAxOTAwCmNw dWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxNDAwIGxldmVsCmNw dWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEyMjUKY3B1ZnJlcTog cmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVw IGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTIyNSBhZnRlciAxNDAwCmNwdWZyZXE6IGV4cGFu ZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDEyMjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNl dCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTA1MApjcHVmcmVxOiByZW1vdmVkIGxhc3Qg cmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0 aW5nIG5ldyBsZXZlbCAxMDUwIGFmdGVyIDEyMjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCBy ZWwgc2V0dGluZyA3NSUgdG8gMTA1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5n IGRlcml2ZWQgc2V0dGluZyA4NzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZl cjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwg ODc1IGFmdGVyIDEwNTAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA2MiUg dG8gODc1IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5n IDcwMApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxl MApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA3MDAgYWZ0ZXIgODc1CmNw dWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNTAlIHRvIDcwMCBsZXZlbApjcHVm cmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA1MjUKY3B1ZnJlcTogcmVt b3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRv bmUsIGluc2VydGluZyBuZXcgbGV2ZWwgNTI1IGFmdGVyIDcwMApjcHVmcmVxOiBleHBhbmQgc2V0 IGFkZGVkIHJlbCBzZXR0aW5nIDM3JSB0byA1MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25z aWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMzUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2 ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3 IGxldmVsIDM1MCBhZnRlciA1MjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGlu ZyAyNSUgdG8gMzUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBz ZXR0aW5nIDE3NQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Ro cm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNzUgYWZ0ZXIg MzUwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTIlIHRvIDE3NSBsZXZl bApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMTkwMCBsZXZl bApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNjYyCmNwdWZy ZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6 IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE2NjIgYWZ0ZXIgMTkwMApjcHVmcmVxOiBl eHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAxNjYyIGxldmVsCmNwdWZyZXE6IGR1 cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE0MjUKY3B1ZnJlcTogcmVtb3ZlZCBs YXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGlu c2VydGluZyBuZXcgbGV2ZWwgMTQyNSBhZnRlciAxNjYyCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRk ZWQgcmVsIHNldHRpbmcgNzUlIHRvIDE0MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRl cmluZyBkZXJpdmVkIHNldHRpbmcgMTE4NwpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUg ZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAxMTg3IChh YnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAxMTg3IChub3Qg b3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDIz MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjAx MgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApj cHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAyMDEyIGFmdGVyIDIzMDAKY3B1 ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMjAxMiBsZXZlbApjcHVm cmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNzI1CmNwdWZyZXE6IHJl bW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBz ZXQgcmVqZWN0aW5nIDE3MjUgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcg bmV3IGxldmVsIDE3MjUgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJl bCBzZXR0aW5nIDEwMCUgdG8gMjgwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5n IGRlcml2ZWQgc2V0dGluZyAyNDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2 ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVs IDI0NTAgYWZ0ZXIgMjgwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3 JSB0byAyNDUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0 aW5nIDIxMDAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJv dHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMjEwMCAoYWJzIHRvbyBiaWcpCmNwdWZy ZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMjEwMCAobm90IG9wdGltYWwpCmNwdWZyZXE6 IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAzMTAwIGxldmVsCmNwdWZyZXE6 IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI3MTIKY3B1ZnJlcTogcmVtb3Zl ZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCBy ZWplY3RpbmcgMjcxMiAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcg bGV2ZWwgMjcxMiAobm90IG9wdGltYWwpCmNwdWZyZXE6IGdldCByZXR1cm5pbmcga25vd24gZnJl cSAzMTAwCmNwdWZyZXE6IGdldCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGdl dCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGFkZGluZyA4IHJlbGF0aXZlIHNl dHRpbmdzCmNwdWZyZXE6IHNraXBwaW5nIGluZm8tb25seSBkcml2ZXIgYWNwaV9wZXJmMApjcHVm cmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMzEwMCBhdCBoZWFkCmNwdWZyZXE6IGFkZGluZyBhYnMg c2V0dGluZyAyODAwIGFmdGVyIDMxMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDIzMDAg YWZ0ZXIgMjgwMApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTkwMCBhZnRlciAyMzAwCmNw dWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAxNDAwIGFmdGVyIDE5MDAKY3B1ZnJlcTogZXhwYW5k IHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDE0MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNl dCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTIyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3Qg cmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0 aW5nIG5ldyBsZXZlbCAxMjI1IGFmdGVyIDE0MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCBy ZWwgc2V0dGluZyA4NyUgdG8gMTIyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5n IGRlcml2ZWQgc2V0dGluZyAxMDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2 ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVs IDEwNTAgYWZ0ZXIgMTIyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDc1 JSB0byAxMDUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0 aW5nIDg3NQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90 dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA4NzUgYWZ0ZXIgMTA1 MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDYyJSB0byA4NzUgbGV2ZWwK Y3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgNzAwCmNwdWZyZXE6 IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1 cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDcwMCBhZnRlciA4NzUKY3B1ZnJlcTogZXhwYW5k IHNldCBhZGRlZCByZWwgc2V0dGluZyA1MCUgdG8gNzAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQg Y29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDUyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVs YXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5n IG5ldyBsZXZlbCA1MjUgYWZ0ZXIgNzAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNl dHRpbmcgMzclIHRvIDUyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2 ZWQgc2V0dGluZyAzNTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNw aV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMzUwIGFm dGVyIDUyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDI1JSB0byAzNTAg bGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTc1CmNw dWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZy ZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE3NSBhZnRlciAzNTAKY3B1ZnJlcTog ZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMiUgdG8gMTc1IGxldmVsCmNwdWZyZXE6IGV4 cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxOTAwIGxldmVsCmNwdWZyZXE6IGR1 cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE2NjIKY3B1ZnJlcTogcmVtb3ZlZCBs YXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGlu c2VydGluZyBuZXcgbGV2ZWwgMTY2MiBhZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRk ZWQgcmVsIHNldHRpbmcgODclIHRvIDE2NjIgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRl cmluZyBkZXJpdmVkIHNldHRpbmcgMTQyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUg ZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBs ZXZlbCAxNDI1IGFmdGVyIDE2NjIKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGlu ZyA3NSUgdG8gMTQyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQg c2V0dGluZyAxMTg3CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlf dGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDExODcgKGFicyB0b28gYmlnKQpj cHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDExODcgKG5vdCBvcHRpbWFsKQpjcHVm cmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMjMwMCBsZXZlbApjcHVm cmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyMDEyCmNwdWZyZXE6IHJl bW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBk b25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDIwMTIgYWZ0ZXIgMjMwMApjcHVmcmVxOiBleHBhbmQg c2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAyMDEyIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQg Y29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE3MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJl bGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3Rpbmcg MTcyNSAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMTcy NSAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAw JSB0byAyODAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0 aW5nIDI0NTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJv dHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjQ1MCBhZnRlciAy ODAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDI0NTAgbGV2 ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjEwMApjcHVm cmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVx OiBkdXAgc2V0IHJlamVjdGluZyAyMTAwIChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBm cmVlaW5nIG5ldyBsZXZlbCAyMTAwIChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBh ZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDMxMDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25z aWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjcxMgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRp dmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAyNzEy IChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAyNzEyIChu b3Qgb3B0aW1hbCkKY3B1ZnJlcTogc2tpcHBpbmcgZnJlcSAzMTAwLCBzYW1lIGFzIGN1cnJlbnQg bGV2ZWwgMzEwMApjcHVmcmVxOiBnZXQgcmV0dXJuaW5nIGtub3duIGZyZXEgMzEwMApjcHVmcmVx OiBnZXQgcmV0dXJuaW5nIGtub3duIGZyZXEgMzEwMApjcHVmcmVxOiBhZGRpbmcgOCByZWxhdGl2 ZSBzZXR0aW5ncwpjcHVmcmVxOiBza2lwcGluZyBpbmZvLW9ubHkgZHJpdmVyIGFjcGlfcGVyZjAK Y3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDMxMDAgYXQgaGVhZApjcHVmcmVxOiBhZGRpbmcg YWJzIHNldHRpbmcgMjgwMCBhZnRlciAzMTAwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAy MzAwIGFmdGVyIDI4MDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE5MDAgYWZ0ZXIgMjMw MApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTQwMCBhZnRlciAxOTAwCmNwdWZyZXE6IGV4 cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxNDAwIGxldmVsCmNwdWZyZXE6IGR1 cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEyMjUKY3B1ZnJlcTogcmVtb3ZlZCBs YXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGlu c2VydGluZyBuZXcgbGV2ZWwgMTIyNSBhZnRlciAxNDAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRk ZWQgcmVsIHNldHRpbmcgODclIHRvIDEyMjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRl cmluZyBkZXJpdmVkIHNldHRpbmcgMTA1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUg ZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBs ZXZlbCAxMDUwIGFmdGVyIDEyMjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGlu ZyA3NSUgdG8gMTA1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQg c2V0dGluZyA4NzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90 aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgODc1IGFmdGVy IDEwNTAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA2MiUgdG8gODc1IGxl dmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDcwMApjcHVm cmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVx OiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA3MDAgYWZ0ZXIgODc1CmNwdWZyZXE6IGV4 cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNTAlIHRvIDcwMCBsZXZlbApjcHVmcmVxOiBkdXAg c2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA1MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0 IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2Vy dGluZyBuZXcgbGV2ZWwgNTI1IGFmdGVyIDcwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJl bCBzZXR0aW5nIDM3JSB0byA1MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBk ZXJpdmVkIHNldHRpbmcgMzUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6 IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDM1 MCBhZnRlciA1MjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAyNSUgdG8g MzUwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE3 NQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApj cHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNzUgYWZ0ZXIgMzUwCmNwdWZy ZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTIlIHRvIDE3NSBsZXZlbApjcHVmcmVx OiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMTkwMCBsZXZlbApjcHVmcmVx OiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNjYyCmNwdWZyZXE6IHJlbW92 ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25l LCBpbnNlcnRpbmcgbmV3IGxldmVsIDE2NjIgYWZ0ZXIgMTkwMApjcHVmcmVxOiBleHBhbmQgc2V0 IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAxNjYyIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29u c2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE0MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0 aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBu ZXcgbGV2ZWwgMTQyNSBhZnRlciAxNjYyCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNl dHRpbmcgNzUlIHRvIDE0MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJp dmVkIHNldHRpbmcgMTE4NwpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBh Y3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAxMTg3IChhYnMgdG9vIGJp ZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAxMTg3IChub3Qgb3B0aW1hbCkK Y3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDIzMDAgbGV2ZWwK Y3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjAxMgpjcHVmcmVx OiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBk dXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAyMDEyIGFmdGVyIDIzMDAKY3B1ZnJlcTogZXhw YW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMjAxMiBsZXZlbApjcHVmcmVxOiBkdXAg c2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNzI1CmNwdWZyZXE6IHJlbW92ZWQgbGFz dCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0 aW5nIDE3MjUgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVs IDE3MjUgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5n IDEwMCUgdG8gMjgwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQg c2V0dGluZyAyNDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlf dGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDI0NTAgYWZ0 ZXIgMjgwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAyNDUw IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDIxMDAK Y3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1 ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMjEwMCAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBz ZXQgZnJlZWluZyBuZXcgbGV2ZWwgMjEwMCAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBz ZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAzMTAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQg Y29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI3MTIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJl bGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3Rpbmcg MjcxMiAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMjcx MiAobm90IG9wdGltYWwpCmNwdWZyZXE6IGFkZGluZyA4IHJlbGF0aXZlIHNldHRpbmdzCmNwdWZy ZXE6IHNraXBwaW5nIGluZm8tb25seSBkcml2ZXIgYWNwaV9wZXJmMApjcHVmcmVxOiBhZGRpbmcg YWJzIHNldHRpbmcgMzEwMCBhdCBoZWFkCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAyODAw IGFmdGVyIDMxMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDIzMDAgYWZ0ZXIgMjgwMApj cHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTkwMCBhZnRlciAyMzAwCmNwdWZyZXE6IGFkZGlu ZyBhYnMgc2V0dGluZyAxNDAwIGFmdGVyIDE5MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCBy ZWwgc2V0dGluZyAxMDAlIHRvIDE0MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmlu ZyBkZXJpdmVkIHNldHRpbmcgMTIyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJp dmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZl bCAxMjI1IGFmdGVyIDE0MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4 NyUgdG8gMTIyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0 dGluZyAxMDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhy b3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDEwNTAgYWZ0ZXIg MTIyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDc1JSB0byAxMDUwIGxl dmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDg3NQpjcHVm cmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVx OiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA4NzUgYWZ0ZXIgMTA1MApjcHVmcmVxOiBl eHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDYyJSB0byA4NzUgbGV2ZWwKY3B1ZnJlcTogZHVw IHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgNzAwCmNwdWZyZXE6IHJlbW92ZWQgbGFz dCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNl cnRpbmcgbmV3IGxldmVsIDcwMCBhZnRlciA4NzUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCBy ZWwgc2V0dGluZyA1MCUgdG8gNzAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcg ZGVyaXZlZCBzZXR0aW5nIDUyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVy OiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA1 MjUgYWZ0ZXIgNzAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMzclIHRv IDUyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAz NTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAK Y3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMzUwIGFmdGVyIDUyNQpjcHVm cmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDI1JSB0byAzNTAgbGV2ZWwKY3B1ZnJl cTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTc1CmNwdWZyZXE6IHJlbW92 ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25l LCBpbnNlcnRpbmcgbmV3IGxldmVsIDE3NSBhZnRlciAzNTAKY3B1ZnJlcTogZXhwYW5kIHNldCBh ZGRlZCByZWwgc2V0dGluZyAxMiUgdG8gMTc1IGxldmVsCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRk ZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxOTAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lk ZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE2NjIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZl IGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcg bGV2ZWwgMTY2MiBhZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRp bmcgODclIHRvIDE2NjIgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVk IHNldHRpbmcgMTQyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3Bp X3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNDI1IGFm dGVyIDE2NjIKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA3NSUgdG8gMTQy NSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxMTg3 CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNw dWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDExODcgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAg c2V0IGZyZWVpbmcgbmV3IGxldmVsIDExODcgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQg c2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMjMwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0 IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyMDEyCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCBy ZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRp bmcgbmV3IGxldmVsIDIwMTIgYWZ0ZXIgMjMwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJl bCBzZXR0aW5nIDg3JSB0byAyMDEyIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcg ZGVyaXZlZCBzZXR0aW5nIDE3MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZl cjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMTcyNSAoYWJzIHRv byBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMTcyNSAobm90IG9wdGlt YWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAyODAwIGxl dmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI0NTAKY3B1 ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJl cTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjQ1MCBhZnRlciAyODAwCmNwdWZyZXE6 IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDI0NTAgbGV2ZWwKY3B1ZnJlcTog ZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjEwMApjcHVmcmVxOiByZW1vdmVk IGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJl amVjdGluZyAyMTAwIChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBs ZXZlbCAyMTAwIChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0 dGluZyAxMDAlIHRvIDMxMDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJp dmVkIHNldHRpbmcgMjcxMgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBh Y3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAyNzEyIChhYnMgdG9vIGJp ZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAyNzEyIChub3Qgb3B0aW1hbCkK Y3B1ZnJlcTogZ2V0IHJldHVybmluZyBrbm93biBmcmVxIDMxMDAKY3B1ZnJlcTogZ2V0IHJldHVy bmluZyBrbm93biBmcmVxIDMxMDAKY3B1ZnJlcTogZ2V0IHJldHVybmluZyBrbm93biBmcmVxIDMx MDAKY3B1ZnJlcTogZ2V0IHJldHVybmluZyBrbm93biBmcmVxIDMxMDAKY3B1ZnJlcTogYWRkaW5n IDggcmVsYXRpdmUgc2V0dGluZ3MKY3B1ZnJlcTogc2tpcHBpbmcgaW5mby1vbmx5IGRyaXZlciBh Y3BpX3BlcmYwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAzMTAwIGF0IGhlYWQKY3B1ZnJl cTogYWRkaW5nIGFicyBzZXR0aW5nIDI4MDAgYWZ0ZXIgMzEwMApjcHVmcmVxOiBhZGRpbmcgYWJz IHNldHRpbmcgMjMwMCBhZnRlciAyODAwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAxOTAw IGFmdGVyIDIzMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE0MDAgYWZ0ZXIgMTkwMApj cHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMTQwMCBsZXZlbApj cHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxMjI1CmNwdWZyZXE6 IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1 cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDEyMjUgYWZ0ZXIgMTQwMApjcHVmcmVxOiBleHBh bmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAxMjI1IGxldmVsCmNwdWZyZXE6IGR1cCBz ZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEwNTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0 IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2Vy dGluZyBuZXcgbGV2ZWwgMTA1MCBhZnRlciAxMjI1CmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQg cmVsIHNldHRpbmcgNzUlIHRvIDEwNTAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmlu ZyBkZXJpdmVkIHNldHRpbmcgODc1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2 ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVs IDg3NSBhZnRlciAxMDUwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgNjIl IHRvIDg3NSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyA3MDAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRs ZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgNzAwIGFmdGVyIDg3NQpj cHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDUwJSB0byA3MDAgbGV2ZWwKY3B1 ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgNTI1CmNwdWZyZXE6IHJl bW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBk b25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDUyNSBhZnRlciA3MDAKY3B1ZnJlcTogZXhwYW5kIHNl dCBhZGRlZCByZWwgc2V0dGluZyAzNyUgdG8gNTI1IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29u c2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDM1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRp dmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5l dyBsZXZlbCAzNTAgYWZ0ZXIgNTI1CmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRp bmcgMjUlIHRvIDM1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQg c2V0dGluZyAxNzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90 aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTc1IGFmdGVy IDM1MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEyJSB0byAxNzUgbGV2 ZWwKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDE5MDAgbGV2 ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTY2MgpjcHVm cmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVx OiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNjYyIGFmdGVyIDE5MDAKY3B1ZnJlcTog ZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMTY2MiBsZXZlbApjcHVmcmVxOiBk dXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNDI1CmNwdWZyZXE6IHJlbW92ZWQg bGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBp bnNlcnRpbmcgbmV3IGxldmVsIDE0MjUgYWZ0ZXIgMTY2MgpjcHVmcmVxOiBleHBhbmQgc2V0IGFk ZGVkIHJlbCBzZXR0aW5nIDc1JSB0byAxNDI1IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lk ZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDExODcKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZl IGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMTE4NyAo YWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMTE4NyAobm90 IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAy MzAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDIw MTIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAK Y3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjAxMiBhZnRlciAyMzAwCmNw dWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDIwMTIgbGV2ZWwKY3B1 ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTcyNQpjcHVmcmVxOiBy ZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAg c2V0IHJlamVjdGluZyAxNzI1IChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5n IG5ldyBsZXZlbCAxNzI1IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCBy ZWwgc2V0dGluZyAxMDAlIHRvIDI4MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmlu ZyBkZXJpdmVkIHNldHRpbmcgMjQ1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJp dmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZl bCAyNDUwIGFmdGVyIDI4MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4 NyUgdG8gMjQ1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0 dGluZyAyMTAwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhy b3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDIxMDAgKGFicyB0b28gYmlnKQpjcHVm cmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDIxMDAgKG5vdCBvcHRpbWFsKQpjcHVmcmVx OiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMzEwMCBsZXZlbApjcHVmcmVx OiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyNzEyCmNwdWZyZXE6IHJlbW92 ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQg cmVqZWN0aW5nIDI3MTIgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3 IGxldmVsIDI3MTIgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBzZXR0aW5nIGFicyBmcmVxIDI4MDAg b24gaHdwc3RhdGUwIChjcHUgMCkKaHdwc3RhdGUwOiBMSU1JVDogMCwgSUQ6IDEKaHdwc3RhdGUw OiBzZXR0aW5nIFAxLXN0YXRlIG9uIGNwdTAKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBTZXR0aW5nIGZhaWxlZCEKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMTAyCmh3 cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0ZSBvbiBjcHUxCmh3cHN0YXRlMDogTVNSOiAxIElEOiAx Cmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAxLXN0YXRlIG9u IGNwdTIKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBTZXR0aW5nIGZh aWxlZCEKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMTAyCmh3cHN0YXRlMDogc2V0dGluZyBQMS1z dGF0ZSBvbiBjcHUzCmh3cHN0YXRlMDogTVNSOiAxIElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9u ZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAxLXN0YXRlIG9uIGNwdTQKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBTZXR0aW5nIGZhaWxlZCEKaHdwc3RhdGUwOiBJdGVy YXRpb25lbjogMTAyCmh3cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0ZSBvbiBjcHU1Cmh3cHN0YXRl MDogTVNSOiAxIElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0 aW5nIFAxLXN0YXRlIG9uIGNwdTYKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6 IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEK aHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUw OiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdw c3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBN U1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDEKaHdwc3Rh dGUwOiBTZXR0aW5nIGZhaWxlZCEKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMTAyCmh3cHN0YXRl MDogc2V0dGluZyBQMS1zdGF0ZSBvbiBjcHU3Cmh3cHN0YXRlMDogTVNSOiAxIElEOiAxCmh3cHN0 YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXQgZnJlcSBmYWlsZWQsIGVyciA2CmNw dWZyZXE6IGdldCByZXR1cm5pbmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGdldCByZXR1cm5p bmcga25vd24gZnJlcSAzMTAwCmNwdWZyZXE6IGFkZGluZyA4IHJlbGF0aXZlIHNldHRpbmdzCmNw dWZyZXE6IHNraXBwaW5nIGluZm8tb25seSBkcml2ZXIgYWNwaV9wZXJmMApjcHVmcmVxOiBhZGRp bmcgYWJzIHNldHRpbmcgMzEwMCBhdCBoZWFkCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAy ODAwIGFmdGVyIDMxMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDIzMDAgYWZ0ZXIgMjgw MApjcHVmcmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTkwMCBhZnRlciAyMzAwCmNwdWZyZXE6IGFk ZGluZyBhYnMgc2V0dGluZyAxNDAwIGFmdGVyIDE5MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRl ZCByZWwgc2V0dGluZyAxMDAlIHRvIDE0MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRl cmluZyBkZXJpdmVkIHNldHRpbmcgMTIyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUg ZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBs ZXZlbCAxMjI1IGFmdGVyIDE0MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGlu ZyA4NyUgdG8gMTIyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQg c2V0dGluZyAxMDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlf dGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDEwNTAgYWZ0 ZXIgMTIyNQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDc1JSB0byAxMDUw IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDg3NQpj cHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVm cmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA4NzUgYWZ0ZXIgMTA1MApjcHVmcmVx OiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDYyJSB0byA4NzUgbGV2ZWwKY3B1ZnJlcTog ZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgNzAwCmNwdWZyZXE6IHJlbW92ZWQg bGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBp bnNlcnRpbmcgbmV3IGxldmVsIDcwMCBhZnRlciA4NzUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRl ZCByZWwgc2V0dGluZyA1MCUgdG8gNzAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJp bmcgZGVyaXZlZCBzZXR0aW5nIDUyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJp dmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZl bCA1MjUgYWZ0ZXIgNzAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMzcl IHRvIDUyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyAzNTAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRs ZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMzUwIGFmdGVyIDUyNQpj cHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDI1JSB0byAzNTAgbGV2ZWwKY3B1 ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTc1CmNwdWZyZXE6IHJl bW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBk b25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE3NSBhZnRlciAzNTAKY3B1ZnJlcTogZXhwYW5kIHNl dCBhZGRlZCByZWwgc2V0dGluZyAxMiUgdG8gMTc1IGxldmVsCmNwdWZyZXE6IGV4cGFuZCBzZXQg YWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxOTAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29u c2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE2NjIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0 aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBu ZXcgbGV2ZWwgMTY2MiBhZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNl dHRpbmcgODclIHRvIDE2NjIgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJp dmVkIHNldHRpbmcgMTQyNQpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBh Y3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNDI1 IGFmdGVyIDE2NjIKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA3NSUgdG8g MTQyNSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAx MTg3CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUw CmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDExODcgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBk dXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDExODcgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBh bmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMjMwMCBsZXZlbApjcHVmcmVxOiBkdXAg c2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyMDEyCmNwdWZyZXE6IHJlbW92ZWQgbGFz dCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNl cnRpbmcgbmV3IGxldmVsIDIwMTIgYWZ0ZXIgMjMwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVk IHJlbCBzZXR0aW5nIDg3JSB0byAyMDEyIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJp bmcgZGVyaXZlZCBzZXR0aW5nIDE3MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRy aXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMTcyNSAoYWJz IHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMTcyNSAobm90IG9w dGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAyODAw IGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI0NTAK Y3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1 ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjQ1MCBhZnRlciAyODAwCmNwdWZy ZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDI0NTAgbGV2ZWwKY3B1ZnJl cTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjEwMApjcHVmcmVxOiByZW1v dmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0 IHJlamVjdGluZyAyMTAwIChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5l dyBsZXZlbCAyMTAwIChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwg c2V0dGluZyAxMDAlIHRvIDMxMDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBk ZXJpdmVkIHNldHRpbmcgMjcxMgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVy OiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAyNzEyIChhYnMgdG9v IGJpZykKY3B1ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAyNzEyIChub3Qgb3B0aW1h bCkKY3B1ZnJlcTogc2V0dGluZyBhYnMgZnJlcSAyODAwIG9uIGh3cHN0YXRlMCAoY3B1IDApCmh3 cHN0YXRlMDogTElNSVQ6IDAsIElEOiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0ZSBvbiBj cHUwCmh3cHN0YXRlMDogTVNSOiAxIElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdw c3RhdGUwOiBzZXR0aW5nIFAxLXN0YXRlIG9uIGNwdTEKaHdwc3RhdGUwOiBNU1I6IDEgSUQ6IDEK aHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpod3BzdGF0ZTA6IHNldHRpbmcgUDEtc3RhdGUgb24g Y3B1Mgpod3BzdGF0ZTA6IE1TUjogMSBJRDogMQpod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3 cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0ZSBvbiBjcHUzCmh3cHN0YXRlMDogTVNSOiAxIElEOiAx Cmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAxLXN0YXRlIG9u IGNwdTQKaHdwc3RhdGUwOiBNU1I6IDEgSUQ6IDEKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpo d3BzdGF0ZTA6IHNldHRpbmcgUDEtc3RhdGUgb24gY3B1NQpod3BzdGF0ZTA6IE1TUjogMSBJRDog MQpod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMS1zdGF0ZSBv biBjcHU2Cmh3cHN0YXRlMDogTVNSOiAxIElEOiAxCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEK aHdwc3RhdGUwOiBzZXR0aW5nIFAxLXN0YXRlIG9uIGNwdTcKaHdwc3RhdGUwOiBNU1I6IDEgSUQ6 IDEKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpjcHVmcmVxOiBzZXR0aW5nIHJlbCBmcmVxIDEw MDAwIG9uIGFjcGlfdGhyb3R0bGUwIChjcHUgMCkKY3B1ZnJlcTogZ2V0IHJldHVybmluZyBrbm93 biBmcmVxIDI4MDAKY3B1ZnJlcTogZ2V0IHJldHVybmluZyBrbm93biBmcmVxIDI4MDAKY3B1ZnJl cTogYWRkaW5nIDggcmVsYXRpdmUgc2V0dGluZ3MKY3B1ZnJlcTogc2tpcHBpbmcgaW5mby1vbmx5 IGRyaXZlciBhY3BpX3BlcmYwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAzMTAwIGF0IGhl YWQKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDI4MDAgYWZ0ZXIgMzEwMApjcHVmcmVxOiBh ZGRpbmcgYWJzIHNldHRpbmcgMjMwMCBhZnRlciAyODAwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0 dGluZyAxOTAwIGFmdGVyIDIzMDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE0MDAgYWZ0 ZXIgMTkwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMTQw MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxMjI1 CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNw dWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDEyMjUgYWZ0ZXIgMTQwMApjcHVm cmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAxMjI1IGxldmVsCmNwdWZy ZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEwNTAKY3B1ZnJlcTogcmVt b3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRv bmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMTA1MCBhZnRlciAxMjI1CmNwdWZyZXE6IGV4cGFuZCBz ZXQgYWRkZWQgcmVsIHNldHRpbmcgNzUlIHRvIDEwNTAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBj b25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgODc1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxh dGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcg bmV3IGxldmVsIDg3NSBhZnRlciAxMDUwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNl dHRpbmcgNjIlIHRvIDg3NSBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2 ZWQgc2V0dGluZyA3MDAKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNw aV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgNzAwIGFm dGVyIDg3NQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDUwJSB0byA3MDAg bGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgNTI1CmNw dWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZy ZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDUyNSBhZnRlciA3MDAKY3B1ZnJlcTog ZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAzNyUgdG8gNTI1IGxldmVsCmNwdWZyZXE6IGR1 cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDM1MApjcHVmcmVxOiByZW1vdmVkIGxh c3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5z ZXJ0aW5nIG5ldyBsZXZlbCAzNTAgYWZ0ZXIgNTI1CmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQg cmVsIHNldHRpbmcgMjUlIHRvIDM1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5n IGRlcml2ZWQgc2V0dGluZyAxNzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZl cjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwg MTc1IGFmdGVyIDM1MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEyJSB0 byAxNzUgbGV2ZWwKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRv IDE5MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcg MTY2MgpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxl MApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNjYyIGFmdGVyIDE5MDAK Y3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMTY2MiBsZXZlbApj cHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNDI1CmNwdWZyZXE6 IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1 cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDE0MjUgYWZ0ZXIgMTY2MgpjcHVmcmVxOiBleHBh bmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDc1JSB0byAxNDI1IGxldmVsCmNwdWZyZXE6IGR1cCBz ZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDExODcKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0 IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3Rp bmcgMTE4NyAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwg MTE4NyAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcg MTAwJSB0byAyMzAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBz ZXR0aW5nIDIwMTIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90 aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgMjAxMiBhZnRl ciAyMzAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgODclIHRvIDIwMTIg bGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMTcyNQpj cHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVm cmVxOiBkdXAgc2V0IHJlamVjdGluZyAxNzI1IChhYnMgdG9vIGJpZykKY3B1ZnJlcTogZHVwIHNl dCBmcmVlaW5nIG5ldyBsZXZlbCAxNzI1IChub3Qgb3B0aW1hbCkKY3B1ZnJlcTogZXhwYW5kIHNl dCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDI4MDAgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBj b25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjQ1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVs YXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5n IG5ldyBsZXZlbCAyNDUwIGFmdGVyIDI4MDAKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwg c2V0dGluZyA4NyUgdG8gMjQ1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRl cml2ZWQgc2V0dGluZyAyMTAwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6 IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDIxMDAgKGFicyB0b28g YmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDIxMDAgKG5vdCBvcHRpbWFs KQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMzEwMCBsZXZl bApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAyNzEyCmNwdWZy ZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6 IGR1cCBzZXQgcmVqZWN0aW5nIDI3MTIgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZy ZWVpbmcgbmV3IGxldmVsIDI3MTIgKG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBzZXR0aW5nIGFicyBm cmVxIDMxMDAgb24gaHdwc3RhdGUwIChjcHUgMCkKaHdwc3RhdGUwOiBMSU1JVDogMCwgSUQ6IDAK aHdwc3RhdGUwOiBzZXR0aW5nIFAwLXN0YXRlIG9uIGNwdTAKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6 IDAKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpod3BzdGF0ZTA6IHNldHRpbmcgUDAtc3RhdGUg b24gY3B1MQpod3BzdGF0ZTA6IE1TUjogMCBJRDogMApod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAx Cmh3cHN0YXRlMDogc2V0dGluZyBQMC1zdGF0ZSBvbiBjcHUyCmh3cHN0YXRlMDogTVNSOiAwIElE OiAwCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAwLXN0YXRl IG9uIGNwdTMKaHdwc3RhdGUwOiBNU1I6IDAgSUQ6IDAKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjog MQpod3BzdGF0ZTA6IHNldHRpbmcgUDAtc3RhdGUgb24gY3B1NApod3BzdGF0ZTA6IE1TUjogMCBJ RDogMApod3BzdGF0ZTA6IEl0ZXJhdGlvbmVuOiAxCmh3cHN0YXRlMDogc2V0dGluZyBQMC1zdGF0 ZSBvbiBjcHU1Cmh3cHN0YXRlMDogTVNSOiAwIElEOiAwCmh3cHN0YXRlMDogSXRlcmF0aW9uZW46 IDEKaHdwc3RhdGUwOiBzZXR0aW5nIFAwLXN0YXRlIG9uIGNwdTYKaHdwc3RhdGUwOiBNU1I6IDAg SUQ6IDAKaHdwc3RhdGUwOiBJdGVyYXRpb25lbjogMQpod3BzdGF0ZTA6IHNldHRpbmcgUDAtc3Rh dGUgb24gY3B1Nwpod3BzdGF0ZTA6IE1TUjogMCBJRDogMApod3BzdGF0ZTA6IEl0ZXJhdGlvbmVu OiAxCmNwdWZyZXE6IHNldHRpbmcgcmVsIGZyZXEgMTAwMDAgb24gYWNwaV90aHJvdHRsZTAgKGNw dSAwKQpjcHVmcmVxOiBnZXQgcmV0dXJuaW5nIGtub3duIGZyZXEgMzEwMApjcHVmcmVxOiBnZXQg cmV0dXJuaW5nIGtub3duIGZyZXEgMzEwMApjcHVmcmVxOiBhZGRpbmcgOCByZWxhdGl2ZSBzZXR0 aW5ncwpjcHVmcmVxOiBza2lwcGluZyBpbmZvLW9ubHkgZHJpdmVyIGFjcGlfcGVyZjAKY3B1ZnJl cTogYWRkaW5nIGFicyBzZXR0aW5nIDMxMDAgYXQgaGVhZApjcHVmcmVxOiBhZGRpbmcgYWJzIHNl dHRpbmcgMjgwMCBhZnRlciAzMTAwCmNwdWZyZXE6IGFkZGluZyBhYnMgc2V0dGluZyAyMzAwIGFm dGVyIDI4MDAKY3B1ZnJlcTogYWRkaW5nIGFicyBzZXR0aW5nIDE5MDAgYWZ0ZXIgMjMwMApjcHVm cmVxOiBhZGRpbmcgYWJzIHNldHRpbmcgMTQwMCBhZnRlciAxOTAwCmNwdWZyZXE6IGV4cGFuZCBz ZXQgYWRkZWQgcmVsIHNldHRpbmcgMTAwJSB0byAxNDAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQg Y29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDEyMjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJl bGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGlu ZyBuZXcgbGV2ZWwgMTIyNSBhZnRlciAxNDAwCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVs IHNldHRpbmcgODclIHRvIDEyMjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBk ZXJpdmVkIHNldHRpbmcgMTA1MApjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVy OiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAx MDUwIGFmdGVyIDEyMjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA3NSUg dG8gMTA1MCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyA4NzUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRs ZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2ZWwgODc1IGFmdGVyIDEwNTAK Y3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyA2MiUgdG8gODc1IGxldmVsCmNw dWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDcwMApjcHVmcmVxOiBy ZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAg ZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCA3MDAgYWZ0ZXIgODc1CmNwdWZyZXE6IGV4cGFuZCBz ZXQgYWRkZWQgcmVsIHNldHRpbmcgNTAlIHRvIDcwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNv bnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyA1MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0 aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBu ZXcgbGV2ZWwgNTI1IGFmdGVyIDcwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0 aW5nIDM3JSB0byA1MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVk IHNldHRpbmcgMzUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlf dGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDM1MCBhZnRl ciA1MjUKY3B1ZnJlcTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAyNSUgdG8gMzUwIGxl dmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDE3NQpjcHVm cmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVx OiBkdXAgZG9uZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAxNzUgYWZ0ZXIgMzUwCmNwdWZyZXE6IGV4 cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcgMTIlIHRvIDE3NSBsZXZlbApjcHVmcmVxOiBleHBh bmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUgdG8gMTkwMCBsZXZlbApjcHVmcmVxOiBkdXAg c2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNjYyCmNwdWZyZXE6IHJlbW92ZWQgbGFz dCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNl cnRpbmcgbmV3IGxldmVsIDE2NjIgYWZ0ZXIgMTkwMApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVk IHJlbCBzZXR0aW5nIDg3JSB0byAxNjYyIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJp bmcgZGVyaXZlZCBzZXR0aW5nIDE0MjUKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRy aXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIGRvbmUsIGluc2VydGluZyBuZXcgbGV2 ZWwgMTQyNSBhZnRlciAxNjYyCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRkZWQgcmVsIHNldHRpbmcg NzUlIHRvIDE0MjUgbGV2ZWwKY3B1ZnJlcTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNl dHRpbmcgMTE4NwpjcHVmcmVxOiByZW1vdmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Ro cm90dGxlMApjcHVmcmVxOiBkdXAgc2V0IHJlamVjdGluZyAxMTg3IChhYnMgdG9vIGJpZykKY3B1 ZnJlcTogZHVwIHNldCBmcmVlaW5nIG5ldyBsZXZlbCAxMTg3IChub3Qgb3B0aW1hbCkKY3B1ZnJl cTogZXhwYW5kIHNldCBhZGRlZCByZWwgc2V0dGluZyAxMDAlIHRvIDIzMDAgbGV2ZWwKY3B1ZnJl cTogZHVwIHNldCBjb25zaWRlcmluZyBkZXJpdmVkIHNldHRpbmcgMjAxMgpjcHVmcmVxOiByZW1v dmVkIGxhc3QgcmVsYXRpdmUgZHJpdmVyOiBhY3BpX3Rocm90dGxlMApjcHVmcmVxOiBkdXAgZG9u ZSwgaW5zZXJ0aW5nIG5ldyBsZXZlbCAyMDEyIGFmdGVyIDIzMDAKY3B1ZnJlcTogZXhwYW5kIHNl dCBhZGRlZCByZWwgc2V0dGluZyA4NyUgdG8gMjAxMiBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNv bnNpZGVyaW5nIGRlcml2ZWQgc2V0dGluZyAxNzI1CmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxh dGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0bGUwCmNwdWZyZXE6IGR1cCBzZXQgcmVqZWN0aW5nIDE3 MjUgKGFicyB0b28gYmlnKQpjcHVmcmVxOiBkdXAgc2V0IGZyZWVpbmcgbmV3IGxldmVsIDE3MjUg KG5vdCBvcHRpbWFsKQpjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDEwMCUg dG8gMjgwMCBsZXZlbApjcHVmcmVxOiBkdXAgc2V0IGNvbnNpZGVyaW5nIGRlcml2ZWQgc2V0dGlu ZyAyNDUwCmNwdWZyZXE6IHJlbW92ZWQgbGFzdCByZWxhdGl2ZSBkcml2ZXI6IGFjcGlfdGhyb3R0 bGUwCmNwdWZyZXE6IGR1cCBkb25lLCBpbnNlcnRpbmcgbmV3IGxldmVsIDI0NTAgYWZ0ZXIgMjgw MApjcHVmcmVxOiBleHBhbmQgc2V0IGFkZGVkIHJlbCBzZXR0aW5nIDg3JSB0byAyNDUwIGxldmVs CmNwdWZyZXE6IGR1cCBzZXQgY29uc2lkZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDIxMDAKY3B1ZnJl cTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZlIGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTog ZHVwIHNldCByZWplY3RpbmcgMjEwMCAoYWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJl ZWluZyBuZXcgbGV2ZWwgMjEwMCAobm90IG9wdGltYWwpCmNwdWZyZXE6IGV4cGFuZCBzZXQgYWRk ZWQgcmVsIHNldHRpbmcgMTAwJSB0byAzMTAwIGxldmVsCmNwdWZyZXE6IGR1cCBzZXQgY29uc2lk ZXJpbmcgZGVyaXZlZCBzZXR0aW5nIDI3MTIKY3B1ZnJlcTogcmVtb3ZlZCBsYXN0IHJlbGF0aXZl IGRyaXZlcjogYWNwaV90aHJvdHRsZTAKY3B1ZnJlcTogZHVwIHNldCByZWplY3RpbmcgMjcxMiAo YWJzIHRvbyBiaWcpCmNwdWZyZXE6IGR1cCBzZXQgZnJlZWluZyBuZXcgbGV2ZWwgMjcxMiAobm90 IG9wdGltYWwpCmNwdWZyZXE6IHNraXBwaW5nIGZyZXEgMzEwMCwgc2FtZSBhcyBjdXJyZW50IGxl dmVsIDMxMDAK --Multipart=_Fri__25_May_2012_16_36_53_+0200_A1+Vw_9qRJb/a2WP-- --Signature=_Fri__25_May_2012_16_36_53_+0200_1q4ByDzg_.J3ETYT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+/mQ0ACgkQWTjlg++8y8tk/QCgt70ixcyPMJW9Ypthc1lY7lLx 278An2ZChwc6i/aJc6ScK0LkVBUwuIfy =4ftY -----END PGP SIGNATURE----- --Signature=_Fri__25_May_2012_16_36_53_+0200_1q4ByDzg_.J3ETYT-- From owner-freebsd-stable@FreeBSD.ORG Fri May 25 15:45:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9187C106567E for ; Fri, 25 May 2012 15:45:50 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 351CE8FC19 for ; Fri, 25 May 2012 15:45:50 +0000 (UTC) Received: by ghbz22 with SMTP id z22so654646ghb.13 for ; Fri, 25 May 2012 08:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=Om98pyiOe9Plq1i7zCdbVDv5sFd1zMiPk90nPKWNDEk=; b=gRKpIiQ4X3OhjeItSHOh8Z/kvgZVPTFnNIYtFY7KtQJ1oEACzRVZ97/AggK3POSh+j aEoIYdqhLOXIyxSVAqawLwTCjG43ji8Bd14GmKSt0s3BvleP4UjNODIjqof5Ao2GLhHM c/fS5Ug7jS3WBYTuyrzej1f1jOSRomm+X5nyk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=Om98pyiOe9Plq1i7zCdbVDv5sFd1zMiPk90nPKWNDEk=; b=Oq2JBL/6nv6TqpbyNXtoagfe2DYKqb+KU60FaMa8A50Wj7H+WOg8qKkbDf4zUelvAP at+0l4xlWezW4cw4W3seiazvF+7iSMKuZ6nOp4VTUVspdxlaY+KjPR08AwBFI3w+KIfW 5m40Uldv+Tgm+AGzLp/nNABvNJvSaITl4/ll2XwD3IiJhfwf51t67wXRemFhXUnz4av5 GLbV/chokD/YAhE41nJ7a3N0f7HmRC1OpuoV6rilQRiHDOxz2F5a2gH25fxUfkdfXpCD kK0AuN6GhqbP8uERbRNxn82nIs8kfvKTzRfw56YBMUYg6HIndAUYFrWlj9hYXK3y00gy 9Pkw== Received: by 10.50.135.37 with SMTP id pp5mr20653198igb.33.1337960749398; Fri, 25 May 2012 08:45:49 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id k4sm7590187igq.16.2012.05.25.08.45.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 08:45:49 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4PFjiU3003115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2012 11:45:44 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4PFjUo8003114; Fri, 25 May 2012 11:45:30 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Fri, 25 May 2012 11:45:30 -0400 From: Jason Hellenthal To: Trond Endrest?l Message-ID: <20120525154530.GA2272@DataIX.net> References: <1337890075.2709.16.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQnbIBkL4kksFEBy7GsunuY6LcW+PmfqpTzEuQTxNQCMFvt4U+zwyKww8h3lHeZTQbEi1jCk Cc: "freebsd-stable@freebsd.org" Subject: Re: bash 4.2 patchlevel 28 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:45:50 -0000 On Fri, May 25, 2012 at 07:44:39AM +0200, Trond Endrest?l wrote: > On Thu, 24 May 2012 13:07-0700, Sean Bruno wrote: > > > Noted that the following syntax is broken somewhere between 4.2 > > patchlevel 10 and 28. I'm sure its because we shouldn't be doing that > > over here at big purple, but we do ... and its a PITA. I'm bisecting to > > find out what is going on. > > > > test: > > VARIABLE="$(uname)" > > bash: command substitution: line 3: syntax error near unexpected token > > `)' > > bash: command substitution: line 3: `uname)"' > > > > Odd, but his works at patchlevel 10 > > I'm unable to reproduce this behaviour on one of my systems: > > trond@enterprise:~>bash --version > GNU bash, version 4.2.28(0)-release (amd64-portbld-freebsd9.0) > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > > This is free software; you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > trond@enterprise:~>my_var="$(uname)" > trond@enterprise:~>echo $my_var > FreeBSD > trond@enterprise:~> > > I'm not sure what's going on in your case. > Same here but on 8.3-STABLE i386 no errors found throughout any of the tests. -- - (2^(N-1)) From owner-freebsd-stable@FreeBSD.ORG Fri May 25 17:11:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20D121065670; Fri, 25 May 2012 17:11:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 387B58FC0A; Fri, 25 May 2012 17:11:22 +0000 (UTC) Message-ID: <4FBFBD39.7000105@FreeBSD.org> Date: Fri, 25 May 2012 13:11:21 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> In-Reply-To: <4FBFA9A9.7020806@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Yamagi Burmeister , seanbru@yahoo-inc.com Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:11:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-25 11:47:53 -0400, Andriy Gapon wrote: > on 25/05/2012 17:36 Yamagi Burmeister said the following: >> Hello, a user at BSDForen.de had the same problem and I helped >> him to track it down. While I was unable to find a solution I >> found the cause of the problems. The problem is (all files and >> line numbers relative to FreeBSD 9.0-RELEASE): >> >> 1. When a new p-state is requested (by powerd or by changing the >> sysctl) in kern/kern_cpu.c the function cf_set_method() is >> invoked. 2. In line 335 the driver depended function is called. >> For newer AMD CPU it's hwpstate_set() in x86/cpufreq/hwpstate.c >> 3. In x86/cpufreq/hwpstate.c line 227 hwpstate_goto_pstate() is >> called which does the actual magic. 4. In line 199 "if (msr != >> id)" triggers, returns ENXIO. The error is send back to >> cf_set_method(), which prints the "hwpstate0: set freq failed". >> powerd translates the error to "Device not configured" >> >> After some further investigation and looking at the linux driver >> [0] I changed the loop at x86/cpufreq/hwpstate.c 188ff from 100 >> iterations to 250. It lessend the problem but didn't solve it. >> The next step was to rewrite the logic between line 183 and 203 >> and adding a lot of debug printf. The patch (non style(9) >> compliant) is attached. With the new logic every 100 usec the new >> p-state is set again, until it's accepted. After 100 tries ENXIO >> is returned. >> >> This lessend the problem even more and showed that - On an old >> Phenom II X4 940 (K10 / Deneb) the new p-state is always accepted >> at the first try. At a test run for about 3 hours there was not a >> single failure. - On the Bulldozer CPU in about 9 in 10 times the >> new p-state is accepted at the first try. At most other times the >> new p-state is accepted after 1 to 10 tries. And there is a >> ~0,25% chance that the new p-state is never accepted, leading to >> "hwpstate0: set freq failed". At the next call to cf_set_method() >> (about 500ms to 1s later) the new p-state it's most likely set >> successfull. This can be seen at the log (full log attached): >> >> # First call, failed after 102 iterations hwpstate0: MSR: 0 ID: >> 1 hwpstate0: Setting failed! hwpstate0: Iterations: 102 >> >> # Second call, successfull hwpstate0: setting P1-state on cpu1 >> hwpstate0: MSR: 1 ID: 1 hwpstate0: Iterations: 1 >> >> So the big question is: Why is the new p-state sometimes not >> accepted? And why does this only happen on Bulldozer CPUs and not >> at the old K10 (Barcelona, Deneb), etc? Reading the "BIOS and >> kernel developer guide" for Bulldozer didn't show anything, but I >> may have overlooked it. One solution may be to change hwpstate >> not to set p-states but "Frequency IDs" (FID) and "Voltage ID" >> (VID) like the linux driver does. > > I think that you misread their code a little bit. The vid/fid > transition is used for K8 processors, for newer ones they do the > same P-state transitioning. The secret of their success seems to be > that they just write the MSR without any post-write checks. > > As to your questions about hardware behavior - yes, they are quite > interesting, but perhaps irrelevant. The BKDG never specifies the > OS P-state transition command sequence and timings, it just says > "write the MSR" (exactly what Linux does). There could be > different reasons why a core could be in a different P-state > (mostly I suspect interactions between cores in a Bulldozer compute > unit). When BKDG does specify the P-state transitioning sequence > (for BIOS) it suggest a different one from what we do - first write > the MSR on al processors, only then check the result (and the way > of checking the result is also a bit different - using MSR xxx71). I just looked through the BKDG and I think you should definitely check MSRC001_0071[18:16]. MSRC001_0063[2:0] is "SharedC" but MSRC001_0062[2:0] and MSRC001_0071[18:15] are "Not-same-for-all". I think this means writing a P-state to MSRC001_0062[2:0] will be reflected in MSRC001_0070[18:16] first, then MSRC001_0071[18:16] gets updated when the P-state transition is complete. MSRC001_0063[2:0] will only change when all cores in a compute unit is in sync., which may be too late. > But as I've said, these details are probably not really useful in > practice. We should just quit worrying and double-checking the > hardware :-) I think we should check. Jung-uk Kim >> 0: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/cpufreq/powernow-k8.c;h=c0e816468e300f242735f4825d09b9d291a9b522;hb=HEAD >> >> >> 1: >> http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/vTkACgkQmlay1b9qnVPY9QCgqcEvUHKKQ3U0Rec5Kzdlrw3L kSkAnj6ofOf8PVkEHlxNrgGZAHJ2so1p =GQw9 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri May 25 17:13:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5D6D1065678; Fri, 25 May 2012 17:13:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4DFB18FC17; Fri, 25 May 2012 17:13:35 +0000 (UTC) Message-ID: <4FBFBDBE.8030302@FreeBSD.org> Date: Fri, 25 May 2012 13:13:34 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> <4FBFBD39.7000105@FreeBSD.org> In-Reply-To: <4FBFBD39.7000105@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Yamagi Burmeister , Andriy Gapon , seanbru@yahoo-inc.com Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:13:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-25 13:11:21 -0400, Jung-uk Kim wrote: > I just looked through the BKDG and I think you should definitely > check MSRC001_0071[18:16]. MSRC001_0063[2:0] is "SharedC" but > MSRC001_0062[2:0] and MSRC001_0071[18:15] are "Not-same-for-all". ^^ 16 Sorry for the typo. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/vb4ACgkQmlay1b9qnVOjPACbBIyx9eHTXqDqJjeAQpamAfPT 9+oAoL99VMf9MAhspIBJGvjFBG2aLynE =4Z9b -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri May 25 19:26:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8F3C1065677 for ; Fri, 25 May 2012 19:26:42 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEA58FC12 for ; Fri, 25 May 2012 19:26:42 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 280251CC4B; Fri, 25 May 2012 16:26:30 -0300 (BRT) Received: from 187.115.176.56 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Fri, 25 May 2012 16:26:30 -0300 Message-ID: Date: Fri, 25 May 2012 16:26:30 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Intel 525MW and FreeBSD 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:26:42 -0000 hail, I got issues with port multiplier and was told to update to 9-STABLE. But I can't. I get this error when trying to compile world: panic: vm_page_inserted: page already inserted cpuid=0 I tried 3 times. my system is Intel 525MW, 4GB Ram. Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.10-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106ca Family = 6 Model = 1c Stepping = 10 Features=0xbfebfbff Features2=0x40e31d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4077744128 (3888 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 It looks its not the first time this happens in this family: http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=104&t=10900 and http://forums.freenas.org/showthread.php?250-panic-vm_page_insert-page-already-inserted-cpuid-3, but no solution so far. is there anything to solve this, any hint or has anyone also seen this ? thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Fri May 25 20:05:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 705DE1065674; Fri, 25 May 2012 20:05:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B3A7F8FC18; Fri, 25 May 2012 20:05:56 +0000 (UTC) Message-ID: <4FBFE624.1020208@FreeBSD.org> Date: Fri, 25 May 2012 16:05:56 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> <4FBFBD39.7000105@FreeBSD.org> <4FBFDFFB.9020501@FreeBSD.org> In-Reply-To: <4FBFDFFB.9020501@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Yamagi Burmeister , seanbru@yahoo-inc.com Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:05:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-25 15:39:39 -0400, Andriy Gapon wrote: > on 25/05/2012 20:11 Jung-uk Kim said the following: >> I just looked through the BKDG and I think you should definitely >> check MSRC001_0071[18:16]. MSRC001_0063[2:0] is "SharedC" but >> MSRC001_0062[2:0] and MSRC001_0071[18:15] are "Not-same-for-all". >> I think this means writing a P-state to MSRC001_0062[2:0] will be >> reflected in MSRC001_0070[18:16] first, then MSRC001_0071[18:16] >> gets updated when the P-state transition is complete. >> MSRC001_0063[2:0] will only change when all cores in a compute >> unit is in sync., which may be too late. >> > [snip] >> I think we should check. > > Jung-uk, > > if we decide so, then I think that we could still keep the things > "simple". As we currently use the "wholesale" approach (all CPUs > are set to the same P-state regardless of topology), then we could > first make a pass of writing the MSR on all processors with a new > P-state value and then make another pass of checking via MSR > C001_0063 that the P-state is acquired. No, I believe checking MSRC001_0071[18:16] is much simpler if it works. And it does not break current cpufreq(4) design principles. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+/5iQACgkQmlay1b9qnVOHLgCfY0ELt5oN1hml8S+bDGSHbOux bj4AoKisSh9DlK46U+LFthaSGicp/+Hc =BYej -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri May 25 20:24:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 349F9106574A for ; Fri, 25 May 2012 20:24:38 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id ADF848FC1D for ; Fri, 25 May 2012 20:24:37 +0000 (UTC) Received: from rbpbp.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q4PKJQtI057596; Fri, 25 May 2012 21:19:26 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Bob Bishop X-Priority: 3 (Normal) In-Reply-To: Date: Fri, 25 May 2012 21:19:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nenhum_de_Nos X-Mailer: Apple Mail (2.1278) Cc: freebsd-stable@freebsd.org Subject: Re: Intel 525MW and FreeBSD 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:24:38 -0000 Hi, On 25 May 2012, at 20:26, Nenhum_de_Nos wrote: > hail, >=20 > I got issues with port multiplier and was told to update to 9-STABLE. = But I can't. >=20 > I get this error when trying to compile world: >=20 > panic: vm_page_inserted: page already inserted > cpuid=3D0 >=20 > I tried 3 times. >=20 > my system is Intel 525MW, 4GB Ram. I had various problems with mine, fixed by updating the BIOS. > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.10-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x106ca Family =3D 6 Model =3D 1c = Stepping =3D 10 > = Features=3D0xbfebfbff > = Features2=3D0x40e31d > AMD Features=3D0x20100800 > AMD Features2=3D0x1 > TSC: P-state invariant, performance statistics > real memory =3D 4294967296 (4096 MB) > avail memory =3D 4077744128 (3888 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 1 > cpu2 (AP): APIC ID: 2 >=20 >=20 > It looks its not the first time this happens in this family: > http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=3D104&t=3D1090= 0 and > = http://forums.freenas.org/showthread.php?250-panic-vm_page_insert-page-alr= eady-inserted-cpuid-3, > but no solution so far. >=20 > is there anything to solve this, any hint or has anyone also seen this = ? >=20 > thanks, >=20 > matheus >=20 >=20 > --=20 > We will call you Cygnus, > The God of balance you shall be >=20 > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? >=20 > http://en.wikipedia.org/wiki/Posting_style -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri May 25 21:05:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C6F106564A for ; Fri, 25 May 2012 21:05:22 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 432FA8FC0A for ; Fri, 25 May 2012 21:05:22 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4PL4oHn094837 for ; Fri, 25 May 2012 14:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337979891; bh=6JtdItDb0DvPvtw2p0KkuSvVnbuL4IkN+N//hHNXP0Y=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=c/ZnCqPHxFRUJLcxGQoRtcLrrm1emyO0bJA7GaIKRAReJqmsyAS1gBYEQg+RoFaV7 Et3skhutjGV5Z2hWAjEf5o4qqiTLPWFrA081lITXEmK6dI3n12ALcoKU1kF3d4okrh lSiFaaItk4Stc48nWDqP/ZTfeX/TWYMFgNqQVy+Y= From: Sean Bruno To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 May 2012 14:04:50 -0700 Message-ID: <1337979890.5264.0.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 979891001 Subject: stable/9 sandybridge reboot panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:05:22 -0000 Dell R620, getting pretty reliable panics here everytime I reboot. http://people.freebsd.org/~sbruno/sandybridge_reboot_panic.txt Sean From owner-freebsd-stable@FreeBSD.ORG Fri May 25 21:32:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C90B9106564A; Fri, 25 May 2012 21:32:05 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0FB8FC0C; Fri, 25 May 2012 21:32:05 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4PLVi3Z004255; Fri, 25 May 2012 14:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337981505; bh=c4/j5hnjKdLOf7Jewnomx4YDvPXaKVJ9JcCUCq/Wuwg=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=OhtRctYp87Jl1rmk9iOSydapZUio0P1SNwCo/ycSUO8k6GrB/Kn6x9v2/cMvao7oZ WjD53ten4+3aw/gd05HjVAhiA7fyPbKIsHz5YQuxVAWpvfpwYCMFurgYrPr9EvvjdD A9lfsJaQFWKsraV9dF4hQsdXAwMLgAKZMXuHmgnQ= From: Sean Bruno To: "sbruno@freebsd.org" In-Reply-To: <1337979890.5264.0.camel@powernoodle-l7.corp.yahoo.com> References: <1337979890.5264.0.camel@powernoodle-l7.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 May 2012 14:31:44 -0700 Message-ID: <1337981504.5264.1.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 981505002 Cc: "freebsd-stable@freebsd.org" Subject: Re: stable/9 sandybridge reboot panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:32:05 -0000 On Fri, 2012-05-25 at 14:04 -0700, Sean Bruno wrote: > Dell R620, getting pretty reliable panics here everytime I reboot. > > http://people.freebsd.org/~sbruno/sandybridge_reboot_panic.txt > > > Sean > > > _______________________________________________ Verbose console boot ... interesting stuff about ioapic in there. http://people.freebsd.org/~sbruno/dell_r620_fbsd9.txt Sean From owner-freebsd-stable@FreeBSD.ORG Fri May 25 22:06:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A25051065697; Fri, 25 May 2012 22:06:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BAAD88FC16; Fri, 25 May 2012 22:06:39 +0000 (UTC) Received: by laai10 with SMTP id i10so1316433laa.13 for ; Fri, 25 May 2012 15:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1KVEW5LVhc+xgNKpHN1YcVpfAIB4JrEg5oBCwTlPlGs=; b=NcJcF2rSFNodMqlE1p5q2Bhv/p2KT+LB7PWevyCgzUNiDpv0otoeyf5zXGQF8Amu4t IvalO1boPrGduO+8/BgvkTK0kFnambgrz/YSeIl/bN/X3MLv2HSJtPFadwI7avKoEqoS EWCgWyv5L/z3I50ibbKrzAgvtfmuygJIzIkBzduPljQE5H9/eWm39Y3LVbeR19xNQDiZ Bi07ePYyU5NpZmOAyzYlY5SjQLoMrGu10PxtoR7sAl+Vg53L8P61eaoAlg8QgBNk1RqK kASRnKLHad0GMShtU7FqSjrLq77g1lR0dFKaGqVS/J/xYKdppohhLPGoVnACROUr6OAY OcZA== MIME-Version: 1.0 Received: by 10.112.103.194 with SMTP id fy2mr228802lbb.64.1337983598480; Fri, 25 May 2012 15:06:38 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Fri, 25 May 2012 15:06:38 -0700 (PDT) In-Reply-To: <1337979890.5264.0.camel@powernoodle-l7.corp.yahoo.com> References: <1337979890.5264.0.camel@powernoodle-l7.corp.yahoo.com> Date: Fri, 25 May 2012 23:06:38 +0100 X-Google-Sender-Auth: 65zaJGIdZTz3ufdSsN8C7AC2ZCc Message-ID: From: Attilio Rao To: sbruno@freebsd.org, Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" Subject: Re: stable/9 sandybridge reboot panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 22:06:40 -0000 2012/5/25, Sean Bruno : > Dell R620, getting pretty reliable panics here everytime I reboot. > > http://people.freebsd.org/~sbruno/sandybridge_reboot_panic.txt I'm sure that if you drop hwpmc you will get rid of it. it would be good if you however get something for Davide and George that they can investigate and fix, would be great, in particular because it is already ported on STABLE_9. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Sat May 26 02:29:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9216A106566C for ; Sat, 26 May 2012 02:29:01 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 682B88FC0C for ; Sat, 26 May 2012 02:29:01 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 8AFF31CC4B; Fri, 25 May 2012 23:28:52 -0300 (BRT) Received: from 187.115.176.56 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Fri, 25 May 2012 23:28:52 -0300 Message-ID: In-Reply-To: References: Date: Fri, 25 May 2012 23:28:52 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Intel 525MW and FreeBSD 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 02:29:01 -0000 On Fri, May 25, 2012 17:19, Bob Bishop wrote: > Hi, > > On 25 May 2012, at 20:26, Nenhum_de_Nos wrote: > >> hail, >> >> I got issues with port multiplier and was told to update to 9-STABLE. But I can't. >> >> I get this error when trying to compile world: >> >> panic: vm_page_inserted: page already inserted >> cpuid=0 >> >> I tried 3 times. >> >> my system is Intel 525MW, 4GB Ram. > > I had various problems with mine, fixed by updating the BIOS. that did the trick so far, I'm building word now. thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sat May 26 06:21:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4A2B1065672 for ; Sat, 26 May 2012 06:21:18 +0000 (UTC) (envelope-from annona2@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9428FC0A for ; Sat, 26 May 2012 06:21:18 +0000 (UTC) Received: by dadv36 with SMTP id v36so2197313dad.13 for ; Fri, 25 May 2012 23:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=16bTNajBayYf0953M+ePQ//oGJZCKqukCH0eRT/Z2xs=; b=O4Z6w5NCDj24sFR3ExNh7KEPpLwb1QVGnahMbXLIvnx/7hMwWOTFnxMlaDj3+qNduu pmQiSO60bSjRmCVFFVLyzEWasEStBru0TTRZO/tZqQKMLXpnPYH+Xg2cetjGaKpuqnJ/ F6zZCRF470WXtZnRhGBMxNZAVsalY4jFA0As/CjWJaIrjz6qc41/v3tpLS1hnEkYV9nP bmqvvBCd5H3RUBlwgBTTQvLYB0uqrIjTdLpwH+LamlzkZFh3u3jOmKDxbi3aFSkXAJlI GkC4swJi/Ng67Tj+cVQgdDQJJZtnxq0DhF5y0nnT5BMRvLbvJQyW7K5GNn4DKXXuS/M9 6GnA== Received: by 10.68.221.74 with SMTP id qc10mr4678674pbc.31.1338013277947; Fri, 25 May 2012 23:21:17 -0700 (PDT) Received: from localhost (52.241.197.113.dy.bbexcite.jp. [113.197.241.52]) by mx.google.com with ESMTPS id kh10sm11530396pbc.67.2012.05.25.23.21.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 23:21:16 -0700 (PDT) Received: from r10 (localhost [127.0.0.1]) by localhost (8.14.5/8.14.5) with SMTP id q4Q6LCM0005244 for ; Sat, 26 May 2012 15:21:12 +0900 (JST) (envelope-from annona2@gmail.com) Date: Sat, 26 May 2012 15:21:12 +0900 From: "Gen O." To: freebsd-stable@freebsd.org Message-Id: <20120526152112.42b20e45.annona2@gmail.com> In-Reply-To: <4FBFE624.1020208@FreeBSD.org> References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> <4FBFBD39.7000105@FreeBSD.org> <4FBFDFFB.9020501@FreeBSD.org> <4FBFE624.1020208@FreeBSD.org> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 06:21:18 -0000 Hi, I suprised that followings , cited from AMD BKDG(42301 Rev 3.06 - January 25, 2012) > 2.5.2.1.4 > Core P-state Visibility > (snip) > If a compute unit is in a boosted P-state, MSRC001_0063[CurPstate] > reads back as 0. ^^^^^^^^^^^^^ if in a boosted P-state, MSRC001_0063 "reads back as 0". so here is ugly patch ;-) --- hwpstate.c.orig 2012-05-26 15:06:06.000000000 +0900 +++ hwpstate.c 2012-05-26 15:07:50.000000000 +0900 @@ -196,7 +196,7 @@ msr = rdmsr(MSR_AMD_10H_11H_STATUS); HWPSTATE_DEBUG(dev, "result P%d-state on cpu%d\n", (int)msr, PCPU_GET(cpuid)); - if (msr != id) { + if (msr != id && msr != 0) { HWPSTATE_DEBUG(dev, "error: loop is not enough.\n"); error = ENXIO; } but this doesn't reflect that the cpu frequency is equal to sysctl value. So, disabling the boost and setting the p-state is an answer. And when setting the max freq from sysctl, enable the boost is also. -- Gen O. From owner-freebsd-stable@FreeBSD.ORG Sat May 26 07:02:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE940106566C; Sat, 26 May 2012 07:02:39 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9E48FC0A; Sat, 26 May 2012 07:02:39 +0000 (UTC) Received: from maka.home.yamagi.org (p4FD17C58.dip.t-dialin.net [79.209.124.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 70A091666334; Sat, 26 May 2012 09:02:36 +0200 (CEST) Date: Sat, 26 May 2012 09:02:33 +0200 From: Yamagi Burmeister To: jkim@FreeBSD.org Message-Id: <20120526090233.f638c1d2.lists@yamagi.org> In-Reply-To: <4FBFE624.1020208@FreeBSD.org> References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> <4FBFBD39.7000105@FreeBSD.org> <4FBFDFFB.9020501@FreeBSD.org> <4FBFE624.1020208@FreeBSD.org> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__26_May_2012_09_02_33_+0200_mBo1t4d7+SWB5n2B" Cc: freebsd-stable@freebsd.org, seanbru@yahoo-inc.com, avg@freebsd.org Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 07:02:39 -0000 --Signature=_Sat__26_May_2012_09_02_33_+0200_mBo1t4d7+SWB5n2B Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 25 May 2012 16:05:56 -0400 Jung-uk Kim wrote: > > if we decide so, then I think that we could still keep the things > > "simple". As we currently use the "wholesale" approach (all CPUs > > are set to the same P-state regardless of topology), then we could > > first make a pass of writing the MSR on all processors with a new > > P-state value and then make another pass of checking via MSR > > C001_0063 that the P-state is acquired. >=20 > No, I believe checking MSRC001_0071[18:16] is much simpler if it > works. And it does not break current cpufreq(4) design principles. Okay, thank's for your input. I'll come up with a patch. But it won't happen until tuesday or wednesday next week. --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Sat__26_May_2012_09_02_33_+0200_mBo1t4d7+SWB5n2B Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/AgA4ACgkQWTjlg++8y8uiVQCgupXRyS7u8iCjTdllMhSgDU1W vb4AoLdEkedgj9V6x+K9P/0HoSRXGFLU =keUc -----END PGP SIGNATURE----- --Signature=_Sat__26_May_2012_09_02_33_+0200_mBo1t4d7+SWB5n2B-- From owner-freebsd-stable@FreeBSD.ORG Sat May 26 09:10:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 257871065672; Sat, 26 May 2012 09:10:28 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id C8C538FC1B; Sat, 26 May 2012 09:10:27 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q4Q9AQ8M089962; Sat, 26 May 2012 18:10:26 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sat, 26 May 2012 18:10:26 +0900 (JST) Message-Id: <20120526.181026.124546767.iwasaki@jp.FreeBSD.org> To: adrian@freebsd.org From: Mitsuru IWASAKI In-Reply-To: References: <20120525.134903.05583594.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: iwasaki@freebsd.org, freebsd-stable@freebsd.org, jkim@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 09:10:28 -0000 Hi, > No, I didn't have vesa loaded. I'll load that now and try tomorrow > after a reboot. vesa(4) has video BIOS init hack run in vm86-mode or on x86 emulator. I think it is cool. My X61 still need video BIOS init in acpi_wakecode, because it seems vesa's BIOS init ends incompletely by page fault for now though. > yes, I tried switching VTYs, each VTY had the same issue. I guess the > driver isn't doing a VGA mode change when I switch VTYs unless the > screens are in different modes? If you have a vty with initial video mode, switching vtys will work I think. Oh yes, please try the following patches. http://people.freebsd.org/~iwasaki/acpi/syscons-vesa-resume-20120526.diff This is already done in vesa(4), added support non-vesa mode. > FWIW, Xorg suspend/resume via the "switch to VTY before suspending" > hack works on this Thinkpad T60. It's not optimal but hey, it _does_ > work. :) Long time ago, I added the hack trying to make it as small as possible for the same effect :) Now we need the true solution... Thanks! From owner-freebsd-stable@FreeBSD.ORG Sat May 26 10:25:59 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AFD3106566C; Sat, 26 May 2012 10:25:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id C3C6D8FC19; Sat, 26 May 2012 10:25:58 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q4QAPwRp047955; Sat, 26 May 2012 10:25:58 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q4QAPv45047954; Sat, 26 May 2012 10:25:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 May 2012 10:25:57 GMT Message-Id: <201205261025.q4QAPv45047954@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 10:25:59 -0000 TB --- 2012-05-26 10:05:00 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-05-26 10:05:00 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-26 10:05:00 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-05-26 10:05:00 - cleaning the object tree TB --- 2012-05-26 10:05:00 - cvsupping the source tree TB --- 2012-05-26 10:05:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2012-05-26 10:05:35 - building world TB --- 2012-05-26 10:05:35 - CROSS_BUILD_TESTING=YES TB --- 2012-05-26 10:05:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-26 10:05:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-26 10:05:35 - SRCCONF=/dev/null TB --- 2012-05-26 10:05:35 - TARGET=sparc64 TB --- 2012-05-26 10:05:35 - TARGET_ARCH=sparc64 TB --- 2012-05-26 10:05:35 - TZ=UTC TB --- 2012-05-26 10:05:35 - __MAKE_CONF=/dev/null TB --- 2012-05-26 10:05:35 - cd /src TB --- 2012-05-26 10:05:35 - /usr/bin/make -B buildworld >>> World build started on Sat May 26 10:05:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] rm -f .depend mkdep -f .depend -a -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ /src/sys/boot/sparc64/loader/locore.S /src/sys/boot/sparc64/loader/main.c /src/sys/boot/sparc64/loader/metadata.c vers.c /src/sys/boot/sparc64/loader/../../common/boot.c /src/sys/boot/sparc64/loader/../../common/commands.c /src/sys/boot/sparc64/loader/../../common/console.c /src/sys/boot/sparc64/loader/../../common/devopen.c /src/sys/boot/sparc64/loader/../../common/interp.c /src/sys/boot/sparc64/loader/../../common/interp_backslash.c /src/sys/boot/sparc64/loader/../../common/interp_parse.c /src/sys/boot/sparc64/loader/../..! /common/ls.c /src/sys/boot/sparc64/loader/../../common/misc.c /src/sys/boot/sparc64/loader/../../common/module.c /src/sys/boot/sparc64/loader/../../common/panic.c /src/sys/boot/sparc64/loader/../../common/load_elf64.c /src/sys/boot/sparc64/loader/../../common/reloc_elf64.c /src/sys/boot/sparc64/loader/../../common/dev_net.c /src/sys/boot/sparc64/loader/../../common/interp_forth.c echo loader: /obj/sparc64/src/sys/boot/sparc64/loader/../../ficl/libficl.a /obj/sparc64/src/sys/boot/sparc64/loader/../../ofw/libofw/libofw.a /obj/sparc64/src/tmp/usr/lib/libstand.a >> .depend ===> sys/boot/sparc64/zfsboot (depend) rm -f .depend mkdep -f .depend -a -I/src/sys/boot/sparc64/zfsboot/../../common /src/sys/boot/sparc64/zfsboot/../boot1/boot1.c ===> sys/boot/sparc64/zfsloader (depend) make: don't know how to make /src/sys/boot/sparc64/zfsloader/version. Stop *** Error code 2 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-26 10:25:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-26 10:25:57 - ERROR: failed to build world TB --- 2012-05-26 10:25:57 - 994.71 user 192.50 system 1257.47 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 26 12:53:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B59CA106566B for ; Sat, 26 May 2012 12:53:16 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3708FC0C for ; Sat, 26 May 2012 12:53:16 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 9E5861CC50; Sat, 26 May 2012 09:53:09 -0300 (BRT) Received: from 187.115.176.56 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sat, 26 May 2012 09:53:09 -0300 Message-ID: In-Reply-To: References: <4FBCF2B6.1060200@sentex.net> <460e1bd626613f125b878f5be65a6b6e.squirrel@eternamente.info> Date: Sat, 26 May 2012 09:53:09 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: siis_timeout with port multiplier on 9.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 12:53:16 -0000 On Wed, May 23, 2012 17:07, Nenhum_de_Nos wrote: > > On Wed, May 23, 2012 12:54, Nenhum_de_Nos wrote: >> >> On Wed, May 23, 2012 11:22, Mike Tancsa wrote: >>> On 5/21/2012 9:04 PM, Matthew Gamble wrote: >>>> We have a box with 3 SiI3124 SATA controllers and 9 CFI-B53PM 5 Port Backplane port >>>> multipliers >>>> (the "backblaze storage pod"). Under intense IO (ZFS rebuild, presently) the system will lock >>>> up all IO for 3-4 minutes and the following entry appears in the dmesg: >>>> >>>> siisch11: Timeout on slot 30 >>>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>>> 00000000 >>>> siisch11: ... waiting for slots 25000000 >>>> siisch11: Timeout on slot 26 >>>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>>> 00000000 >>>> siisch11: ... waiting for slots 21000000 >>>> siisch11: Timeout on slot 29 >>>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>>> 00000000 >>>> siisch11: ... waiting for slots 01000000 >>>> siisch11: Timeout on slot 24 >>>> siisch11: siis_timeout is 00040000 ss 65000000 rs 65000000 es 00000000 sts 80192000 serr >>>> 00000000 >>>> >>>> The errors are on different siisch devices so its not likely to be a SATA cable issue unless >>>> multiple cables all went bad at the same time. On the advice of some other posts to the >>>> mailing >>>> list I've already tried locking the SATA rev to one with the following in /boot/loader.conf >>>> which didn't >>> >>> If they are on different siisch devices then yes, it does not sound like >>> a bad cable. However, I have had that issue with similar errors above >>> that were fixed by using new cables. If you are using 9.0R, I would >>> suggest upgrading to stable. There have been a few bug fixes / >>> improvements to the drivers as well as various parts of the disk >>> subsystem. I have RELENG8 right now and its quite stable for me on a >>> 25TB system which is for the most part similar to 9.x >>> >>> # zpool status >>> pool: zbackup1 >>> state: ONLINE >>> scan: scrub repaired 0 in 11h11m with 0 errors on Mon Jul 25 19:51:11 2011 >>> config: >>> >>> NAME STATE READ WRITE CKSUM >>> zbackup1 ONLINE 0 0 0 >>> raidz1-0 ONLINE 0 0 0 >>> ada14 ONLINE 0 0 0 >>> ada16 ONLINE 0 0 0 >>> ada13 ONLINE 0 0 0 >>> ada15 ONLINE 0 0 0 >>> raidz1-1 ONLINE 0 0 0 >>> ada0 ONLINE 0 0 0 >>> ada1 ONLINE 0 0 0 >>> ada2 ONLINE 0 0 0 >>> ada3 ONLINE 0 0 0 >>> raidz1-2 ONLINE 0 0 0 >>> ada4 ONLINE 0 0 0 >>> ada5 ONLINE 0 0 0 >>> ada6 ONLINE 0 0 0 >>> ada7 ONLINE 0 0 0 >>> raidz1-3 ONLINE 0 0 0 >>> ada9 ONLINE 0 0 0 >>> ada10 ONLINE 0 0 0 >>> ada11 ONLINE 0 0 0 >>> ada12 ONLINE 0 0 0 >>> >>> errors: No known data errors >>> # zpool get all zbackup1 >>> NAME PROPERTY VALUE SOURCE >>> zbackup1 size 25.4T - >>> zbackup1 capacity 68% - >>> zbackup1 altroot - default >>> zbackup1 health ONLINE - >>> zbackup1 guid 917659042733882722 default >>> zbackup1 version 28 default >>> zbackup1 bootfs - default >>> zbackup1 delegation on default >>> zbackup1 autoreplace off default >>> zbackup1 cachefile - default >>> zbackup1 failmode wait default >>> zbackup1 listsnapshots on local >>> zbackup1 autoexpand off default >>> zbackup1 dedupditto 0 default >>> zbackup1 dedupratio 1.00x - >>> zbackup1 free 7.95T - >>> zbackup1 allocated 17.4T - >>> zbackup1 readonly off - >>> zbackup1 comment - default >>> >>> This is on an adonics adaptor. >> >> my adapter is this adonics as well, and my lucky is not the same. the host card is also sis3124 >> PCI ? >> >> I will upgrade to 9-STABLE and try. >> >> thanks, >> >> matheus > > Mike, > > I saw FreeBSD webcvs info on siis.c. The only change in 9-STABLE is this: > > Revision 1.43.2.2: download - view: text, markup, annotated - select for diffs > Sat Dec 31 15:31:34 2011 UTC (4 months, 3 weeks ago) by hselasky > Branches: RELENG_9 > Diff to: previous 1.43.2.1: preferred, colored; branchpoint 1.43: preferred, colored; next MAIN > 1.44: preferred, colored > Changes since revision 1.43.2.1: +2 -7 lines > > SVN rev 229118 on 2011-12-31 15:31:34Z by hselasky > > MFC r227701, r227847 and r227849: > Move the device_delete_all_children() function from usb_util.c > to kern/subr_bus.c. Simplify this function so that it no longer > depends on malloc() to execute. Rename device_delete_all_children() > into device_delete_children(). Identify a few other places where > it makes sense to use device_delete_children(). > > all others, 9.0R has it. As i don't know this stuff, I can't tell how much it would affect my > issue (and the other Matheus/Matthew as well), but I imagine not much as it says something usb on > it :) > > as I'm not at home, will try the cabling thing when I get home. > > thanks, > > matheus Finished, unfortunately the same result :( I've also changed cables, used brand new ones, and the same thing happened :( thanks, matheus >>> ---Mike >>>> >>>> hint.siisch.0.sata_rev=1 >>>> hint.siisch.1.sata_rev=1 >>>> hint.siisch.2.sata_rev=1 >>>> hint.siisch.3.sata_rev=1 >>>> hint.siisch.4.sata_rev=1 >>>> hint.siisch.5.sata_rev=1 >>>> hint.siisch.6.sata_rev=1 >>>> hint.siisch.7.sata_rev=1 >>>> hint.siisch.8.sata_rev=1 >>>> hint.siisch.9.sata_rev=1 >>>> hint.siisch.10.sata_rev=1 >>>> hint.siisch.11.sata_rev=1 >>>> >>>> From time to time this is also causing one of the attached drives to go offline: >>>> >>>> siisch0: siis_timeout is 00040000 ss 40000000 rs 40000000 es 00000000 sts 801f2000 serr >>>> 00000000 >>>> (ada0:siisch0:0:0:0): lost device >>>> (ada0:siisch0:0:0:0): removing device entry >>>> ada0 at siisch0 bus 0 scbus0 target 0 lun 0 >>>> ada0: ATA-8 SATA 3.x device >>>> ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) >>>> ada0: Command Queueing enabled >>>> ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) >>>> ada0: Previously was known as ad4 >>>> siisch11: Timeout on slot 30 >>>> >>>> When the drive goes offline that causes the ZFS rebuild to restart, and so it's never >>>> finishing >>>> the rebuild of the array. Does anyone have any insight into what could be causing the >>>> timeouts >>>> and what we can do to resolve them? Right now my priority is to get the system a bit more >>>> stable so the current ZFS rebuild can complete – right now it's been doing the same rebuild >>>> for just over 6 days and the timeouts and drive drop offs are causing it to restart >>>> constantly. >>>> >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> This electronic message contains information from Primus Telecommunications Canada Inc. >>>> ("PRIMUS") , which may be legally privileged and confidential. The information is intended to >>>> be for the use of the individual(s) or entity named above. If you are not the intended >>>> recipient, be aware that any disclosure, copying, distribution or use of the contents of this >>>> information is prohibited. If you have received this electronic message in error, please >>>> notify >>>> us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or >>>> advice expressed in this electronic message are not necessarily the views, opinions or advice >>>> of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus >>>> free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use >>>> thereof.The term "PRIMUS" includes its affiliates. >>>> >>>> ________________________________ >>>> Pour la version en français de ce message, veuillez voir >>>> http://www.primustel.ca/fr/legal/cs.htm >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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" >>> >>> >>> -- >>> ------------------- >>> 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/ >>> _______________________________________________ >>> 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" >>> >> >> >> -- >> We will call you Cygnus, >> The God of balance you shall be >> >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> >> http://en.wikipedia.org/wiki/Posting_style >> _______________________________________________ >> 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" >> > > > -- > We will call you Cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style > _______________________________________________ > 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" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sat May 26 17:37:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAC28106564A for ; Sat, 26 May 2012 17:37:52 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBEB8FC19 for ; Sat, 26 May 2012 17:37:52 +0000 (UTC) Received: from rancor.immure.com (rancor.immure.com [10.1.132.9]) by maul.immure.com (8.14.5/8.14.5) with ESMTP id q4QHZakN059885 for ; Sat, 26 May 2012 12:35:36 -0500 (CDT) (envelope-from bob@immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.5/8.14.4/Submit) id q4QHZaj1088360 for freebsd-stable@freebsd.org; Sat, 26 May 2012 12:35:36 -0500 (CDT) (envelope-from bob) Date: Sat, 26 May 2012 12:35:35 -0500 From: Bob Willcox To: stable list Message-ID: <20120526173535.GA87335@rancor.immure.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner-ID: q4QHZakN059885 X-immure-MailScanner: Found to be clean X-immure-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 1, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-immure-MailScanner-From: bob@immure.com X-Spam-Status: No Subject: Problems trying to run X on Intel DH77DF System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 17:37:53 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi All, I have a new Intel DH77DF mini-ITX motherboard with a Core i5 3550 CPU and am having trouble getting X to run. This is on a 9-STABLE system just updated today via cvsup. There appear to be two obvious problems: the first is that X will no longer start (it used to with about a two week older 9-stable build); and the second is that once I attempt to start X I seem to lose the console. I'm left with a blue screen and am unable to switch to any other console (neither Alt-Fx nor Ctl-Alt-Fx do anything). The system is, however, still running as I can login via the network. My 'uname -a' output is this: FreeBSD yoda 9.0-STABLE FreeBSD 9.0-STABLE #4: Fri May 25 20:36:02 CDT 2012 bob@yoda:/usr/obj/usr/src/sys/YODA amd64 I have attached my dmesg output, a copy of my xorg.conf file, and the output of 'pciconf -vl'. Anyone have any idea of what's going wrong, or what I can do to get X to work on this system? Thanks, Bob -- Bob Willcox The right half of the brain controls the left half bob@immure.com of the body. This means that only left handed people Austin, TX are in their right mind. --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #4: Fri May 25 20:36:02 CDT 2012 bob@yoda:/usr/obj/usr/src/sys/YODA amd64 CPU: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 Features=0xbfebfbff Features2=0x7fbae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8144031744 (7766 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 67, 1 (4) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 xhci0: mem 0xf7d20000-0xf7d2ffff irq 16 at device 20.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 pci0: at device 22.0 (no driver attached) em0: port 0xf080-0xf09f mem 0xf7d00000-0xf7d1ffff,0xf7d39000-0xf7d39fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: e8:40:f2:0b:45:53 ehci0: mem 0xf7d38000-0xf7d383ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 19 at device 28.7 on pci0 pci2: on pcib2 fwohci0: <1394 Open Host Controller Interface> port 0xe000-0xe0ff mem 0xf7c00000-0xf7c007ff irq 19 at device 0.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 e0:cb:4e:00:00:0f:c7:bc fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xd9d44000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: e2:cb:4e:0f:c7:bc fwe0: Ethernet address: e2:cb:4e:0f:c7:bc fwip0: on firewire0 fwip0: Firewire address: e0:cb:4e:00:00:0f:c7:bc @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ehci1: mem 0xf7d37000-0xf7d373ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf060-0xf07f mem 0xf7d36000-0xf7d367ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 ppc1: port 0x378-0x37f irq 5 on acpi0 ppc1: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc1 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 orm0: at iomem 0xce800-0xcf7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range ctl: CAM Target Layer loaded est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 Timecounters tick every 1.000 msec usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 uhub0: 8 ports with 8 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ugen1.2: at usbus1 uhub3: on usbus1 ugen2.2: at usbus2 uhub4: on usbus2 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered ugen1.3: at usbus1 uhub5: on usbus1 uhub5: 3 ports with 1 removable, bus powered ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 12861664 Hz quality 1000 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Root mount waiting for: usbus1 ugen1.4: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ugen1.5: at usbus1 ums0: on usbus1 ums0: 14 buttons and [XYZT] coordinates ID=2 ums0: 8 buttons and [XYZT] coordinates ID=5 Root mount waiting for: usbus1 ugen1.6: at usbus1 ukbd1: on usbus1 kbd3 at ukbd1 ums1: on usbus1 ums1: 5 buttons and [XYZT] coordinates ID=1 Trying to mount root from ufs:/dev/ada0p2 [rw]... em0: link state changed to UP oss_hdaudio: HDA codec 0x10ec0899 not known yet oss_hdaudio: HDA codec 0x80862806 not known yet oss_hdaudio: HDA codec 0x10ec0899 not known yet oss_hdaudio: HDA codec 0x80862806 not known yet oss_hdaudio: Too many output endpoints. Endpoint 8 ignored. oss_hdaudio: Too many output endpoints. Endpoint 0 ignored. oss_hdaudio: Too many output endpoints. Endpoint 1 ignored. oss_hdaudio: Too many output endpoints. Endpoint 2 ignored. oss_hdaudio: Too many output endpoints. Endpoint 3 ignored. oss_hdaudio: Too many output endpoints. Endpoint 4 ignored. oss_hdaudio: Too many output endpoints. Endpoint 5 ignored. oss_hdaudio: Too many output endpoints. Endpoint 6 ignored. oss_hdaudio: Too many output endpoints. Endpoint 7 ignored. oss_hdaudio: Too many output endpoints. Endpoint 8 ignored. oss_hdaudio0: mem 0xf7d30000-0xf7d33fff irq 22 at device 27.0 on pci0 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pciconf.out" hostb0@pci0:0:0:0: class=0x060000 card=0x20348086 chip=0x01508086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Ivy Bridge DRAM Controller' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x20348086 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Ivy Bridge Graphics Controller' class = display subclass = VGA xhci0@pci0:0:20:0: class=0x0c0330 card=0x20348086 chip=0x1e318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point USB xHCI Host Controller' class = serial bus subclass = USB none0@pci0:0:22:0: class=0x078000 card=0x20348086 chip=0x1e3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point MEI Controller' class = simple comms em0@pci0:0:25:0: class=0x020000 card=0x20348086 chip=0x15038086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82579V Gigabit Network Connection' class = network subclass = ethernet ehci0@pci0:0:26:0: class=0x0c0320 card=0x20348086 chip=0x1e2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point USB Enhanced Host Controller' class = serial bus subclass = USB oss_hdaudio0@pci0:0:27:0: class=0x040300 card=0x20348086 chip=0x1e208086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point High Definition Audio Controller' class = multimedia subclass = HDA pcib1@pci0:0:28:0: class=0x060400 card=0x20348086 chip=0x1e108086 rev=0xc4 hdr=0x01 vendor = 'Intel Corporation' device = 'Panther Point PCI Express Root Port 1' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:7: class=0x060400 card=0x20348086 chip=0x1e1e8086 rev=0xc4 hdr=0x01 vendor = 'Intel Corporation' device = 'Panther Point PCI Express Root Port 8' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x20348086 chip=0x1e268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point USB Enhanced Host Controller' class = serial bus subclass = USB isab0@pci0:0:31:0: class=0x060100 card=0x20348086 chip=0x1e4a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point LPC Controller' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x20348086 chip=0x1e028086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point 6 port SATA AHCI Controller' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x20348086 chip=0x1e228086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Panther Point SMBus Controller' class = serial bus subclass = SMBus fwohci0@pci0:2:0:0: class=0x0c0010 card=0x20348086 chip=0x34031106 rev=0x01 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT6315 Series Firewire Controller' class = serial bus subclass = FireWire --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xorg.conf" Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "ServerFlags" Option "AllowEmptyInput" "off" EndSection Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" Load "glx" Load "dri" Load "dri2" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "ShadowFB" # [] #Option "DefaultRefresh" # [] #Option "ModeSetClearScreen" # [] Identifier "Card0" Driver "vesa" VendorName "Intel Corporation" BoardName "3rd Gen Core processor Graphics Controller" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection --J2SCkAp4GZ/dPZZf-- From owner-freebsd-stable@FreeBSD.ORG Sat May 26 18:03:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1791065672 for ; Sat, 26 May 2012 18:03:55 +0000 (UTC) (envelope-from cn2i-solaire@e-mailink.fr) Received: from smtp.e-mailink.fr (smtp.e-mailink.fr [82.97.20.66]) by mx1.freebsd.org (Postfix) with ESMTP id 52A088FC0C for ; Sat, 26 May 2012 18:03:55 +0000 (UTC) Received: from smtp.e-mailink.fr (localhost [127.0.0.1]) by smtp.e-mailink.fr (Postfix) with ESMTP id 9613A1F64AE for ; Sat, 26 May 2012 19:32:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=e-mailink.fr; h= mime-version:content-type:content-transfer-encoding:date:to:from :reply-to:subject:message-id; s=smtp1; bh=neveGDaCH7scbTCFvNE0Yc 3cywI=; b=JZ7znz5VfJ5ktyoutaxNs0lR0igbJAWkK07f0dIADQgKmaCl7Nt6kO T2owq2rtyatNbFv2uYqhhoHbhdoE22e5w5JjKXvvi8RyUDOeAgUfii35PhhWm/Ml KaUFXvFW+Qio+dsgVLph6LPoHTyTqpcDiRw5nMFL1oJOW+lZ7iy64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=e-mailink.fr; h=mime-version :content-type:content-transfer-encoding:date:to:from:reply-to :subject:message-id; q=dns; s=smtp1; b=ZrBnfItasHOqI2yg+PnYet0Z+ YOOUVGfFkow4AEaPbuuUu8nPHBAt4HPsHLaB7UVtlf35WufS1Vm4OGj2riYYn3Hw 2gNjMMxkY30hELBejyV0PFbs2tLcDtr6Ekc1wwQFo+tDceEPLY4ACxoKDm0dvG9V GKV0iM5qiTnocDzjX0= Received: from [192.168.1.16] (AToulouse-754-1-17-120.w90-55.abo.wanadoo.fr [90.55.176.120]) by smtp.e-mailink.fr (Postfix) with ESMTPA id 481921F63C0 for ; Sat, 26 May 2012 19:32:58 +0200 (CEST) Content-Transfer-Encoding: quoted-printable Date: Sat, 26 May 2012 19:54:01 +0200 To: freebsd-stable@freebsd.org From: CN2i SOLAIRE 9% Rendement Sud FRANCE X-Emailink: Ref=Elk-5088150-14663 X-Mailer: eMailink 4 Message-Id: <20120526173258.481921F63C0@smtp.e-mailink.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: INVESTISSEMENT SOLAIRE 9% Securite EDF et REVENTE a 6 ans MP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cn2i@live.fr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 18:03:55 -0000 Pour afficher correctem= ent la page [1]Cliquez-ici Pour = Devenir Partenaire [2]Cliq= uez-ici [3]3D"PV4_NEWSLETTER_SOLAIRE_PV4_CAVAILLON_CN2i_DEVELOPPEMENT_MARS_20= Pour Dev= enir Partenaire [4]Cliq= uez-ici Michael FRAYSSE =AB&n= bsp;Direction =BB CN2i DEVELOPPEMENT Site Web : [5]www.cn2i.fr &n= bsp; &nb= sp; Skype :=A0michael.frayss= e Accueil : 05 . 61 . 214 . 942 = ; Mobile de Permanence : 06 . 60 . 168 . 528 Fax =AB Back Office =BB : = ; 08 . 21 . 896 . 859 _____________________________________________________________________ = ______ =A9CN2i D=E9veloppement =AB Promoteur National en Investissement Photovolta=EFque =BB =AB Plate-forme de Commercialisation Centrales Solaires Photovolta=EFq= ues =BB Rcs : 502 083 652 .NAF : 66 19 B Capital Social : 50.000 =80 = &nb= sp; = &nb= sp; Si=E8ge Social : 10 Ter Avenue des PYRENEES 31120 LACROIX FALGARDE ______________________________________________________________________ _____= Michael Tv Piano YouTube : [6]http://www.youtube.com/user/MichaelMusicPiano/videos Michael Tv Piano Dailymotion : [7]http://www.dailymotion.com/Michael_Fraysse?fbc=3D503 [8]DESINSCRIPTION : CLIQUEZ-ICI = References 1. 3D"http://www.cn2i.fr/NEWSLETTER/PV4_NEWSLETTER_SOLAIRE_PV4_CAVAILL= 2. 3D"http://www.cn2i.fr/devenir_partenaire.php" 3. 3D"http://www.cn2i.fr/Projet-d-Investissement-Centrale-Photovoltaiq= 4. 3D"http://www.cn2i.fr/devenir_partenaire.php" 5. 3D"http://www.cn2i.fr"/ 6. 3D"http://www.youtube.com/user/MichaelMusicPiano/videos" 7. 3D"http://www.dailymotion.com/Michael_Fraysse?fbc=3D503" 8. 3D"mailto:desabo-solaire@e-mailink.fr?Subject=3DRef_Desabo=3DElk-50= From owner-freebsd-stable@FreeBSD.ORG Sat May 26 20:24:37 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D4C10656D2 for ; Sat, 26 May 2012 20:24:37 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50ADD8FC16 for ; Sat, 26 May 2012 20:24:37 +0000 (UTC) Received: by ggnm2 with SMTP id m2so1719748ggn.13 for ; Sat, 26 May 2012 13:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=iIy4UZZUSYD4lqMk2HlGwYd3gpmDVPpSjuVEifa1UzI=; b=gzpxE54WpH2Sc1sxhZ0m7k43fEzpkjRoJJriaidVun+f/E5+V4azeYdwRvgGlJp/yj VLPc5dW4coeuzykpI1WZmhDOeKuWUgM/S66TM7uH/Av5rBNQSR1ysI0F5r2yJCi035nh S94ZA4KS2rMtEeHb3YndqO2/MXzmRiUErdT+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-gm-message-state; bh=iIy4UZZUSYD4lqMk2HlGwYd3gpmDVPpSjuVEifa1UzI=; b=B6xhfF63cDxcXb90RnQ1CIk8N/nypHGxWhr3CXWUvFmzkhQ1RM8HPJyoz0n4EYGzkL RmJLvMbuG+B1ea+COOkI9p/kPhtNR6pMH08Q3+D75RQiZAGypbDPF0z8YQOQPU5A2uwc uCmXll6wYSzNSMJSvCMV5Vz83bdY1lg0Kx23DkRvM8rzYVaYBI4bEltv9vyW76Dfn67l 8oju8YcqvWRRw62mCNBCuMyDpamwi0SERFti8IXnGsK6ubx2e7A9iTlcVXdziUR8FDSo izj2SCp4q0tzfOOpMdt9ZAMaMS8aQfIKkyJBCCDLSPZ4gGAqTkUvZVxpcP9C8wGDS+pV QSzg== Received: by 10.43.49.3 with SMTP id uy3mr1774138icb.2.1338063876455; Sat, 26 May 2012 13:24:36 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id gh2sm3787223igb.9.2012.05.26.13.24.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 13:24:35 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4QKOXjI001532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 May 2012 16:24:33 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4QKOXDt001531 for stable@freebsd.org; Sat, 26 May 2012 16:24:33 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 26 May 2012 16:24:32 -0400 From: Jason Hellenthal To: stable@freebsd.org Message-ID: <20120526202432.GA265@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Gm-Message-State: ALoCoQlrvdxgdG6UZ0Y32dGbgX9UEp7sw5rETGtS7wbFeP/j8VBbtnFx7a3BNqMfX9x/UY3zOqCg Cc: Subject: /usr/bin/unzip not being installed on 8.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 20:24:37 -0000 I have just noticed the following depicting unzip not being updated/installed during a make installworld. The last binary before this test that caught my attention was from Apr 15, in which I cd(1) into unzip's source directory and did a make && everything neccesary to install it. After running a make installworld once again I see that it seems not connected to the install target somehow. Could someone look into this when they get a chance ? Install world happened here: May 26 16:11 ls -l /usr/bin [...] -r-xr-xr-x 1 root wheel 10168 May 26 16:11 uniq -r-xr-xr-x 1 root wheel 11952 May 26 16:11 units -r-xr-xr-x 6 root wheel 56796 May 26 16:11 unlzma -r-xr-xr-x 1 root wheel 5016 May 26 16:11 unvis -r-xr-xr-x 6 root wheel 56796 May 26 16:11 unxz -r-xr-xr-x 1 root wheel 15504 May 26 02:54 unzip -r-xr-xr-x 2 root wheel 14840 May 26 16:11 uptime -r-xr-xr-x 1 root wheel 14384 May 26 16:11 usbhidaction -r-xr-xr-x 1 root wheel 14344 May 26 16:11 usbhidctl [...] This is on FreeBSD 8.3-STABLE r236003M i386 Thanks -- - (2^(N-1)) From owner-freebsd-stable@FreeBSD.ORG Sat May 26 20:38:15 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D41106566C for ; Sat, 26 May 2012 20:38:15 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2510C8FC15 for ; Sat, 26 May 2012 20:38:14 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0AFDD37B57F; Sat, 26 May 2012 15:31:29 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 65DCF1770A; Sat, 26 May 2012 15:31:28 -0500 (CDT) Date: Sat, 26 May 2012 15:31:28 -0500 From: "Matthew D. Fuller" To: Jason Hellenthal Message-ID: <20120526203128.GA43402@over-yonder.net> References: <20120526202432.GA265@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120526202432.GA265@DataIX.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.4 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: stable@freebsd.org Subject: Re: /usr/bin/unzip not being installed on 8.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 20:38:15 -0000 On Sat, May 26, 2012 at 04:24:32PM -0400 I heard the voice of Jason Hellenthal, and lo! it spake thus: > > I have just noticed the following depicting unzip not being > updated/installed during a make installworld. >From a quick look at history, unzip was never connected to the build in 8.x, only 9.x+ (r200068, Dec 2009). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Sat May 26 20:39:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CF8B106566C for ; Sat, 26 May 2012 20:39:45 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 302D68FC23 for ; Sat, 26 May 2012 20:39:45 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4049821obc.13 for ; Sat, 26 May 2012 13:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=XKE260Y76Oxb4geB6NDVZanLHLBJHRXG4LGPiJsYv2Y=; b=Q1u8MDP1yo0flcDiwXoTD+Bnc/mnP37LAtMpq5q8D6p3Y9mOVHHupPixOI5Rpbb0wb yTMzQKro+BfGGa4N77Y/Qj1K4rX34mxHWHwR8dxzd8Y/cgy4/j/Zs4UIoxT2mC10a6k7 Ylr7UJ3ugvwHSE8f23Xp0BeToBFPeUsu9xeo0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=XKE260Y76Oxb4geB6NDVZanLHLBJHRXG4LGPiJsYv2Y=; b=IY2Byzqt0QaPNAgRUKkCBpkE23Uf2rmoBHU6XVvP/9dCeQsZMBJE+G9LG5X7a+JH2x ZKTLYTRwkXDyX/tVgKxiZgLYzX7yxqI5WHkip3BiNTD15rvP14BUZFKI/FamFFahECeZ KB5hP1V3H3+Az4NQHb6XeBQwcpMYLLH8ydeTyvNsnt7RW7QTPjnJnMCa0EW+zymB6yM0 rAaYFnFxfmxDwoO1Y2nhAMOw8jzvQndK8X3SnP3pB6EXzp2TnJdCO2+NS2N/olQ+121Z y/rWhCPUNPLAsK9hO4L6p6Ex81Se9Oh8KZxw+A9KSSFxvfKOHBF2YaIahXRsCX6WqleP 9QCw== Received: by 10.50.94.166 with SMTP id dd6mr1546495igb.11.1338064784491; Sat, 26 May 2012 13:39:44 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id vi7sm2106779igb.1.2012.05.26.13.39.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 13:39:44 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4QKdfsF005626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 May 2012 16:39:41 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4QKdewb005625; Sat, 26 May 2012 16:39:40 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 26 May 2012 16:39:40 -0400 From: Jason Hellenthal To: "Matthew D. Fuller" Message-ID: <20120526203940.GA3721@DataIX.net> References: <20120526202432.GA265@DataIX.net> <20120526203128.GA43402@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120526203128.GA43402@over-yonder.net> X-Gm-Message-State: ALoCoQny17l+LS8pHAqoxXJ2u/pQSN8ox76WzwhkU8Udl+1VUKXTpkwyp2AxbhI/16bHByA7hx5y Cc: stable@freebsd.org Subject: Re: /usr/bin/unzip not being installed on 8.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 20:39:45 -0000 On Sat, May 26, 2012 at 03:31:28PM -0500, Matthew D. Fuller wrote: > On Sat, May 26, 2012 at 04:24:32PM -0400 I heard the voice of > Jason Hellenthal, and lo! it spake thus: > > > > I have just noticed the following depicting unzip not being > > updated/installed during a make installworld. > > >From a quick look at history, unzip was never connected to the build > in 8.x, only 9.x+ (r200068, Dec 2009). > Funny... so there are probably alot of machines running around with old unzip binaries... including the already packaged releases. > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. -- - (2^(N-1)) From owner-freebsd-stable@FreeBSD.ORG Sat May 26 20:41:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C18F81065675 for ; Sat, 26 May 2012 20:41:56 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 94EFE8FC08 for ; Sat, 26 May 2012 20:41:56 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0E6A937B4E5; Sat, 26 May 2012 15:41:56 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7C8B417746; Sat, 26 May 2012 15:41:55 -0500 (CDT) Date: Sat, 26 May 2012 15:41:55 -0500 From: "Matthew D. Fuller" To: Jason Hellenthal Message-ID: <20120526204155.GB43402@over-yonder.net> References: <20120526202432.GA265@DataIX.net> <20120526203128.GA43402@over-yonder.net> <20120526203940.GA3721@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120526203940.GA3721@DataIX.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.4 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: stable@freebsd.org Subject: Re: /usr/bin/unzip not being installed on 8.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 20:41:56 -0000 On Sat, May 26, 2012 at 04:39:40PM -0400 I heard the voice of Jason Hellenthal, and lo! it spake thus: > > Funny... so there are probably alot of machines running around with > old unzip binaries... including the already packaged releases. No, they wouldn't have _any_ unzip binaries. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Sat May 26 20:55:26 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8569B106566B for ; Sat, 26 May 2012 20:55:26 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 375A28FC14 for ; Sat, 26 May 2012 20:55:26 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4069030obc.13 for ; Sat, 26 May 2012 13:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=lOTujiL+/ByFU8SwGcg1kD4yTjS0BHzN8RiF6GAr0So=; b=B2OXVB72gpRN+ZK0NamK+WNz3acNnkrLTmOj2BkcLK9CS7R5mRtkTwilTpCYSb/rpQ fEGxFEJxTJ4p/Q1wgYdt74IfyO33ziACCRAuERyHuhnB86qqqOUdjPCPSyJ3oJfPM31B v5r/EqvmoluZDLZQzDthM4mn4qOYdV/6zmikM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=lOTujiL+/ByFU8SwGcg1kD4yTjS0BHzN8RiF6GAr0So=; b=RCNvyBWUq26wLF2luBJFPWOI2Icb6euodn4+bewc9xWF4+uPfIqlg0AYsAv4K3Y3Eh FOs9DxiR4YCRzq3Kz4qvpAeXfZDIVc/wsJVAdIla1RlM/fx9TmnkdN2IeYI5dP/N2fSj 3ich6TqNVEd9BXIfEnCFRoyXibJslF7NtcJXW+0FPk0X+hoRQHjhDNSFSPbI7BHoyRrW FT5h5DU/PQ/BnN1dburCWE/XstHR+sP1OJq9Zs5QWivDINwu3S/bmobi5nYUVelJgEK2 /8W3SWM4JkGMzcZDUC5FuIgYAELeE1sA49D0RJ7X4VuYX6sMxiufX2kdUdYc1zofL6uS K6AQ== Received: by 10.50.186.129 with SMTP id fk1mr1527601igc.73.1338065725729; Sat, 26 May 2012 13:55:25 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id b16sm1879016igp.3.2012.05.26.13.55.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 13:55:25 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4QKtN6l011299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 May 2012 16:55:23 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4QKtNVY011298; Sat, 26 May 2012 16:55:23 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 26 May 2012 16:55:23 -0400 From: Jason Hellenthal To: "Matthew D. Fuller" Message-ID: <20120526205523.GA10366@DataIX.net> References: <20120526202432.GA265@DataIX.net> <20120526203128.GA43402@over-yonder.net> <20120526203940.GA3721@DataIX.net> <20120526204155.GB43402@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120526204155.GB43402@over-yonder.net> X-Gm-Message-State: ALoCoQk5iohDnTanHK8BfRcH4dkz/rc9P05fwTM8QwKj/3d/U9bt8ugKAQ9CAZwwFCruFjBBM2bc Cc: stable@freebsd.org Subject: Re: /usr/bin/unzip not being installed on 8.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 20:55:26 -0000 On Sat, May 26, 2012 at 03:41:55PM -0500, Matthew D. Fuller wrote: > On Sat, May 26, 2012 at 04:39:40PM -0400 I heard the voice of > Jason Hellenthal, and lo! it spake thus: > > > > Funny... so there are probably alot of machines running around with > > old unzip binaries... including the already packaged releases. > > No, they wouldn't have _any_ unzip binaries. > Absolutely. From: FreeBSD-8.2-RELEASE-i386-livefs.iso Console# pwd ;ls usr/bin/ |grep unzip /mnt/cd9660 bunzip2 gunzip Silly -- - (2^(N-1))