From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 00:44:54 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1288EA7; Sun, 16 Dec 2012 00:44:54 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D24928FC13; Sun, 16 Dec 2012 00:44:54 +0000 (UTC) Received: from [10.0.1.102] (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 21F021A3C1B; Sat, 15 Dec 2012 16:44:54 -0800 (PST) References: <20121215132246.GH69724@acme.spoerlein.net> <20121215210746.GI69724@acme.spoerlein.net> <20121215211634.GJ69724@acme.spoerlein.net> Mime-Version: 1.0 (1.0) In-Reply-To: <20121215211634.GJ69724@acme.spoerlein.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Alfred Perlstein Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Date: Sat, 15 Dec 2012 16:44:52 -0800 To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= Cc: "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 00:44:55 -0000 On Dec 15, 2012, at 1:16 PM, Ulrich Sp=C3=B6rlein wrote: >=20 > Ok, scrap that, I have too many copies of the conversion lying around > and got confused. >=20 > I'd like to thank all who reported in with hashes of their conversion > run and will make sure all is solid tomorrow. >=20 Thanks. I am wondering will the new repo include svn revision numbers in the= git commit logs? Thank you.=20 -Alfred=20= From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 02:02:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19E33E2D; Sun, 16 Dec 2012 02:02:04 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id C5D778FC16; Sun, 16 Dec 2012 02:02:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=1WDWBwUE0XL0s7s+U61K4zTdjO1OBE33CdLBuQDAU9Q=; b=qxnyuAsTySrtdMRXvaVLGaNCyrZityfHpB8UbELzVBgs8BuhKUYbMHSDTyfuepFJXWJXsOOMOpMLe2NHZfzlwP4lIwMivR5tgnCYxy70W8gWW2oI2M+b1KccWbL8hwN/; Received: from [122.129.203.50] (port=59314 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tk3YC-0009lI-9e; Sat, 15 Dec 2012 19:01:56 -0700 Date: Sun, 16 Dec 2012 09:01:52 +0700 From: Erich Dollansky To: Eitan Adler Subject: Re: looking for help from ppp users Message-ID: <20121216090152.3b223049@X220.ovitrap.com> In-Reply-To: References: <20121203154154.GA20011@in-addr.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Gary Palmer , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 02:02:04 -0000 Hi, On Sat, 15 Dec 2012 01:14:10 -0500 Eitan Adler wrote: > On 3 December 2012 10:41, Gary Palmer wrote: > > While not commenting on the correctness of the current contents, > > the userland PPP section of the FAQ appears to mostly deal with > > dialup modems. I suspect more people use it now to do PPPoA or > > PPPoE for some form of DSL link and there probably needs to be some > > effort to address the differences. > > I've never used PPP in any sense. Any chance I could enlist you to > help write some content? I could turn it into docbook, edit it, etc. > > > let me share my experience with ppp and one CDMA 'modem' we have to use in Indonesia. First, what makes it work in ppp.conf: set device /dev/cuaU0.0 set ctsrts off set login set dial set authname internet@ceria set authkey ceria set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns # set dns servers in resolv.conf nat enable yes nat deny_incoming yes set phone #777 The fun starts with the first start and after each restart of the modem after the battery went empty. It simply does not work after above's commands are entered manually one by one. There is no useful error message except that the modem either sends the wrong authentication information to the server or something else makes it drop the connection after this information is sent when doing it via the script. If I manually enter these commands, it works from the start. Of course, this is a problem caused by the modem but mentioning this in the handbook could help others in this strange situation. Erich From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 04:32:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10684FD2; Sun, 16 Dec 2012 04:32:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 522E48FC12; Sun, 16 Dec 2012 04:32:51 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so5923112vba.13 for ; Sat, 15 Dec 2012 20:32:50 -0800 (PST) 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=VoOmzxyPfJSnPI4/w+TqWDHna8nvL6EiJrAqBOdESJg=; b=axqsLY8Q74+BQZJB+qou/QvBpa7+v2fHXWxk3oGKW0XpIFtwt/qTorn9ghz2wSsWlp d6AMam7vOTHoY16w/d0iDo1x+tMxu5qq75U12AJOmYrHvmYlrLMww8gcWyPhye1hBJtr TkDoVMdqBLa4agi4Gd76UG2p/ffv4kjkkk1RAlIeAi5TfGryoFaUb5Re747bIsugfQ/U TUB1Cakl+KHejD6gYxfI6VaR/wIqpDC+QDzg7Bw0c0kutr6GYezO5YiCezO2P8pcEj2O GNMXaFFj9c7K9IMCM2oe72ZbT4iZiiTc3b2hVy9I1oB2A6wMI4042Bo19Jz4dIFfBPQv kbzg== MIME-Version: 1.0 Received: by 10.220.115.19 with SMTP id g19mr16946618vcq.69.1355632370225; Sat, 15 Dec 2012 20:32:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.201.202 with HTTP; Sat, 15 Dec 2012 20:32:50 -0800 (PST) In-Reply-To: <50CB5DEF.8030503@gmail.com> References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> Date: Sat, 15 Dec 2012 20:32:50 -0800 X-Google-Sender-Auth: aP1mjUbRjU_sIUEDm8a9yMJp-z0 Message-ID: Subject: Re: Lenovo x220 suspend/resume broken From: Adrian Chadd To: matt , freebsd-mobile@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Ganael LAPLANCHE , jkim@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 04:32:52 -0000 Hi, jkim - is there any negative side-effect from reverting r231797 ? Did this fix a bug you saw on another platform? I have the same symptom on my T400, unfortunately it's in the office and I can't get to it right now to test. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 09:44:46 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44C427BC for ; Sun, 16 Dec 2012 09:44:46 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6FA28FC12 for ; Sun, 16 Dec 2012 09:44:45 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qBG9ihvt005211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 10:44:44 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sun, 16 Dec 2012 10:44:43 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alfred Perlstein Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20121216094443.GK69724@acme.spoerlein.net> Mail-Followup-To: Alfred Perlstein , "current@FreeBSD.org" References: <20121215132246.GH69724@acme.spoerlein.net> <20121215210746.GI69724@acme.spoerlein.net> <20121215211634.GJ69724@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 09:44:46 -0000 On Sat, 2012-12-15 at 16:44:52 -0800, Alfred Perlstein wrote: > > > On Dec 15, 2012, at 1:16 PM, Ulrich Spörlein wrote: > > > > Ok, scrap that, I have too many copies of the conversion lying around > > and got confused. > > > > I'd like to thank all who reported in with hashes of their conversion > > run and will make sure all is solid tomorrow. > > > > Thanks. I am wondering will the new repo include svn revision numbers in the git commit logs? > > Thank you. Not in the logs, they are stored in git notes. If you don't have em, run the following: git config add remote.origin.fetch '+refs/notes/*:refs/notes/*' git fetch The git log will then produce output like this: commit c3c1c81918dd701cfecb370f591746bacc907e4d Author: rwatson Date: Sat Dec 15 15:21:09 2012 +0000 Four .c files from OpenBSM are used, in modified form, by the kernel to implement the BSM audit trail format. Rename the kernel versions of the files to match the userspace filenames so that it's easier to work out what they correspond to, and therefore ensure they are kept in-sync. Obtained from: TrustedBSD Project Notes: svn path=/head/; revision=244267 You can search for a specific revision like this: % git log --grep="revision=234567" commit 0264d1ea29a4b35914a658ab01ece38e3637f84f Author: delphij Date: Sun Apr 22 07:51:49 2012 +0000 - Use quote when tab is used; - Follow the same macros used in device driver manual pages. Notes: svn path=/head/; revision=234567 hth Uli From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 07:14:18 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 017C5BF8; Sun, 16 Dec 2012 07:14:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 865DD8FC17; Sun, 16 Dec 2012 07:14:17 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBG7E7jR006811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Dec 2012 18:14:09 +1100 Date: Sun, 16 Dec 2012 18:14:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Cooper Subject: Re: [RFC/RFT] calloutng In-Reply-To: <35705A81-690A-4993-B0C3-C8BC0BC89C67@gmail.com> Message-ID: <20121216175614.V1027@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> <35705A81-690A-4993-B0C3-C8BC0BC89C67@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zvi1sKHG c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=6I5d2MoRAAAA:8 a=QqY8FBgQtirPoTa2VqoA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Sun, 16 Dec 2012 12:28:25 +0000 Cc: Davide Italiano , freebsd-arch@FreeBSD.org, Alexander Motin , FreeBSD Current , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:14:18 -0000 On Sat, 15 Dec 2012, Garrett Cooper wrote: > On Dec 15, 2012, at 12:34 PM, Mark Johnston wrote: > >> On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: >>> Hi. >>> >>> I'm sorry to interrupt review, but as usual good ideas came during the >>> final testing, causing another round. :) Here is updated patch for >>> HEAD, that includes several new changes: >>> http://people.freebsd.org/~mav/calloutng_12_15.patch >> >> This patch breaks the libprocstat build. >> >> Specifically, the OpenSolaris sys/time.h defines the preprocessor >> symbols gethrestime and gethrestime_sec. These symbols are also defined >> in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. >> libprocstat:zfs.c is compiled using include paths that pick up the >> OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. >> >> zfs.c includes taskqueue.h (with _KERNEL defined), which includes >> _callout.h, so both time.h and zfs_context.h are included in zfs.c, and >> the symbols are thus defined twice. Gross namespace pollution. sys/_callout.h exists so that the full namespace pollution of sys/callout.h doesn't get included nested. But sys/time.h is much more polluted than sys/callout.h. However, sys/time.h is old standard pollution in sys/param.h, and sys/callout.h is not so old standard pollution in sys/systm.h. It is a bug to not include sys/param.h and sys/systm.h in most kernel source code, so these nested includes are just style bugs -- they have no effect for correct kernel source code. >> The patch below fixes the build for me. Another approach might be to >> include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. Good if it works. > I had a patch open once upon a time to cleanup inclusion of sys/time.h all over the tree and deal with the sys/time.h <-> time.h pollution issue, but it got dropped due to lack of interest (20~30 apps/libs were affected IIRC and I only really got assistance in fixing the UFS and bsnmpd pieces, and gave up due to lack of response from maintainers). dtrace/zfs is a definite instigator in this pollution (I remember nasty cddl/... pollution with the compat sys/time.h header). Please use the unix newline character in mail. The above is difficult to quote. The standard sys/time.h pollution in sys/param.h is only in the kernel, and there aren't many direct includes of sys/time.h in the kernel. Userland is different and many of the direct includes were correct. But not POSIX specifies that struct timespec and struct timeval be defined in most places where they are needed, so the includes of sys/time.h are not necessary for POSIX or FreeBSD, although FreeBSD man pages still say that they are necessary. The sys/time.h <-> time.h pollution issue is also only for userland. Many places depend on one including the other, and include the wrong one themself. > Bottom line: make sure anything new you're defining isn't already defined via POSIX or other OSes, and if so please try to make the implementations match (so that eventual POSIX inclusion might be possible) and when in doubt I suggest consulting standards@ / brde@. Bruce From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 19:51:22 2012 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EFB7138 for ; Sun, 16 Dec 2012 19:51:22 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E40C08FC12 for ; Sun, 16 Dec 2012 19:51:18 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so2057581eaa.13 for ; Sun, 16 Dec 2012 11:51:17 -0800 (PST) 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=MrShxaoIedkjVUMVoDNY1s+qYTdMqac8gv3ZlxC/a/s=; b=nuIn0WXpzqra19j9QB3o501UF69s6PTi+5Etw2hopNMo7tSEx3H0Gkep2nKMw8ihUq YEmj4XLVpQEuBg1RlGY/nESuLCA/A8D6B6Q6oEeeL6skWl81/VbO3TROK3cYPehEHi2e K6r/rQNOXygXWOe1VIg77dy0XD2J3yNIDZgDXcO+8W+VzI4JJjLYGnpHN0iFrAp+kiZ6 FQmGz7H7HytDoeFA3dZA4ggRPDFZEORRwL1Gds+RumFwM9OuhjrwZVFRJkGNxC/OFOs/ V13Pheq40EJAZKvcNJu+ymWn44yX7E8awN2qea4XtXxuyhV4nsqXYEd8NIGW0VqBFL+4 njJQ== MIME-Version: 1.0 Received: by 10.14.215.6 with SMTP id d6mr34405872eep.40.1355687477064; Sun, 16 Dec 2012 11:51:17 -0800 (PST) Received: by 10.14.4.68 with HTTP; Sun, 16 Dec 2012 11:51:16 -0800 (PST) Date: Sun, 16 Dec 2012 14:51:16 -0500 Message-ID: Subject: Clang/LLVM revision 169451 From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 19:51:22 -0000 hello list, I like to run FreeBSD HEAD on my workstation, I am wondering if a easy way exists to follow LLVM HEAD in FreeBSD HEAD? I am in need of this patch http://llvm.org/viewvc/llvm-project?view=rev&revision=169451 to specifically fix http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174459 im not sure how it works, but does someone have a merge script that basically puts LLVM HEAD into FreeBSD HEAD? looking for some tips -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 20:25:17 2012 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D22A908 for ; Sun, 16 Dec 2012 20:25:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB9FA8FC13 for ; Sun, 16 Dec 2012 20:25:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c062:9144:f85e:eefe] (unknown [IPv6:2001:7b8:3a7:0:c062:9144:f85e:eefe]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 544FB5C5A; Sun, 16 Dec 2012 21:25:15 +0100 (CET) Message-ID: <50CE2E29.4030906@FreeBSD.org> Date: Sun, 16 Dec 2012 21:25:13 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "Sam Fourman Jr." Subject: Re: Clang/LLVM revision 169451 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 20:25:17 -0000 On 2012-12-16 20:51, Sam Fourman Jr. wrote: > I like to run FreeBSD HEAD on my workstation, > > I am wondering if a easy way exists to follow LLVM HEAD in FreeBSD HEAD? > I am in need of this patch > http://llvm.org/viewvc/llvm-project?view=rev&revision=169451 > to specifically fix http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174459 Is there any reason you cannot apply the patch locally to your tree for now? > im not sure how it works, but does someone have a merge script that > basically puts LLVM HEAD into FreeBSD HEAD? No, there is no one-click merge script, it needs humanoid help, I'm afraid. :-) Is there any reason you cannot just install the port, or if that is too outdated, just checkout from llvm.org directly and build it? From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 22:17:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31EA690F; Sun, 16 Dec 2012 22:17:56 +0000 (UTC) (envelope-from stolpe@resilans.se) Received: from server.resilans.se (ns1.resilans.se [IPv6:2a01:280:1::53]) by mx1.freebsd.org (Postfix) with ESMTP id B2EF68FC13; Sun, 16 Dec 2012 22:17:55 +0000 (UTC) Received: from server.resilans.se (server.resilans.se [194.14.3.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.resilans.se (Postfix) with ESMTPS id 3FCC12E4001; Sun, 16 Dec 2012 23:17:54 +0100 (CET) Date: Sun, 16 Dec 2012 23:17:53 +0100 (CET) From: Daniel Stolpe To: Adrian Chadd Subject: Re: Lenovo x220 suspend/resume broken In-Reply-To: Message-ID: References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: matt , freebsd-current@freebsd.org, Ganael LAPLANCHE , jkim@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:17:56 -0000 I have run 10.0-current on a X121e for about a year (in order to get graphics working) and the plan was to go to 9.1-release as soon as it was out. I was rather surprised to find that the screen did not wake up on resume. It would be very nice to have resume working again. On Sat, 15 Dec 2012, Adrian Chadd wrote: > Hi, > > jkim - is there any negative side-effect from reverting r231797 ? Did > this fix a bug you saw on another platform? > > I have the same symptom on my T400, unfortunately it's in the office > and I can't get to it right now to test. > > Thanks, > > > > Adrian > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > > Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 22:28:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 822D1AF2; Sun, 16 Dec 2012 22:28:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8591A8FC0A; Sun, 16 Dec 2012 22:28:12 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2265813wgh.31 for ; Sun, 16 Dec 2012 14:28:11 -0800 (PST) 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=DCt9E9eOhj6l6E8/A5r9HIX3CmCYug3o9fRrMiyzFck=; b=NUo28WxSo8g/S6OPhfNz2CDDiq6Y6N7c3Jhl9m+nb68+V/jvCgVNyGPGYJZzfVna58 EVpmfPKsL4NCVXG9Vtb2h3DOWDWx+07ehdjkCvA6rJmw3t5NAf5wfxF1orn41QYCjd1I OGtE04Tuv/XBvc5YfWZDBonitxq4LzsG851/srtY50tbtjXl3EtnqyIbDRlUqmpDFlrC ZvqMs3JEFCwohDO8b2oMSQPJ6R7lqcXDFD/z9djLJuNGNWk5o76WQfQSq34aHWd5Ga6q 83aFpzWWOfBrKkuMBKViGT7lcyTkkhFyjB2GvZdjPI+Ix9k9g38Nfvxfslzy/I/F02wq 6DJQ== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr13789933wjc.1.1355696891705; Sun, 16 Dec 2012 14:28:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 16 Dec 2012 14:28:11 -0800 (PST) In-Reply-To: References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> Date: Sun, 16 Dec 2012 14:28:11 -0800 X-Google-Sender-Auth: BV06CFgTkmty0KdbYUg2G6JJufk Message-ID: Subject: Re: Lenovo x220 suspend/resume broken From: Adrian Chadd To: Daniel Stolpe Content-Type: text/plain; charset=ISO-8859-1 Cc: matt , freebsd-current@freebsd.org, Ganael LAPLANCHE , jkim@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:28:15 -0000 Hi, have you filed a PR about this? There shouldn't be any reason why it works on 10-current but not 9.1-release. If that's the case, I'm hopeful that jkim and the syscons peeps can figure out what's going on. Thanks, adrian On 16 December 2012 14:17, Daniel Stolpe wrote: > > I have run 10.0-current on a X121e for about a year (in order to get > graphics working) and the plan was to go to 9.1-release as soon as it was > out. > > I was rather surprised to find that the screen did not wake up on resume. > > It would be very nice to have resume working again. > > > On Sat, 15 Dec 2012, Adrian Chadd wrote: > >> Hi, >> >> jkim - is there any negative side-effect from reverting r231797 ? Did >> this fix a bug you saw on another platform? >> >> I have the same symptom on my T400, unfortunately it's in the office >> and I can't get to it right now to test. >> >> Thanks, >> >> >> >> Adrian >> _______________________________________________ >> freebsd-mobile@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile >> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" >> >> > > Best Regards, > > Daniel Stolpe > > _________________________________________________________________________________ > Daniel Stolpe Tel: 08 - 688 11 81 > stolpe@resilans.se > Resilans AB Fax: 08 - 55 00 21 63 > http://www.resilans.se/ > Box 13 054 > 556741-1193 > 103 02 Stockholm > From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 22:42:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 153A3DCA; Sun, 16 Dec 2012 22:42:22 +0000 (UTC) (envelope-from yanegomi@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 B44D68FC12; Sun, 16 Dec 2012 22:42:21 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so3131562pbc.13 for ; Sun, 16 Dec 2012 14:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=7nOFS8HINPSOupp9/bM1cSUZaX7VqqWFWxbv1IbMb7g=; b=gFW1r5QoPVCd5JhBG4H5i0yMlx6N/+hH4ZVTXfD6mgIMv2zA+3iedPjZBgv+o7/O4v jPsEuG2NsfqRlYU/PpW0j62j4zcXIKDl13xgYPMk9MYeR2YtD2HYx264aAw7gdIu32Q5 ZlFBbiIz3JHCRD7r8LH+f4dFsbfkOURYp0is8Ahvo3h12tRXlDN9BOxDEV1+DH4PrAlF WP2+wA3KYZQ8gu6UT6gPSmur03iRHsvi/mSAry4mFVsdxv+Mz8Qzr7qvkJjg9p3de8Ac 3U1UuuPVMlTKVDNMjUtNzG1YNecTR1c62ALMkJLyxACV+nqsIeFUKpJWIgddYDk8wMD+ QVqQ== Received: by 10.66.52.79 with SMTP id r15mr36903033pao.46.1355697741204; Sun, 16 Dec 2012 14:42:21 -0800 (PST) Received: from [10.143.75.51] (mobile-166-147-095-092.mycingular.net. [166.147.95.92]) by mx.google.com with ESMTPS id wr4sm6968885pbc.72.2012.12.16.14.42.19 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 14:42:20 -0800 (PST) References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8608A766-72F2-423D-BD88-247CBE3724ED@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: Lenovo x220 suspend/resume broken Date: Sun, 16 Dec 2012 14:42:14 -0800 To: Adrian Chadd Cc: matt , "freebsd-mobile@freebsd.org" , "freebsd-current@freebsd.org" , Daniel Stolpe , Ganael LAPLANCHE , "jkim@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:42:22 -0000 On Dec 16, 2012, at 2:28 PM, Adrian Chadd wrote: > Hi, >=20 > have you filed a PR about this? >=20 > There shouldn't be any reason why it works on 10-current but not > 9.1-release. If that's the case, I'm hopeful that jkim and the syscons > peeps can figure out what's going on. >=20 > Thanks, >=20 >=20 > adrian >=20 >=20 > On 16 December 2012 14:17, Daniel Stolpe wrote: >>=20 >> I have run 10.0-current on a X121e for about a year (in order to get >> graphics working) and the plan was to go to 9.1-release as soon as it was= >> out. >>=20 >> I was rather surprised to find that the screen did not wake up on resume.= >>=20 >> It would be very nice to have resume working again. >>=20 >>=20 >> On Sat, 15 Dec 2012, Adrian Chadd wrote: >>=20 >>> Hi, >>>=20 >>> jkim - is there any negative side-effect from reverting r231797 ? Did >>> this fix a bug you saw on another platform? >>>=20 >>> I have the same symptom on my T400, unfortunately it's in the office >>> and I can't get to it right now to test. Can't speak for your lenovos, but my netbook has been working like a champ o= n i386 with smp since it was fixed. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 22:44:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53561C5; Sun, 16 Dec 2012 22:44:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id F3BE88FC1A; Sun, 16 Dec 2012 22:44:22 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so3175473pad.13 for ; Sun, 16 Dec 2012 14:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=TEFeH7vYJxIwr9MMPSXArlY8SI1BXn4KaTD3rPAA1Q0=; b=lUn6eXdvC9fYBkMJWwQymq67f/N8EQFVrUPNaqq3U2CalPmmeJ3rmcqU4uXz6n8dN5 ChQo/qbG7Qg15Vad2J8748AmWhvyn14GMHncigmnfA6muiLK0rZHbujS5PupAUh1S5gg ZbrGNrHoeaD9xCEXBT6TnTMFg96MgZBgQeTYyvhi1p0Smslur6HQWWJIBKMoev8U2Xhb MPHrICkPTKWwsp/y4YLZqj0TzD16RN8ODxA5JmrNAyDSC8WWPE19K1WXNlqmLPWcVIX2 MCPmWLXm2bjctoJDo/mebYtZ+fFqiICcY4o9NECvDk+LJ8cRVUEBAIpr1jU3QNckY9qs rk1g== Received: by 10.66.77.38 with SMTP id p6mr36841117paw.47.1355697862723; Sun, 16 Dec 2012 14:44:22 -0800 (PST) Received: from [10.143.75.51] (mobile-166-147-095-092.mycingular.net. [166.147.95.92]) by mx.google.com with ESMTPS id nm2sm6978142pbc.43.2012.12.16.14.44.21 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 14:44:22 -0800 (PST) References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> <8608A766-72F2-423D-BD88-247CBE3724ED@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8608A766-72F2-423D-BD88-247CBE3724ED@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <131C5139-87F2-454C-935D-5149D9DD5F07@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: Lenovo x220 suspend/resume broken Date: Sun, 16 Dec 2012 14:44:16 -0800 To: Adrian Chadd Cc: matt , "freebsd-mobile@freebsd.org" , "freebsd-current@freebsd.org" , Daniel Stolpe , Ganael LAPLANCHE , "jkim@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:44:24 -0000 On Dec 16, 2012, at 2:42 PM, Garrett Cooper wrote: > On Dec 16, 2012, at 2:28 PM, Adrian Chadd wrote: >=20 >> Hi, >>=20 >> have you filed a PR about this? >>=20 >> There shouldn't be any reason why it works on 10-current but not >> 9.1-release. If that's the case, I'm hopeful that jkim and the syscons >> peeps can figure out what's going on. >>=20 >> Thanks, >>=20 >>=20 >> adrian >>=20 >>=20 >> On 16 December 2012 14:17, Daniel Stolpe wrote: >>>=20 >>> I have run 10.0-current on a X121e for about a year (in order to get >>> graphics working) and the plan was to go to 9.1-release as soon as it wa= s >>> out. >>>=20 >>> I was rather surprised to find that the screen did not wake up on resume= . >>>=20 >>> It would be very nice to have resume working again. >>>=20 >>>=20 >>> On Sat, 15 Dec 2012, Adrian Chadd wrote: >>>=20 >>>> Hi, >>>>=20 >>>> jkim - is there any negative side-effect from reverting r231797 ? Did >>>> this fix a bug you saw on another platform? >>>>=20 >>>> I have the same symptom on my T400, unfortunately it's in the office >>>> and I can't get to it right now to test. >=20 > Can't speak for your lenovos, but my netbook has been working like a champ= on i386 with smp since it was fixed. Sorry; missed the context where you said 9.1. What video driver are you guys= using? -Garrett= From owner-freebsd-current@FreeBSD.ORG Sun Dec 16 23:38:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95BFAE12; Sun, 16 Dec 2012 23:38:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id CA0258FC0C; Sun, 16 Dec 2012 23:38:01 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2282032wgh.31 for ; Sun, 16 Dec 2012 15:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EzfZxHJTGDewpVwapnVhmR8/61Cb4ukJOWIIGg2UEeA=; b=cqJwGKUCQwqkhTfJiARESFkdJ7l/e3tOVWZrp5WEIc53HlQQQslem/tlzoCoJl5R9O T3sOT4z+Qxu2zvLi0VtAVfOlgdc6W+bDh538sYzuHbhdKSVREkoHkPxlp1yfLePXFkyE LyNbNLZ3t+uJc4YGrvaRJ0dBEpE9UC4XTQwzMhRNWWHI2Fd4uHeTtfzRokJlyKDbkge1 zc0YFOzz55VxqASWzMlAbXm8bSFWs2ZBoqU+gOvtaO20B9BfOENSyQblTfL1+NfNpuh6 nWRHl5TqXPTAEXLK1h41hYW4MwRLMOomiGV0QLLYheyysg+Slhiu29P5O/R20/r6Bd+e xqBg== Received: by 10.194.57.206 with SMTP id k14mr13795024wjq.26.1355701080847; Sun, 16 Dec 2012 15:38:00 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id i2sm8826403wiw.3.2012.12.16.15.37.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 15:37:59 -0800 (PST) Sender: Alexander Motin Message-ID: <50CE5B54.3050905@FreeBSD.org> Date: Mon, 17 Dec 2012 01:37:56 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> In-Reply-To: <50CCAB99.4040308@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 23:38:02 -0000 Hi. Here is one more version. Unless something new will be found/reported this may be the last one, because me and Davide are quite satisfied with the results. If everything will be fine, I think we could commit it to HEAD closer to the end of the week: http://people.freebsd.org/~mav/calloutng_12_16.patch Changes in this version: -- Removed couple of redundant variables in callout implementation, that reduced sizeof(struct callout) by two pointers and simplified some internal code. -- syscons driver was made to schedule only 1-2 callouts per second instead of 20-30 before when console is in graphical mode and there are few other things to do. Now my laptop has only about 30 interrupts per second total during idle periods with X running. -- i8254 eventtimer driver was optimized to work faster in disabled by default one-shot mode. -- Few kernel functions were added to make KPIs more complete. -- Man pages were updated. -- Some style fixes were made. On 15.12.2012 18:55, Alexander Motin wrote: > I'm sorry to interrupt review, but as usual good ideas came during the > final testing, causing another round. :) Here is updated patch for > HEAD, that includes several new changes: > http://people.freebsd.org/~mav/calloutng_12_15.patch > > The new changes are: > -- Precision and event aggregation code was reworked. Instead of > previous -prec/+prec representation, precision is now single-sided -- > -0/+prec. It allowed to significantly improve precision on long time > intervals for APIs which imply that event should not happen before the > specified time. Depending on CPU activity, mistake for long time > intervals now will never be more then 1-500ms, even if specified > precision allows more. > -- Some minor optimizations were made to reduce callout overhead and > latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer > and TSC timecounter usleep(1) call from user-level executes in just > 5-6us, instead of 7-8us before. Now it can do 180K cycles per second on > single CPU with only partial CPU load. > -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, > setrlimit) were modified to reduce number of interrupts, also with event > aggregation by explicit specification of the acceptable events > precision. Now my Core2Duo test system has only 30 interrupts per second > in idle. If not remaining syscons events, it could easily be 15. My > IvyBridge ultrabook first time in its history shown 5.5 hours of battery > time with full screen brightness and 10 hours with lid closed. > -- Some kernel functions were added to make KPIs more complete. > > I've successfully tested this patch on amd64 and arm. > -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 00:17:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28D9C36D for ; Mon, 17 Dec 2012 00:17:48 +0000 (UTC) (envelope-from mr.kodiak@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3E588FC0A for ; Mon, 17 Dec 2012 00:17:47 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id x2so4840971iad.13 for ; Sun, 16 Dec 2012 16:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=OqMCXz2L7+OXXlBassbVSMLlP1VfXs5VLLYlitJI9EI=; b=O033qzZp9Sw/vN0irmQpI94Tev6N/1nUrfhzXL11+mCwioUoPrlqcspEfq63g7BWju JdV6ZmJoFIXGYFTLLoFuV4A5CuYWAjsWHr5bs/dZvLotqjh3LoUSXDW1oFy92v9Ag+0b 4hajVegXujuYODtk3NeQYXmjs3w6MpAwYke//hI38Go0RDB7xHH+vtwPqEdv/Opey9Ta P/LfbYGn/7sIkQ/V2+i/QSLUPjPlV2B1pOgUGs3wPFroROYVI2IQysnazufl6pm7Noin bFa3B93buO902L4edn+reLsAfYUuRI1gbzI4NKho5guxhB7mkIrnNtUUAY0YvQBJ2MeJ o1wA== Received: by 10.50.237.103 with SMTP id vb7mr7706890igc.29.1355703467223; Sun, 16 Dec 2012 16:17:47 -0800 (PST) MIME-Version: 1.0 Sender: mr.kodiak@gmail.com Received: by 10.64.41.133 with HTTP; Sun, 16 Dec 2012 16:17:17 -0800 (PST) From: Bryan Venteicher Date: Sun, 16 Dec 2012 18:17:17 -0600 X-Google-Sender-Auth: WrGwkzZJE6w5sp_YESheWDC6q14 Message-ID: Subject: VirtIO in GENERIC To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:17:48 -0000 There's been lots of requests to have VirtIO in GENERIC for i386 and amd64. Anybody have any issues or concerns with this or the patch at [1]. This also removes the kludge that was introduced in r239009. I've compiled LINT for i386 and amd64 so hopefully there won't be any surprise breakages. [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 01:29:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAFD87E9; Mon, 17 Dec 2012 01:29:41 +0000 (UTC) (envelope-from adrian.chadd@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 0A8AD8FC14; Mon, 17 Dec 2012 01:29:40 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so1722704wib.1 for ; Sun, 16 Dec 2012 17:29:34 -0800 (PST) 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=6kLopwV/0d4yFTfYbv979vnBKt/HrQoxDC7WgiGFrSo=; b=YVeKThTQ8nMJ3hE3C+z7XjKSFEq+pi8pABbd17XMnAsUnbKXJZVX6ZdZC2bpZKyubT O0RLb6yVj2pZDafR7fIlD9ojwsqNGNOnbGwing8fZLyT+OYOWQL17Hg3om2WgBy4m8NU PuZBaFG0t7JEbar2dHm+Qc/mLSqK0enXbptu0gs9z3Lxd9via7phQ21tczfATCH43KYW AhyfEuKP0SWVcH4+VX503Ga+a40wBGXSG0n2TIV/ckSXMYuKRY+dj6u2XHYka3R0QL4B tNDrF7a2W46IlO9uDjXEd4Np98QBdqG+iGCrhijc83Bt8QsaTStADlL5wZweCiEGIE5O EkhQ== MIME-Version: 1.0 Received: by 10.194.93.40 with SMTP id cr8mr14203847wjb.16.1355707774499; Sun, 16 Dec 2012 17:29:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 16 Dec 2012 17:29:34 -0800 (PST) In-Reply-To: <50CE5B54.3050905@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> Date: Sun, 16 Dec 2012 17:29:34 -0800 X-Google-Sender-Auth: whr3NmJDdOYbOmYt_qvpgXk1_Vw Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 01:29:42 -0000 On 16 December 2012 15:37, Alexander Motin wrote: > Hi. > > Here is one more version. Unless something new will be found/reported this > may be the last one, because me and Davide are quite satisfied with the > results. If everything will be fine, I think we could commit it to HEAD > closer to the end of the week: > http://people.freebsd.org/~mav/calloutng_12_16.patch Hi, Don't you think one week is a little on the low side for reviewing something this critical? Would you mind approaching some of the cluster peeps and seeing if they'll run this up on the ref10* boxes and VMs, just to get some further exposure? Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 01:40:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7613DE8 for ; Mon, 17 Dec 2012 01:40:42 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 88B0D8FC19 for ; Mon, 17 Dec 2012 01:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=PFnoxVYeD8dojUc01zB3ZW1nsJpKJI8mqKALODoXjtM=; b=SSQ1viVSk0OJF+1glKWmUWHfotR+4YC368WuhkKkIU/8S8Qe3P7aglf1BgVXM5wODbbGfmmpHNdExb1x4SETJfwc6n5U1edZ4+WiFiLodabUfWexOfkZEVk1XjyHLlHz; Received: from [122.129.203.50] (port=14285 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TkPhB-002XiS-49 for freebsd-current@freebsd.org; Sun, 16 Dec 2012 18:40:41 -0700 Date: Mon, 17 Dec 2012 08:40:37 +0700 From: Erich Dollansky To: "freebsd-current@freebsd.org" Subject: X on ThinkPad X220 with chrome or firefox goes blank Message-ID: <20121217084037.2ff6391a@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 01:40:42 -0000 Hi, I updated my notebook over the last couple of days and have now problems starting chrome and firefox. The effect is that the screen turns blury leaving hard to recognose characters on a white screen after starting any of these applications. I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this is now a flight in the dark. After entering Ctrl-C and restart X, I get a new X running until I start firefox or chrome again. Applications like Claws Mail, Arora or xterm work without problems. I do not see anything different in the log file of X. Does anybody have a clue what could cause this? I will recompile and reinstall all my ports now to see what will come out there. Erich From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 01:54:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56E7CFFE for ; Mon, 17 Dec 2012 01:54:00 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F18E8FC16 for ; Mon, 17 Dec 2012 01:53:59 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so2198205dad.13 for ; Sun, 16 Dec 2012 17:53:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Ek8BgL1hWosp0Of5FHx2XflaS0gVngwd69mRzoEWhKo=; b=DDj7kpufQfsoNhve3Fpxk3+1D9diqp3r9yOX2etFQjPcYEg5dizAU9x7QXSHx/iORL qL7MlwBc/h+xIHtv3UtPlHvXjF2BahHE2xrJgev26LYAByz8DHSHg6UVE6PrPT5E65Ol M2Bsg0GKvEek530B5q0YxjI8Q/HUq2hVjeKWQ1PI5iC7xRFx/B5HTSx2tXP+9OSJCNmr Jx1JrLoEC8+h7oxYqIHv29/MEQZ4R/wrAJZ0Q9ppCGUrpENL8ZG4hvVPcbcw/IskniNH FMA9Ia8EAJrHMGpH66lSsp4JIDn3ow1JOWiKT3HzlULBOX682d1lILd0YBEVjbKPR9YN ocbA== MIME-Version: 1.0 Received: by 10.68.227.73 with SMTP id ry9mr38366102pbc.73.1355709239342; Sun, 16 Dec 2012 17:53:59 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.68.48.163 with HTTP; Sun, 16 Dec 2012 17:53:59 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Dec 2012 14:53:59 +1300 X-Google-Sender-Auth: a0aHEyV46T130RddzxsTCM4mQ5E Message-ID: Subject: Re: VirtIO in GENERIC From: Andrew Thompson To: Bryan Venteicher X-Gm-Message-State: ALoCoQnvIUEXdAEH8Okil6dIKG/EqE1xAEiGUbhtXAQZz9on9ApJUwTMOBE7nItvzxw08eM3GtBR Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 01:54:00 -0000 On 17 December 2012 13:17, Bryan Venteicher wrote: > There's been lots of requests to have VirtIO in GENERIC for i386 and > amd64. Anybody have any issues or concerns with this or the patch at > [1]. This also removes the kludge that was introduced in r239009. > > I've compiled LINT for i386 and amd64 so hopefully there won't be any > surprise breakages. > > [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch It would be great to have the drivers enabled. You do not need the sys/conf/files changes, the common and arch files are combined. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 02:31:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ED58DD7; Mon, 17 Dec 2012 02:31:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7478FC0C; Mon, 17 Dec 2012 02:31:13 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so2210558dad.13 for ; Sun, 16 Dec 2012 18:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=Jfs/csDriVbtDw72bcSnp4VNSlZjMDVG8UxRQuJocgU=; b=pyTeD21uNMineh7fIl3yPc4JBRxOq1qQ6aGZNFFRFeltOinO7BJ/McrADjlJuYIHQS wcoT5K9CFvLExugTnuYEERwFqdPaTuCHZ2w0nO2B9cU37iiKH8ZWjnc8Vr7NCIgJZZcb /IZx7Yv4P/fFpSSM5AuU38+mUpXf9nqid/Ly3ylffjO0zqHxurZ6uloKylxDjQHUGgM3 B68d06vJmXT90hOO3o+sd/+PzO9FdcLr4hVSAK8Wm50pQNQPZlBEn6agiZcGfwSXeeuo 83uSrvTLUOjmEqw06+dmH2zdnoqaW6wkEDMUSx6qtgM9n1n3hI2HcLWaPHC46mSLbQ7r 6b9A== Received: by 10.66.84.3 with SMTP id u3mr38017849pay.51.1355711472913; Sun, 16 Dec 2012 18:31:12 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id nm2sm7267267pbc.43.2012.12.16.18.31.11 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 18:31:12 -0800 (PST) References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: [RFC/RFT] calloutng Date: Sun, 16 Dec 2012 18:31:10 -0800 To: Adrian Chadd Cc: Davide Italiano , Alexander Motin , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 02:31:13 -0000 On Dec 16, 2012, at 5:29 PM, Adrian Chadd wrote: > On 16 December 2012 15:37, Alexander Motin wrote: >> Hi. >> >> Here is one more version. Unless something new will be found/reported this >> may be the last one, because me and Davide are quite satisfied with the >> results. If everything will be fine, I think we could commit it to HEAD >> closer to the end of the week: >> http://people.freebsd.org/~mav/calloutng_12_16.patch > > Hi, > > Don't you think one week is a little on the low side for reviewing > something this critical? > > Would you mind approaching some of the cluster peeps and seeing if > they'll run this up on the ref10* boxes and VMs, just to get some > further exposure? And maybe tinderbox..? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 03:38:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 584A1C95; Mon, 17 Dec 2012 03:38:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC168FC0C; Mon, 17 Dec 2012 03:38:17 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so1634686wib.13 for ; Sun, 16 Dec 2012 19:38:17 -0800 (PST) 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=kgbYkSvIJeXPpgoSE9zP1o/keHXf6yUaW4vs/3YK6O4=; b=gjBCke9sbYnUmjHI8hbdFshBfxPDCqpWdCLmMGmQN4uDE2dz0zSBist5+Ebh7XWEq0 Iguw/I7M8R4Hfq26YSVGPPYzqF1uHXzJnonUD4+jQMSFtgThiArN/fuaeBNskUaCbTm2 tPPVB1SrrGzPXcaQdBN1CwBSN/vTdPfCNJp2NvWe/uNbfNtXRruJUqL88IXaEISPFDqK rC2Ad4WecVXY5zZCEVQsz/XD6DQTlncKQ2TCD0afBKUwAj+X0ROwFBOVpWkMhAThR3vA DtVv+qdokm7CKTgsW6AkGOp+oTfS3bieJEauJcCZmypIKLK2g7KyOmSmwTS1pj0jIzzQ GHlg== MIME-Version: 1.0 Received: by 10.180.73.202 with SMTP id n10mr12640921wiv.17.1355715496969; Sun, 16 Dec 2012 19:38:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 16 Dec 2012 19:38:16 -0800 (PST) In-Reply-To: References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> Date: Sun, 16 Dec 2012 19:38:16 -0800 X-Google-Sender-Auth: 5Ej0KTuR1hczwAWCIFzf3_8FMmU Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Alexander Motin , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 03:38:19 -0000 On 16 December 2012 18:31, Garrett Cooper wrote: >> Would you mind approaching some of the cluster peeps and seeing if >> they'll run this up on the ref10* boxes and VMs, just to get some >> further exposure? > > And maybe tinderbox..? Tinderbox is a great idea. Maybe hit up the altq/pf using crowd and see if they'll test this stuff out too? What else gets heavily callout /timer driven? Try some computational workloads that stress the fairness of ULE/4BSD, maybe? Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 05:06:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EC67A80; Mon, 17 Dec 2012 05:06:40 +0000 (UTC) (envelope-from jim.harris@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 72E358FC12; Mon, 17 Dec 2012 05:06:39 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2534319wey.13 for ; Sun, 16 Dec 2012 21:06:38 -0800 (PST) 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=1a6YwoK/NvrK7xCnrVBQB4R87/qBE4P+aiotwNUqodA=; b=gJFrBBffBvT2BbGh7V62LowUBjVmUXEji+qgjK31QxAqNXp5guxKTgc2B5r7CeG1YY 48+ffHQ+dR5yBG0r/kaGYtXFeTgL8i04n0vh9yYpCEtbRJa9Dk6c3FBTDs9SyAFNaQ/l Tc0FsaJKKvEckeb7mwYOvz/EilkF8waBYZ59zKn4SPtZKHVofd3MFYi2W2DyoOD8r9ST GbUO9Zv0ltsd5jRlE5q6/kgrp+K79mr7lNYzfPLhMYEkCBaEr2TyzshT0YC14TnPcoYK 31yYiKZpW6o6varQsMXU0dYcXKnm06LOpcIwwmrD2pzIllAq0wR2q7vhDzRKpMJBQy7N sVwQ== MIME-Version: 1.0 Received: by 10.180.75.135 with SMTP id c7mr13408691wiw.10.1355720798339; Sun, 16 Dec 2012 21:06:38 -0800 (PST) Sender: jim.harris@gmail.com Received: by 10.217.57.4 with HTTP; Sun, 16 Dec 2012 21:06:38 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Dec 2012 22:06:38 -0700 X-Google-Sender-Auth: QdIxRHUlONSyw1E7xRDoEVtCnPI Message-ID: Subject: Re: VirtIO in GENERIC From: Jim Harris To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Bryan Venteicher , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:06:40 -0000 On Sun, Dec 16, 2012 at 6:53 PM, Andrew Thompson wrote: > On 17 December 2012 13:17, Bryan Venteicher wrote: > > > There's been lots of requests to have VirtIO in GENERIC for i386 and > > amd64. Anybody have any issues or concerns with this or the patch at > > [1]. This also removes the kludge that was introduced in r239009. > > > > I've compiled LINT for i386 and amd64 so hopefully there won't be any > > surprise breakages. > > > > [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch > > > It would be great to have the drivers enabled. You do not need the > sys/conf/files changes, the common and arch files are combined. > > Removing the virtio files from sys/conf/files ensures these drivers can only be specified in x86 kernel configuration files. r239009 added these lines to sys/conf/files, but Bryan's patch does it more correctly. The only question I have is the GENERIC changes where "device virtio" is added - it says it is required, but should this instead say it's required for any of the other drivers in this section? -Jim From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 05:52:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49703739; Mon, 17 Dec 2012 05:52:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id D32CE8FC0C; Mon, 17 Dec 2012 05:52:50 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so8564453iec.13 for ; Sun, 16 Dec 2012 21:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=pEQVqOAblMbQuUoYbG8D0QuMm6MYG5VIQNhxjQxaN3A=; b=NWNsiHw1pYoEK8NB1Bw9/Tsdv33jdbJOrJZKp33o6C8Q5P1JJutzuVAk0DATnBIQQ8 w0e+Is3+TmGdmWRa94ZWZRmxRL0zhnlnYRMJo5P5J76gepzFZaJvPZtdyPyOugAqA88U CGQH3WnkcxesjI4EWniTaxgCiOEq/z9tRo/iyaksIspEjzWbmNbRmUAEYxU5bzHxL48T xF23Sfc4wN3aRVODgjWaJcJAI1lxaGfU5h5blf29zJCD035kMcf/h8/4PlUccBd0G7JP jSKf/6kdE4731zYKU2MK2N+RExTQMIca6g6QF8Hz7gr4A3kt7e0FXboAhB86Rz+qqr7D P3kQ== X-Received: by 10.50.34.225 with SMTP id c1mr8011375igj.67.1355723569999; Sun, 16 Dec 2012 21:52:49 -0800 (PST) Received: from oddish ([66.11.160.25]) by mx.google.com with ESMTPS id ex10sm5498832igc.15.2012.12.16.21.52.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 21:52:49 -0800 (PST) Date: Mon, 17 Dec 2012 00:52:41 -0500 From: Mark Johnston To: Bruce Evans Subject: Re: [RFC/RFT] calloutng Message-ID: <20121217055241.GA5228@oddish> References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> <35705A81-690A-4993-B0C3-C8BC0BC89C67@gmail.com> <20121216175614.V1027@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121216175614.V1027@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:52:51 -0000 On Sun, Dec 16, 2012 at 06:14:07PM +1100, Bruce Evans wrote: > On Sat, 15 Dec 2012, Garrett Cooper wrote: > > > On Dec 15, 2012, at 12:34 PM, Mark Johnston wrote: > > > >> On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote: > >>> Hi. > >>> > >>> I'm sorry to interrupt review, but as usual good ideas came during the > >>> final testing, causing another round. :) Here is updated patch for > >>> HEAD, that includes several new changes: > >>> http://people.freebsd.org/~mav/calloutng_12_15.patch > >> > >> This patch breaks the libprocstat build. > >> > >> Specifically, the OpenSolaris sys/time.h defines the preprocessor > >> symbols gethrestime and gethrestime_sec. These symbols are also defined > >> in cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h. > >> libprocstat:zfs.c is compiled using include paths that pick up the > >> OpenSolaris time.h, and with this patch _callout.h includes sys/time.h. > >> > >> zfs.c includes taskqueue.h (with _KERNEL defined), which includes > >> _callout.h, so both time.h and zfs_context.h are included in zfs.c, and > >> the symbols are thus defined twice. > > Gross namespace pollution. sys/_callout.h exists so that the full > namespace pollution of sys/callout.h doesn't get included nested. But > sys/time.h is much more polluted than sys/callout.h. > > However, sys/time.h is old standard pollution in sys/param.h, and > sys/callout.h is not so old standard pollution in sys/systm.h. It is > a bug to not include sys/param.h and sys/systm.h in most kernel source > code, so these nested includes are just style bugs -- they have no > effect for correct kernel source code. > > >> The patch below fixes the build for me. Another approach might be to > >> include sys/_task.h instead of taskqueue.h at the beginning of zfs.c. > > Good if it works. The diff below is what I had in mind. taskqueue.h is used so that sizeof(struct task) can be used, but I don't see why that's preferable to just including _task.h. -Mark diff --git a/lib/libprocstat/zfs.c b/lib/libprocstat/zfs.c index aa6d78e..f04eedf 100644 --- a/lib/libprocstat/zfs.c +++ b/lib/libprocstat/zfs.c @@ -27,15 +27,12 @@ */ #include +#include #define _KERNEL #include -#include #undef _KERNEL #include -#undef lbolt -#undef lbolt64 -#undef gethrestime_sec #include #include #include From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 06:06:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C640EB26 for ; Mon, 17 Dec 2012 06:06:28 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8474D8FC0C for ; Mon, 17 Dec 2012 06:06:28 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so3301507pbc.13 for ; Sun, 16 Dec 2012 22:06:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=FJI5Xn6sOFRvyOoE7CR97HrGFDHEvGOEiwXugKDEr8A=; b=Kof/M7ppH4k/IVxwZiPJfBgodGbAkwvanSc5FFsOLTGtbh0bT2y/apN1ctY3mVqK1Q iTmjRlHnBo10BpdOrF2EGr8ZNbQyaJb1vCNFEC4ryT3iheAjtRozG30bMUZOtNmACcQt Zznn3Tj85BTztRH7M5olR1rwZ9rXgHqFk3Ad3QrMEHhU1imljIR/clJwHdafLfeElyCT kLZBGh5u28ufsej3FRW5BPdbSHSTPHFTeFCMXUMZ3kkNQdAZVNEk1NKO2++pidbqN1NN goK/SwmX3hMNRhcSO0Ly1R9qnTkk8njj0V5fc5tA6vCiu5Pn47evLVcug7LZKZxsySff GPnw== MIME-Version: 1.0 Received: by 10.68.129.233 with SMTP id nz9mr39753411pbb.139.1355724387591; Sun, 16 Dec 2012 22:06:27 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.68.48.163 with HTTP; Sun, 16 Dec 2012 22:06:27 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Dec 2012 19:06:27 +1300 X-Google-Sender-Auth: dnkBrrep3j5EVj_43hJySTyxIMY Message-ID: Subject: Re: VirtIO in GENERIC From: Andrew Thompson To: Jim Harris X-Gm-Message-State: ALoCoQnPxUc0RYtQK/BrqUD0DeMcPs7hqlGmdW5mF3+bNIP0lQmQpzAoA1gECDYVU3cE7i6wit/J Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Bryan Venteicher , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 06:06:28 -0000 On 17 December 2012 18:06, Jim Harris wrote: > > > On Sun, Dec 16, 2012 at 6:53 PM, Andrew Thompson wrote: > >> On 17 December 2012 13:17, Bryan Venteicher wrote: >> >> > There's been lots of requests to have VirtIO in GENERIC for i386 and >> > amd64. Anybody have any issues or concerns with this or the patch at >> > [1]. This also removes the kludge that was introduced in r239009. >> > >> > I've compiled LINT for i386 and amd64 so hopefully there won't be any >> > surprise breakages. >> > >> > [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch >> >> >> It would be great to have the drivers enabled. You do not need the >> sys/conf/files changes, the common and arch files are combined. >> >> > Removing the virtio files from sys/conf/files ensures these drivers can > only be specified in x86 kernel configuration files. r239009 added these > lines to sys/conf/files, but Bryan's patch does it more correctly. > Linux supports virtio on ARM so I dont think its necessarily x86 MD. I guess it can be moved back later. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:17:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B48E9E05; Mon, 17 Dec 2012 07:17:41 +0000 (UTC) (envelope-from mr.kodiak@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 552348FC0A; Mon, 17 Dec 2012 07:17:40 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id x2so5046990iad.13 for ; Sun, 16 Dec 2012 23:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Mt2na8ZSY6K5r85sqgLAITj+r4lyr2SDRiUEsdE8a6w=; b=Frhzy9aOce2oxvuHB4uOdfxrWWbtZrTwt/iVleUm8lj7xWYJ94x+ulg6bwJvZ2liOJ eDMTDOCbHCSG1jKDVw/daD4z8nSnpDbf97kcHRRe7NTRMiVLDhGqM6UlyrJUx+K9a/gu tK73qkmX0AlkXxKwDAV+FBDqvEmZ3olF83SEZ/y+IyDBOCvO+NOfHu/HIgoBovTqwAxH ErbJ2OrryPceB7PawOPS53B1DOE8kh2M5iMzYzyJxSS02wqB0N9WFDTvKAQ23bJnqutv vZCrCFxF43YVqE8A2Tt+At+PIOAxxH2qeXofylsv2ZfRJDaVf2xwlvIxkHYuz/GxXfSk 5+pA== Received: by 10.50.41.225 with SMTP id i1mr8207144igl.73.1355728660652; Sun, 16 Dec 2012 23:17:40 -0800 (PST) MIME-Version: 1.0 Sender: mr.kodiak@gmail.com Received: by 10.64.41.133 with HTTP; Sun, 16 Dec 2012 23:17:10 -0800 (PST) In-Reply-To: References: From: Bryan Venteicher Date: Mon, 17 Dec 2012 01:17:10 -0600 X-Google-Sender-Auth: 0s6BKhMYHZ2VcwmMSGZgEubGi-U Message-ID: Subject: Re: VirtIO in GENERIC To: Jim Harris Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:17:41 -0000 On Sun, Dec 16, 2012 at 11:06 PM, Jim Harris wrote: > > > On Sun, Dec 16, 2012 at 6:53 PM, Andrew Thompson > wrote: >> >> On 17 December 2012 13:17, Bryan Venteicher wrote: >> >> > There's been lots of requests to have VirtIO in GENERIC for i386 and >> > amd64. Anybody have any issues or concerns with this or the patch at >> > [1]. This also removes the kludge that was introduced in r239009. >> > >> > I've compiled LINT for i386 and amd64 so hopefully there won't be any >> > surprise breakages. >> > >> > [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch >> >> >> It would be great to have the drivers enabled. You do not need the >> sys/conf/files changes, the common and arch files are combined. >> > > Removing the virtio files from sys/conf/files ensures these drivers can only > be specified in x86 kernel configuration files. r239009 added these lines > to sys/conf/files, but Bryan's patch does it more correctly. > > The only question I have is the GENERIC changes where "device virtio" is > added - it says it is required, but should this instead say it's required > for any of the other drivers in this section? > Yes, that wording could be improved; will update the patch in the morning. > -Jim > From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:30:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 283AAF9; Mon, 17 Dec 2012 07:30:33 +0000 (UTC) (envelope-from stolpe@resilans.se) Received: from server.resilans.se (ns1.resilans.se [IPv6:2a01:280:1::53]) by mx1.freebsd.org (Postfix) with ESMTP id A6EC38FC0C; Mon, 17 Dec 2012 07:30:31 +0000 (UTC) Received: from server.resilans.se (server.resilans.se [194.14.3.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.resilans.se (Postfix) with ESMTPS id BCD622E4001; Mon, 17 Dec 2012 08:30:22 +0100 (CET) Date: Mon, 17 Dec 2012 08:30:22 +0100 (CET) From: Daniel Stolpe To: Garrett Cooper Subject: Re: Lenovo x220 suspend/resume broken In-Reply-To: <131C5139-87F2-454C-935D-5149D9DD5F07@gmail.com> Message-ID: References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> <8608A766-72F2-423D-BD88-247CBE3724ED@gmail.com> <131C5139-87F2-454C-935D-5149D9DD5F07@gmail.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: matt , Adrian Chadd , "freebsd-mobile@freebsd.org" , "freebsd-current@freebsd.org" , Ganael LAPLANCHE , "jkim@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:30:33 -0000 On Sun, 16 Dec 2012, Garrett Cooper wrote: > On Dec 16, 2012, at 2:42 PM, Garrett Cooper wrote: > >> On Dec 16, 2012, at 2:28 PM, Adrian Chadd wrote: >> >>> Hi, >>> >>> have you filed a PR about this? >>> >>> There shouldn't be any reason why it works on 10-current but not >>> 9.1-release. If that's the case, I'm hopeful that jkim and the syscons >>> peeps can figure out what's going on. >>> >>> Thanks, >>> >>> >>> adrian >>> >>> >>> On 16 December 2012 14:17, Daniel Stolpe wrote: >>>> >>>> I have run 10.0-current on a X121e for about a year (in order to get >>>> graphics working) and the plan was to go to 9.1-release as soon as it was >>>> out. >>>> >>>> I was rather surprised to find that the screen did not wake up on resume. >>>> >>>> It would be very nice to have resume working again. >>>> >>>> >>>> On Sat, 15 Dec 2012, Adrian Chadd wrote: >>>> >>>>> Hi, >>>>> >>>>> jkim - is there any negative side-effect from reverting r231797 ? Did >>>>> this fix a bug you saw on another platform? >>>>> >>>>> I have the same symptom on my T400, unfortunately it's in the office >>>>> and I can't get to it right now to test. >> >> Can't speak for your lenovos, but my netbook has been working like a champ on i386 with smp since it was fixed. > > Sorry; missed the context where you said 9.1. What video driver are you guys using? Video driver: xf86-video-intel-2.17.0_1 (used to be 2.7 I think). r244122 I got a lot of Linux hits on different forums so maybe this is a i915kms thing but it's still funny it worked with 10.0-current, a lot of manual patching and experimental xorg-ports a year ago but not now with 9.1-release and WITH_KMS=YES + WITH_NEW_XORG=YES. As I said it's just the screen that doesn't wake up. SSH works and I managed to verify so does the keyboard. Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:56:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0DF18C8; Mon, 17 Dec 2012 07:56:27 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 7067E8FC13; Mon, 17 Dec 2012 07:56:27 +0000 (UTC) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id 2EDF81FA5CE2; Mon, 17 Dec 2012 08:56:26 +0100 (CET) From: "Ganael LAPLANCHE" To: Garrett Cooper ,Adrian Chadd Subject: Re: Lenovo x220 suspend/resume broken X-Openwebmail-Date: Mon, 17 Dec 2012 09:56:26 +0200 Message-Id: <20121217075129.M42386@martymac.org> In-Reply-To: <131C5139-87F2-454C-935D-5149D9DD5F07@gmail.com> References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> <8608A766-72F2-423D-BD88-247CBE3724ED@gmail.com> <131C5139-87F2-454C-935D-5149D9DD5F07@gmail.com> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 157.99.64.43 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Mon, 17 Dec 2012 07:56:27 +0000 (UTC) Cc: matt , "freebsd-mobile@freebsd.org" , "freebsd-current@freebsd.org" , Daniel Stolpe , Ganael LAPLANCHE , "jkim@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:56:28 -0000 On Sun, 16 Dec 2012 14:44:16 -0800, Garrett Cooper wrote Hi Garett, > > Can't speak for your lenovos, but my netbook has been working like a > > champ on i386 with smp since it was fixed. The diff I have spotted is partly amd64-related ; you may not encounter the same problem on i386. > Sorry; missed the context where you said 9.1. What video > driver are you guys using? I am using KMS patch "all.13.7.patch", since it was not in -CURRENT at this time. Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:56:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD5FA00; Mon, 17 Dec 2012 07:56:42 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 9614F8FC14; Mon, 17 Dec 2012 07:56:42 +0000 (UTC) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id E07E91FA5CF8; Mon, 17 Dec 2012 08:56:41 +0100 (CET) From: "Ganael LAPLANCHE" To: Adrian Chadd ,Daniel Stolpe Subject: Re: Lenovo x220 suspend/resume broken X-Openwebmail-Date: Mon, 17 Dec 2012 09:56:41 +0200 Message-Id: <20121217074723.M97178@martymac.org> In-Reply-To: References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 157.99.64.43 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Mon, 17 Dec 2012 07:56:42 +0000 (UTC) Cc: matt , freebsd-current@freebsd.org, Ganael LAPLANCHE , jkim@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:56:42 -0000 On Sun, 16 Dec 2012 14:28:11 -0800, Adrian Chadd wrote Hi Adrian, > have you filed a PR about this? I have just filed one : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 > There shouldn't be any reason why it works on 10-current but not > 9.1-release. If that's the case, I'm hopeful that jkim and the > syscons peeps can figure out what's going on. It depends on the age of -CURRENT Daniel runs. Things have been MFC'd since, and 9.1 does not suspend/resume for me either, while my old -CURRENT from february works like a charm. Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:57:36 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0039CB69; Mon, 17 Dec 2012 07:57:35 +0000 (UTC) (envelope-from martymac@FreeBSD.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B202F8FC0C; Mon, 17 Dec 2012 07:57:35 +0000 (UTC) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id 0C9261FA5CE2; Mon, 17 Dec 2012 08:57:35 +0100 (CET) From: "Ganael LAPLANCHE" To: matt ,Ganael LAPLANCHE Subject: Re: Lenovo x220 suspend/resume broken X-Openwebmail-Date: Mon, 17 Dec 2012 09:57:35 +0200 Message-Id: <20121217075654.M18500@FreeBSD.org> In-Reply-To: <50CB5DEF.8030503@gmail.com> References: <20121214124854.M44964@martymac.org> <50CB5DEF.8030503@gmail.com> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 157.99.64.43 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Mon, 17 Dec 2012 07:57:35 +0000 (UTC) Cc: freebsd-current@FreeBSD.org, jkim@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:57:36 -0000 On Fri, 14 Dec 2012 09:12:15 -0800, matt wrote Hi Matt, > Perhaps revert the spinlocks to the the > intr_suspend/intr_resume code and see if it has an effect? > It's an uneducated guess :) I tried that, but it did not fix the problem. Thanks for the suggestion :p -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:57:49 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E365C6C; Mon, 17 Dec 2012 07:57:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D5AAA8FC0A; Mon, 17 Dec 2012 07:57:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA23533; Mon, 17 Dec 2012 09:57:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TkVZy-0004iV-DQ; Mon, 17 Dec 2012 09:57:38 +0200 Message-ID: <50CED06F.6080909@FreeBSD.org> Date: Mon, 17 Dec 2012 09:57:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:57:49 -0000 on 17/12/2012 03:29 Adrian Chadd said the following: > On 16 December 2012 15:37, Alexander Motin wrote: >> Hi. >> >> Here is one more version. Unless something new will be found/reported this >> may be the last one, because me and Davide are quite satisfied with the >> results. If everything will be fine, I think we could commit it to HEAD >> closer to the end of the week: >> http://people.freebsd.org/~mav/calloutng_12_16.patch > > Hi, > > Don't you think one week is a little on the low side for reviewing > something this critical? Thank god that this feature was developed in a branch, it was developed for a long period of time and there were people who routinely reviewed and tested (and really used) it. And yeah, its design was announced and discussed well in advance too. > Would you mind approaching some of the cluster peeps and seeing if > they'll run this up on the ref10* boxes and VMs, just to get some > further exposure? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 08:01:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FD45EEC; Mon, 17 Dec 2012 08:01:03 +0000 (UTC) (envelope-from mavbsd@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 5DB2F8FC12; Mon, 17 Dec 2012 08:01:02 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so2590387wey.13 for ; Mon, 17 Dec 2012 00:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V27VYDtiEN0I5WUehtWQ00IsO4YmLnQb5LP8VwO4KG0=; b=nhIBmSZK9WEeobW3CvXBLhAh5e9RmH0ua4RTaTtdMLjTY3oxwHd2AXq9Ej1y0r6pyc x9IPopjFABZqG27J4TcYt6hGjnbhpciwee+B5sv7AWZt6LahE1L+rzqpBJlYgV4zEIy2 LQxvR/X21KYmLExeGbpX1uljj8S2okDHxMMPjqc1VnRpBOcmF+mgz55RCgXwv2aGwbdl 6frw3dNmJcaQutdvf/Jx8dTGU+LaiRjeTe7AHUkM+nrtRGhIamd/fNRPwXVzMaJze0HZ NiT7QaOMmuaLTlK9pHz+o6+6eKUPoGUq3IVpl+IHj96B8t4cvymZqp33pbWukZPxtcV1 rsIA== X-Received: by 10.181.11.234 with SMTP id el10mr13968450wid.7.1355731261377; Mon, 17 Dec 2012 00:01:01 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id w5sm9979350wif.11.2012.12.17.00.00.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 00:01:00 -0800 (PST) Sender: Alexander Motin Message-ID: <50CED13A.50209@FreeBSD.org> Date: Mon, 17 Dec 2012 10:00:58 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 08:01:03 -0000 On 17.12.2012 03:29, Adrian Chadd wrote: > On 16 December 2012 15:37, Alexander Motin wrote: >> Here is one more version. Unless something new will be found/reported this >> may be the last one, because me and Davide are quite satisfied with the >> results. If everything will be fine, I think we could commit it to HEAD >> closer to the end of the week: >> http://people.freebsd.org/~mav/calloutng_12_16.patch > > Don't you think one week is a little on the low side for reviewing > something this critical? It was in public development for the last half a year. IIRC, previous announce by Davide few months ago caused no any feedback. If you say you will review it in two weeks, I will wait for two weeks. But I don't want to wait without a purpose. > Would you mind approaching some of the cluster peeps and seeing if > they'll run this up on the ref10* boxes and VMs, just to get some > further exposure? Are the ref* system have any load to see anything? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 08:14:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AF6E2EC; Mon, 17 Dec 2012 08:14:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE6D8FC0C; Mon, 17 Dec 2012 08:14:33 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so1731017wib.13 for ; Mon, 17 Dec 2012 00:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w/zkQSr9Q5/ISD7Iud0VXFj1xFWCvFP+QpH7bdfudHo=; b=ynuSDXv0Qf5Og62Mt9CewcJLHbqKw3YlwIuU9obgspbJiV0PND35mRS+FIHMTA3Kb7 R523E/6KCNxcjG3AiRijIuMg7xUQDPSw8Hh9rv+/K3Tmq/wKc8UM6zxPx8TTPBsTL0dw ChMewPE6f6eirGnafnE55xhG5PHAev4l0xYQd/mXHkBhPgmYHDirSi3AjaOPlDmXe6dB sLsmVZ+bMLZVYEYdITuWOE0v/cdBJWvPvo7oqCPXXEsjowoArzF7X0Ce2uH6XVHGyE2m ynwLKiwQUI7BjHY+0Uh+/lDh5xDqvlBCbaI/JULJJv89OdHTULGEAClDkvZoNt55pknI GOAQ== Received: by 10.194.235.6 with SMTP id ui6mr15359807wjc.12.1355732072371; Mon, 17 Dec 2012 00:14:32 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id df2sm840955wib.0.2012.12.17.00.14.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 00:14:31 -0800 (PST) Sender: Alexander Motin Message-ID: <50CED465.3010501@FreeBSD.org> Date: Mon, 17 Dec 2012 10:14:29 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Davide Italiano , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 08:14:34 -0000 On 17.12.2012 05:38, Adrian Chadd wrote: > On 16 December 2012 18:31, Garrett Cooper wrote: > >>> Would you mind approaching some of the cluster peeps and seeing if >>> they'll run this up on the ref10* boxes and VMs, just to get some >>> further exposure? >> >> And maybe tinderbox..? > > Tinderbox is a great idea. > > Maybe hit up the altq/pf using crowd and see if they'll test this stuff out too? It would be good to test, though I know that at least dummynet is written awful from the point of this project with its callout_reset(&dn_timeout, 1, dummynet, NULL); It should work, but kill most of power benefits. I was promised it will be fixed after this project end. > What else gets heavily callout /timer driven? Try some computational > workloads that stress the fairness of ULE/4BSD, maybe? Schedulers are driven directly by hardclock()/statclock(), so fairness is not affected here. If CPU is not idle, it will receive full set of required events with maximum available precision. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 08:36:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 122BC83F; Mon, 17 Dec 2012 08:36:01 +0000 (UTC) (envelope-from adrian.chadd@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 E6AA58FC12; Mon, 17 Dec 2012 08:35:59 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so1865699wib.1 for ; Mon, 17 Dec 2012 00:35:58 -0800 (PST) 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=mVs6lqD0bgHlaOfmxq94n5D5qrBcpUi17FOo3c4f24A=; b=iF8LVV3BjzZYaOPDwL1KezEXAY4ebs7svqxVvRuV+93T+BFxPWWS3nJvQ2l72NrWX4 dAZMqVM+hdJZ+bbLWfwtfWGKWVCc1G3rxuNnsebAIbZHjE/Joyw2wHgMq8Fk3RhlD+6d WU3a4zqr0wifX1O0qgkzHyImsgT3n/Ifq+y2k5V8kw4G4M9aMjO/GYGbEv5k24G6FNgj 17wYUqPYxWgvplbr3Ii5bBn7heGmdfZm/rxhg35ki4WKUn1phWX1ohCi4itbRfZdxwbf 4KsDG7L6y1VaVq3OHE3AbwAPM6Q1WSQlrY1KdqQAJS2tnjZ1qHaR7f/ODIiuohPFisqa 5xBg== MIME-Version: 1.0 Received: by 10.180.88.138 with SMTP id bg10mr14124048wib.13.1355733358907; Mon, 17 Dec 2012 00:35:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Mon, 17 Dec 2012 00:35:58 -0800 (PST) In-Reply-To: <50CED06F.6080909@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50CED06F.6080909@FreeBSD.org> Date: Mon, 17 Dec 2012 00:35:58 -0800 X-Google-Sender-Auth: hOVybu-Q6r561y4QjoqUU-3x2Nw Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 08:36:01 -0000 On 16 December 2012 23:57, Andriy Gapon wrote: > > Thank god that this feature was developed in a branch, it was developed for a > long period of time and there were people who routinely reviewed and tested (and > really used) it. And yeah, its design was announced and discussed well in > advance too. I can see that; I was even there at David's presentation at BSDCan 2012 about it. Now that it's finished though, it would be nice to get some more stress testing before committing it. Just because it's been developed in a branch doesn't at all imply that it's had wide testing. It's now imminently going into the tree, so that may scare (heh!) a few people into testing it. I'm sure it'll mostly just work, that it'll not really break anything. It just to me feels that a week of warning before committing something like this is a little soon. It's _just_ been finished and the authors have been doing some last minute changes as they get better ideas on implementing things. I think it's great work, I'd just like to see some wider testing. So to put my money where my mouth is, I bought a new hard disk for my T60 last week. I'll install -HEAD on it tomorrow and give it a whirl. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 08:36:05 2012 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8396B939; Mon, 17 Dec 2012 08:36:05 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D13B18FC0A; Mon, 17 Dec 2012 08:36:04 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so3011805eek.13 for ; Mon, 17 Dec 2012 00:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c/Enc8Z9HyPLkmbjUTyTda9a+UFn+DPxqLldWWAk7GU=; b=Rk7BqIF6mB/SAL1uJSutLd/RCpCbzhgtBwtK4SdTFX1Ro7q84W8eSOYKqYe7cWk8J+ 7SV23ZxmwHXkxkObLnBesfbHlJKAFrZw8kqknk99g2KyQaIyco1Feadm7UxI47jmWptd gqrvWrFSBpD8qBqKUsRhIxDzCokd7jaHutdIBSTPva5B5P31X14XPpbmfEGN9Sx6M23w qCRZvjjgneoHkCGZhxPVaq8Ok3yvSt3SM5jKHsJg7UvkwrsGxdNDvjT6dozFgMUoH7JL tZVypzrkmQS5ksYRYZmQAhL9VXmPnxu2PbDQKxj5PsT4MRphg/vbwTn4ntk/h04GKstV Dvmg== MIME-Version: 1.0 Received: by 10.14.215.197 with SMTP id e45mr39772567eep.0.1355733362256; Mon, 17 Dec 2012 00:36:02 -0800 (PST) Received: by 10.14.4.68 with HTTP; Mon, 17 Dec 2012 00:36:02 -0800 (PST) In-Reply-To: <50CE2E29.4030906@FreeBSD.org> References: <50CE2E29.4030906@FreeBSD.org> Date: Mon, 17 Dec 2012 03:36:02 -0500 Message-ID: Subject: Re: Clang/LLVM revision 169451 From: "Sam Fourman Jr." To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 08:36:05 -0000 > No, there is no one-click merge script, it needs humanoid help, I'm > afraid. :-) Is there any reason you cannot just install the port, or > if that is too outdated, just checkout from llvm.org directly and build > it? is it currently possible to build FreeBSD world, without clang and then build clang from ports? From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 09:18:12 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCE9711A for ; Mon, 17 Dec 2012 09:18:12 +0000 (UTC) (envelope-from andersbo87@icloud.com) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtp004.mac.com [17.172.81.3]) by mx1.freebsd.org (Postfix) with ESMTP id A077F8FC17 for ; Mon, 17 Dec 2012 09:18:12 +0000 (UTC) MIME-version: 1.0 Received: from [192.168.1.253] (ti0025a380-1699.bb.online.no [80.213.202.165]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0MF600M5M1Q1UJ40@st11p00mm-asmtp004.mac.com> for current@FreeBSD.org; Mon, 17 Dec 2012 08:18:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2012-12-17_02:2012-12-15,2012-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1212170004 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 17 Dec 2012 09:10:36 +0100 Subject: Problem booting FreeBSD 10-CURRENT from my MacBook Pro: "Can't load kernel" From: Anders Bolt-Evensen To: "current@FreeBSD.org" Message-id: Thread-topic: Problem booting FreeBSD 10-CURRENT from my MacBook Pro: "Can't load kernel" Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 09:18:12 -0000 Hi, everyone and good morning! To make a long story short I'm attempting to install 10-CURRENT on my 2011 model 17 inch MacBook Pro. I downloaded the appropriate amd64 image from FreeBSD's FTP site, burned it out to DVD and installed it on my old FreeBSD 9 partition, erasing existing data. However, when I try to boot the new system, I get a "can't load kernel" error. Giving the command "ls" returns the message "Open '/' failed: no such file or directory". When I type "lsdev" the following is returned: "cd devices: disk devices: disk0: BIOS drive C pxe devices:" I can work around the problem by copying /boot from the FreeBSD 9 installer to my new FreeBSD 10 system, but I do believe this is not the right solution? And when I then boot off the system, I get a lot of other system errors. PS: my Mac does not have a real BIOS, so changing any BIOS settings is unfortunately not an option. I hope you can help me out and thanks in advance. Have a great day, everyone! Best wishes, Anders From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 09:44:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 230599D5 for ; Mon, 17 Dec 2012 09:44:57 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from qs3206.pair.com (qs3206.pair.com [216.92.131.43]) by mx1.freebsd.org (Postfix) with ESMTP id D9B028FC0C for ; Mon, 17 Dec 2012 09:44:56 +0000 (UTC) Received: from notebook.alkar.net (unknown [178.215.171.20]) by qs3206.pair.com (Postfix) with ESMTPSA id 36C23E604A; Mon, 17 Dec 2012 04:44:50 -0500 (EST) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: Re: X on ThinkPad X220 with chrome or firefox goes blank Date: Mon, 17 Dec 2012 11:44:59 +0200 Message-ID: <5770330.aKFb2b9JYM@notebook.alkar.net> User-Agent: KMail/4.9.3 (FreeBSD/10.0-CURRENT; KDE/4.9.3; amd64; ; ) In-Reply-To: <20121217084037.2ff6391a@X220.ovitrap.com> References: <20121217084037.2ff6391a@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Erich Dollansky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 09:44:57 -0000 Did you try to rebuild xorg-server with latest clang patch? (this patch commited 2-3 days ago) On Monday 17 December 2012 08:40:37 Erich Dollansky wrote: > Hi, > > I updated my notebook over the last couple of days and have now > problems starting chrome and firefox. The effect is that the screen > turns blury leaving hard to recognose characters on a white screen > after starting any of these applications. > > I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this is > now a flight in the dark. After entering Ctrl-C and restart X, I get a > new X running until I start firefox or chrome again. > > Applications like Claws Mail, Arora or xterm work without problems. > > I do not see anything different in the log file of X. > > Does anybody have a clue what could cause this? > > I will recompile and reinstall all my ports now to see what will come > out there. > > Erich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 11:50:54 2012 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27826FF9 for ; Mon, 17 Dec 2012 11:50:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id CE9138FC15 for ; Mon, 17 Dec 2012 11:50:53 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8d40:6f90:726d:a241] (unknown [IPv6:2001:7b8:3a7:0:8d40:6f90:726d:a241]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7662B5C5A; Mon, 17 Dec 2012 12:50:46 +0100 (CET) Message-ID: <50CF0715.7060300@FreeBSD.org> Date: Mon, 17 Dec 2012 12:50:45 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "Sam Fourman Jr." Subject: Re: Clang/LLVM revision 169451 References: <50CE2E29.4030906@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:50:54 -0000 On 2012-12-17 09:36, Sam Fourman Jr. wrote: >> No, there is no one-click merge script, it needs humanoid help, I'm >> afraid. :-) Is there any reason you cannot just install the port, or >> if that is too outdated, just checkout from llvm.org directly and build >> it? > > is it currently possible to build FreeBSD world, without clang and > then build clang from ports? There is no real need, as you can just put /usr/local/bin before /usr/bin in your PATH, but if you really want to do so, you can put the following in /etc/src.conf: CC=gcc CXX=g++ CPP=gcpp WITHOUT_CLANG= From then on, you build world with gcc, which will also be installed as /usr/bin/cc again. From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 11:55:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8A5924B for ; Mon, 17 Dec 2012 11:55:48 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 747098FC13 for ; Mon, 17 Dec 2012 11:55:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=INjpWdFxd8vds6oIydcWtrxcFvzs4Hfm9qxnwa3OZAc=; b=GaH4oWjGipvfNwXCiW6eE7PCcXHBQOpTGb8bE03cLf0K2oNsyxPZYLFj3S4fWAao4ubHOsrpIu0F/R6RlZ7MZXbm5RP0Ujr2U5bHPxua1uhup1NSabMTRJGVguAiJYER; Received: from [122.129.203.50] (port=39727 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TkZIL-000ZxE-Io; Mon, 17 Dec 2012 04:55:42 -0700 Date: Mon, 17 Dec 2012 18:55:37 +0700 From: Erich Dollansky To: Artyom Mirgorodskiy Subject: Re: X on ThinkPad X220 with chrome or firefox goes blank Message-ID: <20121217185537.4aaced2a@X220.ovitrap.com> In-Reply-To: <5770330.aKFb2b9JYM@notebook.alkar.net> References: <20121217084037.2ff6391a@X220.ovitrap.com> <5770330.aKFb2b9JYM@notebook.alkar.net> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:55:48 -0000 Hi, On Mon, 17 Dec 2012 11:44:59 +0200 Artyom Mirgorodskiy wrote: > Did you try to rebuild xorg-server with latest clang patch? (this > patch commited 2-3 days ago) I do not know as I updated the ports tree around this time. Let me do it again. Thanks for the hint. Erich > > On Monday 17 December 2012 08:40:37 Erich Dollansky wrote: > > Hi, > > > > I updated my notebook over the last couple of days and have now > > problems starting chrome and firefox. The effect is that the screen > > turns blury leaving hard to recognose characters on a white screen > > after starting any of these applications. > > > > I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this > > is now a flight in the dark. After entering Ctrl-C and restart X, I > > get a new X running until I start firefox or chrome again. > > > > Applications like Claws Mail, Arora or xterm work without problems. > > > > I do not see anything different in the log file of X. > > > > Does anybody have a clue what could cause this? > > > > I will recompile and reinstall all my ports now to see what will > > come out there. > > > > Erich > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 12:40:54 2012 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5773483; Mon, 17 Dec 2012 12:40:54 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2A28FC12; Mon, 17 Dec 2012 12:40:53 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so3159604eek.13 for ; Mon, 17 Dec 2012 04:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ETyYbx6+PYovWyGjZ6rJp5WONAfBwEVD952KR3C4xfw=; b=X8J3d0Iit17SkiA5gnA94DP8pknFLsYymyUfIizn/k1x2/n8kLg2N/FthJrSEnyeuY zrLJ+DcQFctxEjea3V0IXYPKlSWCT6Gqcr+FVAqiGzjrJwq1y9Os/DILkxVPbieiM6LU 8U8DrqvKBTFXuoqvZIrNZioNdNix4gtRsNGHaXlOgEUGoWAX2wKJP0HPwUpRo1tBKtws RyzkUK/Vfy1OsXjHpwNaUNkE6voI9yUft3ek64q6zF05x2nrU2IENOoODIas2/D1LvDq P1EG8VMCEUVUWR3Dn4bwt3m0exNKDyxyp5VhsmsHnzkAaHON0xa3j1nuecf01x+n/WMV u2HA== MIME-Version: 1.0 Received: by 10.14.209.193 with SMTP id s41mr41304670eeo.9.1355748052980; Mon, 17 Dec 2012 04:40:52 -0800 (PST) Received: by 10.14.4.68 with HTTP; Mon, 17 Dec 2012 04:40:52 -0800 (PST) In-Reply-To: <50CF0715.7060300@FreeBSD.org> References: <50CE2E29.4030906@FreeBSD.org> <50CF0715.7060300@FreeBSD.org> Date: Mon, 17 Dec 2012 07:40:52 -0500 Message-ID: Subject: Re: Clang/LLVM revision 169451 From: "Sam Fourman Jr." To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:40:54 -0000 On Mon, Dec 17, 2012 at 6:50 AM, Dimitry Andric wrote: > On 2012-12-17 09:36, Sam Fourman Jr. wrote: >>> >>> No, there is no one-click merge script, it needs humanoid help, I'm >>> afraid. :-) Is there any reason you cannot just install the port, or >>> if that is too outdated, just checkout from llvm.org directly and build >>> it? >> >> >> is it currently possible to build FreeBSD world, without clang and >> then build clang from ports? > > > There is no real need, as you can just put /usr/local/bin before > /usr/bin in your PATH, but if you really want to do so, you can put the > following in /etc/src.conf: > > CC=gcc > CXX=g++ > CPP=gcpp > WITHOUT_CLANG= > > From then on, you build world with gcc, which will also be installed as > /usr/bin/cc again. I ended up generating and applying this patch, and rebuilt world again root@www:/root # cat clang-169451.patch Index: contrib/llvm/tools/clang/include/clang/Sema/Scope.h =================================================================== --- contrib/llvm/tools/clang/include/clang/Sema/Scope.h (revision 244350) +++ contrib/llvm/tools/clang/include/clang/Sema/Scope.h (working copy) @@ -84,11 +84,18 @@ /// TryScope - This is the scope of a C++ try statement. TryScope = 0x1000, + /// CatchScope - This is the scope of a C++ catch statement. + CatchScope = 0x2000, + + /// FnTryCatchScope - This is the scope for a function-level C++ try or + /// catch scope. + FnTryCatchScope = 0x4000, + /// FnTryScope - This is the scope of a function-level C++ try scope. - FnTryScope = 0x3000, + FnTryScope = TryScope | FnTryCatchScope, /// FnCatchScope - This is the scope of a function-level C++ catch scope. - FnCatchScope = 0x4000 + FnCatchScope = CatchScope | FnTryCatchScope }; private: /// The parent scope for this scope. This is null for the translation-unit Index: contrib/llvm/tools/clang/lib/Parse/ParseStmt.cpp =================================================================== --- contrib/llvm/tools/clang/lib/Parse/ParseStmt.cpp (revision 244350) +++ contrib/llvm/tools/clang/lib/Parse/ParseStmt.cpp (working copy) @@ -2197,7 +2197,7 @@ // The name in a catch exception-declaration is local to the handler and // shall not be redeclared in the outermost block of the handler. ParseScope CatchScope(this, Scope::DeclScope | Scope::ControlScope | - (FnCatch ? Scope::FnCatchScope : 0)); + (FnCatch ? Scope::FnCatchScope : Scope::CatchScope)); // exception-declaration is equivalent to '...' or a parameter-declaration // without default arguments. Index: contrib/llvm/tools/clang/lib/Sema/IdentifierResolver.cpp =================================================================== --- contrib/llvm/tools/clang/lib/Sema/IdentifierResolver.cpp (revision 244350) +++ contrib/llvm/tools/clang/lib/Sema/IdentifierResolver.cpp (working copy) @@ -135,16 +135,13 @@ // of the controlled statement. // assert(S->getParent() && "No TUScope?"); - if (S->getFlags() & Scope::FnTryScope) - return S->getParent()->isDeclScope(D); if (S->getParent()->getFlags() & Scope::ControlScope) { - if (S->getParent()->getFlags() & Scope::FnCatchScope) { - S = S->getParent(); - if (S->isDeclScope(D)) - return true; - } + S = S->getParent(); + if (S->isDeclScope(D)) + return true; + } + if (S->getFlags() & Scope::FnTryCatchScope) return S->getParent()->isDeclScope(D); - } } return false; } From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 12:51:21 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A03D8A6; Mon, 17 Dec 2012 12:51:21 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5494E8FC12; Mon, 17 Dec 2012 12:51:21 +0000 (UTC) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id B26358BE; Mon, 17 Dec 2012 12:43:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id GLtM4nmvmp1C; Mon, 17 Dec 2012 12:42:37 +0000 (UTC) Received: from [192.168.1.1] (a89-152-58-56.cpe.netcabo.pt [89.152.58.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTPSA id BA2438BD; Mon, 17 Dec 2012 12:42:36 +0000 (UTC) Message-ID: <50CF132A.9020804@barafranca.com> Date: Mon, 17 Dec 2012 12:42:18 +0000 From: Hugo Silva User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Robert Watson Subject: Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:51:21 -0000 On 12/01/12 15:15, Robert Watson wrote: > > Dear all: > > I've now committed the build glue required to install the recently > merged Audit Distribution Daemon (auditdistd) contributed by the Pawel > Dawidek, and sponsored by the FreeBSD Foundation. This allows > individual hosts generating audit trails to submit trails to a central > audit server for review and safe keeping. Part of the goal is to ensure > that a host submitting trail data can't later modify the trails. Pawel > uses a variety of useful security- and resilience-related features such > as TLS, Capsicum, etc, in auditdistd. As the recent security incident > in the FreeBSD.org cluster illustrated, having reliable and detailed > audit trails makes a big difference in forensic work, and hopefully this > will allow the FreeBSD Project (and our users) to do that better in the > future. > > Robert N M Watson > Computer Laboratory > University of Cambridge Wonderful! Personally I think this is a very worthy addition to the project and I would like to congratulate and thank everyone involved in this work. From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 12:56:52 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16214BCB for ; Mon, 17 Dec 2012 12:56:52 +0000 (UTC) (envelope-from andersbo87@icloud.com) Received: from st11p00mm-asmtp002.mac.com (st11p00mm-asmtp002.mac.com [17.172.81.1]) by mx1.freebsd.org (Postfix) with ESMTP id D439E8FC12 for ; Mon, 17 Dec 2012 12:56:51 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.253] (ti0025a380-1699.bb.online.no [80.213.202.165]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTPSA id <0MF6001CSBUHAP20@st11p00mm-asmtp002.mac.com> for current@FreeBSD.org; Mon, 17 Dec 2012 11:56:45 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2012-12-17_02:2012-12-17,2012-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1212170064 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 17 Dec 2012 12:56:40 +0100 Subject: Re: Problem booting FreeBSD 10-CURRENT from my MacBook Pro: "Can't load kernel" From: Anders Bolt-Evensen To: "current@FreeBSD.org" Message-id: Thread-topic: Problem booting FreeBSD 10-CURRENT from my MacBook Pro: "Can't load kernel" In-reply-to: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:56:52 -0000 Update: I said: "I can work around the problem by copying /boot from the FreeBSD 9 installer to my new FreeBSD 10 system, but I do believe this is not the right solution? And when I then boot off the system, I get a lot of other system errors." It appeared that those other errors occurred because I forgot to copy the kernel for FreeBSD 10 into the boot directory I copied from the FreeBSD 9 installer. However, du any of you have any solution how to get rid of the "Can't load kernel" error without booting off the FreeBSD 9 installer and copy the boot directory? Once again, any help would be appreciated. -Anders On 17.12.2012 09:10, "Anders Bolt-Evensen" wrote: >Hi, everyone and good morning! To make a long story short I'm attempting >to >install 10-CURRENT on my 2011 model 17 inch MacBook Pro. I downloaded the >appropriate amd64 image from FreeBSD's FTP site, burned it out to DVD and >installed it on my old FreeBSD 9 partition, erasing existing data. >However, >when I try to boot the new system, I get a "can't load kernel" error. >Giving >the command "ls" returns the message "Open '/' failed: no such file or >directory". >When I type "lsdev" the following is returned: >"cd devices: >disk devices: > disk0: BIOS drive C >pxe devices:" >I can work around the problem by copying /boot from the FreeBSD 9 >installer >to my new FreeBSD 10 system, but I do believe this is not the right >solution? And when I then boot off the system, I get a lot of other system >errors. >PS: my Mac does not have a real BIOS, so changing any BIOS settings is >unfortunately not an option. > >I hope you can help me out and thanks in advance. > >Have a great day, everyone! >Best wishes, >Anders > > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 12:57:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2E59CD7; Mon, 17 Dec 2012 12:57:31 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92D258FC17; Mon, 17 Dec 2012 12:57:30 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so4587583lah.13 for ; Mon, 17 Dec 2012 04:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8mwtH2xHw8BLf+pBELb9zOvsnhHDLl/4FwJP1KNCong=; b=Gsy+W4Arbe3eqFBZXdVwfx+vXx4UW7x7xIcOiB2Hr56nJ/FRJGi7lfx7kXflPCL5N5 xP+GEsgMaGC/CYsZ0AFB4z6ftgQDe8GUB4zX15XZRb284fLiyK8naopSIAL+QlWdem+W 1qFJsEusimajab/j1R2iiO8c8ORJBiXYlHuZ62rXdaijv5Ifx8MBTTtO8tiOc8ssBZp1 DPYptH4RaQUjdv4H/u1nJh1iVGPpCRpbgcYM1G2rVXNJLYx81JLML9FnASHVEQXTSI0h vEPgLqlqCEH/4T2azv0ZYkGkeIfzVf+0xqvgYv2nDuIiFFQg1HQJg9bXFGwaCev33Dpg 8O9Q== Received: by 10.112.44.135 with SMTP id e7mr5920253lbm.55.1355749049271; Mon, 17 Dec 2012 04:57:29 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id pm16sm4880860lab.8.2012.12.17.04.57.26 (version=SSLv3 cipher=OTHER); Mon, 17 Dec 2012 04:57:28 -0800 (PST) Message-ID: <50CF16B0.9090104@gmail.com> Date: Mon, 17 Dec 2012 14:57:20 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> In-Reply-To: <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:57:31 -0000 13.12.2012 12:25, Andriy Gapon: > on 12/12/2012 21:35 Dimitry Andric said the following: >> Especially the recursive spa_load and traverse_visitbp calls are scary, >> because that can grow out of hand very quickly. It is probably tricky >> to remove the recursion... > > Re-entering spa_load once is normal and is expected. > traverse_visitbp is also expected to recurse depending on data layout. > So yeah, it's probably even trickier than teaching clang to allocate smaller stack > frames ;-) I hit this one again, but this time my world and kernel are compiled with stock gcc. Pictures 3 to 5: https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault This happens on mounting root after unclean shutdown. I fixed my pool with booting amd64 kernel, after this i386 kernel starts fine. Maybe it's just time to accept that ZFS on i386 is not stable? Current handbook elaborates on ZFS like it's known to work on i386. -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 07:16:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAF92DF6; Mon, 17 Dec 2012 07:16:09 +0000 (UTC) (envelope-from mr.kodiak@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB7C8FC14; Mon, 17 Dec 2012 07:16:09 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id x2so5046170iad.13 for ; Sun, 16 Dec 2012 23:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=bP2afdEn3yowvQUmMkbDIaIewlN3Ys/gKZNzRyY2pEs=; b=tmrlr8t4g3OkSNmZXfhkr7A/yaSdkSsMYdGbc1Mel7ril4qSBtWwala3PySJ9JaO7h IfDj/O1iR1n/SF15iM+019rYS4uiJ1z/cFbYyDg5tc6AN+wsLzU+5r0XCg1qp1YxqFk7 lfb4saO+vsXWG9mBRZRDG1D8c4MTiT1BYwWQSPT6X4HZhAOqbvhSnWGODdKJU9OXkWFf aNOc56xgGz6hZRaZ16beELJ7S9kRdw516b0HW8wEHok/giHRhbj7AzSs6PRx78dCdrBP 9gHX3C7rKMUVCFTAs0Dp5CvebUYH8X4kZjO/0o1BSE5hiekf3aQJHh9SifFmTUrM9YMi sg9g== Received: by 10.50.33.147 with SMTP id r19mr8246780igi.73.1355728568735; Sun, 16 Dec 2012 23:16:08 -0800 (PST) MIME-Version: 1.0 Sender: mr.kodiak@gmail.com Received: by 10.64.41.133 with HTTP; Sun, 16 Dec 2012 23:15:38 -0800 (PST) In-Reply-To: References: From: Bryan Venteicher Date: Mon, 17 Dec 2012 01:15:38 -0600 X-Google-Sender-Auth: wOTGi0DaRy-Jyiw_eUssiHTTHds Message-ID: Subject: Re: VirtIO in GENERIC To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 17 Dec 2012 13:44:23 +0000 Cc: Jim Harris , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:16:09 -0000 On Mon, Dec 17, 2012 at 12:06 AM, Andrew Thompson wrote: > On 17 December 2012 18:06, Jim Harris wrote: >> >> >> >> On Sun, Dec 16, 2012 at 6:53 PM, Andrew Thompson >> wrote: >>> >>> On 17 December 2012 13:17, Bryan Venteicher wrote: >>> >>> > There's been lots of requests to have VirtIO in GENERIC for i386 and >>> > amd64. Anybody have any issues or concerns with this or the patch at >>> > [1]. This also removes the kludge that was introduced in r239009. >>> > >>> > I've compiled LINT for i386 and amd64 so hopefully there won't be any >>> > surprise breakages. >>> > >>> > [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch >>> >>> >>> It would be great to have the drivers enabled. You do not need the >>> sys/conf/files changes, the common and arch files are combined. >>> >> >> Removing the virtio files from sys/conf/files ensures these drivers can >> only be specified in x86 kernel configuration files. r239009 added these >> lines to sys/conf/files, but Bryan's patch does it more correctly. > > Yes, I think the patch is correct for what I intended - support for x86 only (for now). > Linux supports virtio on ARM so I dont think its necessarily x86 MD. I guess > it can be moved back later. > I think VirtIO on ARM (on QEMU) effectively requires VirtIO-MMIO, which we don't support yet. And virtio_pci is probably missing some bus_space_barriers() required for non-x86. Both are on my TODO, but nobody has prodded me about either yet. > > Andrew From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 14:28:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7184CA13 for ; Mon, 17 Dec 2012 14:28:11 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 315AB8FC14 for ; Mon, 17 Dec 2012 14:28:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=lY2h/1nTX0pSrTVDewb2ME9Pqq1BV2AN+trWpztFTv8=; b=TlqmzFtgWlYbM6lTD3DOLnaY/VJSRrtlDj7Pe4+mmI7W4NOOQL3tljhJMvqnV9eeZwkftUjXeIVo1whkhpM7rX0VOWOBqxz80kYJE5LPUnvTYTy3+DrtduarZmkUYpU5; Received: from [122.129.203.50] (port=58477 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tkbfu-001JkT-2G; Mon, 17 Dec 2012 07:28:10 -0700 Date: Mon, 17 Dec 2012 21:28:07 +0700 From: Erich Dollansky To: Artyom Mirgorodskiy Subject: Re: X on ThinkPad X220 with chrome or firefox goes blank Message-ID: <20121217212807.0bcb07e6@X220.ovitrap.com> In-Reply-To: <5770330.aKFb2b9JYM@notebook.alkar.net> References: <20121217084037.2ff6391a@X220.ovitrap.com> <5770330.aKFb2b9JYM@notebook.alkar.net> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:28:11 -0000 Hi, On Mon, 17 Dec 2012 11:44:59 +0200 Artyom Mirgorodskiy wrote: > Did you try to rebuild xorg-server with latest clang patch? (this > patch commited 2-3 days ago) it seems that my X server was a bit too old. I just upgraded and all works fine now? Thanks! Erich > > On Monday 17 December 2012 08:40:37 Erich Dollansky wrote: > > Hi, > > > > I updated my notebook over the last couple of days and have now > > problems starting chrome and firefox. The effect is that the screen > > turns blury leaving hard to recognose characters on a white screen > > after starting any of these applications. > > > > I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this > > is now a flight in the dark. After entering Ctrl-C and restart X, I > > get a new X running until I start firefox or chrome again. > > > > Applications like Claws Mail, Arora or xterm work without problems. > > > > I do not see anything different in the log file of X. > > > > Does anybody have a clue what could cause this? > > > > I will recompile and reinstall all my ports now to see what will > > come out there. > > > > Erich > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 19:07:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1728C697; Mon, 17 Dec 2012 19:07:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BE2248FC13; Mon, 17 Dec 2012 19:07:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 606BF7300A; Mon, 17 Dec 2012 20:06:20 +0100 (CET) Date: Mon, 17 Dec 2012 20:06:20 +0100 From: Luigi Rizzo To: Alexander Motin Subject: calloutng and dummynet (Re: [RFC/RFT] calloutng) Message-ID: <20121217190620.GA83203@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50CED465.3010501@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CED465.3010501@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Garrett Cooper , Davide Italiano , Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:07:49 -0000 On Mon, Dec 17, 2012 at 10:14:29AM +0200, Alexander Motin wrote: > On 17.12.2012 05:38, Adrian Chadd wrote: ... > >Maybe hit up the altq/pf using crowd and see if they'll test this stuff > >out too? > > It would be good to test, though I know that at least dummynet is > written awful from the point of this project with its > callout_reset(&dn_timeout, 1, dummynet, NULL); > It should work, but kill most of power benefits. I was promised it will > be fixed after this project end. never trust italians :) but it is good that you are reminding me this, hopefully i will be able to give it a shot after the holidays cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 19:28:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 995E92C6; Mon, 17 Dec 2012 19:28:52 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 50B7D8FC0C; Mon, 17 Dec 2012 19:28:52 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CF1B17300A; Mon, 17 Dec 2012 20:27:31 +0100 (CET) Date: Mon, 17 Dec 2012 20:27:31 +0100 From: Luigi Rizzo To: Davide Italiano Subject: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng Message-ID: <20121217192731.GA83405@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:28:52 -0000 [addressing the various items separately] On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote: > On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: ... > > - for several functions the only change is the name of an argument > > from "busy" to "us". Can you elaborate the reason for the change, > > and whether "us" means microseconds or the pronoun ?) > > > > Please see r242905 by mav@. i see the goal of this patch is to pass along the amount of time till the next timer. I wonder why the choice is to use (actually, call) the value "microseconds" rather use a bintime or something scaled and with a well defined resolution. In fact looking at the relevant diff http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905&r2=242904&pathrev=242905 cpu_idleclock() actually returns a value that is not even microseconds but 1/(2^20) seconds. The value seems to be ignored right now so it would be a good time to discuss the resolution. I am concerned that at some point (5 years from now perhaps ?) microseconds might start to become too coarse and we would like something with a more fine-grained resolution. On the other hand, for the purposes of this change, we can probably live with an upper limit of some seconds (waking up the machine once per second is not going to kill performance). So i would suggest to make the argument to these functions uint_32 or uint_64 (preferably the same for 32- and 64-bit machines), rename it to something different from 'us' and have at least 28-30 fractional bits to represent a bintime. Right now you are using a bintime with 20 fractional and 11 or 43 bits for the integer part. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 19:59:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3208DC41; Mon, 17 Dec 2012 19:59:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 679BC8FC14; Mon, 17 Dec 2012 19:59:45 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2782571wgh.31 for ; Mon, 17 Dec 2012 11:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=CVxVzJmOM1P1VQmTd5HRCxSNaY494vnOGnGSy77hHng=; b=0q3GrivsgQyVGHiIWG0cMfWQa9rN1+za+GLH6QWvMQ1fImO1P2LUpqnPDc1af3SLWN wHLwy95OoE5CQ+k/5MxtvapYL7yk6bYj/zfcAQHwNrANB1LLaURoxpgBxcJKhFKRkJh4 scZJZceJsO4UtccppeUK84apuNoHX/1oajlG9GVbDRTL3+xBLYvEL3BmqtKxs/tovJs0 0+478P/wmJMBHTpFjKIS/swUDvsypF1C/HVbnI40WmvmG4ZW453s5lDnaLnJelmk+pA0 AxSHmqC88cbWE2BohE7IiKWg1dRnCJFYFd2p0GIma8J+NMP/DbRadjxRizharIClRezt r4kg== Received: by 10.180.97.68 with SMTP id dy4mr17502497wib.7.1355774384480; Mon, 17 Dec 2012 11:59:44 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id u6sm14120591wif.2.2012.12.17.11.59.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 11:59:43 -0800 (PST) Sender: Alexander Motin Message-ID: <50CF79AD.9040600@FreeBSD.org> Date: Mon, 17 Dec 2012 21:59:41 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: rizzo@iet.unipi.it Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:59:46 -0000 Hi. > I wonder why the choice is to use (actually, call) the value > "microseconds" rather use a bintime or something scaled and with a > well defined resolution. It was kind of engineering choice. I've chosen microseconds, following values used by ACPI to represent CPU sleep states exit latencies. Now that is the only usage for that value. If CPUs so much reduce wakeup latencies to make this scale too coarse, this type will be the smallest of our optimization tasks. On the other side, I have some doubts that we will be able to reach supported 2048 seconds limit on the integer side. Now even completely empty idle system has about 30 interrupts per second, that is far from 0.0005. From the other side, I don't know any system where CPUs have 2048 seconds wakeup latency. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 20:02:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C9A3F3; Mon, 17 Dec 2012 20:02:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D94858FC13; Mon, 17 Dec 2012 20:02:22 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 68BF97300A; Mon, 17 Dec 2012 21:01:02 +0100 (CET) Date: Mon, 17 Dec 2012 21:01:02 +0100 From: Luigi Rizzo To: Davide Italiano Subject: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121217200102.GA83832@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:02:23 -0000 [again, response to another issue i raised] On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote: > On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: ... > > Finally, a more substantial comment: > > - a lot of functions which formerly had only a "timo" argument > > now have "timo, bt, precision, flags". Take seltdwait() as an example. > > > > seltdwait() is not part of the public KPI. It has been modified to > avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e. > two separate functions, even though we could share most of the code is > not a clever approach, IMHO. > As I told before, seltdwait() is not exposed so we can modify its > argument without breaking anything. > > > It seems that you have been undecided between two approaches: > > for some of these functions you have preserved the original function > > that deals with ticks and introduced a new one that deals with the > > bintime, > > whereas in other cases you have modified the original function to add > > "bt, precision, flags". > > > > I'm not. All the functions which are part of the public KPI (e.g. > condvar(9), sleepq(9), *) are still available. *_flags variants have > been introduced so that consumers can take advantage of the new > 'precision tolerance mechanism' implemented. Also, *_bt variants have > been introduced. I don't see any "undecision" between the two > approaches. > Please note that now the callout backend deals with bintime, so every > time callout_reset_on() is called, the 'tick' argument passed is > silently converted to bintime. I will try to give more specific example, using the latest patch from mav http://people.freebsd.org/~mav/calloutng_12_16.patch In the manpage, for instance, the existing functions now are extended with two more variants (sometimes; msleep_spin() for instance is missing msleep_spin_bt() but perhaps that is just an oversight). .Nm sleepq_set_timeout , +.Nm sleepq_set_timeout_flags , +.Nm sleepq_set_timeout_bt , .Nm msleep , +.Nm msleep_flags , +.Nm msleep_bt , .Nm msleep_spin , +.Nm msleep_spin_flags , .Nm pause , +.Nm pause_flags , +.Nm pause_bt , .Nm tsleep , +.Nm tsleep_flags , +.Nm tsleep_bt , .Nm cv_timedwait , +.Nm cv_timedwait_bt , +.Nm cv_timedwait_flags , .Nm cv_timedwait_sig , +.Nm cv_timedwait_sig_bt , +.Nm cv_timedwait_sig_flags , .Nm callout_reset , +.Nm callout_reset_flags , .Nm callout_reset_on , +.Nm callout_reset_flags_on , +.Nm callout_reset_bt_on , If you look at the backends, they take both a timo and a bintime. -int _cv_timedwait(struct cv *cvp, struct lock_object *lock, int timo); -int _cv_timedwait_sig(struct cv *cvp, struct lock_object *lock, int timo); +int _cv_timedwait(struct cv *cvp, struct lock_object *lock, + struct bintime *bt, struct bintime *precision, int timo, + int flags); +int _cv_timedwait_sig(struct cv *cvp, struct lock_object *lock, + struct bintime *bt, struct bintime *precision, int timo, + int flags); and then internally they call the 'timo' or the 'bt' version depending on the case + if (bt == NULL) + sleepq_set_timeout_flags(cvp, timo, flags); + else + sleepq_set_timeout_bt(cvp, bt, precision); So basically you are doing the following: + create two new variant for each existing function foo(, ... timo, ... ) old method foo_flags(, ... timo, ... ) new method foo_bt(... , bt, precision, ...) new method (the 'API explosion' i am mentioning in the Subject) + the variants are mapped to the same internal function _foo_internal(..., timo, bt, precision, flags, ...) + and then the internal function has a (runtime) conditional if (bt == NULL) { // convert timo to bt } else { // have a bt + precision } ... I would instead do the following: + create a new API function that takes only bintime+precision+flags, no ticks. I am not sure if there is even a need to have an internal name _cv_timedwait_sig( .... ) or you can just have cv_timedwait_sig_bt(...) + use a macro or an inline function to remap the old API to the (single) new one, making the argument conversion immediately. #define cv_timedwait_sig(...) cv_timedwait_sig_bt( ...) This has the advantage that conversions might be done at compile time perhaps with some advantage in terms of code and performance. + do not bother creating yet another cv_timedwait_sig_flags() function. Since it did not exist before, you have to do the conversion manually anyways, at which point you just change the argument to use bintime instead of ticks. Note that what i am proposing is a simplification of your code and should not require much extra effort. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 20:17:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 041128C6; Mon, 17 Dec 2012 20:17:56 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 853D38FC0A; Mon, 17 Dec 2012 20:17:55 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so7768137vba.13 for ; Mon, 17 Dec 2012 12:17:54 -0800 (PST) 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=dgTMgSHlhvv2LNpvLOg3HmEKKueXCoDfISnnecrQaH4=; b=vDNtf0VWQtycePzfTy/Fd95STGm2kvY1RTAmhZGVDExFhO20d8MVqDMK9bSHvdk29F 0Xs+wnho935+Sr8RT9/3+BVG40CBG3DZhha7OavodTqTWd0E4AwJeTyegmVpe7592/Oo eypEN23eiyly3vkgEiJ/Y3bTw+ORd88WNIRm4TPMWcyahhhDMkDDGMt00fk1YqiHOOdp 6I7kVMG33gKhsobZHWz75pWqkEaC1bNBZZjzr/SZECqHjwNwGDNktQKaAxueay9/OZ1I H2v7fhiBnD/levRsU0prVixJDEOr2zr8NN/344gpJr0jhqwex+e4uiQTRFiuBlwScPVy 0DgQ== MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr22146251vdt.30.1355775474752; Mon, 17 Dec 2012 12:17:54 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Mon, 17 Dec 2012 12:17:54 -0800 (PST) In-Reply-To: <20121217192731.GA83405@onelab2.iet.unipi.it> References: <20121217192731.GA83405@onelab2.iet.unipi.it> Date: Mon, 17 Dec 2012 12:17:54 -0800 X-Google-Sender-Auth: 2atf83R1CkUURAQQX-9NZ0rna8M Message-ID: Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng From: Davide Italiano To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:17:56 -0000 On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo wrote: > [addressing the various items separately] > > On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote: >> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: > ... >> > - for several functions the only change is the name of an argument >> > from "busy" to "us". Can you elaborate the reason for the change, >> > and whether "us" means microseconds or the pronoun ?) >> > >> >> Please see r242905 by mav@. > > i see the goal of this patch is to pass along the amount of > time till the next timer. > > I wonder why the choice is to use (actually, call) the value > "microseconds" rather use a bintime or something scaled and with a > well defined resolution. > > In fact looking at the relevant diff > > http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905&r2=242904&pathrev=242905 > > cpu_idleclock() actually returns a value that is not even microseconds > but 1/(2^20) seconds. The value seems to be ignored right now > so it would be a good time to discuss the resolution. > > I am concerned that at some point (5 years from now perhaps ?) > microseconds might start to become too coarse and we would like > something with a more fine-grained resolution. On the > other hand, for the purposes of this change, we can probably > live with an upper limit of some seconds (waking up the machine > once per second is not going to kill performance). > I would talk more about power consumption problem rather than performances. Yes, you're right because now, even with calloutng changes, the CPU is woken up at least twice per second. The wheel scan, in case it doesn't find a new callout to schedule in the next half-second, schedules an interrupt half a second from "now" (where now is the time obtained using getbinuptime()/binuptime()). This is a threshold we set up empirically, and it resulted is "good" for now. But in the future someone may raise the threshold to 1 second, 10 seconds, or something like. So, I don't agree with your statement. > So i would suggest to make the argument to these functions > uint_32 or uint_64 (preferably the same for 32- and 64-bit machines), > rename it to something different from 'us' > and have at least 28-30 fractional bits to represent a bintime. > > Right now you are using a bintime with 20 fractional and 11 or 43 > bits for the integer part. > > > cheers > luigi Thanks Davide From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 21:03:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33FA49C2; Mon, 17 Dec 2012 21:03:59 +0000 (UTC) (envelope-from mavbsd@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 5E3B88FC12; Mon, 17 Dec 2012 21:03:58 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so3022735wey.13 for ; Mon, 17 Dec 2012 13:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=BSdFSZV7b+8Je0QAPEO+KvvoTC+MZ3f0TujYVgfjsJE=; b=iARPxZ6cMYac1CYvTjyUBzHk7GuXZnuNTdrCBK/1tCTohajTh5+oLIIX9k1I1LkOFR zjmYDn5gXX4U6RgQc/c7onTnOIeuY6OWBCg08Gy++1cSsvo4nMm6UiQiw59sKJdMWwJ7 0vCy8anjZ3NbXOSwAofkuTQEQX+rMAWPlaAFY9qDcETCypYCQ+PJpngIbR88OvFTehCA k/bm9LnthNCDIqdVgDjJkAsPdVBt4puaHc/DUMgcZ5WlSjNjfdKbrWxWCGWrvNITKFjX WY3SRiQh3XI7iHINYdFAZAfLR2kLaJHuuzJrvHFpahtphost9CnYIc6c5h/lupOr2VAV Avrw== Received: by 10.180.87.102 with SMTP id w6mr17883446wiz.19.1355778236465; Mon, 17 Dec 2012 13:03:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id i6sm12853292wix.5.2012.12.17.13.03.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 13:03:55 -0800 (PST) Sender: Alexander Motin Message-ID: <50CF88B9.6040004@FreeBSD.org> Date: Mon, 17 Dec 2012 23:03:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:03:59 -0000 Hi. > I would instead do the following: I also don't very like the wide API and want to hear fresh ideas, but approaches to time measurement there are too different to do what you are proposing. Main problem is that while ticks value is relative, bintime is absolute. It is not easy to make conversion between them fast and precise. I've managed to do it, but the only function that does it now is _callout_reset_on(). All other functions are just passing values down. I am not sure I want to duplicate that code in each place, though doing it at least for for callout may be a good idea. Creating sets of three functions I had three different goals: - callout_reset() -- it is legacy variant required to keep API compatibility; - callout_reset_flags() -- it is for cases where custom precision specification needs to be added to the existing code, or where direct callout execution is needed. Conversion to bintime would additionally complicate consumer code, that I would try to avoid. - callout_reset_bt() -- API for the new code, which needs high precision and doesn't mind to operate bintime. Now there is only three such places in kernel now, and I don't think there will be much more. Respectively, these three options are replicated to other APIs where time intervals are used. PS: Please keep me in CC. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 21:12:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE114D98; Mon, 17 Dec 2012 21:12:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 95E458FC15; Mon, 17 Dec 2012 21:12:33 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D07967300A; Mon, 17 Dec 2012 22:11:12 +0100 (CET) Date: Mon, 17 Dec 2012 22:11:12 +0100 From: Luigi Rizzo To: Davide Italiano Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng Message-ID: <20121217211112.GA84347@onelab2.iet.unipi.it> References: <20121217192731.GA83405@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:12:33 -0000 On Mon, Dec 17, 2012 at 12:17:54PM -0800, Davide Italiano wrote: > On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo wrote: > > [addressing the various items separately] > > > > On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote: > >> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: > > ... > >> > - for several functions the only change is the name of an argument > >> > from "busy" to "us". Can you elaborate the reason for the change, > >> > and whether "us" means microseconds or the pronoun ?) > >> > > >> > >> Please see r242905 by mav@. > > > > i see the goal of this patch is to pass along the amount of > > time till the next timer. > > > > I wonder why the choice is to use (actually, call) the value > > "microseconds" rather use a bintime or something scaled and with a > > well defined resolution. > > > > In fact looking at the relevant diff > > > > http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905&r2=242904&pathrev=242905 > > > > cpu_idleclock() actually returns a value that is not even microseconds > > but 1/(2^20) seconds. The value seems to be ignored right now > > so it would be a good time to discuss the resolution. > > > > I am concerned that at some point (5 years from now perhaps ?) > > microseconds might start to become too coarse and we would like > > something with a more fine-grained resolution. On the > > other hand, for the purposes of this change, we can probably > > live with an upper limit of some seconds (waking up the machine > > once per second is not going to kill performance). > > > > I would talk more about power consumption problem rather than performances. > Yes, you're right because now, even with calloutng changes, the CPU is > woken up at least twice per second. > The wheel scan, in case it doesn't find a new callout to schedule in > the next half-second, schedules an interrupt half a second from "now" > (where now is the time obtained using getbinuptime()/binuptime()). > This is a threshold we set up empirically, and it resulted is "good" > for now. But in the future someone may raise the threshold to 1 > second, 10 seconds, or something like. So, I don't agree with your > statement. this is only an issue if we want to use 32 bits. If we go to 64 bits, there is enogh space for picoseconds on the fractional part, and a few years in the integer part. but keep in mind, even powerwise, i doubt the exit from deep sleep and a callout takes more than 500us so even doing that once per second gives less than 0.5 per mille increase in power compared to a machine that is always idle This is really noise that we should not worry about. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 21:54:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78B86450; Mon, 17 Dec 2012 21:54:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by mx1.freebsd.org (Postfix) with ESMTP id AAA328FC12; Mon, 17 Dec 2012 21:54:32 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id x48so2973194wey.8 for ; Mon, 17 Dec 2012 13:54:26 -0800 (PST) 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=5s2Y48be157PAg2mxRaAAWvMFobgVyxf3UwS9g2FFvc=; b=Gx9k2yP3Pey6Zpf8wudzTbPgkiJkSweuyvUi11a5lBJTVvVuqK9Cb7tr4x71K5F1O/ fBDFayr32c5mOPz1f550mB7+Pb1lDdOVyDE6jNhIevqYEmyZ2T+rw9almhqc4snjvBdZ Ej+XGehKesuh24T8mafu8p4zc8wIToyMvin5FIl7OcASX0EuNfwDLIRbeXVKZMWaAu7f 6Bd93ReDogU7xH7tU69hQ+1KyYqTwx0PZu9h45wuRaLWy+9rRlcT0SRZOzXHbjj90MWD heWjbXV6hGWZhEzoYAu5ay5WZ5A151EYpAztAkOnSwZJ2206jG+0TZHi/uN+lqRLxCJQ PgEw== MIME-Version: 1.0 Received: by 10.180.24.4 with SMTP id q4mr14835wif.19.1355779379090; Mon, 17 Dec 2012 13:22:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Mon, 17 Dec 2012 13:22:59 -0800 (PST) In-Reply-To: <20121217211112.GA84347@onelab2.iet.unipi.it> References: <20121217192731.GA83405@onelab2.iet.unipi.it> <20121217211112.GA84347@onelab2.iet.unipi.it> Date: Mon, 17 Dec 2012 13:22:59 -0800 X-Google-Sender-Auth: yElOrvB5M6U2oSN7CV9Sg3YZFE4 Message-ID: Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:54:33 -0000 Personally, I'd rather see some consistently used units here.. Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 22:18:50 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3ED192C0; Mon, 17 Dec 2012 22:18:50 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CC47C8FC16; Mon, 17 Dec 2012 22:18:49 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 529438A3FC; Mon, 17 Dec 2012 22:18:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBHMIlI2006709; Mon, 17 Dec 2012 22:18:47 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Motin Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng In-reply-to: <50CF79AD.9040600@FreeBSD.org> From: "Poul-Henning Kamp" References: <50CF79AD.9040600@FreeBSD.org> Date: Mon, 17 Dec 2012 22:18:47 +0000 Message-ID: <6708.1355782727@critter.freebsd.dk> Cc: Davide Italiano , freebsd-current , rizzo@iet.unipi.it, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:18:50 -0000 -------- In message <50CF79AD.9040600@FreeBSD.org>, Alexander Motin writes: >Hi. > > > I wonder why the choice is to use (actually, call) the value > > "microseconds" rather use a bintime or something scaled and with a > > well defined resolution. > >It was kind of engineering choice. I've chosen microseconds [...] And that was the wrong choice, the format should be a binary number so arithmetic and comparisons does not become a nightmare. If people need milliseconds or microseconds, they can get that using suitable #defined multiplication factors. A 64 bit type, with 32bit before and after the binary point would be sufficient for now, and easily extensible to something larger should one or more laws of computing nature be changed. So do the following: typedef dur_t int64_t; /* signed for bug catching */ #define DURSEC ((dur_t)1 << 32) #define DURMIN (DURSEC * 60) #define DURMSEC (DURSEC / 1000) #define DURUSEC (DURSEC / 10000000) #define DURNSEC (DURSEC / 100000000000) And stop crapping around with mixed-radix numbers, even the british changed to decimal coinage to avoid that crap... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 22:20:30 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8673857C; Mon, 17 Dec 2012 22:20:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 666CD8FC18; Mon, 17 Dec 2012 22:20:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00155; Tue, 18 Dec 2012 00:20:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tkj2v-0005rx-Up; Tue, 18 Dec 2012 00:20:25 +0200 Message-ID: <50CF9AA9.1030808@FreeBSD.org> Date: Tue, 18 Dec 2012 00:20:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> <50CF16B0.9090104@gmail.com> In-Reply-To: <50CF16B0.9090104@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:20:30 -0000 on 17/12/2012 14:57 Volodymyr Kostyrko said the following: > 13.12.2012 12:25, Andriy Gapon: >> on 12/12/2012 21:35 Dimitry Andric said the following: >>> Especially the recursive spa_load and traverse_visitbp calls are scary, >>> because that can grow out of hand very quickly. It is probably tricky >>> to remove the recursion... >> >> Re-entering spa_load once is normal and is expected. >> traverse_visitbp is also expected to recurse depending on data layout. >> So yeah, it's probably even trickier than teaching clang to allocate smaller >> stack >> frames ;-) > > I hit this one again, but this time my world and kernel are compiled with stock > gcc. Pictures 3 to 5: > > https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault > > This happens on mounting root after unclean shutdown. I fixed my pool with > booting amd64 kernel, after this i386 kernel starts fine. > > Maybe it's just time to accept that ZFS on i386 is not stable? Current handbook > elaborates on ZFS like it's known to work on i386. Yes, it is known to work. It's been already mentioned many times that ZFS works much better on amd64. It's up to a (potential) user to understand limitations of i386 and to decide whether to use ZFS, in what situations and how. You may want to consider using KSTACK_PAGES=4 in your kernel configuration. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 22:39:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id D504FC9D; Mon, 17 Dec 2012 22:39:43 +0000 (UTC) Date: Mon, 17 Dec 2012 14:39:43 -0800 From: David O'Brien To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20121217223943.GA88856@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Alexander Motin , Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Mark Johnston References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> <50CCE59F.1080107@FreeBSD.org> <50CCE7F6.2090505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CCE7F6.2090505@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Davide Italiano , Mark Johnston , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:39:43 -0000 On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote: > On 15.12.2012 23:03, Alexander Motin wrote: > > Sorry, it's my fault. I've tried to save some time on patch generation > > and forgot about that change in lib/. We haven't touched user-level in > > our work except that file. Here is patch with that chunk added: > > http://people.freebsd.org/~mav/calloutng_12_15_1.patch > > And one more part I've missed is manual pages update, that probably > needs more improvements: > http://people.freebsd.org/~mav/calloutng_12_15.man.patch Perhaps use the SCM at what its good at? Sync your branch with HEAD and then do an 'svn diff ^/head' and your branch. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 22:53:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9DE83BE; Mon, 17 Dec 2012 22:53:34 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 302AF8FC17; Mon, 17 Dec 2012 22:53:34 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so5898303vcb.13 for ; Mon, 17 Dec 2012 14:53:33 -0800 (PST) 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:content-type; bh=H6KlhSiR6C2nko2l4TkcphHSJnA30idh3OLsi8lL+jU=; b=om6qrOk72mWOCMhzNyu/HQjEU/aku5j/YI0jvbNdPuRJmhmrJbqBgSesx95FGcnwFl z35cTj3Tm7YzxjLqgFMjjnzqM3MvWyicHlNYvnISJeKCNXknFMb2QCDrWMrJjSlpYqmI WwdF931alSCgb2iIpnq5CyUS4sVNB2oC3/jkRmtOPiHI77S8L+qpbogoyXHPqCYtRw2H U3HKZ7D/zYlmP0pEQe0yROmhAhoJlqc/SYvgXOYEUmH/DFvQT2A1Pf9LooC3tYjdznTj 9XuzyF44FSNjmVLgic7+pFYURf6lyC73wuB+XWL6KuZBg/4BfzeJeww1gOxD8b6T3Xv6 vPDQ== MIME-Version: 1.0 Received: by 10.220.108.79 with SMTP id e15mr25745037vcp.61.1355784813492; Mon, 17 Dec 2012 14:53:33 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Mon, 17 Dec 2012 14:53:33 -0800 (PST) In-Reply-To: <20121217223943.GA88856@dragon.NUXI.org> References: <50CCAB99.4040308@FreeBSD.org> <20121215203458.GA22361@oddish> <50CCE59F.1080107@FreeBSD.org> <50CCE7F6.2090505@FreeBSD.org> <20121217223943.GA88856@dragon.NUXI.org> Date: Mon, 17 Dec 2012 14:53:33 -0800 X-Google-Sender-Auth: xnCvV9VqCGLkO6JabtmmVnG1LTE Message-ID: Subject: Re: [RFC/RFT] calloutng From: Davide Italiano To: obrien@freebsd.org, Alexander Motin , Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:53:35 -0000 On Mon, Dec 17, 2012 at 2:39 PM, David O'Brien wrote: > On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote: >> On 15.12.2012 23:03, Alexander Motin wrote: >> > Sorry, it's my fault. I've tried to save some time on patch generation >> > and forgot about that change in lib/. We haven't touched user-level in >> > our work except that file. Here is patch with that chunk added: >> > http://people.freebsd.org/~mav/calloutng_12_15_1.patch >> >> And one more part I've missed is manual pages update, that probably >> needs more improvements: >> http://people.freebsd.org/~mav/calloutng_12_15.man.patch > > Perhaps use the SCM at what its good at? > > Sync your branch with HEAD and then do an 'svn diff ^/head' and your > branch. > > -- > -- David (obrien@FreeBSD.org) Last time I tried doing that the way you describe, I got an output with tons svn:mergeinfo and I didn't find a way to suppress them if not manually. e.g. Property changes on: usr.bin/procstat ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/usr.bin/procstat:r236314-239017 Index: usr.bin/calendar =================================================================== --- usr.bin/calendar (.../head) (revision 239166) +++ usr.bin/calendar (.../projects/calloutng) (revision 239166) Can you help me in understanding what I did wrong? Thanks From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 00:09:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DF2069D; Tue, 18 Dec 2012 00:09:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D246B8FC0C; Tue, 18 Dec 2012 00:09:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI09BvE097689; Mon, 17 Dec 2012 19:09:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI09BDV097676; Tue, 18 Dec 2012 00:09:11 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 00:09:11 GMT Message-Id: <201212180009.qBI09BDV097676@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 00:09:19 -0000 TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-17 22:40:00 - cleaning the object tree TB --- 2012-12-17 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-17 22:44:18 - /usr/local/bin/svn update /src TB --- 2012-12-17 22:44:28 - At svn revision 244368 TB --- 2012-12-17 22:44:29 - building world TB --- 2012-12-17 22:44:29 - CROSS_BUILD_TESTING=YES TB --- 2012-12-17 22:44:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-17 22:44:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-17 22:44:29 - SRCCONF=/dev/null TB --- 2012-12-17 22:44:29 - TARGET=arm TB --- 2012-12-17 22:44:29 - TARGET_ARCH=arm TB --- 2012-12-17 22:44:29 - TZ=UTC TB --- 2012-12-17 22:44:29 - __MAKE_CONF=/dev/null TB --- 2012-12-17 22:44:29 - cd /src TB --- 2012-12-17 22:44:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 17 22:44:39 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 Mon Dec 17 23:43:03 UTC 2012 TB --- 2012-12-17 23:43:03 - generating LINT kernel config TB --- 2012-12-17 23:43:03 - cd /src/sys/arm/conf TB --- 2012-12-17 23:43:03 - /usr/bin/make -B LINT TB --- 2012-12-17 23:43:03 - cd /src/sys/arm/conf TB --- 2012-12-17 23:43:03 - /usr/sbin/config -m LINT TB --- 2012-12-17 23:43:03 - building LINT kernel TB --- 2012-12-17 23:43:03 - CROSS_BUILD_TESTING=YES TB --- 2012-12-17 23:43:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-17 23:43:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-17 23:43:03 - SRCCONF=/dev/null TB --- 2012-12-17 23:43:03 - TARGET=arm TB --- 2012-12-17 23:43:03 - TARGET_ARCH=arm TB --- 2012-12-17 23:43:03 - TZ=UTC TB --- 2012-12-17 23:43:03 - __MAKE_CONF=/dev/null TB --- 2012-12-17 23:43:03 - cd /src TB --- 2012-12-17 23:43:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 17 23:43:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 00:03:19 UTC 2012 TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m AC100 TB --- 2012-12-18 00:03:19 - skipping AC100 kernel TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m ARMADAXP TB --- 2012-12-18 00:03:19 - skipping ARMADAXP kernel TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m ATMEL TB --- 2012-12-18 00:03:19 - building ATMEL kernel TB --- 2012-12-18 00:03:19 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 00:03:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 00:03:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 00:03:19 - SRCCONF=/dev/null TB --- 2012-12-18 00:03:19 - TARGET=arm TB --- 2012-12-18 00:03:19 - TARGET_ARCH=arm TB --- 2012-12-18 00:03:19 - TZ=UTC TB --- 2012-12-18 00:03:19 - __MAKE_CONF=/dev/null TB --- 2012-12-18 00:03:19 - cd /src TB --- 2012-12-18 00:03:19 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Dec 18 00:03:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Dec 18 00:07:13 UTC 2012 TB --- 2012-12-18 00:07:13 - cd /src/sys/arm/conf TB --- 2012-12-18 00:07:13 - /usr/sbin/config -m AVILA TB --- 2012-12-18 00:07:13 - skipping AVILA kernel TB --- 2012-12-18 00:07:13 - cd /src/sys/arm/conf TB --- 2012-12-18 00:07:13 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-12-18 00:07:14 - skipping BEAGLEBONE kernel TB --- 2012-12-18 00:07:14 - cd /src/sys/arm/conf TB --- 2012-12-18 00:07:14 - /usr/sbin/config -m BWCT TB --- 2012-12-18 00:07:14 - building BWCT kernel TB --- 2012-12-18 00:07:14 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 00:07:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 00:07:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 00:07:14 - SRCCONF=/dev/null TB --- 2012-12-18 00:07:14 - TARGET=arm TB --- 2012-12-18 00:07:14 - TARGET_ARCH=arm TB --- 2012-12-18 00:07:14 - TZ=UTC TB --- 2012-12-18 00:07:14 - __MAKE_CONF=/dev/null TB --- 2012-12-18 00:07:14 - cd /src TB --- 2012-12-18 00:07:14 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Dec 18 00:07:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc.c 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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc_newreno.c 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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_hostcache.c 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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c: In function 'tcp_input': /src/sys/netinet/tcp_input.c:783: error: 'isipv6' undeclared (first use in this function) /src/sys/netinet/tcp_input.c:783: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_input.c:783: error: for each function it appears in.) *** [tcp_input.o] Error code 1 Stop in /obj/arm.arm/src/sys/BWCT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 00:09:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 00:09:11 - ERROR: failed to build BWCT kernel TB --- 2012-12-18 00:09:11 - 3742.32 user 790.08 system 5351.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 03:18:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3E8EE37; Tue, 18 Dec 2012 03:18:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB318FC26; Tue, 18 Dec 2012 03:18:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI3IEPa017971; Mon, 17 Dec 2012 22:18:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI3IDIu017967; Tue, 18 Dec 2012 03:18:13 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 03:18:13 GMT Message-Id: <201212180318.qBI3IDIu017967@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:18:15 -0000 TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-12-17 22:40:00 - cleaning the object tree TB --- 2012-12-17 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-17 22:43:33 - /usr/local/bin/svn update /src TB --- 2012-12-17 22:43:44 - At svn revision 244368 TB --- 2012-12-17 22:43:45 - building world TB --- 2012-12-17 22:43:45 - CROSS_BUILD_TESTING=YES TB --- 2012-12-17 22:43:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-17 22:43:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-17 22:43:45 - SRCCONF=/dev/null TB --- 2012-12-17 22:43:45 - TARGET=i386 TB --- 2012-12-17 22:43:45 - TARGET_ARCH=i386 TB --- 2012-12-17 22:43:45 - TZ=UTC TB --- 2012-12-17 22:43:45 - __MAKE_CONF=/dev/null TB --- 2012-12-17 22:43:45 - cd /src TB --- 2012-12-17 22:43:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 17 22:43: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 >>> World build completed on Tue Dec 18 01:59:32 UTC 2012 TB --- 2012-12-18 01:59:32 - generating LINT kernel config TB --- 2012-12-18 01:59:32 - cd /src/sys/i386/conf TB --- 2012-12-18 01:59:32 - /usr/bin/make -B LINT TB --- 2012-12-18 01:59:32 - cd /src/sys/i386/conf TB --- 2012-12-18 01:59:32 - /usr/sbin/config -m LINT TB --- 2012-12-18 01:59:32 - building LINT kernel TB --- 2012-12-18 01:59:32 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 01:59:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 01:59:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 01:59:32 - SRCCONF=/dev/null TB --- 2012-12-18 01:59:32 - TARGET=i386 TB --- 2012-12-18 01:59:32 - TARGET_ARCH=i386 TB --- 2012-12-18 01:59:32 - TZ=UTC TB --- 2012-12-18 01:59:32 - __MAKE_CONF=/dev/null TB --- 2012-12-18 01:59:32 - cd /src TB --- 2012-12-18 01:59:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 18 01:59:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 02:32:52 UTC 2012 TB --- 2012-12-18 02:32:52 - cd /src/sys/i386/conf TB --- 2012-12-18 02:32:52 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-18 02:32:52 - building LINT-NOINET kernel TB --- 2012-12-18 02:32:52 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 02:32:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 02:32:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 02:32:52 - SRCCONF=/dev/null TB --- 2012-12-18 02:32:52 - TARGET=i386 TB --- 2012-12-18 02:32:52 - TARGET_ARCH=i386 TB --- 2012-12-18 02:32:52 - TZ=UTC TB --- 2012-12-18 02:32:52 - __MAKE_CONF=/dev/null TB --- 2012-12-18 02:32:52 - cd /src TB --- 2012-12-18 02:32:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Dec 18 02:32:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Dec 18 03:03:09 UTC 2012 TB --- 2012-12-18 03:03:09 - cd /src/sys/i386/conf TB --- 2012-12-18 03:03:09 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-18 03:03:09 - building LINT-NOINET6 kernel TB --- 2012-12-18 03:03:09 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 03:03:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 03:03:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 03:03:09 - SRCCONF=/dev/null TB --- 2012-12-18 03:03:09 - TARGET=i386 TB --- 2012-12-18 03:03:09 - TARGET_ARCH=i386 TB --- 2012-12-18 03:03:09 - TZ=UTC TB --- 2012-12-18 03:03:09 - __MAKE_CONF=/dev/null TB --- 2012-12-18 03:03:09 - cd /src TB --- 2012-12-18 03:03:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Dec 18 03:03:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:783:7: error: use of undeclared identifier 'isipv6' if ((isipv6 && (m->m_flags & M_IP6_NEXTHOP)) || ^ /src/sys/netinet/tcp_input.c:784:8: error: use of undeclared identifier 'isipv6' (!isipv6 && (m->m_flags & M_IP_NEXTHOP))) ^ 2 errors generated. *** [tcp_input.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET6. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 03:18:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 03:18:13 - ERROR: failed to build LINT-NOINET6 kernel TB --- 2012-12-18 03:18:13 - 12023.02 user 2108.62 system 16693.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 03:53:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03C13AE7; Tue, 18 Dec 2012 03:53:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C21638FC0A; Tue, 18 Dec 2012 03:53:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI3rXLh039032; Mon, 17 Dec 2012 22:53:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI3rXlU039026; Tue, 18 Dec 2012 03:53:33 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 03:53:33 GMT Message-Id: <201212180353.qBI3rXlU039026@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:53:34 -0000 TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-12-17 22:40:00 - cleaning the object tree TB --- 2012-12-17 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-17 22:43:54 - /usr/local/bin/svn update /src TB --- 2012-12-17 22:44:06 - At svn revision 244368 TB --- 2012-12-17 22:44:07 - building world TB --- 2012-12-17 22:44:07 - CROSS_BUILD_TESTING=YES TB --- 2012-12-17 22:44:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-17 22:44:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-17 22:44:07 - SRCCONF=/dev/null TB --- 2012-12-17 22:44:07 - TARGET=amd64 TB --- 2012-12-17 22:44:07 - TARGET_ARCH=amd64 TB --- 2012-12-17 22:44:07 - TZ=UTC TB --- 2012-12-17 22:44:07 - __MAKE_CONF=/dev/null TB --- 2012-12-17 22:44:07 - cd /src TB --- 2012-12-17 22:44:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 17 22:44:15 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 Dec 18 02:36:46 UTC 2012 TB --- 2012-12-18 02:36:46 - generating LINT kernel config TB --- 2012-12-18 02:36:46 - cd /src/sys/amd64/conf TB --- 2012-12-18 02:36:46 - /usr/bin/make -B LINT TB --- 2012-12-18 02:36:46 - cd /src/sys/amd64/conf TB --- 2012-12-18 02:36:46 - /usr/sbin/config -m LINT TB --- 2012-12-18 02:36:46 - building LINT kernel TB --- 2012-12-18 02:36:46 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 02:36:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 02:36:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 02:36:46 - SRCCONF=/dev/null TB --- 2012-12-18 02:36:46 - TARGET=amd64 TB --- 2012-12-18 02:36:46 - TARGET_ARCH=amd64 TB --- 2012-12-18 02:36:46 - TZ=UTC TB --- 2012-12-18 02:36:46 - __MAKE_CONF=/dev/null TB --- 2012-12-18 02:36:46 - cd /src TB --- 2012-12-18 02:36:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 18 02:36:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 03:09:12 UTC 2012 TB --- 2012-12-18 03:09:12 - cd /src/sys/amd64/conf TB --- 2012-12-18 03:09:12 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-18 03:09:12 - building LINT-NOINET kernel TB --- 2012-12-18 03:09:12 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 03:09:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 03:09:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 03:09:12 - SRCCONF=/dev/null TB --- 2012-12-18 03:09:12 - TARGET=amd64 TB --- 2012-12-18 03:09:12 - TARGET_ARCH=amd64 TB --- 2012-12-18 03:09:12 - TZ=UTC TB --- 2012-12-18 03:09:12 - __MAKE_CONF=/dev/null TB --- 2012-12-18 03:09:12 - cd /src TB --- 2012-12-18 03:09:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Dec 18 03:09:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Dec 18 03:39:09 UTC 2012 TB --- 2012-12-18 03:39:09 - cd /src/sys/amd64/conf TB --- 2012-12-18 03:39:09 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-18 03:39:09 - building LINT-NOINET6 kernel TB --- 2012-12-18 03:39:09 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 03:39:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 03:39:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 03:39:09 - SRCCONF=/dev/null TB --- 2012-12-18 03:39:09 - TARGET=amd64 TB --- 2012-12-18 03:39:09 - TARGET_ARCH=amd64 TB --- 2012-12-18 03:39:09 - TZ=UTC TB --- 2012-12-18 03:39:09 - __MAKE_CONF=/dev/null TB --- 2012-12-18 03:39:09 - cd /src TB --- 2012-12-18 03:39:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Dec 18 03:39:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:783:7: error: use of undeclared identifier 'isipv6' if ((isipv6 && (m->m_flags & M_IP6_NEXTHOP)) || ^ /src/sys/netinet/tcp_input.c:784:8: error: use of undeclared identifier 'isipv6' (!isipv6 && (m->m_flags & M_IP_NEXTHOP))) ^ 2 errors generated. *** [tcp_input.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET6. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 03:53:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 03:53:32 - ERROR: failed to build LINT-NOINET6 kernel TB --- 2012-12-18 03:53:32 - 13281.83 user 2379.50 system 18812.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 04:00:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3061D1F; Tue, 18 Dec 2012 04:00:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 73C728FC17; Tue, 18 Dec 2012 04:00:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI40ILX065395; Mon, 17 Dec 2012 23:00:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI40I17065394; Tue, 18 Dec 2012 04:00:18 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 04:00:18 GMT Message-Id: <201212180400.qBI40I17065394@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 04:00:19 -0000 TB --- 2012-12-18 02:48:50 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 02:48:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 02:48:50 - starting HEAD tinderbox run for mips/mips TB --- 2012-12-18 02:48:50 - cleaning the object tree TB --- 2012-12-18 02:48:50 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 02:48:50 - cd /tinderbox/HEAD/mips/mips TB --- 2012-12-18 02:48:50 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 02:49:55 - /usr/local/bin/svn update /src TB --- 2012-12-18 02:50:01 - At svn revision 244372 TB --- 2012-12-18 02:50:02 - building world TB --- 2012-12-18 02:50:02 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 02:50:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 02:50:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 02:50:02 - SRCCONF=/dev/null TB --- 2012-12-18 02:50:02 - TARGET=mips TB --- 2012-12-18 02:50:02 - TARGET_ARCH=mips TB --- 2012-12-18 02:50:02 - TZ=UTC TB --- 2012-12-18 02:50:02 - __MAKE_CONF=/dev/null TB --- 2012-12-18 02:50:02 - cd /src TB --- 2012-12-18 02:50:02 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 18 02:50:10 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 Dec 18 03:57:41 UTC 2012 TB --- 2012-12-18 03:57:41 - cd /src/sys/mips/conf TB --- 2012-12-18 03:57:41 - /usr/sbin/config -m ADM5120 TB --- 2012-12-18 03:57:41 - skipping ADM5120 kernel TB --- 2012-12-18 03:57:41 - cd /src/sys/mips/conf TB --- 2012-12-18 03:57:41 - /usr/sbin/config -m ALCHEMY TB --- 2012-12-18 03:57:41 - skipping ALCHEMY kernel TB --- 2012-12-18 03:57:41 - cd /src/sys/mips/conf TB --- 2012-12-18 03:57:41 - /usr/sbin/config -m AP91 TB --- 2012-12-18 03:57:41 - building AP91 kernel TB --- 2012-12-18 03:57:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 03:57:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 03:57:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 03:57:41 - SRCCONF=/dev/null TB --- 2012-12-18 03:57:41 - TARGET=mips TB --- 2012-12-18 03:57:41 - TARGET_ARCH=mips TB --- 2012-12-18 03:57:41 - TZ=UTC TB --- 2012-12-18 03:57:41 - __MAKE_CONF=/dev/null TB --- 2012-12-18 03:57:41 - cd /src TB --- 2012-12-18 03:57:41 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Tue Dec 18 03:57:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -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=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/netinet/cc/cc.c cc -c -O -pipe -std=c99 -g -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=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/netinet/cc/cc_newreno.c cc -c -O -pipe -std=c99 -g -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=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_hostcache.c cc -c -O -pipe -std=c99 -g -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=768 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c: In function 'tcp_input': /src/sys/netinet/tcp_input.c:783: error: 'isipv6' undeclared (first use in this function) /src/sys/netinet/tcp_input.c:783: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_input.c:783: error: for each function it appears in.) *** [tcp_input.o] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 04:00:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 04:00:18 - ERROR: failed to build AP91 kernel TB --- 2012-12-18 04:00:18 - 2727.20 user 616.63 system 4287.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 04:25:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E46B9501; Tue, 18 Dec 2012 04:25:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 896BC8FC0A; Tue, 18 Dec 2012 04:25:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI4PRbd004173; Mon, 17 Dec 2012 23:25:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI4PRR3004168; Tue, 18 Dec 2012 04:25:27 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 04:25:27 GMT Message-Id: <201212180425.qBI4PRR3004168@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 04:25:32 -0000 TB --- 2012-12-18 02:51:53 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 02:51:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 02:51:53 - starting HEAD tinderbox run for mips64/mips TB --- 2012-12-18 02:51:53 - cleaning the object tree TB --- 2012-12-18 02:51:53 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 02:51:53 - cd /tinderbox/HEAD/mips64/mips TB --- 2012-12-18 02:51:53 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 02:53:34 - /usr/local/bin/svn update /src TB --- 2012-12-18 02:53:40 - At svn revision 244372 TB --- 2012-12-18 02:53:41 - building world TB --- 2012-12-18 02:53:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 02:53:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 02:53:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 02:53:41 - SRCCONF=/dev/null TB --- 2012-12-18 02:53:41 - TARGET=mips TB --- 2012-12-18 02:53:41 - TARGET_ARCH=mips64 TB --- 2012-12-18 02:53:41 - TZ=UTC TB --- 2012-12-18 02:53:41 - __MAKE_CONF=/dev/null TB --- 2012-12-18 02:53:41 - cd /src TB --- 2012-12-18 02:53:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 18 02:53:47 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 Dec 18 04:03:35 UTC 2012 TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m ADM5120 TB --- 2012-12-18 04:03:35 - skipping ADM5120 kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m ALCHEMY TB --- 2012-12-18 04:03:35 - skipping ALCHEMY kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AP91 TB --- 2012-12-18 04:03:35 - skipping AP91 kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AP93 TB --- 2012-12-18 04:03:35 - skipping AP93 kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AP94 TB --- 2012-12-18 04:03:35 - skipping AP94 kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AP96 TB --- 2012-12-18 04:03:35 - skipping AP96 kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AR71XX_BASE TB --- 2012-12-18 04:03:35 - skipping AR71XX_BASE kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AR724X_BASE TB --- 2012-12-18 04:03:35 - skipping AR724X_BASE kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m AR91XX_BASE TB --- 2012-12-18 04:03:35 - skipping AR91XX_BASE kernel TB --- 2012-12-18 04:03:35 - cd /src/sys/mips/conf TB --- 2012-12-18 04:03:35 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2012-12-18 04:03:35 - building BERI_DE4_MDROOT kernel TB --- 2012-12-18 04:03:35 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:03:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:03:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:03:35 - SRCCONF=/dev/null TB --- 2012-12-18 04:03:35 - TARGET=mips TB --- 2012-12-18 04:03:35 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:03:35 - TZ=UTC TB --- 2012-12-18 04:03:35 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:03:35 - cd /src TB --- 2012-12-18 04:03:35 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Tue Dec 18 04:03:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Tue Dec 18 04:06:52 UTC 2012 TB --- 2012-12-18 04:06:52 - cd /src/sys/mips/conf TB --- 2012-12-18 04:06:52 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2012-12-18 04:06:52 - building BERI_DE4_SDROOT kernel TB --- 2012-12-18 04:06:52 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:06:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:06:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:06:52 - SRCCONF=/dev/null TB --- 2012-12-18 04:06:52 - TARGET=mips TB --- 2012-12-18 04:06:52 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:06:52 - TZ=UTC TB --- 2012-12-18 04:06:52 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:06:52 - cd /src TB --- 2012-12-18 04:06:52 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Tue Dec 18 04:06:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_SDROOT completed on Tue Dec 18 04:09:06 UTC 2012 TB --- 2012-12-18 04:09:06 - cd /src/sys/mips/conf TB --- 2012-12-18 04:09:06 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2012-12-18 04:09:06 - building BERI_SIM_MDROOT kernel TB --- 2012-12-18 04:09:06 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:09:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:09:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:09:06 - SRCCONF=/dev/null TB --- 2012-12-18 04:09:06 - TARGET=mips TB --- 2012-12-18 04:09:06 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:09:06 - TZ=UTC TB --- 2012-12-18 04:09:06 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:09:06 - cd /src TB --- 2012-12-18 04:09:06 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Tue Dec 18 04:09:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_MDROOT completed on Tue Dec 18 04:11:18 UTC 2012 TB --- 2012-12-18 04:11:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:11:18 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2012-12-18 04:11:18 - building BERI_TEMPLATE kernel TB --- 2012-12-18 04:11:18 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:11:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:11:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:11:18 - SRCCONF=/dev/null TB --- 2012-12-18 04:11:18 - TARGET=mips TB --- 2012-12-18 04:11:18 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:11:18 - TZ=UTC TB --- 2012-12-18 04:11:18 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:11:18 - cd /src TB --- 2012-12-18 04:11:18 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Tue Dec 18 04:11:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_TEMPLATE completed on Tue Dec 18 04:13:26 UTC 2012 TB --- 2012-12-18 04:13:26 - cd /src/sys/mips/conf TB --- 2012-12-18 04:13:26 - /usr/sbin/config -m DIR-825 TB --- 2012-12-18 04:13:26 - skipping DIR-825 kernel TB --- 2012-12-18 04:13:26 - cd /src/sys/mips/conf TB --- 2012-12-18 04:13:26 - /usr/sbin/config -m GXEMUL TB --- 2012-12-18 04:13:26 - building GXEMUL kernel TB --- 2012-12-18 04:13:26 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:13:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:13:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:13:26 - SRCCONF=/dev/null TB --- 2012-12-18 04:13:26 - TARGET=mips TB --- 2012-12-18 04:13:26 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:13:26 - TZ=UTC TB --- 2012-12-18 04:13:26 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:13:26 - cd /src TB --- 2012-12-18 04:13:26 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Tue Dec 18 04:13:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GXEMUL completed on Tue Dec 18 04:15:22 UTC 2012 TB --- 2012-12-18 04:15:22 - cd /src/sys/mips/conf TB --- 2012-12-18 04:15:22 - /usr/sbin/config -m IDT TB --- 2012-12-18 04:15:22 - skipping IDT kernel TB --- 2012-12-18 04:15:22 - cd /src/sys/mips/conf TB --- 2012-12-18 04:15:22 - /usr/sbin/config -m MALTA TB --- 2012-12-18 04:15:22 - skipping MALTA kernel TB --- 2012-12-18 04:15:22 - cd /src/sys/mips/conf TB --- 2012-12-18 04:15:22 - /usr/sbin/config -m MALTA64 TB --- 2012-12-18 04:15:22 - skipping MALTA64 kernel TB --- 2012-12-18 04:15:22 - cd /src/sys/mips/conf TB --- 2012-12-18 04:15:22 - /usr/sbin/config -m OCTEON1 TB --- 2012-12-18 04:15:22 - building OCTEON1 kernel TB --- 2012-12-18 04:15:22 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:15:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:15:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:15:22 - SRCCONF=/dev/null TB --- 2012-12-18 04:15:22 - TARGET=mips TB --- 2012-12-18 04:15:22 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:15:22 - TZ=UTC TB --- 2012-12-18 04:15:22 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:15:22 - cd /src TB --- 2012-12-18 04:15:22 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Tue Dec 18 04:15:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for OCTEON1 completed on Tue Dec 18 04:23:18 UTC 2012 TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m PB47 TB --- 2012-12-18 04:23:18 - skipping PB47 kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m PB92 TB --- 2012-12-18 04:23:18 - skipping PB92 kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m QEMU TB --- 2012-12-18 04:23:18 - skipping QEMU kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m ROUTERSTATION TB --- 2012-12-18 04:23:18 - skipping ROUTERSTATION kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m ROUTERSTATION_MFS TB --- 2012-12-18 04:23:18 - skipping ROUTERSTATION_MFS kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m RSPRO TB --- 2012-12-18 04:23:18 - skipping RSPRO kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m RSPRO_MFS TB --- 2012-12-18 04:23:18 - skipping RSPRO_MFS kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m RSPRO_STANDALONE TB --- 2012-12-18 04:23:18 - skipping RSPRO_STANDALONE kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m RT305X TB --- 2012-12-18 04:23:18 - skipping RT305X kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m SENTRY5 TB --- 2012-12-18 04:23:18 - skipping SENTRY5 kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m SWARM TB --- 2012-12-18 04:23:18 - skipping SWARM kernel TB --- 2012-12-18 04:23:18 - cd /src/sys/mips/conf TB --- 2012-12-18 04:23:18 - /usr/sbin/config -m SWARM64 TB --- 2012-12-18 04:23:18 - building SWARM64 kernel TB --- 2012-12-18 04:23:18 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 04:23:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 04:23:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 04:23:18 - SRCCONF=/dev/null TB --- 2012-12-18 04:23:18 - TARGET=mips TB --- 2012-12-18 04:23:18 - TARGET_ARCH=mips64 TB --- 2012-12-18 04:23:18 - TZ=UTC TB --- 2012-12-18 04:23:18 - __MAKE_CONF=/dev/null TB --- 2012-12-18 04:23:18 - cd /src TB --- 2012-12-18 04:23:18 - /usr/bin/make -B buildkernel KERNCONF=SWARM64 >>> Kernel build for SWARM64 started on Tue Dec 18 04:23:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80001000 -mabi=64 -march=mips64 -msoft-float -ffreestanding -Werror /src/sys/netinet/cc/cc.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80001000 -mabi=64 -march=mips64 -msoft-float -ffreestanding -Werror /src/sys/netinet/cc/cc_newreno.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80001000 -mabi=64 -march=mips64 -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_hostcache.c cc -c -O -pipe -std=c99 -g -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=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80001000 -mabi=64 -march=mips64 -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c: In function 'tcp_input': /src/sys/netinet/tcp_input.c:783: error: 'isipv6' undeclared (first use in this function) /src/sys/netinet/tcp_input.c:783: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_input.c:783: error: for each function it appears in.) *** [tcp_input.o] Error code 1 Stop in /obj/mips.mips64/src/sys/SWARM64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 04:25:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 04:25:27 - ERROR: failed to build SWARM64 kernel TB --- 2012-12-18 04:25:27 - 3668.23 user 751.59 system 5613.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 09:03:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8F5459E; Tue, 18 Dec 2012 09:03:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id 09EF18FC17; Tue, 18 Dec 2012 09:03:51 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id dr13so157694wgb.13 for ; Tue, 18 Dec 2012 01:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jUmn3xQGBB1Ucfa2lVNrmWszs0brmWUzyg2wEgyTH1w=; b=N3sA2gvIxnW1tXnkv0FYd6Rf+XOWCI3/kIkXIE0doJcNmouw3l0h+Z4k7Wcq1a9Ser 92Gr+GuHd5Nn02vWTeWpBVHwwnfG0E/ZN58n2uuR9XIjLnVvpquSutpEBDZ5V4YQ/VSE pxv8R47rUs52C5MkJlco+IA6+6ymffz3BJooXGkJjEG2g3mHeq8Q9U1HUvzoKa4P21kE 4DYVnaf19GBOadDebwT1/31SnQ9MkOPSDGKN8KV4m8S/ke2lILnWBbtX5z+WJl4eajOB fUGp2r6O7qTaYJ48/ZJLkNNR41Ebv3q+obKytua9Szp8dPqRs1RVnmFchbXW4v0zPYGh H80Q== X-Received: by 10.194.57.206 with SMTP id k14mr2559373wjq.26.1355821430972; Tue, 18 Dec 2012 01:03:50 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id hg17sm14947309wib.1.2012.12.18.01.03.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 01:03:49 -0800 (PST) Sender: Alexander Motin Message-ID: <50D03173.9080904@FreeBSD.org> Date: Tue, 18 Dec 2012 11:03:47 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> In-Reply-To: <50CE5B54.3050905@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:03:52 -0000 Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With several important changes made last time I am going to delay commit to HEAD for another week to do more testing. Comments and new test cases are welcome. Thanks for staying tuned and commenting. On 17.12.2012 01:37, Alexander Motin wrote: > Here is one more version. Unless something new will be found/reported > this may be the last one, because me and Davide are quite satisfied with > the results. If everything will be fine, I think we could commit it to > HEAD closer to the end of the week: > http://people.freebsd.org/~mav/calloutng_12_16.patch > > Changes in this version: > -- Removed couple of redundant variables in callout implementation, > that reduced sizeof(struct callout) by two pointers and simplified some > internal code. > -- syscons driver was made to schedule only 1-2 callouts per second > instead of 20-30 before when console is in graphical mode and there are > few other things to do. Now my laptop has only about 30 interrupts per > second total during idle periods with X running. > -- i8254 eventtimer driver was optimized to work faster in disabled by > default one-shot mode. > -- Few kernel functions were added to make KPIs more complete. > -- Man pages were updated. > -- Some style fixes were made. > > On 15.12.2012 18:55, Alexander Motin wrote: >> I'm sorry to interrupt review, but as usual good ideas came during the >> final testing, causing another round. :) Here is updated patch for >> HEAD, that includes several new changes: >> http://people.freebsd.org/~mav/calloutng_12_15.patch >> >> The new changes are: >> -- Precision and event aggregation code was reworked. Instead of >> previous -prec/+prec representation, precision is now single-sided -- >> -0/+prec. It allowed to significantly improve precision on long time >> intervals for APIs which imply that event should not happen before the >> specified time. Depending on CPU activity, mistake for long time >> intervals now will never be more then 1-500ms, even if specified >> precision allows more. >> -- Some minor optimizations were made to reduce callout overhead and >> latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer >> and TSC timecounter usleep(1) call from user-level executes in just >> 5-6us, instead of 7-8us before. Now it can do 180K cycles per second on >> single CPU with only partial CPU load. >> -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, >> setrlimit) were modified to reduce number of interrupts, also with event >> aggregation by explicit specification of the acceptable events >> precision. Now my Core2Duo test system has only 30 interrupts per second >> in idle. If not remaining syscons events, it could easily be 15. My >> IvyBridge ultrabook first time in its history shown 5.5 hours of battery >> time with full screen brightness and 10 hours with lid closed. >> -- Some kernel functions were added to make KPIs more complete. >> >> I've successfully tested this patch on amd64 and arm. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 09:09:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E884890; Tue, 18 Dec 2012 09:09:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 601528FC12; Tue, 18 Dec 2012 09:09:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI99LQw082656; Tue, 18 Dec 2012 04:09:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI99LtU082649; Tue, 18 Dec 2012 09:09:21 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 09:09:21 GMT Message-Id: <201212180909.qBI99LtU082649@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:09:22 -0000 TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:36:16 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:36:16 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-18 07:36:16 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:37:46 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:38:04 - At svn revision 244385 TB --- 2012-12-18 07:38:05 - building world TB --- 2012-12-18 07:38:05 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:38:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:38:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:38:05 - SRCCONF=/dev/null TB --- 2012-12-18 07:38:05 - TARGET=arm TB --- 2012-12-18 07:38:05 - TARGET_ARCH=arm TB --- 2012-12-18 07:38:05 - TZ=UTC TB --- 2012-12-18 07:38:05 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:38:05 - cd /src TB --- 2012-12-18 07:38:05 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 18 07:38:11 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 Dec 18 08:41:58 UTC 2012 TB --- 2012-12-18 08:41:58 - generating LINT kernel config TB --- 2012-12-18 08:41:58 - cd /src/sys/arm/conf TB --- 2012-12-18 08:41:58 - /usr/bin/make -B LINT TB --- 2012-12-18 08:41:58 - cd /src/sys/arm/conf TB --- 2012-12-18 08:41:58 - /usr/sbin/config -m LINT TB --- 2012-12-18 08:41:58 - building LINT kernel TB --- 2012-12-18 08:41:58 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 08:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 08:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 08:41:58 - SRCCONF=/dev/null TB --- 2012-12-18 08:41:58 - TARGET=arm TB --- 2012-12-18 08:41:58 - TARGET_ARCH=arm TB --- 2012-12-18 08:41:58 - TZ=UTC TB --- 2012-12-18 08:41:58 - __MAKE_CONF=/dev/null TB --- 2012-12-18 08:41:58 - cd /src TB --- 2012-12-18 08:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 18 08:41:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 09:03:17 UTC 2012 TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m AC100 TB --- 2012-12-18 09:03:17 - skipping AC100 kernel TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m ARMADAXP TB --- 2012-12-18 09:03:17 - skipping ARMADAXP kernel TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m ATMEL TB --- 2012-12-18 09:03:17 - building ATMEL kernel TB --- 2012-12-18 09:03:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 09:03:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 09:03:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 09:03:17 - SRCCONF=/dev/null TB --- 2012-12-18 09:03:17 - TARGET=arm TB --- 2012-12-18 09:03:17 - TARGET_ARCH=arm TB --- 2012-12-18 09:03:17 - TZ=UTC TB --- 2012-12-18 09:03:17 - __MAKE_CONF=/dev/null TB --- 2012-12-18 09:03:17 - cd /src TB --- 2012-12-18 09:03:17 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Dec 18 09:03:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Dec 18 09:07:33 UTC 2012 TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m AVILA TB --- 2012-12-18 09:07:33 - skipping AVILA kernel TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-12-18 09:07:33 - skipping BEAGLEBONE kernel TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m BWCT TB --- 2012-12-18 09:07:33 - building BWCT kernel TB --- 2012-12-18 09:07:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 09:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 09:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 09:07:33 - SRCCONF=/dev/null TB --- 2012-12-18 09:07:33 - TARGET=arm TB --- 2012-12-18 09:07:33 - TARGET_ARCH=arm TB --- 2012-12-18 09:07:33 - TZ=UTC TB --- 2012-12-18 09:07:33 - __MAKE_CONF=/dev/null TB --- 2012-12-18 09:07:33 - cd /src TB --- 2012-12-18 09:07:33 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Dec 18 09:07:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc.c 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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc_newreno.c 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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_hostcache.c 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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c: In function 'tcp_input': /src/sys/netinet/tcp_input.c:783: error: 'isipv6' undeclared (first use in this function) /src/sys/netinet/tcp_input.c:783: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_input.c:783: error: for each function it appears in.) *** [tcp_input.o] Error code 1 Stop in /obj/arm.arm/src/sys/BWCT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 09:09:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 09:09:21 - ERROR: failed to build BWCT kernel TB --- 2012-12-18 09:09:21 - 3774.85 user 812.13 system 5960.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 11:30:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36115536 for ; Tue, 18 Dec 2012 11:30:52 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id C4AEF8FC1A for ; Tue, 18 Dec 2012 11:30:51 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBIBUjSE090839 for ; Tue, 18 Dec 2012 06:30:50 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50D053E5.3050003@m5p.com> Date: Tue, 18 Dec 2012 06:30:45 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Failed to initialize dwarf? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 18 Dec 2012 06:30:50 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 11:30:52 -0000 I checked out head Sunday and now my attempt at building a kernel says: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] on every module it compiles (though it seems happy enough to keep compiling). Should I just ignore this? -- George Mitchell From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 12:16:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5761EED for ; Tue, 18 Dec 2012 12:16:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6174D8FC0A for ; Tue, 18 Dec 2012 12:16:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:90a8:9e4b:2980:e339] (unknown [IPv6:2001:7b8:3a7:0:90a8:9e4b:2980:e339]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C31ED5C5A; Tue, 18 Dec 2012 13:15:58 +0100 (CET) Message-ID: <50D05E7E.4040105@FreeBSD.org> Date: Tue, 18 Dec 2012 13:15:58 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: George Mitchell Subject: Re: Failed to initialize dwarf? References: <50D053E5.3050003@m5p.com> In-Reply-To: <50D053E5.3050003@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:16:00 -0000 On 2012-12-18 12:30, George Mitchell wrote: > I checked out head Sunday and now my attempt at building a kernel says: > > ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at > [dwarf_init_attr(400)] > > on every module it compiles (though it seems happy enough to keep > compiling). Should I just ignore this? -- George Mitchell This problem was fixed in libdwarf in r239872; did you run "make buildworld" before "make buildkernel"? From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 12:18:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7F80CE; Tue, 18 Dec 2012 12:18:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6F18FC17; Tue, 18 Dec 2012 12:18:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBICIqRV098457; Tue, 18 Dec 2012 07:18:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBICIqqK098453; Tue, 18 Dec 2012 12:18:52 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 12:18:52 GMT Message-Id: <201212181218.qBICIqqK098453@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:18:53 -0000 TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:40:33 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:40:33 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-12-18 07:40:33 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:42:24 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:42:33 - At svn revision 244385 TB --- 2012-12-18 07:42:34 - building world TB --- 2012-12-18 07:42:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:42:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:42:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:42:34 - SRCCONF=/dev/null TB --- 2012-12-18 07:42:34 - TARGET=i386 TB --- 2012-12-18 07:42:34 - TARGET_ARCH=i386 TB --- 2012-12-18 07:42:34 - TZ=UTC TB --- 2012-12-18 07:42:34 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:42:34 - cd /src TB --- 2012-12-18 07:42:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 18 07:42:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Dec 18 10:59:43 UTC 2012 TB --- 2012-12-18 10:59:43 - generating LINT kernel config TB --- 2012-12-18 10:59:43 - cd /src/sys/i386/conf TB --- 2012-12-18 10:59:43 - /usr/bin/make -B LINT TB --- 2012-12-18 10:59:43 - cd /src/sys/i386/conf TB --- 2012-12-18 10:59:43 - /usr/sbin/config -m LINT TB --- 2012-12-18 10:59:43 - building LINT kernel TB --- 2012-12-18 10:59:43 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 10:59:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 10:59:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 10:59:43 - SRCCONF=/dev/null TB --- 2012-12-18 10:59:43 - TARGET=i386 TB --- 2012-12-18 10:59:43 - TARGET_ARCH=i386 TB --- 2012-12-18 10:59:43 - TZ=UTC TB --- 2012-12-18 10:59:43 - __MAKE_CONF=/dev/null TB --- 2012-12-18 10:59:43 - cd /src TB --- 2012-12-18 10:59:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 18 10:59:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 11:32:41 UTC 2012 TB --- 2012-12-18 11:32:41 - cd /src/sys/i386/conf TB --- 2012-12-18 11:32:41 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-18 11:32:41 - building LINT-NOINET kernel TB --- 2012-12-18 11:32:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 11:32:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 11:32:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 11:32:41 - SRCCONF=/dev/null TB --- 2012-12-18 11:32:41 - TARGET=i386 TB --- 2012-12-18 11:32:41 - TARGET_ARCH=i386 TB --- 2012-12-18 11:32:41 - TZ=UTC TB --- 2012-12-18 11:32:41 - __MAKE_CONF=/dev/null TB --- 2012-12-18 11:32:41 - cd /src TB --- 2012-12-18 11:32:41 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Dec 18 11:32:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Dec 18 12:03:32 UTC 2012 TB --- 2012-12-18 12:03:32 - cd /src/sys/i386/conf TB --- 2012-12-18 12:03:32 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-18 12:03:32 - building LINT-NOINET6 kernel TB --- 2012-12-18 12:03:32 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 12:03:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 12:03:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 12:03:32 - SRCCONF=/dev/null TB --- 2012-12-18 12:03:32 - TARGET=i386 TB --- 2012-12-18 12:03:32 - TARGET_ARCH=i386 TB --- 2012-12-18 12:03:32 - TZ=UTC TB --- 2012-12-18 12:03:32 - __MAKE_CONF=/dev/null TB --- 2012-12-18 12:03:32 - cd /src TB --- 2012-12-18 12:03:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Dec 18 12:03:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:783:7: error: use of undeclared identifier 'isipv6' if ((isipv6 && (m->m_flags & M_IP6_NEXTHOP)) || ^ /src/sys/netinet/tcp_input.c:784:8: error: use of undeclared identifier 'isipv6' (!isipv6 && (m->m_flags & M_IP_NEXTHOP))) ^ 2 errors generated. *** [tcp_input.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET6. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 12:18:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 12:18:52 - ERROR: failed to build LINT-NOINET6 kernel TB --- 2012-12-18 12:18:52 - 12152.95 user 2129.01 system 17331.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 12:21:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C1932B4 for ; Tue, 18 Dec 2012 12:21:48 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id B2CD38FC0A for ; Tue, 18 Dec 2012 12:21:47 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id k6so581069lbo.7 for ; Tue, 18 Dec 2012 04:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=kLmBnq4Hw0FnEooQJQGVf5p/6sTfVUDbF9fJhXD5svE=; b=VTi8MzHB7FLQfhhOxhkKJlPRRkD3aCxftYJlYm8/KVmXCJq/Pzb+e63FHXmBAgl3cz H5QNQeT9fOGpJyBnY3qsWhkE9O5rkVhEFTo1po7IIAVDbD8r+lzcVIimP/XKwL+Hl4+k 1OapcrEE8000R/QGwA6m16FEU0+zynTEuXALJFSwmTJzIiBWhQh4DJOqab2j4ekIMdm/ 2D73b0V4vCVlBvJ+f2AMcZ4uL75f9g9yL7KvgMv2XKslOIwHXC7bZKsStQzfdS00v2gl H29oedtzcdR5K4xhL7/kuIHSfEfypYtOVa+TCuY3BfYR042t2movsmzBChPJsR/phOvV JvuQ== X-Received: by 10.112.40.101 with SMTP id w5mr770046lbk.74.1355833306382; Tue, 18 Dec 2012 04:21:46 -0800 (PST) Received: from ?IPv6:2001:980:d7ed:1:2d4f:965:7530:7eb7? ([2001:980:d7ed:1:2d4f:965:7530:7eb7]) by mx.google.com with ESMTPS id if8sm644930lab.1.2012.12.18.04.21.44 (version=SSLv3 cipher=OTHER); Tue, 18 Dec 2012 04:21:45 -0800 (PST) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <50D05FD6.7080008@freebsd.org> Date: Tue, 18 Dec 2012 13:21:42 +0100 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: current@freebsd.org Subject: protoc crash in libstdc++ X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:21:48 -0000 Hi, the following backtrace is from a crash that happened when building www/chromium with clang. The chromium port builds a binary protoc which crashes when built with clang. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 802006400 (LWP 100869)] 0x0000000800996506 in std::ostream::sentry::sentry(std::ostream&) () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x0000000800996506 in std::ostream::sentry::sentry(std::ostream&) () from /usr/lib/libstdc++.so.6 #1 0x00000008009964cd in std::basic_ostream::sentry::sentry (this=0x7fffffffcf88, __os=...) at /usr/include/c++/4.2/ostream:62 #2 0x0000000800998a4b in std::__ostream_insert > (__out=..., __s=0x485df0 "Missing input file.", __n=19) at /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83 #3 0x000000000040592c in operator<< > (this=, __out=..., __out=..., __s=) at /usr/include/c++/4.2/ostream:517 #4 google::protobuf::compiler::CommandLineInterface::ParseArguments (this=, argc=1, argv=0x7fffffffd640) at third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:790 #5 0x00000000004048b0 in google::protobuf::compiler::CommandLineInterface::Run (this=0x7fffffffd4d0, argc=-12408, argv=0x7fffffffcf88) at third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:588 #6 0x0000000000432957 in main (argc=-12408, argv=0x7fffffffcf88) at third_party/protobuf/src/google/protobuf/compiler/main.cc:59 (gdb) frame 2 #2 0x0000000800998a4b in std::__ostream_insert > (__out=..., __s=0x485df0 "Missing input file.", __n=19) at /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83 83 (gdb) list 78 __ostream_insert(basic_ostream<_CharT, _Traits>& __out, 79 const _CharT* __s, streamsize __n) 80 { 81 typedef basic_ostream<_CharT, _Traits> __ostream_type; 82 typedef typename __ostream_type::ios_base __ios_base; 83 84 typename __ostream_type::sentry __cerb(__out); ... So the question is if this is a protoc or a clang or a libstdc++ bug. René From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 12:22:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF7983BB; Tue, 18 Dec 2012 12:22:04 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 744058FC18; Tue, 18 Dec 2012 12:22:03 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 929CF7300A; Tue, 18 Dec 2012 13:20:43 +0100 (CET) Date: Tue, 18 Dec 2012 13:20:43 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng Message-ID: <20121218122043.GB84347@onelab2.iet.unipi.it> References: <20121217192731.GA83405@onelab2.iet.unipi.it> <20121217211112.GA84347@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , freebsd-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:22:04 -0000 On Mon, Dec 17, 2012 at 01:22:59PM -0800, Adrian Chadd wrote: > Personally, I'd rather see some consistently used units here.. bintime (or something similar) is the correct choice here. If we are concerned about the size (128 bit) then we can map it to a shorter, fixed point format, such as sign+31+32 as phk was suggesting. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 12:32:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CB5AAB1; Tue, 18 Dec 2012 12:32:59 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [178.238.39.38]) by mx1.freebsd.org (Postfix) with ESMTP id F1E668FC12; Tue, 18 Dec 2012 12:32:58 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id E18141CC55BF; Tue, 18 Dec 2012 13:24:22 +0100 (CET) Date: Tue, 18 Dec 2012 13:24:22 +0100 From: Roman Divacky To: Ren? Ladan Subject: Re: protoc crash in libstdc++ Message-ID: <20121218122422.GA35312@freebsd.org> References: <50D05FD6.7080008@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D05FD6.7080008@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:32:59 -0000 On Tue, Dec 18, 2012 at 01:21:42PM +0100, Ren? Ladan wrote: > Hi, > > the following backtrace is from a crash that happened when building > www/chromium with clang. The chromium port builds a binary protoc which > crashes when built with clang. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 802006400 (LWP 100869)] > 0x0000000800996506 in std::ostream::sentry::sentry(std::ostream&) () > from /usr/lib/libstdc++.so.6 > (gdb) bt > #0 0x0000000800996506 in std::ostream::sentry::sentry(std::ostream&) () > from /usr/lib/libstdc++.so.6 > #1 0x00000008009964cd in std::basic_ostream::sentry::sentry > (this=0x7fffffffcf88, __os=...) at /usr/include/c++/4.2/ostream:62 > #2 0x0000000800998a4b in std::__ostream_insert std::char_traits > (__out=..., __s=0x485df0 "Missing input file.", > __n=19) > at > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83 > #3 0x000000000040592c in operator<< > > (this=, __out=..., __out=..., __s=) at > /usr/include/c++/4.2/ostream:517 > #4 google::protobuf::compiler::CommandLineInterface::ParseArguments > (this=, argc=1, argv=0x7fffffffd640) at > third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:790 > #5 0x00000000004048b0 in > google::protobuf::compiler::CommandLineInterface::Run > (this=0x7fffffffd4d0, argc=-12408, argv=0x7fffffffcf88) > at > third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:588 > #6 0x0000000000432957 in main (argc=-12408, argv=0x7fffffffcf88) at ^^^^^^ wow :) Can you run this under valgrind? Roman From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 12:58:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A0B47F5; Tue, 18 Dec 2012 12:58:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 31C8E8FC14; Tue, 18 Dec 2012 12:58:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBICw4gl035998; Tue, 18 Dec 2012 07:58:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBICw4Yk035997; Tue, 18 Dec 2012 12:58:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 12:58:04 GMT Message-Id: <201212181258.qBICw4Yk035997@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:58:05 -0000 TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:42:39 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:42:39 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-12-18 07:42:39 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:44:55 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:45:02 - At svn revision 244385 TB --- 2012-12-18 07:45:03 - building world TB --- 2012-12-18 07:45:03 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:45:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:45:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:45:03 - SRCCONF=/dev/null TB --- 2012-12-18 07:45:03 - TARGET=amd64 TB --- 2012-12-18 07:45:03 - TARGET_ARCH=amd64 TB --- 2012-12-18 07:45:03 - TZ=UTC TB --- 2012-12-18 07:45:03 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:45:03 - cd /src TB --- 2012-12-18 07:45:03 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 18 07:45: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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Dec 18 11:38:40 UTC 2012 TB --- 2012-12-18 11:38:40 - generating LINT kernel config TB --- 2012-12-18 11:38:40 - cd /src/sys/amd64/conf TB --- 2012-12-18 11:38:40 - /usr/bin/make -B LINT TB --- 2012-12-18 11:38:41 - cd /src/sys/amd64/conf TB --- 2012-12-18 11:38:41 - /usr/sbin/config -m LINT TB --- 2012-12-18 11:38:41 - building LINT kernel TB --- 2012-12-18 11:38:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 11:38:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 11:38:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 11:38:41 - SRCCONF=/dev/null TB --- 2012-12-18 11:38:41 - TARGET=amd64 TB --- 2012-12-18 11:38:41 - TARGET_ARCH=amd64 TB --- 2012-12-18 11:38:41 - TZ=UTC TB --- 2012-12-18 11:38:41 - __MAKE_CONF=/dev/null TB --- 2012-12-18 11:38:41 - cd /src TB --- 2012-12-18 11:38:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 18 11:38:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 12:12:17 UTC 2012 TB --- 2012-12-18 12:12:17 - cd /src/sys/amd64/conf TB --- 2012-12-18 12:12:17 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-18 12:12:17 - building LINT-NOINET kernel TB --- 2012-12-18 12:12:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 12:12:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 12:12:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 12:12:17 - SRCCONF=/dev/null TB --- 2012-12-18 12:12:17 - TARGET=amd64 TB --- 2012-12-18 12:12:17 - TARGET_ARCH=amd64 TB --- 2012-12-18 12:12:17 - TZ=UTC TB --- 2012-12-18 12:12:17 - __MAKE_CONF=/dev/null TB --- 2012-12-18 12:12:17 - cd /src TB --- 2012-12-18 12:12:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Dec 18 12:12:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Dec 18 12:42:59 UTC 2012 TB --- 2012-12-18 12:42:59 - cd /src/sys/amd64/conf TB --- 2012-12-18 12:42:59 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-18 12:42:59 - building LINT-NOINET6 kernel TB --- 2012-12-18 12:42:59 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 12:42:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 12:42:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 12:42:59 - SRCCONF=/dev/null TB --- 2012-12-18 12:42:59 - TARGET=amd64 TB --- 2012-12-18 12:42:59 - TARGET_ARCH=amd64 TB --- 2012-12-18 12:42:59 - TZ=UTC TB --- 2012-12-18 12:42:59 - __MAKE_CONF=/dev/null TB --- 2012-12-18 12:42:59 - cd /src TB --- 2012-12-18 12:42:59 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Dec 18 12:42:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] 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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:783:7: error: use of undeclared identifier 'isipv6' if ((isipv6 && (m->m_flags & M_IP6_NEXTHOP)) || ^ /src/sys/netinet/tcp_input.c:784:8: error: use of undeclared identifier 'isipv6' (!isipv6 && (m->m_flags & M_IP_NEXTHOP))) ^ 2 errors generated. *** [tcp_input.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET6. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 12:58:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 12:58:04 - ERROR: failed to build LINT-NOINET6 kernel TB --- 2012-12-18 12:58:04 - 13411.36 user 2496.84 system 19684.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 17:38:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD567DB6; Tue, 18 Dec 2012 17:38:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6192E8FC13; Tue, 18 Dec 2012 17:38:03 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CA6527300A; Tue, 18 Dec 2012 18:36:43 +0100 (CET) Date: Tue, 18 Dec 2012 18:36:43 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121218173643.GA94266@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CF88B9.6040004@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 17:38:03 -0000 On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: > Hi. > > > I would instead do the following: > > I also don't very like the wide API and want to hear fresh ideas, but > approaches to time measurement there are too different to do what you > are proposing. Main problem is that while ticks value is relative, > bintime is absolute. It is not easy to make conversion between them fast > and precise. I've managed to do it, but the only function that does it > now is _callout_reset_on(). All other functions are just passing values > down. I am not sure I want to duplicate that code in each place, though > doing it at least for for callout may be a good idea. I am afraid the above is not convincing. Most/all of the APIs i mentioned still have the conversion from ticks to bintime, and the code in your patch is just building multiple parallel paths (one for each of the three versions of the same function) to some final piece of code where the conversion takes place. The problem is that all of this goes through a set of obfuscating macros and the end result is horrible. To be clear, i believe the work you have been doing on cleaning up callout is great, i am just saying that this is the time to look at the code from a few steps away and clean up all those design decisions that perhaps were made in a haste to make things work. I will give you another example to show how convoluted is the code now: cv_timedwait() and cv_timedwait_sig() now have three versions each (plain, bt, flags). These six are remapped through macros to two functions, _cv_timedwait() and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() maps to _cv_timedwait_sig() ) These two _cv_timedwait*() take both ticks and bintimes, and contain this sequence: + if (bt == NULL) + sleepq_set_timeout_flags(cvp, timo, flags); + else + sleepq_set_timeout_bt(cvp, bt, precision); Guess what, both sleepq_* are macros that remap to the same _sleepq_set_timeout(...) . So the above "if (bt == NULL)" is useless. But then if you dig into _sleepq_set_timeout() you'll see + if (bt == NULL) + callout_reset_flags_on(&td->td_slpcallout, timo, + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); + else + callout_reset_bt_on(&td->td_slpcallout, bt, precision, + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); and again both callout_reset*() are again remapped through macros to _callout_reset_on(), so another useless "if (bt == NULL)" And in the end you have the conversion from ticks to bintime. So basically the code path for cv_timedwait() has those two useless switches and one useless extra argument, and the conversion from ticks to bintime is down deep down in _callout_reset_on() where it can only be resolved at runtime, whereas by doing the conversion at the beginning the decision could have been made at compile time. So I believe my proposal would give large simplifications in the code and lead to a much cleaner implementation of what you have designed: 1. acknowledge the fact that the only representation of time that callouts use internally is a bintime+precision, define one single function (instead of two or three or six) that implements the blessed API, and implement the others with macros or inline functions doing the appropriate conversions; 2. specifically, the *_flags() variant has no reason to exist. It can be implemented through the *_bt() variant, and being a new function the only places where you introduce it require manual modifications so you can directly invoke the new function. Again, please take this as constructive criticism, as i really like the work you have been doing and appreciate the time and effort you are putting on it cheers luigi > > Creating sets of three functions I had three different goals: > - callout_reset() -- it is legacy variant required to keep API > compatibility; > - callout_reset_flags() -- it is for cases where custom precision > specification needs to be added to the existing code, or where direct > callout execution is needed. Conversion to bintime would additionally > complicate consumer code, that I would try to avoid. > - callout_reset_bt() -- API for the new code, which needs high > precision and doesn't mind to operate bintime. Now there is only three > such places in kernel now, and I don't think there will be much more. > > Respectively, these three options are replicated to other APIs where > time intervals are used. > > PS: Please keep me in CC. > > -- > Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 17:51:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31BF43EC; Tue, 18 Dec 2012 17:51:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DAAE08FC0C; Tue, 18 Dec 2012 17:51:32 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id AC5847300A; Tue, 18 Dec 2012 18:50:13 +0100 (CET) Date: Tue, 18 Dec 2012 18:50:13 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121218175013.GB94266@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121218173643.GA94266@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 17:51:33 -0000 On Tue, Dec 18, 2012 at 06:36:43PM +0100, Luigi Rizzo wrote: > On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: ... > So I believe my proposal would give large simplifications in > the code and lead to a much cleaner implementation of what > you have designed: > > 1. acknowledge the fact that the only representation of time > that callouts use internally is a bintime+precision, define one > single function (instead of two or three or six) that implements > the blessed API, and implement the others with macros or > inline functions doing the appropriate conversions; > > 2. specifically, the *_flags() variant has no reason to exist. > It can be implemented through the *_bt() variant, and > being a new function the only places where you introduce it > require manual modifications so you can directly invoke > the new function. to clarify: i am not sure if now the *_bt() variant takes flags too, but my point is that the main API function should take all supported arguments (including flags) and others should simply be regarded as simplified versions. More or less what we have for sockets, with send() and sendmsg() and friend cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 18:10:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D1BBCCD; Tue, 18 Dec 2012 18:10:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 883558FC0A; Tue, 18 Dec 2012 18:10:58 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id ei8so463317wgb.20 for ; Tue, 18 Dec 2012 10:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9mYs28aKuBSA7F6k48Zxj2pbpDAEkuPkA8AqKpsPtdk=; b=asaQT2MMU7tpEWfR4+lRVRq66SQyrtGL+ubc/O1iKnpboCgodhDhUeAnYkEN52DtvX KlRG5dsPpjgG8oMv8o6C/t56iSoDp6Cwb4M9m3ic6+jT5TveFJsN4t5T/PLXv0buMEkb R3qd7Gk6/Pob4M4dwc550kq7V0xFYUG06KNWRFybCTtR5J3exWfYjvq1IvSw8sfWp7Ym h8ILiWbQywUwQtYCE2USCjGfmXG63LtrVnF96kvHtFuB2R2JzBDyl9YeeKwCsFs7n77x P2+oqn7Sc+UFwr/hC8PJCdAfX1sw6g7+s8bfFRiXoowwQ4dHCte5W8KeTSziKPLVKRDL DaIQ== X-Received: by 10.180.106.34 with SMTP id gr2mr6093537wib.18.1355853858666; Tue, 18 Dec 2012 10:04:18 -0800 (PST) Received: from pc.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id h19sm16857143wiv.7.2012.12.18.10.04.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 10:04:17 -0800 (PST) Sender: Alexander Motin Message-ID: <50D0B00D.8090002@FreeBSD.org> Date: Tue, 18 Dec 2012 20:03:57 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: API explosion (Re: [RFC/RFT] calloutng) References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> In-Reply-To: <20121218173643.GA94266@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:10:59 -0000 On 18.12.2012 19:36, Luigi Rizzo wrote: > On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: >>> I would instead do the following: >> >> I also don't very like the wide API and want to hear fresh ideas, but >> approaches to time measurement there are too different to do what you >> are proposing. Main problem is that while ticks value is relative, >> bintime is absolute. It is not easy to make conversion between them fast >> and precise. I've managed to do it, but the only function that does it >> now is _callout_reset_on(). All other functions are just passing values >> down. I am not sure I want to duplicate that code in each place, though >> doing it at least for for callout may be a good idea. > > I am afraid the above is not convincing. > > Most/all of the APIs i mentioned still have the conversion from > ticks to bintime, and the code in your patch is just > building multiple parallel paths (one for each of the > three versions of the same function) to some final > piece of code where the conversion takes place. > > The problem is that all of this goes through a set of obfuscating > macros and the end result is horrible. > > To be clear, i believe the work you have been doing on cleaning up > callout is great, i am just saying that this is the time to look > at the code from a few steps away and clean up all those design > decisions that perhaps were made in a haste to make things work. > > I will give you another example to show how convoluted > is the code now: > > cv_timedwait() and cv_timedwait_sig() now have three > versions each (plain, bt, flags). > > These six are remapped through macros to two functions, _cv_timedwait() > and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() > maps to _cv_timedwait_sig() ) > > These two _cv_timedwait*() take both ticks and bintimes, > and contain this sequence: > > + if (bt == NULL) > + sleepq_set_timeout_flags(cvp, timo, flags); > + else > + sleepq_set_timeout_bt(cvp, bt, precision); > > Guess what, both sleepq_* are macros that remap to the same > _sleepq_set_timeout(...) . So the above "if (bt == NULL)" is useless. > > But then if you dig into _sleepq_set_timeout() you'll see > > + if (bt == NULL) > + callout_reset_flags_on(&td->td_slpcallout, timo, > + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > + else > + callout_reset_bt_on(&td->td_slpcallout, bt, precision, > + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > > and again both callout_reset*() are again remapped through > macros to _callout_reset_on(), so another useless "if (bt == NULL)" > And in the end you have the conversion from ticks to bintime. > > So basically the code path for cv_timedwait() has those > two useless switches and one useless extra argument, > and the conversion from ticks to bintime is down > deep down in _callout_reset_on() where it can only > be resolved at runtime, whereas by doing the conversion > at the beginning the decision could have been made at compile > time. > > So I believe my proposal would give large simplifications in > the code and lead to a much cleaner implementation of what > you have designed: > > 1. acknowledge the fact that the only representation of time > that callouts use internally is a bintime+precision, define one > single function (instead of two or three or six) that implements > the blessed API, and implement the others with macros or > inline functions doing the appropriate conversions; > > 2. specifically, the *_flags() variant has no reason to exist. > It can be implemented through the *_bt() variant, and > being a new function the only places where you introduce it > require manual modifications so you can directly invoke > the new function. > > Again, please take this as constructive criticism, as i really > like the work you have been doing and appreciate the time and > effort you are putting on it Your words about useless cascaded ifs touched me. Actually I've looked on _callout_reset_bt_on() yesterday, thinking about moving tick to bt conversion to separate function or wrapper. The only thing we would save in such case is single integer argument (ticks), as all others (bt, prec, flags) are used in the new world order. From the other side, to make the conversion process really effective and correct, I've used quite specific way of obtaining time, that may change in the future. I would not really like it to be inlined in every consumer function and become an ABI. So I see two possible ways: make that conversion a separate non-inline function (that will require two temporary variables to return results and will consume some time on call/return), or make callout_reset_bt_on() to have extra ticks argument, allowing to use it in one or another way without external ifs and macros. In last case all _bt functions in other APIs will also obtain ticks, bt, pr and flags arguments. Actually flags there could be used to specify time scale (monotonic or wall) and time base (relative or absolute), if we decide to implement all of them at some point. >> Creating sets of three functions I had three different goals: >> - callout_reset() -- it is legacy variant required to keep API >> compatibility; >> - callout_reset_flags() -- it is for cases where custom precision >> specification needs to be added to the existing code, or where direct >> callout execution is needed. Conversion to bintime would additionally >> complicate consumer code, that I would try to avoid. >> - callout_reset_bt() -- API for the new code, which needs high >> precision and doesn't mind to operate bintime. Now there is only three >> such places in kernel now, and I don't think there will be much more. >> >> Respectively, these three options are replicated to other APIs where >> time intervals are used. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 18:50:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CC4C6D9; Tue, 18 Dec 2012 18:50:39 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 589CD8FC17; Tue, 18 Dec 2012 18:50:37 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fg15so475723wgb.33 for ; Tue, 18 Dec 2012 10:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hhFJi4uBnJY1ACU/yG9i4X1lOFer+uXPHXmiAxzLfkU=; b=j8ceGVMEjQ/N+1Ds9fy12orZKUf6aXevy5zY8APkBq/iT975SzZ//nU4KqCR+pZ2ri BNt/p3VsIDjPAZ1wXd2dFfcovr0RE1YhWMHyDWhhamyHPccacdprMcmyUC1mgICIslaF 1BwdVo1koOxjRz+bT964ITnErwc8gGK64oRNn3Qisie3f2XoyRAdjj89Byh2WL0ntC4f oTWxNbqPQafAX3qLglyOvrP4XPl2LWe/s9lB9CsauZOjRv7quNgdCrWbEQ2fv2c7iMer d1Cj7MriIHWT0A4SUM8qUBPmOWL1Zfd7RmBpjt87nWuvAy3YgHzFv5KK2EcqMOcJYcH/ 2MZw== MIME-Version: 1.0 Received: by 10.180.72.232 with SMTP id g8mr6865027wiv.0.1355856593219; Tue, 18 Dec 2012 10:49:53 -0800 (PST) Received: by 10.195.12.113 with HTTP; Tue, 18 Dec 2012 10:49:53 -0800 (PST) In-Reply-To: <20121218122422.GA35312@freebsd.org> References: <50D05FD6.7080008@freebsd.org> <20121218122422.GA35312@freebsd.org> Date: Tue, 18 Dec 2012 20:49:53 +0200 Message-ID: Subject: Re: protoc crash in libstdc++ From: George Liaskos To: Roman Divacky Content-Type: text/plain; charset=UTF-8 Cc: Ren? Ladan , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:50:39 -0000 ==90885== Memcheck, a memory error detector ==90885== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==90885== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==90885== Command: ./protoc ==90885== ==90885== Invalid read of size 8 ==90885== at 0x1388506: std::ostream::sentry::sentry(std::ostream&) (ostream.tcc:55) ==90885== by 0x13884CC: std::ostream::sentry::sentry(std::ostream&) (ostream:62) ==90885== by 0x138AA4A: std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long) (ostream_insert.h:83) ==90885== by 0x40599B: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (ostream:517) ==90885== by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885== by 0x4329D0: main (main.cc:63) ==90885== Address 0xffffffffffffffe8 is not stack'd, malloc'd or (recently) free'd ==90885== ==90885== ==90885== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==90885== Access not within mapped region at address 0xFFFFFFFFFFFFFFE8 ==90885== at 0x1388506: std::ostream::sentry::sentry(std::ostream&) (ostream.tcc:55) ==90885== by 0x13884CC: std::ostream::sentry::sentry(std::ostream&) (ostream:62) ==90885== by 0x138AA4A: std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long) (ostream_insert.h:83) ==90885== by 0x40599B: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (ostream:517) ==90885== by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885== by 0x4329D0: main (main.cc:63) ==90885== If you believe this happened as a result of a stack ==90885== overflow in your program's main thread (unlikely but ==90885== possible), you can try to increase the size of the ==90885== main thread stack using the --main-stacksize= flag. ==90885== The main thread stack size used in this run was 16777216. ==90885== ==90885== HEAP SUMMARY: ==90885== in use at exit: 1,949 bytes in 20 blocks ==90885== total heap usage: 20 allocs, 0 frees, 1,949 bytes allocated ==90885== ==90885== 26 bytes in 1 blocks are possibly lost in loss record 3 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x4057CF: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (command_line_interface.cc:784) ==90885== by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885== by 0x4329D0: main (main.cc:63) ==90885== ==90885== 32 bytes in 1 blocks are possibly lost in loss record 4 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x432816: main (main.cc:45) ==90885== ==90885== 33 bytes in 1 blocks are possibly lost in loss record 5 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x1375D65: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (basic_string.tcc:460) ==90885== by 0x1377A62: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (basic_string.tcc:665) ==90885== by 0x1377974: std::string::assign(char const*, unsigned long) (basic_string.tcc:268) ==90885== by 0x4055EA: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (basic_string.h:919) ==90885== by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885== by 0x4329D0: main (main.cc:63) ==90885== ==90885== 34 bytes in 1 blocks are possibly lost in loss record 6 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x432861: main (main.cc:49) ==90885== ==90885== 35 bytes in 1 blocks are possibly lost in loss record 7 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x4328E3: main (main.cc:54) ==90885== ==90885== 37 bytes in 1 blocks are possibly lost in loss record 8 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x432965: main (main.cc:60) ==90885== ==90885== 51 bytes in 1 blocks are possibly lost in loss record 9 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x432900: main (main.cc:54) ==90885== ==90885== 53 bytes in 1 blocks are possibly lost in loss record 10 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x432982: main (main.cc:60) ==90885== ==90885== 56 bytes in 1 blocks are possibly lost in loss record 14 of 20 ==90885== at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885== by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885== by 0x1375465: __gnu_cxx::new_allocator::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885== by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (basic_string.tcc:588) ==90885== by 0x137A8AF: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:150) ==90885== by 0x137AB34: char* std::string::_S_construct_aux(char const*, char const*, std::allocator const&, std::__false_type) (basic_string.h:1453) ==90885== by 0x1376644: char* std::string::_S_construct(char const*, char const*, std::allocator const&) (basic_string.h:1468) ==90885== by 0x13766F4: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:226) ==90885== by 0x1376674: std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) (basic_string.h:228) ==90885== by 0x43287E: main (main.cc:49) ==90885== ==90885== LEAK SUMMARY: ==90885== definitely lost: 0 bytes in 0 blocks ==90885== indirectly lost: 0 bytes in 0 blocks ==90885== possibly lost: 357 bytes in 9 blocks ==90885== still reachable: 1,592 bytes in 11 blocks ==90885== suppressed: 0 bytes in 0 blocks ==90885== Reachable blocks (those to which a pointer was found) are not shown. ==90885== To see them, rerun with: --leak-check=full --show-reachable=yes ==90885== ==90885== For counts of detected and suppressed errors, rerun with: -v ==90885== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 0 from 0) Segmentation fault On Tue, Dec 18, 2012 at 2:24 PM, Roman Divacky wrote: > On Tue, Dec 18, 2012 at 01:21:42PM +0100, Ren? Ladan wrote: >> Hi, >> >> the following backtrace is from a crash that happened when building >> www/chromium with clang. The chromium port builds a binary protoc which >> crashes when built with clang. >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 802006400 (LWP 100869)] >> 0x0000000800996506 in std::ostream::sentry::sentry(std::ostream&) () >> from /usr/lib/libstdc++.so.6 >> (gdb) bt >> #0 0x0000000800996506 in std::ostream::sentry::sentry(std::ostream&) () >> from /usr/lib/libstdc++.so.6 >> #1 0x00000008009964cd in std::basic_ostream::sentry::sentry >> (this=0x7fffffffcf88, __os=...) at /usr/include/c++/4.2/ostream:62 >> #2 0x0000000800998a4b in std::__ostream_insert> std::char_traits > (__out=..., __s=0x485df0 "Missing input file.", >> __n=19) >> at >> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83 >> #3 0x000000000040592c in operator<< > >> (this=, __out=..., __out=..., __s=) at >> /usr/include/c++/4.2/ostream:517 >> #4 google::protobuf::compiler::CommandLineInterface::ParseArguments >> (this=, argc=1, argv=0x7fffffffd640) at >> third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:790 >> #5 0x00000000004048b0 in >> google::protobuf::compiler::CommandLineInterface::Run >> (this=0x7fffffffd4d0, argc=-12408, argv=0x7fffffffcf88) >> at >> third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:588 >> #6 0x0000000000432957 in main (argc=-12408, argv=0x7fffffffcf88) at > ^^^^^^ > wow :) > > > Can you run this under valgrind? > > Roman > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 20:12:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49D5F8A7; Tue, 18 Dec 2012 20:12:51 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 009B28FC12; Tue, 18 Dec 2012 20:12:50 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:90a8:9e4b:2980:e339] (unknown [IPv6:2001:7b8:3a7:0:90a8:9e4b:2980:e339]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D75C95C5A; Tue, 18 Dec 2012 21:12:43 +0100 (CET) Message-ID: <50D0CE37.3000306@FreeBSD.org> Date: Tue, 18 Dec 2012 21:12:39 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Ladan?= Subject: Re: protoc crash in libstdc++ References: <50D05FD6.7080008@freebsd.org> In-Reply-To: <50D05FD6.7080008@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Roman Divacky , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 20:12:51 -0000 On 2012-12-18 13:21, Ren=E9 Ladan wrote: > the following backtrace is from a crash that happened when building > www/chromium with clang. The chromium port builds a binary protoc whic= h > crashes when built with clang. =2E.. > So the question is if this is a protoc or a clang or a libstdc++ bug. Try removing --gc-sections from the link flags for protoc, that should solve it for now. I am still looking at the root cause, which seems to be something in our ld; it does not seem to be related to either clang or libstdc++. From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 21:12:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0680DE6F; Tue, 18 Dec 2012 21:12:24 +0000 (UTC) (envelope-from geo.liaskos@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 F3A838FC0A; Tue, 18 Dec 2012 21:12:22 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so3296855wib.1 for ; Tue, 18 Dec 2012 13:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O87mjw1do2Zu26PBrNxELPaqkuisHvb48QT4rLIxaco=; b=jDgCvFiWZbOlFhI4pwz/i+p/TlV6q2O6Up/5o9wb5Vjal3b8tSzVjmYknvs1XGhWhU I8xQeuj3+lm5wffgtqErNyP5UKi0fcHkTgCMI2R7YYO1oXhKww3KtuJQ3+vUb1yIgLlG 3bou2jt21/zeqsbW+3K16gZT5wFe1kc9o6dtFCDeuAJbCw3vfczpkObmyino0dDXTVl9 AVPdTu+pdTx/0uJl6Bg3rKSA4pHvYx267XNwi0RA79WLCCo52hGkn/ud1mmFOupvLhtZ 2yRhPfIoI+DUqAu5rLTpGZoYc8JS6cvbpErjG0LEyTj+4jxEGGY3lrz2DCQNGyXfXrLS FE6Q== MIME-Version: 1.0 Received: by 10.194.236.166 with SMTP id uv6mr7222164wjc.34.1355865136034; Tue, 18 Dec 2012 13:12:16 -0800 (PST) Received: by 10.195.12.113 with HTTP; Tue, 18 Dec 2012 13:12:15 -0800 (PST) In-Reply-To: <50D0CE37.3000306@FreeBSD.org> References: <50D05FD6.7080008@freebsd.org> <50D0CE37.3000306@FreeBSD.org> Date: Tue, 18 Dec 2012 23:12:15 +0200 Message-ID: Subject: Re: protoc crash in libstdc++ From: George Liaskos To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Ren=C3=A9_Ladan?= , Roman Divacky , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 21:12:24 -0000 > Try removing --gc-sections from the link flags for protoc, that should > solve it for now. I am still looking at the root cause, which seems to > be something in our ld; it does not seem to be related to either clang > or libstdc++. Whoa, thank you! Removing --gc-sections from the link flags solves the issue indeed! From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 21:37:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE3E786C; Tue, 18 Dec 2012 21:37:26 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx1.freebsd.org (Postfix) with ESMTP id 64A018FC0A; Tue, 18 Dec 2012 21:37:26 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id p1so1539042vcq.10 for ; Tue, 18 Dec 2012 13:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E53TKN0d2CttYapjYSTlcOTAUbtcv7H1rG2mnf9m69s=; b=X/R91D5wVD/Dvobc2kG2SiQHPA1T1DDdZ9gdL6I4EoHDWOfEmm9a0ZMBfvx042m9i/ 8K0ljnmI2c+6FFymAhuPAwmXcnfYpf9JEP1lKv/c5wxZFS1H+W69TFNmB2qsiIwY7P1s Epp7bJG8hVZgJ7+aQSZehJF66GrQV723eWYyVMnm2/mp7BD5GjjwfTcie/Q4jNzAng6/ lWGuGR/cqPalZ1/0UXTUYRCSFZzLWktxWof0s6MqSwxbxQbnhT256uHfiAG3WvAy1Lp0 2LjBnixj5wvPLgtr7p9d1SRp0ohWhz9/ZOfHh87vBj1D7+1fK+ePmBYEOdECcvDhs3Hv gB0w== MIME-Version: 1.0 Received: by 10.52.27.241 with SMTP id w17mr4732788vdg.96.1355866640720; Tue, 18 Dec 2012 13:37:20 -0800 (PST) Received: by 10.58.207.114 with HTTP; Tue, 18 Dec 2012 13:37:20 -0800 (PST) In-Reply-To: <50D05E7E.4040105@FreeBSD.org> References: <50D053E5.3050003@m5p.com> <50D05E7E.4040105@FreeBSD.org> Date: Tue, 18 Dec 2012 16:37:20 -0500 Message-ID: Subject: Re: Failed to initialize dwarf? From: Ryan Stone To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Mitchell , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 21:37:26 -0000 I have a checkout of r244047. I did a make kernel-toolchain followed by a make buildkernel and I see this warning. On Tue, Dec 18, 2012 at 7:15 AM, Dimitry Andric wrote: > On 2012-12-18 12:30, George Mitchell wrote: > >> I checked out head Sunday and now my attempt at building a kernel says: >> >> ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at >> [dwarf_init_attr(400)] >> >> on every module it compiles (though it seems happy enough to keep >> compiling). Should I just ignore this? -- George Mitchell >> > > This problem was fixed in libdwarf in r239872; did you run "make > buildworld" before "make buildkernel"? > > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 21:46:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22788D0B; Tue, 18 Dec 2012 21:46:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4C96E8FC13; Tue, 18 Dec 2012 21:46:24 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm2so740685wib.4 for ; Tue, 18 Dec 2012 13:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A68M3grTghYB4r+16AGzieL1sMBAZo7c+1yR/mVHgog=; b=iaQtlPdUBNka2Ll0yOAcNFmT+A3Xdh8nkw7polEH7nqp6PlY4niYz3KUyanBWIKbfH /GZqHWm9exHES9bTyAnLN7k+37aenGG1GqixMmngrttu+y0Nok6Y3nIRjQ8zGN7BpWcw X8ZctZtsxOmOqBmv9W/lgtjXvODtdmWgLxTSjiRTwIAe+EWN50KNZmviV2+GHzeXk/IA K0A+5Aif/Y2jZ/Tp3DMr7zSDvyQWLhp3xAYUsDzbjSm+jOPTyAasWESa/ltJNIkTplZW I2AzXEe9Fe/Pru+/h6oRaKfF5qzYmz7AIA6L4o7I8Z+gsTdKB+XJk26dxsxFOCpe5CaQ VXUg== X-Received: by 10.194.118.229 with SMTP id kp5mr7520317wjb.2.1355867183807; Tue, 18 Dec 2012 13:46:23 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id bd7sm4666335wib.8.2012.12.18.13.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 13:46:22 -0800 (PST) Sender: Alexander Motin Message-ID: <50D0E42B.6030605@FreeBSD.org> Date: Tue, 18 Dec 2012 23:46:19 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: API explosion (Re: [RFC/RFT] calloutng) References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> In-Reply-To: <50D0B00D.8090002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 21:46:26 -0000 On 18.12.2012 20:03, Alexander Motin wrote: > On 18.12.2012 19:36, Luigi Rizzo wrote: >> On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: >>>> I would instead do the following: >>> >>> I also don't very like the wide API and want to hear fresh ideas, but >>> approaches to time measurement there are too different to do what you >>> are proposing. Main problem is that while ticks value is relative, >>> bintime is absolute. It is not easy to make conversion between them fast >>> and precise. I've managed to do it, but the only function that does it >>> now is _callout_reset_on(). All other functions are just passing values >>> down. I am not sure I want to duplicate that code in each place, though >>> doing it at least for for callout may be a good idea. >> >> I am afraid the above is not convincing. >> >> Most/all of the APIs i mentioned still have the conversion from >> ticks to bintime, and the code in your patch is just >> building multiple parallel paths (one for each of the >> three versions of the same function) to some final >> piece of code where the conversion takes place. >> >> The problem is that all of this goes through a set of obfuscating >> macros and the end result is horrible. >> >> To be clear, i believe the work you have been doing on cleaning up >> callout is great, i am just saying that this is the time to look >> at the code from a few steps away and clean up all those design >> decisions that perhaps were made in a haste to make things work. >> >> I will give you another example to show how convoluted >> is the code now: >> >> cv_timedwait() and cv_timedwait_sig() now have three >> versions each (plain, bt, flags). >> >> These six are remapped through macros to two functions, _cv_timedwait() >> and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() >> maps to _cv_timedwait_sig() ) >> >> These two _cv_timedwait*() take both ticks and bintimes, >> and contain this sequence: >> >> + if (bt == NULL) >> + sleepq_set_timeout_flags(cvp, timo, flags); >> + else >> + sleepq_set_timeout_bt(cvp, bt, precision); >> >> Guess what, both sleepq_* are macros that remap to the same >> _sleepq_set_timeout(...) . So the above "if (bt == NULL)" is useless. >> >> But then if you dig into _sleepq_set_timeout() you'll see >> >> + if (bt == NULL) >> + callout_reset_flags_on(&td->td_slpcallout, timo, >> + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); >> + else >> + callout_reset_bt_on(&td->td_slpcallout, bt, precision, >> + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); >> >> and again both callout_reset*() are again remapped through >> macros to _callout_reset_on(), so another useless "if (bt == NULL)" >> And in the end you have the conversion from ticks to bintime. >> >> So basically the code path for cv_timedwait() has those >> two useless switches and one useless extra argument, >> and the conversion from ticks to bintime is down >> deep down in _callout_reset_on() where it can only >> be resolved at runtime, whereas by doing the conversion >> at the beginning the decision could have been made at compile >> time. >> >> So I believe my proposal would give large simplifications in >> the code and lead to a much cleaner implementation of what >> you have designed: >> >> 1. acknowledge the fact that the only representation of time >> that callouts use internally is a bintime+precision, define one >> single function (instead of two or three or six) that implements >> the blessed API, and implement the others with macros or >> inline functions doing the appropriate conversions; >> >> 2. specifically, the *_flags() variant has no reason to exist. >> It can be implemented through the *_bt() variant, and >> being a new function the only places where you introduce it >> require manual modifications so you can directly invoke >> the new function. >> >> Again, please take this as constructive criticism, as i really >> like the work you have been doing and appreciate the time and >> effort you are putting on it > > Your words about useless cascaded ifs touched me. Actually I've looked > on _callout_reset_bt_on() yesterday, thinking about moving tick to bt > conversion to separate function or wrapper. The only thing we would save > in such case is single integer argument (ticks), as all others (bt, > prec, flags) are used in the new world order. From the other side, to > make the conversion process really effective and correct, I've used > quite specific way of obtaining time, that may change in the future. I > would not really like it to be inlined in every consumer function and > become an ABI. So I see two possible ways: make that conversion a > separate non-inline function (that will require two temporary variables > to return results and will consume some time on call/return), or make > callout_reset_bt_on() to have extra ticks argument, allowing to use it > in one or another way without external ifs and macros. In last case all > _bt functions in other APIs will also obtain ticks, bt, pr and flags > arguments. Actually flags there could be used to specify time scale > (monotonic or wall) and time base (relative or absolute), if we decide > to implement all of them at some point. What will you say about this patch: http://people.freebsd.org/~mav/calloutng_api2.patch ? It is the second way of above. Somewhat less functions, one extra argument, no branching. >>> Creating sets of three functions I had three different goals: >>> - callout_reset() -- it is legacy variant required to keep API >>> compatibility; >>> - callout_reset_flags() -- it is for cases where custom precision >>> specification needs to be added to the existing code, or where direct >>> callout execution is needed. Conversion to bintime would additionally >>> complicate consumer code, that I would try to avoid. >>> - callout_reset_bt() -- API for the new code, which needs high >>> precision and doesn't mind to operate bintime. Now there is only three >>> such places in kernel now, and I don't think there will be much more. >>> >>> Respectively, these three options are replicated to other APIs where >>> time intervals are used. > -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 21:56:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C10982F0 for ; Tue, 18 Dec 2012 21:56:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 774378FC12 for ; Tue, 18 Dec 2012 21:56:07 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:90a8:9e4b:2980:e339] (unknown [IPv6:2001:7b8:3a7:0:90a8:9e4b:2980:e339]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C4A155C5A; Tue, 18 Dec 2012 22:56:05 +0100 (CET) Message-ID: <50D0E672.8020006@FreeBSD.org> Date: Tue, 18 Dec 2012 22:56:02 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Ryan Stone Subject: Re: Failed to initialize dwarf? References: <50D053E5.3050003@m5p.com> <50D05E7E.4040105@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: George Mitchell , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 21:56:07 -0000 On 2012-12-18 22:37, Ryan Stone wrote: > On Tue, Dec 18, 2012 at 7:15 AM, Dimitry Andric > wrote: >> On 2012-12-18 12:30, George Mitchell wrote: >> ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at >> [dwarf_init_attr(400)] > This problem was fixed in libdwarf in r239872; did you run "make > buildworld" before "make buildkernel"? > I have a checkout of r244047. I did a make kernel-toolchain followed by a make buildkernel and I see this warning. The question is if ctfconvert (and dependencies) are rebuilt when you do kernel-toolchain. Can you figure out if it runs ctfconvert from base? From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 22:39:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 808C8EF0; Tue, 18 Dec 2012 22:39:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id 141F08FC16; Tue, 18 Dec 2012 22:39:52 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id fw7so1617783vcb.3 for ; Tue, 18 Dec 2012 14:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9G/qKWQPiiCoZoL/aAYkzZCVynnMsDScIEUU0QjGfp4=; b=mVBqoNCJWqGY7UJW9xFKCulHh8SleS6BvGJBl8dlO6Tk+byRS8M5FAcCvlhoD1xj/0 3jmdYl1o8QVIZ8Po8l4Dyzz6AY4E8ZQY8bdDh5O+dkqbJBdXXwG1XJ0SvY5iU8Kxsoty yz1Foc1GGXMygxU/wX2HH3Z0dnIGcKnjSWnTm9sxjs+arcpwdKmvgbcsv8vsmEFqX7wu 6ZXWMVL4xjPLgVWOC51a8x+K7B/enrs4DHTmVczsbe/CxQ1/EdXjZVGRppVl7mPufW9h Mp90NCNdBJpmxedjjKE9zxDt8JmBfqut9T4mk0ZKS+Bl1kVvFAnSupd6+vWoeyaS7vkJ OJ8Q== MIME-Version: 1.0 Received: by 10.220.240.141 with SMTP id la13mr5646183vcb.39.1355870386131; Tue, 18 Dec 2012 14:39:46 -0800 (PST) Received: by 10.58.207.114 with HTTP; Tue, 18 Dec 2012 14:39:45 -0800 (PST) In-Reply-To: <50D0E672.8020006@FreeBSD.org> References: <50D053E5.3050003@m5p.com> <50D05E7E.4040105@FreeBSD.org> <50D0E672.8020006@FreeBSD.org> Date: Tue, 18 Dec 2012 17:39:45 -0500 Message-ID: Subject: Re: Failed to initialize dwarf? From: Ryan Stone To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Mitchell , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:39:53 -0000 On Tue, Dec 18, 2012 at 4:56 PM, Dimitry Andric wrote: > The question is if ctfconvert (and dependencies) are rebuilt when you do > kernel-toolchain. Can you figure out if it runs ctfconvert from base? > Aha! You're right: [rstone@rstone-laptop vll]make buildenv Entering world for amd64:amd64 $ which ctfconvert /usr/bin/ctfconvert $ which cc /home/rstone/obj/usr/home/rstone/git/vll/tmp/usr/bin/cc I think that this (in Makefile.incl1) might be the culprit? # dtrace tools are required for older bootstrap env and cross-build .if ${MK_CDDL} != "no" && \ ((${BOOTSTRAPPING} < 800038 && \ !(${BOOTSTRAPPING} >= 700112 && ${BOOTSTRAPPING} < 799999)) \ || (${MACHINE} != ${TARGET} || ${MACHINE_ARCH} != ${TARGET_ARCH})) _dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \ lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge .endif From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 22:59:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D221637; Tue, 18 Dec 2012 22:59:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECCF8FC15; Tue, 18 Dec 2012 22:59:49 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B16B07300A; Tue, 18 Dec 2012 23:58:23 +0100 (CET) Date: Tue, 18 Dec 2012 23:58:23 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121218225823.GA96962@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D0E42B.6030605@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , freebsd-current , phk@onelab2.iet.unipi.it, "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:59:50 -0000 [top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. The key difference between 'ticks' and bintimes (and the main difficulty in the conversion) is that ticks are relative and bintimes are interpreted as absolute. This could be easily solved by using a flag to specify if the 'bt' argument is absolute or relative, and passing the argument by value. So now the flags could contain C_DIRECT_EXEC, C_BT_IS_RELATIVE, the precision, and another 64 or 128 bit field contains the bintime. How does this look ? cheers luigi > On 18.12.2012 20:03, Alexander Motin wrote: > >On 18.12.2012 19:36, Luigi Rizzo wrote: > >>On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: > >>>>I would instead do the following: > >>> > >>>I also don't very like the wide API and want to hear fresh ideas, but > >>>approaches to time measurement there are too different to do what you > >>>are proposing. Main problem is that while ticks value is relative, > >>>bintime is absolute. It is not easy to make conversion between them fast > >>>and precise. I've managed to do it, but the only function that does it > >>>now is _callout_reset_on(). All other functions are just passing values > >>>down. I am not sure I want to duplicate that code in each place, though > >>>doing it at least for for callout may be a good idea. > >> > >>I am afraid the above is not convincing. > >> > >>Most/all of the APIs i mentioned still have the conversion from > >>ticks to bintime, and the code in your patch is just > >>building multiple parallel paths (one for each of the > >>three versions of the same function) to some final > >>piece of code where the conversion takes place. > >> > >>The problem is that all of this goes through a set of obfuscating > >>macros and the end result is horrible. > >> > >>To be clear, i believe the work you have been doing on cleaning up > >>callout is great, i am just saying that this is the time to look > >>at the code from a few steps away and clean up all those design > >>decisions that perhaps were made in a haste to make things work. > >> > >>I will give you another example to show how convoluted > >>is the code now: > >> > >>cv_timedwait() and cv_timedwait_sig() now have three > >>versions each (plain, bt, flags). > >> > >>These six are remapped through macros to two functions, _cv_timedwait() > >>and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() > >>maps to _cv_timedwait_sig() ) > >> > >>These two _cv_timedwait*() take both ticks and bintimes, > >>and contain this sequence: > >> > >>+ if (bt == NULL) > >>+ sleepq_set_timeout_flags(cvp, timo, flags); > >>+ else > >>+ sleepq_set_timeout_bt(cvp, bt, precision); > >> > >>Guess what, both sleepq_* are macros that remap to the same > >>_sleepq_set_timeout(...) . So the above "if (bt == NULL)" is useless. > >> > >>But then if you dig into _sleepq_set_timeout() you'll see > >> > >>+ if (bt == NULL) > >>+ callout_reset_flags_on(&td->td_slpcallout, timo, > >>+ sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > >>+ else > >>+ callout_reset_bt_on(&td->td_slpcallout, bt, precision, > >>+ sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > >> > >>and again both callout_reset*() are again remapped through > >>macros to _callout_reset_on(), so another useless "if (bt == NULL)" > >>And in the end you have the conversion from ticks to bintime. > >> > >>So basically the code path for cv_timedwait() has those > >>two useless switches and one useless extra argument, > >>and the conversion from ticks to bintime is down > >>deep down in _callout_reset_on() where it can only > >>be resolved at runtime, whereas by doing the conversion > >>at the beginning the decision could have been made at compile > >>time. > >> > >>So I believe my proposal would give large simplifications in > >>the code and lead to a much cleaner implementation of what > >>you have designed: > >> > >>1. acknowledge the fact that the only representation of time > >> that callouts use internally is a bintime+precision, define one > >> single function (instead of two or three or six) that implements > >> the blessed API, and implement the others with macros or > >> inline functions doing the appropriate conversions; > >> > >>2. specifically, the *_flags() variant has no reason to exist. > >> It can be implemented through the *_bt() variant, and > >> being a new function the only places where you introduce it > >> require manual modifications so you can directly invoke > >> the new function. > >> > >>Again, please take this as constructive criticism, as i really > >>like the work you have been doing and appreciate the time and > >>effort you are putting on it > > > >Your words about useless cascaded ifs touched me. Actually I've looked > >on _callout_reset_bt_on() yesterday, thinking about moving tick to bt > >conversion to separate function or wrapper. The only thing we would save > >in such case is single integer argument (ticks), as all others (bt, > >prec, flags) are used in the new world order. From the other side, to > >make the conversion process really effective and correct, I've used > >quite specific way of obtaining time, that may change in the future. I > >would not really like it to be inlined in every consumer function and > >become an ABI. So I see two possible ways: make that conversion a > >separate non-inline function (that will require two temporary variables > >to return results and will consume some time on call/return), or make > >callout_reset_bt_on() to have extra ticks argument, allowing to use it > >in one or another way without external ifs and macros. In last case all > >_bt functions in other APIs will also obtain ticks, bt, pr and flags > >arguments. Actually flags there could be used to specify time scale > >(monotonic or wall) and time base (relative or absolute), if we decide > >to implement all of them at some point. > > What will you say about this patch: > http://people.freebsd.org/~mav/calloutng_api2.patch > ? > > It is the second way of above. Somewhat less functions, one extra > argument, no branching. > > >>>Creating sets of three functions I had three different goals: > >>> - callout_reset() -- it is legacy variant required to keep API > >>>compatibility; > >>> - callout_reset_flags() -- it is for cases where custom precision > >>>specification needs to be added to the existing code, or where direct > >>>callout execution is needed. Conversion to bintime would additionally > >>>complicate consumer code, that I would try to avoid. > >>> - callout_reset_bt() -- API for the new code, which needs high > >>>precision and doesn't mind to operate bintime. Now there is only three > >>>such places in kernel now, and I don't think there will be much more. > >>> > >>>Respectively, these three options are replicated to other APIs where > >>>time intervals are used. > > > > > -- > Alexander Motin > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 23:28:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BF2A978; Tue, 18 Dec 2012 23:28:07 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id A84468FC15; Tue, 18 Dec 2012 23:28:02 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBINRtBF014465; Tue, 18 Dec 2012 16:27:55 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBINRjZu064428; Tue, 18 Dec 2012 16:27:45 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Ian Lepore To: Luigi Rizzo In-Reply-To: <20121218225823.GA96962@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Dec 2012 16:27:45 -0700 Message-ID: <1355873265.1198.183.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Alexander Motin , freebsd-current , phk@onelab2.iet.unipi.it, "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:28:07 -0000 On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > [top posting for readability; > in summary we were discussing the new callout API trying to avoid > an explosion of methods and arguments while at the same time > supporting the old API and the new one] > (I am also Cc-ing phk as he might have better insight > on the topic). > > I think the patch you propose is a step in the right direction, > but i still remain concerned by having to pass two bintimes > (by reference, but they should really go by value) > and one 'ticks' value to all these functions. > > I am also dubious that we need a full 128 bits to specify > the 'precision': there would be absolutely no loss of functionality > if we decided to specify the precision in powers of 2, so a precision > 'k' (signed) means 2^k seconds. This way 8 bits are enough to > represent any precision we want. > > The key difference between 'ticks' and bintimes (and the main > difficulty in the conversion) is that ticks are relative and bintimes > are interpreted as absolute. This could be easily solved by using > a flag to specify if the 'bt' argument is absolute or relative, and > passing the argument by value. > > So now the flags could contain C_DIRECT_EXEC, C_BT_IS_RELATIVE, the > precision, and another 64 or 128 bit field contains the bintime. > > How does this look ? > > cheers > luigi > I tend to agree that the bintime should be passed by value instead of reference. That would allow an inline tickstobintime() that converts relative ticks to an absolute bintime returned by value and passed right along in one tidy line/clump of code without any temporary variables cluttering things up. While the 1980s C programmer in me still wants to avoid returning complex objects by value, the reality is that modern compilers tend to generate really nice code for such constructs, usually without any copying of the return value at all. I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It would typical to want a 500uS timeout but be willing to late by up to 250uS if that helped scheduling and performance. Also, my idea of precision would virtually always be "I'm willing to be late by this much, but never early by any amount." To reinforce the point of that last paragraph... the way I'm looking at these changes has nothing to do with power saving (I've never owned a battery-operated computer, probably never will) and everything to do with performance and being able to sleep accurately for less than a tick. -- Ian > > On 18.12.2012 20:03, Alexander Motin wrote: > > >On 18.12.2012 19:36, Luigi Rizzo wrote: > > >>On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: > > >>>>I would instead do the following: > > >>> > > >>>I also don't very like the wide API and want to hear fresh ideas, but > > >>>approaches to time measurement there are too different to do what you > > >>>are proposing. Main problem is that while ticks value is relative, > > >>>bintime is absolute. It is not easy to make conversion between them fast > > >>>and precise. I've managed to do it, but the only function that does it > > >>>now is _callout_reset_on(). All other functions are just passing values > > >>>down. I am not sure I want to duplicate that code in each place, though > > >>>doing it at least for for callout may be a good idea. > > >> > > >>I am afraid the above is not convincing. > > >> > > >>Most/all of the APIs i mentioned still have the conversion from > > >>ticks to bintime, and the code in your patch is just > > >>building multiple parallel paths (one for each of the > > >>three versions of the same function) to some final > > >>piece of code where the conversion takes place. > > >> > > >>The problem is that all of this goes through a set of obfuscating > > >>macros and the end result is horrible. > > >> > > >>To be clear, i believe the work you have been doing on cleaning up > > >>callout is great, i am just saying that this is the time to look > > >>at the code from a few steps away and clean up all those design > > >>decisions that perhaps were made in a haste to make things work. > > >> > > >>I will give you another example to show how convoluted > > >>is the code now: > > >> > > >>cv_timedwait() and cv_timedwait_sig() now have three > > >>versions each (plain, bt, flags). > > >> > > >>These six are remapped through macros to two functions, _cv_timedwait() > > >>and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() > > >>maps to _cv_timedwait_sig() ) > > >> > > >>These two _cv_timedwait*() take both ticks and bintimes, > > >>and contain this sequence: > > >> > > >>+ if (bt == NULL) > > >>+ sleepq_set_timeout_flags(cvp, timo, flags); > > >>+ else > > >>+ sleepq_set_timeout_bt(cvp, bt, precision); > > >> > > >>Guess what, both sleepq_* are macros that remap to the same > > >>_sleepq_set_timeout(...) . So the above "if (bt == NULL)" is useless. > > >> > > >>But then if you dig into _sleepq_set_timeout() you'll see > > >> > > >>+ if (bt == NULL) > > >>+ callout_reset_flags_on(&td->td_slpcallout, timo, > > >>+ sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > > >>+ else > > >>+ callout_reset_bt_on(&td->td_slpcallout, bt, precision, > > >>+ sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > > >> > > >>and again both callout_reset*() are again remapped through > > >>macros to _callout_reset_on(), so another useless "if (bt == NULL)" > > >>And in the end you have the conversion from ticks to bintime. > > >> > > >>So basically the code path for cv_timedwait() has those > > >>two useless switches and one useless extra argument, > > >>and the conversion from ticks to bintime is down > > >>deep down in _callout_reset_on() where it can only > > >>be resolved at runtime, whereas by doing the conversion > > >>at the beginning the decision could have been made at compile > > >>time. > > >> > > >>So I believe my proposal would give large simplifications in > > >>the code and lead to a much cleaner implementation of what > > >>you have designed: > > >> > > >>1. acknowledge the fact that the only representation of time > > >> that callouts use internally is a bintime+precision, define one > > >> single function (instead of two or three or six) that implements > > >> the blessed API, and implement the others with macros or > > >> inline functions doing the appropriate conversions; > > >> > > >>2. specifically, the *_flags() variant has no reason to exist. > > >> It can be implemented through the *_bt() variant, and > > >> being a new function the only places where you introduce it > > >> require manual modifications so you can directly invoke > > >> the new function. > > >> > > >>Again, please take this as constructive criticism, as i really > > >>like the work you have been doing and appreciate the time and > > >>effort you are putting on it > > > > > >Your words about useless cascaded ifs touched me. Actually I've looked > > >on _callout_reset_bt_on() yesterday, thinking about moving tick to bt > > >conversion to separate function or wrapper. The only thing we would save > > >in such case is single integer argument (ticks), as all others (bt, > > >prec, flags) are used in the new world order. From the other side, to > > >make the conversion process really effective and correct, I've used > > >quite specific way of obtaining time, that may change in the future. I > > >would not really like it to be inlined in every consumer function and > > >become an ABI. So I see two possible ways: make that conversion a > > >separate non-inline function (that will require two temporary variables > > >to return results and will consume some time on call/return), or make > > >callout_reset_bt_on() to have extra ticks argument, allowing to use it > > >in one or another way without external ifs and macros. In last case all > > >_bt functions in other APIs will also obtain ticks, bt, pr and flags > > >arguments. Actually flags there could be used to specify time scale > > >(monotonic or wall) and time base (relative or absolute), if we decide > > >to implement all of them at some point. > > > > What will you say about this patch: > > http://people.freebsd.org/~mav/calloutng_api2.patch > > ? > > > > It is the second way of above. Somewhat less functions, one extra > > argument, no branching. > > > > >>>Creating sets of three functions I had three different goals: > > >>> - callout_reset() -- it is legacy variant required to keep API > > >>>compatibility; > > >>> - callout_reset_flags() -- it is for cases where custom precision > > >>>specification needs to be added to the existing code, or where direct > > >>>callout execution is needed. Conversion to bintime would additionally > > >>>complicate consumer code, that I would try to avoid. > > >>> - callout_reset_bt() -- API for the new code, which needs high > > >>>precision and doesn't mind to operate bintime. Now there is only three > > >>>such places in kernel now, and I don't think there will be much more. > > >>> > > >>>Respectively, these three options are replicated to other APIs where > > >>>time intervals are used. > > > > > > > > > -- > > Alexander Motin > > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 23:31:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 073A1B67; Tue, 18 Dec 2012 23:31:15 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B1A7F8FC0C; Tue, 18 Dec 2012 23:31:14 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id AD3B37300A; Wed, 19 Dec 2012 00:29:55 +0100 (CET) Date: Wed, 19 Dec 2012 00:29:55 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121218232955.GA97440@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355873265.1198.183.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:31:15 -0000 On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: > On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > > [top posting for readability; > > in summary we were discussing the new callout API trying to avoid > > an explosion of methods and arguments while at the same time > > supporting the old API and the new one] > > (I am also Cc-ing phk as he might have better insight > > on the topic). > > > > I think the patch you propose is a step in the right direction, > > but i still remain concerned by having to pass two bintimes > > (by reference, but they should really go by value) > > and one 'ticks' value to all these functions. > > > > I am also dubious that we need a full 128 bits to specify > > the 'precision': there would be absolutely no loss of functionality > > if we decided to specify the precision in powers of 2, so a precision > > 'k' (signed) means 2^k seconds. This way 8 bits are enough to > > represent any precision we want. ... > I'm not so sure about the 2^k precision. You speak of seconds, but I > would be worrying about sub-second precision in my work. It would > typical to want a 500uS timeout but be willing to late by up to 250uS if i said k is signed so negative values represent fractions of a second. 2^-128 is pretty short :) cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 23:37:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49399D9F; Tue, 18 Dec 2012 23:37:16 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E01328FC0A; Tue, 18 Dec 2012 23:37:13 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBINbCI3036231; Tue, 18 Dec 2012 16:37:12 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBINbAla064484; Tue, 18 Dec 2012 16:37:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Ian Lepore To: Luigi Rizzo In-Reply-To: <20121218232955.GA97440@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <20121218232955.GA97440@onelab2.iet.unipi.it> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Dec 2012 16:37:10 -0700 Message-ID: <1355873830.1198.189.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:37:16 -0000 On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: > On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: > > On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > > > [top posting for readability; > > > in summary we were discussing the new callout API trying to avoid > > > an explosion of methods and arguments while at the same time > > > supporting the old API and the new one] > > > (I am also Cc-ing phk as he might have better insight > > > on the topic). > > > > > > I think the patch you propose is a step in the right direction, > > > but i still remain concerned by having to pass two bintimes > > > (by reference, but they should really go by value) > > > and one 'ticks' value to all these functions. > > > > > > I am also dubious that we need a full 128 bits to specify > > > the 'precision': there would be absolutely no loss of functionality > > > if we decided to specify the precision in powers of 2, so a precision > > > 'k' (signed) means 2^k seconds. This way 8 bits are enough to > > > represent any precision we want. > > ... > > I'm not so sure about the 2^k precision. You speak of seconds, but I > > would be worrying about sub-second precision in my work. It would > > typical to want a 500uS timeout but be willing to late by up to 250uS if > > i said k is signed so negative values represent fractions of a > second. 2^-128 is pretty short :) > > cheers > luigi Ahh, I missed that. Good enough then! Hmmm, if that ideas survives further review, then could precision be encoded in 8 bits of the flags, eliminating another parm? -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Dec 18 23:44:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E482243; Tue, 18 Dec 2012 23:44:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C1D398FC0C; Tue, 18 Dec 2012 23:43:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 073547300A; Wed, 19 Dec 2012 00:42:41 +0100 (CET) Date: Wed, 19 Dec 2012 00:42:41 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121218234240.GA97678@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <20121218232955.GA97440@onelab2.iet.unipi.it> <1355873830.1198.189.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355873830.1198.189.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:44:00 -0000 On Tue, Dec 18, 2012 at 04:37:10PM -0700, Ian Lepore wrote: > On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: > > On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: > > > On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > > > > [top posting for readability; > > > > in summary we were discussing the new callout API trying to avoid > > > > an explosion of methods and arguments while at the same time > > > > supporting the old API and the new one] > > > > (I am also Cc-ing phk as he might have better insight > > > > on the topic). > > > > > > > > I think the patch you propose is a step in the right direction, > > > > but i still remain concerned by having to pass two bintimes > > > > (by reference, but they should really go by value) > > > > and one 'ticks' value to all these functions. > > > > > > > > I am also dubious that we need a full 128 bits to specify > > > > the 'precision': there would be absolutely no loss of functionality > > > > if we decided to specify the precision in powers of 2, so a precision > > > > 'k' (signed) means 2^k seconds. This way 8 bits are enough to > > > > represent any precision we want. > > > > ... > > > I'm not so sure about the 2^k precision. You speak of seconds, but I > > > would be worrying about sub-second precision in my work. It would > > > typical to want a 500uS timeout but be willing to late by up to 250uS if > > > > i said k is signed so negative values represent fractions of a > > second. 2^-128 is pretty short :) > > > > cheers > > luigi > > Ahh, I missed that. Good enough then! Hmmm, if that ideas survives > further review, then could precision be encoded in 8 bits of the flags, > eliminating another parm? that was also what i wrote later in the message :) now we should figure out some use for the remaining 22 bits of the flags cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 00:00:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BFB5616 for ; Wed, 19 Dec 2012 00:00:55 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 4D07F8FC0C for ; Wed, 19 Dec 2012 00:00:55 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBJ00nw9099033 for ; Tue, 18 Dec 2012 19:00:54 -0500 (EST) (envelope-from george@m5p.com) Message-ID: <50D103B1.5000600@m5p.com> Date: Tue, 18 Dec 2012 19:00:49 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Failed to initialize dwarf? References: <50D053E5.3050003@m5p.com> <50D05E7E.4040105@FreeBSD.org> In-Reply-To: <50D05E7E.4040105@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 18 Dec 2012 19:00:54 -0500 (EST) X-Mailman-Approved-At: Wed, 19 Dec 2012 00:05:24 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 00:00:55 -0000 On 12/18/12 07:15, Dimitry Andric wrote: > On 2012-12-18 12:30, George Mitchell wrote: >> I checked out head Sunday and now my attempt at building a kernel says: >> >> ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at >> [dwarf_init_attr(400)] >> >> on every module it compiles (though it seems happy enough to keep >> compiling). Should I just ignore this? -- George Mitchell > > This problem was fixed in libdwarf in r239872; did you run "make > buildworld" before "make buildkernel"? Yes. "svnversion ." says I have 244356. I'll try again. -- George > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 06:14:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25645A37; Wed, 19 Dec 2012 06:14:19 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by mx1.freebsd.org (Postfix) with ESMTP id 887928FC14; Wed, 19 Dec 2012 06:14:17 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id r3so764305wey.31 for ; Tue, 18 Dec 2012 22:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4zJdCVhNfOK0nkvkd/9Oy212ZudWEmYIoniMXRwxWwk=; b=fkkFQfpLzKpoMILAhZlKzqD1xSDJk3ekiGPHQNEt3CDT03uglcz7pLxldMgLP/B1i0 WodUotHuRyroxqiZdexu/XanQW6aof5PvxW6yzgsoR7SpXDoHvxbk2B/AMZfs8CzyV7t YwuwCFoGQRO3Q0qyttRlYUilcftrUp4dj3j+EhJU6l8cU4NfnTLYnIf134/mh+iTxDg1 uAFk4BPP8wkryrGfthjfi98MkAthi8yJZPufXRXCr0lmfseQ0r0meReUfX3MKOWRLi92 Y44WpopsFKJdXdkN1LVEgjapzHwF2dWQlY0/m5zdKxY6YYjeZggyfgsgSRayF3Qiyeav 7QjQ== MIME-Version: 1.0 Received: by 10.180.103.136 with SMTP id fw8mr1806777wib.27.1355897656369; Tue, 18 Dec 2012 22:14:16 -0800 (PST) Received: by 10.216.172.197 with HTTP; Tue, 18 Dec 2012 22:14:16 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Dec 2012 08:14:16 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 06:14:19 -0000 On Fri, Dec 7, 2012 at 12:42 PM, Kimmo Paasiala wrote: > Hello, > > I wrote a small patch for /etc/network.subr to add support for > ipv6_addrs_IF aliases in rc.conf(5) to match the already existing > ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 > aliases can be written like: > > ipv6_addrs_re0="2001:db8:1111:2222::1/64 2001:db8:1111:2222::2/64" > > Only this syntax is supported, it's not possible to use the "prefixlen > nn" syntax in the list. > > The patch is against a recent 9-STABLE, last changed rev of > network.subr on my SVN checkout is r242187. I don't have a CURRENT > system to test if it applies to CURRENT as well. > > The patch can be found attached to a PR I sent: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=174225 > > > I wrote this patch inspired by a question on the FreeBSD forums: > > http://forums.freebsd.org/showthread.php?t=36136 > > Please test and report if it works for you :) > > > Regards, > Kimmo Paasiala Hello, Did anyone try my patch? I thought it would be nice to have the ipv6_addrs_IF syntax supported to complement the existing ipv4_addrs_IF alias syntax. -Kimmo From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 08:34:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E15B48D; Wed, 19 Dec 2012 08:34:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id B50A88FC0C; Wed, 19 Dec 2012 08:34:45 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so997337wib.1 for ; Wed, 19 Dec 2012 00:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DadxxGdYJHOV3q/w6EouO8LdB8CbMOLMQf5BpToPM1E=; b=s50Z4udQ6HeeDIGg5napEbdv8lah3hPMbzf/nlG5xwMD6g+73iSGwMtqqB+HNajOca H3GLWdg53OE2ZxEx6clVchLC4moT/DsKTuMntsQpOUOHyY0+K2vNIGD//beVOcr5coH+ 0PduBSki1Tk1HvBIbFaJ6kmugYhlZ+2QXF94k6KSgk5MEmnyxRZqmtc+KvHR/hGetI49 Q/xeLC9wSaPIxKjZmKDwnS0jlsuSqQaMCzQr35l21E8qyvNo8cI3zq3Ra5QAEJWnzYwc mXAeTLzvI4tyxh9bcQOuV6x3XvdmyIc9ncx1xfe0J7jVL95/kU5eDAHjZqiMizOD/uHr NH/g== X-Received: by 10.194.122.98 with SMTP id lr2mr9798965wjb.55.1355906079195; Wed, 19 Dec 2012 00:34:39 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id l5sm6806692wia.10.2012.12.19.00.34.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 00:34:38 -0800 (PST) Sender: Alexander Motin Message-ID: <50D17C1B.8010207@FreeBSD.org> Date: Wed, 19 Dec 2012 10:34:35 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: API explosion (Re: [RFC/RFT] calloutng) References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <20121218232955.GA97440@onelab2.iet.unipi.it> <1355873830.1198.189.camel@revolution.hippie.lan> In-Reply-To: <1355873830.1198.189.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-current , Luigi Rizzo , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 08:34:46 -0000 On 19.12.2012 01:37, Ian Lepore wrote: > On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: >> On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: >>> On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: >>>> [top posting for readability; >>>> in summary we were discussing the new callout API trying to avoid >>>> an explosion of methods and arguments while at the same time >>>> supporting the old API and the new one] >>>> (I am also Cc-ing phk as he might have better insight >>>> on the topic). >>>> >>>> I think the patch you propose is a step in the right direction, >>>> but i still remain concerned by having to pass two bintimes >>>> (by reference, but they should really go by value) >>>> and one 'ticks' value to all these functions. >>>> >>>> I am also dubious that we need a full 128 bits to specify >>>> the 'precision': there would be absolutely no loss of functionality >>>> if we decided to specify the precision in powers of 2, so a precision >>>> 'k' (signed) means 2^k seconds. This way 8 bits are enough to >>>> represent any precision we want. >> >> ... >>> I'm not so sure about the 2^k precision. You speak of seconds, but I >>> would be worrying about sub-second precision in my work. It would >>> typical to want a 500uS timeout but be willing to late by up to 250uS if >> >> i said k is signed so negative values represent fractions of a >> second. 2^-128 is pretty short :) > > Ahh, I missed that. Good enough then! Hmmm, if that ideas survives > further review, then could precision be encoded in 8 bits of the flags, > eliminating another parm? Those who tracked the branch could see that actually was our first approach to handle precision. Unfortunately, it appeared not very convenient when you need to convert relative precision in percents or fraction of interval to the absolute precision in power of 2. We were worried that using some ffsll() for it can be inconvenient or expensive. But since we are now talking about passing relative bintime as an argument, that may be more viable option. I'll make another try. Thanks for the input. Pity it didn't happen couple of months ago. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 09:54:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A2D914F; Wed, 19 Dec 2012 09:54:17 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D3CEE8FC13; Wed, 19 Dec 2012 09:54:16 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id AA90289EAF; Wed, 19 Dec 2012 09:54:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJ9s8Kn014605; Wed, 19 Dec 2012 09:54:08 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <1355873265.1198.183.camel@revolution.hippie.lan> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> Date: Wed, 19 Dec 2012 09:54:08 +0000 Message-ID: <14604.1355910848@critter.freebsd.dk> Cc: Davide Italiano , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 09:54:17 -0000 -------- In message <1355873265.1198.183.camel@revolution.hippie.lan>, Ian Lepore writes : >On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: >I'm not so sure about the 2^k precision. You speak of seconds, but I >would be worrying about sub-second precision in my work. It is a bad idea, and it is physically pointless, given the stabilities of the timebases available for computers in general. Please just take my word as a time-nut, and use a 32.32 binary format in seconds (see previous email) and be done with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 10:03:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2563A531; Wed, 19 Dec 2012 10:03:34 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx1.freebsd.org (Postfix) with ESMTP id 898658FC16; Wed, 19 Dec 2012 10:03:33 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id m8so2063896vcd.36 for ; Wed, 19 Dec 2012 02:03:32 -0800 (PST) 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=e2OnjHZR5gvjn99Aks5MWvPKVpUHayeKe6gYI/7v3no=; b=kCneGXbC1/yYEy9kNEE9Up3LjxNNqV7T57XQmTPOvPx77cvdN58rpME15iNYAKwHEH OU0bQtNBwxHRctgcV4r55u9cYrbxRF2Ds+1jaOm0F8auwbCL79JRx22YoIVmNkwZAK5X cWKFquIhEn69zIZdWRovbPSNCB8TyIJPzNy1CWysDjfqmyvLYMpsQ85hR+P/Igv2s1Nc 3PF10qqa4qXV/zwD+c518rjKtR31pzQWTc+j2l5TAoB4vDfYMJCMFB1X9leEMs/QSrUd 1BdHNXUuz7J6mA9Fkj7GaKubPa6tiXbnGYXAXiGtC+ww2uI+ovPRI+pCohjL67jWCuCL HXKQ== MIME-Version: 1.0 Received: by 10.220.154.148 with SMTP id o20mr7834553vcw.54.1355911412603; Wed, 19 Dec 2012 02:03:32 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Wed, 19 Dec 2012 02:03:32 -0800 (PST) In-Reply-To: <14604.1355910848@critter.freebsd.dk> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> Date: Wed, 19 Dec 2012 02:03:32 -0800 X-Google-Sender-Auth: 5j9_ioOEHcmA53K-Ww31vnAW9gM Message-ID: Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Davide Italiano To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:03:34 -0000 On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp wrote: > -------- > In message <1355873265.1198.183.camel@revolution.hippie.lan>, Ian Lepore writes > : >>On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > >>I'm not so sure about the 2^k precision. You speak of seconds, but I >>would be worrying about sub-second precision in my work. > > It is a bad idea, and it is physically pointless, given the stabilities > of the timebases available for computers in general. > > Please just take my word as a time-nut, and use a 32.32 binary format > in seconds (see previous email) and be done with it. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. Right now -- the precision is specified in 'bintime', which is a binary number. It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in the specific platform. I do not really think it worth to create another structure for handling time (e.g. struct bintime32), as it will lead to code duplication for all the basic conversion/math operation. On the other hand, 32.32 may not be enough in the long future. What do you think about that? Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 10:18:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E6F89AB; Wed, 19 Dec 2012 10:18:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id C255D8FC12; Wed, 19 Dec 2012 10:18:12 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so210184wgb.0 for ; Wed, 19 Dec 2012 02:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CIHZ1ahh1M/SzSEHIHjnikoUbcY3hIh/SFfqZZf3g20=; b=w9iSy3YziITUVq18IAKOzUDq039HYSUfHl+uzQ9O+9ZYCs3tkLvfjegPgHHHIgX9xI yHsS9eObV6wldPOhkWi7SkUV/qrs4p7hNIG6c29TohkiTlGfn+JUK7dhxtmDEDjEjyRH j27i37M3sUT5heC80Bjib8/ihENHokimMau7W3BjmzBjb5fzTuEEjeMbcShkFj7x06pJ GbgXxfBCVR7zoKxU7JRgX8zTDiYpvE95rXH0CRKm8iT536N82HZZ07qVnqlG37ywi720 /HDlivYcSdiQ6gQ2jmni6LQzJmrBjRqTgjlvKJ/4hhEZNmgeFBuddlQ1AFPpaxNWX0Ah rJ4A== X-Received: by 10.180.24.4 with SMTP id q4mr10538733wif.19.1355911916210; Wed, 19 Dec 2012 02:11:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id ew4sm7163770wid.11.2012.12.19.02.11.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 02:11:55 -0800 (PST) Sender: Alexander Motin Message-ID: <50D192E8.3020704@FreeBSD.org> Date: Wed, 19 Dec 2012 12:11:52 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Davide Italiano Subject: Re: API explosion (Re: [RFC/RFT] calloutng) References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:18:13 -0000 On 19.12.2012 12:03, Davide Italiano wrote: > On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp wrote: >> -------- >> In message <1355873265.1198.183.camel@revolution.hippie.lan>, Ian Lepore writes >> : >>> On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: >> >>> I'm not so sure about the 2^k precision. You speak of seconds, but I >>> would be worrying about sub-second precision in my work. >> >> It is a bad idea, and it is physically pointless, given the stabilities >> of the timebases available for computers in general. >> >> Please just take my word as a time-nut, and use a 32.32 binary format >> in seconds (see previous email) and be done with it. > > Right now -- the precision is specified in 'bintime', which is a binary number. > It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in > the specific platform. > I do not really think it worth to create another structure for > handling time (e.g. struct bintime32), as it will lead to code > duplication for all the basic conversion/math operation. On the other > hand, 32.32 may not be enough in the long future. > What do you think about that? Linux uses 32.32 format in their eventtimers code. Respecting that now we have no any timer hardware with frequency about 4GHz, that precision is probably sufficient. But if at some point we want to be able to handle absolute wall time, then 32bit integer part may be not enough. Then we return to the question: "how many different data types do we want to see in one subsystem"? Sure, using single 64bit value would be much easier then struct bintime from many perspectives, but what's about the edge cases? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 10:39:34 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37BA9C91; Wed, 19 Dec 2012 10:39:34 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 24F658FC0C; Wed, 19 Dec 2012 10:39:32 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qBJAdF7M075458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 19:39:26 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qBJAdD6Y029702; Wed, 19 Dec 2012 19:39:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 19 Dec 2012 19:37:56 +0900 (JST) Message-Id: <20121219.193756.587071206473895567.hrs@allbsd.org> To: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: FreeBSD daily snapshot build in allbsd.org temporarily down From: Hiroki Sato In-Reply-To: <20121207.101917.103513550140980591.hrs@allbsd.org> References: <20121207.101917.103513550140980591.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Dec_19_19_37_56_2012_604)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 19 Dec 2012 19:39:26 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: alexandr.kovalenko@gmail.com, ozkan.kirik@gmail.com, drue@therub.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:39:34 -0000 ----Security_Multipart(Wed_Dec_19_19_37_56_2012_604)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20121207.101917.103513550140980591.hrs@allbsd.org>: hr> Hi all, hr> hr> I received many emails asking why hr> https://pub.allbsd.org/FreeBSD-snapshots/ is stopped working and when hr> it will recover, so I just wanted to let you know that FreeBSD daily hr> snapshot build in allbsd.org is temporarily down. The reason why it hr> is down is some local network issue and CVS->SVN migration of the hr> build system. The latter was solved already. However, the former hr> was unexpected and needed some time than I thought originally. The service has almost recovered. Snapshots for i386, amd64, and pc98/i386 are being rebuilt now, and then ia64, sparc64, and powerpc will also be connected to the build queue soon. For stable/9 and later, Subversion repository is used and the build results are sorted by the revision numbers on each day. For 8.X it still uses CVS via the make release target but will be switched to use Subversion shortly. Note that some local network performance issue still remains. It seems due to traffic congestion around the border router which I do not have control of. The transfer rate can become less than 100KB/s especially in 12:00-18:00 in JST. I will planning to add a custom build functionality by using the source trees under projects/ or user/ branch to this service. -- Hiroki ----Security_Multipart(Wed_Dec_19_19_37_56_2012_604)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlDRmQQACgkQTyzT2CeTzy02KwCffKIxyn1fOPkIQ2V15b6tUMnk vIgAnijalgLuXwe/YwohUCCBW7StjnqN =rO7t -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Dec_19_19_37_56_2012_604)---- From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 10:51:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C300E28B; Wed, 19 Dec 2012 10:51:50 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBE48FC0C; Wed, 19 Dec 2012 10:51:50 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 15DB389EAF; Wed, 19 Dec 2012 10:51:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJApmOF015883; Wed, 19 Dec 2012 10:51:48 GMT (envelope-from phk@phk.freebsd.dk) To: Davide Italiano Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> Date: Wed, 19 Dec 2012 10:51:48 +0000 Message-ID: <15882.1355914308@critter.freebsd.dk> Cc: Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:51:50 -0000 -------- In message , Davide Italiano writes: >Right now -- the precision is specified in 'bintime', which is a binary number. >It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in >the specific platform. And that is way overkill for specifying a callout, at best your clock has short term stabilities approaching 1e-8, but likely as bad as 1e-6. (The reason why bintime is important for timekeeping is that we accumulate timeintervals approx 1e3 times a second, so the rounding error has to be much smaller than the short term stability in order to not dominate) >I do not really think it worth to create another structure for >handling time (e.g. struct bintime32), as it will lead to code No, that was exactly my point: It should be an integer so that comparisons and arithmetic is trivial. A 32.32 format fits nicely into a int64_t which is readily available in the language. As I said in my previous email: typedef dur_t int64_t; /* signed for bug catching */ #define DURSEC ((dur_t)1 << 32) #define DURMIN (DURSEC * 60) #define DURMSEC (DURSEC / 1000) #define DURUSEC (DURSEC / 10000000) #define DURNSEC (DURSEC / 10000000000) (Bikeshed the names at your convenience) Then you can say callout_foo(34 * DURSEC) callout_foo(2400 * DURMSEC) or callout_foo(500 * DURNSEC) With this format you can specify callouts 68 years into the future with quarter nanosecond resolution, and you can trivially and efficiently compare dur_t's with if (d1 < d2) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 11:00:09 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C515955; Wed, 19 Dec 2012 11:00:09 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AB49B8FC1E; Wed, 19 Dec 2012 11:00:08 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 812708A512; Wed, 19 Dec 2012 11:00:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJB06xL015948; Wed, 19 Dec 2012 11:00:06 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Motin Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <50D192E8.3020704@FreeBSD.org> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <50D192E8.3020704@FreeBSD.org> Date: Wed, 19 Dec 2012 11:00:06 +0000 Message-ID: <15947.1355914806@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 11:00:09 -0000 -------- In message <50D192E8.3020704@FreeBSD.org>, Alexander Motin writes: >Linux uses 32.32 format in their eventtimers code. (And that is no accident, I know who they got the number from :-) >But if at some point we want to be able to >handle absolute wall time, [...] Then you have other problems, including but not limited to clock being stepped, leap-seconds, suspend/resume and frequency stability. If you want to support callouts of the type ("At 14:00 UTC tomorrow") (disregarding the time-zone issue), you need to catch all significant changes to our UTC estimate and recalibrate your callout based on that. It is not obvious that we have applications for such an API that warrant the complexity. Either way, such a facility should be layered on top of the callout facility, which should always run in "elapsed time"[1] with no attention paid to what NTPD might do to the UTC estimate. So summary: 32.32 is the right format. Poul-Henning [1] Notice that "elapsed time" needs a firm definition with respect to suspend/resume, and that this decision has big implications for the API use and code duplication. I think it prudent to specify a flag to callouts, to tell what should happen on suspend/resume, something like: SR_CANCEL /* Cancel the callout on S/R */ /* no flag* /* Toll this callout only when system is running */ SR_IGNORE /* Toll suspended time from callout */ If you get this right, callouts from device drivers will just "DTRT", if you get it wrong, all device drivers will need boilerplate code to handle S/R -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 12:19:05 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B07BB562; Wed, 19 Dec 2012 12:19:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id CE74B8FC0C; Wed, 19 Dec 2012 12:19:04 +0000 (UTC) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJCIuSs016828; Wed, 19 Dec 2012 23:18:56 +1100 Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJCIcZS017294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 23:18:40 +1100 Date: Wed, 19 Dec 2012 23:18:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: <15882.1355914308@critter.freebsd.dk> Message-ID: <20121219221518.E1082@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=SfSv7Ytu c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=pGLkceISAAAA:8 a=9Mupeb60rhJ5CC9yY78A:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 12:37:19 +0000 Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 12:19:05 -0000 On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > -------- > In message > , Davide Italiano writes: > >> Right now -- the precision is specified in 'bintime', which is a binary number. >> It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in >> the specific platform. > > And that is way overkill for specifying a callout, at best your clock > has short term stabilities approaching 1e-8, but likely as bad as 1e-6. So you always agreed with me that bintimes are unsuitable for almost everything, and especially unsuitable for timeouts? :-) > (The reason why bintime is important for timekeeping is that we > accumulate timeintervals approx 1e3 times a second, so the rounding > error has to be much smaller than the short term stability in order > to not dominate) bintimes are not unsuitable for timekeeping, but they a painful to use for other APIs. You have to either put bintimes in layers in the other APIs, or convert them to a more suitable format, and there is a problem placing the conversion at points where it is efficient. This thread seems to be mostly about putting the conversion in wrong places. My original objection was about using bintimes for almost everything at the implementation level. >> I do not really think it worth to create another structure for >> handling time (e.g. struct bintime32), as it will lead to code > > No, that was exactly my point: It should be an integer so that > comparisons and arithmetic is trivial. A 32.32 format fits > nicely into a int64_t which is readily available in the language. I would have tried a 32 bit format with a variable named 'ticks'. Something like: - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use this. The tick period would be constant but for virtual ticks and not too small. hz = 1000 now makes the period too small, and not a power of 2. So make the period 1/128 second. This gives a 1.24.7 binary format. 2**24 seconds is 194 days. - ticks < 0. The 31 value bits are now a cookie (descriptor) referring to a bintime or whatever. This case should rarely be used. I don't like it that a tickless kernel, which is needed mainly for power saving, has expanded into complications to support short timeouts which should rarely be used. > As I said in my previous email: > > typedef dur_t int64_t; /* signed for bug catching */ > #define DURSEC ((dur_t)1 << 32) > #define DURMIN (DURSEC * 60) > #define DURMSEC (DURSEC / 1000) > #define DURUSEC (DURSEC / 10000000) > #define DURNSEC (DURSEC / 10000000000) > > (Bikeshed the names at your convenience) > > Then you can say > > callout_foo(34 * DURSEC) > callout_foo(2400 * DURMSEC) > or > callout_foo(500 * DURNSEC) Constructing the cookie for my special case would not be so easy. > With this format you can specify callouts 68 years into the future > with quarter nanosecond resolution, and you can trivially and > efficiently compare dur_t's with > if (d1 < d2) This would make a better general format than timevals, timespecs and of course bintimes :-). It is a bit wasteful for timeouts since its extremes are rarely used. Malicious and broken callers can still cause overflow at 68 years, so you have to check for it and handle it. The limit of 194 days is just as good for timeouts. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 13:04:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9018571; Wed, 19 Dec 2012 13:04:45 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7AB8FC12; Wed, 19 Dec 2012 13:04:45 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C90E189EAF; Wed, 19 Dec 2012 13:04:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJD4gQR016440; Wed, 19 Dec 2012 13:04:42 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <20121219221518.E1082@besplex.bde.org> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> Date: Wed, 19 Dec 2012 13:04:42 +0000 Message-ID: <16439.1355922282@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:04:45 -0000 -------- In message <20121219221518.E1082@besplex.bde.org>, Bruce Evans writes: >> With this format you can specify callouts 68 years into the future >> with quarter nanosecond resolution, and you can trivially and >> efficiently compare dur_t's with >> if (d1 < d2) > >This would make a better general format than timevals, timespecs and >of course bintimes :-). Except that for absolute timescales, we're running out of the 32 bits integer part. Bintimes is a necessary superset of the 32.32 which tries to work around the necessary but missing int96_t or int128_t[1]. Poul-Henning [1] A good addition to C would be a general multi-word integer type where you could ask for any int%d_t or uint%d_t you cared for, and have the compiler DTRT. In difference from using a multiword-library, this would still give these types their natural integer behaviour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 13:05:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50B1F714; Wed, 19 Dec 2012 13:05:08 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id AED108FC0C; Wed, 19 Dec 2012 13:05:07 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so2209257vbi.4 for ; Wed, 19 Dec 2012 05:05:06 -0800 (PST) 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=MX5cw1qHYhNlodpk7btfMXKeyR7NnCm68rmxmtC5ebg=; b=Z2/gXbAKOyEmkjIzySBTvavzH4mRlpyHpZqD+PfPzf2mTNEcFgHLhmNixEwLYClvDQ 0TMQHVRslhhdWkuJkVhdsA6aRRAVfAs3WD15fN+ZuoAAnplMo3jJ9Z7DjKvSsxcuoU/K Keo+0jMcH+lVipoNmhVVuZSiNiYxOjgxVT4wnHgo2WkNbqqMGh4dM844ad1x2mJNgrDA GwoX9OqYerjEXQghNBuq+8Pd1VLv0olpNn83sSQK5Kc4AmbM2TQAdpAR3KajBKQnKZzJ 8oXCkZjr5TcHQGJAerXKcsFIi18EOnwFMJ53JNKcL8v8yKcBm+mS41WHuPkbPbp7GpCZ SMdg== MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr7575902vdt.30.1355922306590; Wed, 19 Dec 2012 05:05:06 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Wed, 19 Dec 2012 05:05:06 -0800 (PST) In-Reply-To: <20121219221518.E1082@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> Date: Wed, 19 Dec 2012 05:05:06 -0800 X-Google-Sender-Auth: 0-_PGXea5bUURKIlbagvU5Ucxbs Message-ID: Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Davide Italiano To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:05:08 -0000 On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: > On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > >> -------- >> In message >> >> , Davide Italiano writes: >> >>> Right now -- the precision is specified in 'bintime', which is a binary >>> number. >>> It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in >>> the specific platform. >> >> >> And that is way overkill for specifying a callout, at best your clock >> has short term stabilities approaching 1e-8, but likely as bad as 1e-6. > > > So you always agreed with me that bintimes are unsuitable for almost > everything, and especially unsuitable for timeouts? :-) > > >> (The reason why bintime is important for timekeeping is that we >> accumulate timeintervals approx 1e3 times a second, so the rounding >> error has to be much smaller than the short term stability in order >> to not dominate) > > > bintimes are not unsuitable for timekeeping, but they a painful to use > for other APIs. You have to either put bintimes in layers in the other > APIs, or convert them to a more suitable format, and there is a problem > placing the conversion at points where it is efficient. This thread > seems to be mostly about putting the conversion in wrong places. My > original objection was about using bintimes for almost everything at > the implementation level. > > >>> I do not really think it worth to create another structure for >>> handling time (e.g. struct bintime32), as it will lead to code >> >> >> No, that was exactly my point: It should be an integer so that >> comparisons and arithmetic is trivial. A 32.32 format fits >> nicely into a int64_t which is readily available in the language. > > > I would have tried a 32 bit format with a variable named 'ticks'. > Something like: > - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use > this. The tick period would be constant but for virtual ticks and > not too small. hz = 1000 now makes the period too small, and not a > power of 2. So make the period 1/128 second. This gives a 1.24.7 > binary format. 2**24 seconds is 194 days. > - ticks < 0. The 31 value bits are now a cookie (descriptor) referring > to a bintime or whatever. This case should rarely be used. I don't > like it that a tickless kernel, which is needed mainly for power > saving, has expanded into complications to support short timeouts > which should rarely be used. > Bruce, I don't really agree with this. The data addressed by cookie should be still stored somewhere, and KBI will result broken. This, indeed, is not real problem as long as current calloutng code heavily breaks KBI, but if that was your point, I don't see how your proposed change could help. > >> As I said in my previous email: >> >> typedef dur_t int64_t; /* signed for bug catching */ >> #define DURSEC ((dur_t)1 << 32) >> #define DURMIN (DURSEC * 60) >> #define DURMSEC (DURSEC / 1000) >> #define DURUSEC (DURSEC / 10000000) >> #define DURNSEC (DURSEC / 10000000000) >> >> (Bikeshed the names at your convenience) >> >> Then you can say >> >> callout_foo(34 * DURSEC) >> callout_foo(2400 * DURMSEC) >> or >> callout_foo(500 * DURNSEC) > > > Constructing the cookie for my special case would not be so easy. > > >> With this format you can specify callouts 68 years into the future >> with quarter nanosecond resolution, and you can trivially and >> efficiently compare dur_t's with >> if (d1 < d2) > > > This would make a better general format than timevals, timespecs and > of course bintimes :-). It is a bit wasteful for timeouts since > its extremes are rarely used. Malicious and broken callers can > still cause overflow at 68 years, so you have to check for it and > handle it. The limit of 194 days is just as good for timeouts. > > Bruce I think the phk's proposal is better. About your overflow objection, I think is really unlikely to happen, but better safe than sorry. Thanks Davide From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 13:47:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EE48683; Wed, 19 Dec 2012 13:47:12 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mx1.freebsd.org (Postfix) with ESMTP id 407A28FC12; Wed, 19 Dec 2012 13:47:11 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [91.204.91.44]) by bijou.wasikowski.net (Postfix) with ESMTP id F37D6CBE; Wed, 19 Dec 2012 14:47:00 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (scan.wasikowski.net [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id 0TKlJYYT3yeP; Wed, 19 Dec 2012 14:47:00 +0100 (CET) Received: from [192.168.138.150] (cadera.waw.pl [62.121.127.119]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lukasz@wasikowski.net) by bijou.wasikowski.net (Postfix) with ESMTPSA id 9722CCBB; Wed, 19 Dec 2012 14:47:00 +0100 (CET) Message-ID: <50D1C553.9060100@wasikowski.net> Date: Wed, 19 Dec 2012 14:46:59 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:47:12 -0000 W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: >> I wrote a small patch for /etc/network.subr to add support for >> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing >> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 >> aliases can be written like: [...] > Did anyone try my patch? I thought it would be nice to have the > ipv6_addrs_IF syntax supported to complement the existing > ipv4_addrs_IF alias syntax. Can I use range syntax in it like in ipv4? I mean something like: ipv4_addrs_lagg0="x.x.x.10-30/22" That feature would be very nice to have for ipv6. -- best regards, Lukasz Wasikowski From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 14:14:52 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5B6BFB1; Wed, 19 Dec 2012 14:14:52 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2378FC13; Wed, 19 Dec 2012 14:14:52 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 316E18A3FC; Wed, 19 Dec 2012 14:14:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJEEnN9016665; Wed, 19 Dec 2012 14:14:49 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <20121220005706.I1675@besplex.bde.org> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <16439.1355922282@critter.freebsd.dk> <20121220005706.I1675@besplex.bde.org> Date: Wed, 19 Dec 2012 14:14:49 +0000 Message-ID: <16664.1355926489@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:14:52 -0000 -------- In message <20121220005706.I1675@besplex.bde.org>, Bruce Evans writes: >On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: >> Except that for absolute timescales, we're running out of the 32 bits >> integer part. > >Except 32 bit time_t works until 2106 if it is unsigned. That's sort of not an option. The real problem was that time_t was not defined as a floating point number. >> [1] A good addition to C would be a general multi-word integer type >> where you could ask for any int%d_t or uint%d_t you cared for, and >> have the compiler DTRT. In difference from using a multiword-library, >> this would still give these types their natural integer behaviour. > >That would be convenient, but bad for efficiency if it were actually >used much. You can say that about anything but CPU-native operations, and I doubt it would be as inefficient as struct bintime, which does not have access to the carry bit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 14:07:00 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 096C8BE7; Wed, 19 Dec 2012 14:07:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 8814D8FC14; Wed, 19 Dec 2012 14:06:58 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJE6mBV001435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 01:06:51 +1100 Date: Thu, 20 Dec 2012 01:06:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: <16439.1355922282@critter.freebsd.dk> Message-ID: <20121220005706.I1675@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <16439.1355922282@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=e5de0tV/ c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=sKz94c0OIJE1EZh3uQcA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 14:20:12 +0000 Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:07:00 -0000 On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > -------- > In message <20121219221518.E1082@besplex.bde.org>, Bruce Evans writes: > >>> With this format you can specify callouts 68 years into the future >>> with quarter nanosecond resolution, and you can trivially and >>> efficiently compare dur_t's with >>> if (d1 < d2) >> >> This would make a better general format than timevals, timespecs and >> of course bintimes :-). > > Except that for absolute timescales, we're running out of the 32 bits > integer part. Except 32 bit time_t works until 2106 if it is unsigned. > Bintimes is a necessary superset of the 32.32 which tries to work > around the necessary but missing int96_t or int128_t[1]. > > [1] A good addition to C would be a general multi-word integer type > where you could ask for any int%d_t or uint%d_t you cared for, and > have the compiler DTRT. In difference from using a multiword-library, > this would still give these types their natural integer behaviour. That would be convenient, but bad for efficiency if it were actually used much. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:05:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CB46309 for ; Wed, 19 Dec 2012 15:05:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE988FC15 for ; Wed, 19 Dec 2012 15:05:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEPX0VCDaFvO/2dsb2JhbABEhju3YnOCSIELAg0ZAokFlmKOUZJ1gSKMRYIWgRMDiGGNKZBIgxKCBA X-IronPort-AV: E=Sophos;i="4.84,318,1355115600"; d="scan'208";a="5315464" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Dec 2012 10:05:36 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 52FFFB3F13 for ; Wed, 19 Dec 2012 10:05:36 -0500 (EST) Date: Wed, 19 Dec 2012 10:05:36 -0500 (EST) From: Rick Macklem To: freebsd-current@freebsd.org Message-ID: <58267838.1494299.1355929536321.JavaMail.root@erie.cs.uoguelph.ca> Subject: nfsd won't start on post r243965 kernels without INET6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:05:43 -0000 Just fyi, r243965 introduced a minor pola violation where the nfsd daemon won't start for kernels built without "options INET6". The attached patch, which I will commit to head later to-day, fixes the problem. (Or you can add "options INET6" to your kernel config.) Reported and tested by avg@. rick From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:08:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0EE9456 for ; Wed, 19 Dec 2012 15:08:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 995748FC1C for ; Wed, 19 Dec 2012 15:08:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEPX0VCDaFvO/2dsb2JhbABEhju3YnOCHgEBAQQBAQEgKyAXDykZAgQlAQkmDgcEARwEh3IMllaOUZJ1jGh/ghaBEwOIYYYlhFaCLoEcjyyDEoFPNQ X-IronPort-AV: E=Sophos;i="4.84,318,1355115600"; d="scan'208";a="5316672" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Dec 2012 10:08:29 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C2D57B3F1D for ; Wed, 19 Dec 2012 10:08:29 -0500 (EST) Date: Wed, 19 Dec 2012 10:08:29 -0500 (EST) From: Rick Macklem To: freebsd-current@freebsd.org Message-ID: <836862692.1494392.1355929709771.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <58267838.1494299.1355929536321.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: nfsd won't start on post r243965 kernels without INET6 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1494391_662787520.1355929709769" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:08:31 -0000 ------=_Part_1494391_662787520.1355929709769 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Oops, I did my usual brain fart again and forgot to attach the patch. Here it is, rick ----- Original Message ----- > Just fyi, r243965 introduced a minor pola violation where the > nfsd daemon won't start for kernels built without "options INET6". > > The attached patch, which I will commit to head later to-day, fixes > the problem. (Or you can add "options INET6" to your kernel config.) > > Reported and tested by avg@. > > rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" ------=_Part_1494391_662787520.1355929709769 Content-Type: text/x-patch; name=nfsd.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nfsd.patch LS0tIHVzci5zYmluL25mc2QvbmZzZC5jLnNhdgkyMDEyLTEyLTE4IDA4OjMyOjE0LjAwMDAwMDAw MCAtMDUwMAorKysgdXNyLnNiaW4vbmZzZC9uZnNkLmMJMjAxMi0xMi0xOCAwODozMzoxOS4wMDAw MDAwMDAgLTA1MDAKQEAgLTI2NCw3ICsyNjQsNyBAQCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikKIAlpcDZmbGFnID0gMTsKIAlzID0gc29ja2V0KEFGX0lORVQ2LCBTT0NLX0RHUkFNLCBJUFBS T1RPX1VEUCk7CiAJaWYgKHMgPT0gLTEpIHsKLQkJaWYgKGVycm5vICE9IEVQUk9UT05PU1VQUE9S VCkKKwkJaWYgKGVycm5vICE9IEVQUk9UT05PU1VQUE9SVCAmJiBlcnJubyAhPSBFQUZOT1NVUFBP UlQpCiAJCQllcnIoMSwgInNvY2tldCIpOwogCQlpcDZmbGFnID0gMDsKIAl9IGVsc2UgaWYgKGdl dG5ldGNvbmZpZ2VudCgidWRwNiIpID09IE5VTEwgfHwK ------=_Part_1494391_662787520.1355929709769-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:09:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4848264C; Wed, 19 Dec 2012 15:09:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id EFF978FC16; Wed, 19 Dec 2012 15:09:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0E9237300B; Wed, 19 Dec 2012 16:08:09 +0100 (CET) Date: Wed, 19 Dec 2012 16:08:09 +0100 From: Luigi Rizzo To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121219150809.GA98673@onelab2.iet.unipi.it> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15882.1355914308@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:09:28 -0000 On Wed, Dec 19, 2012 at 10:51:48AM +0000, Poul-Henning Kamp wrote: > -------- > In message > , Davide Italiano writes: > > >Right now -- the precision is specified in 'bintime', which is a binary number. > >It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in > >the specific platform. > > And that is way overkill for specifying a callout, at best your clock > has short term stabilities approaching 1e-8, but likely as bad as 1e-6. > > (The reason why bintime is important for timekeeping is that we > accumulate timeintervals approx 1e3 times a second, so the rounding > error has to be much smaller than the short term stability in order > to not dominate) > > >I do not really think it worth to create another structure for > >handling time (e.g. struct bintime32), as it will lead to code > > No, that was exactly my point: It should be an integer so that > comparisons and arithmetic is trivial. A 32.32 format fits > nicely into a int64_t which is readily available in the language. > > As I said in my previous email: > > > typedef dur_t int64_t; /* signed for bug catching */ > #define DURSEC ((dur_t)1 << 32) > #define DURMIN (DURSEC * 60) > #define DURMSEC (DURSEC / 1000) > #define DURUSEC (DURSEC / 10000000) > #define DURNSEC (DURSEC / 10000000000) > > (Bikeshed the names at your convenience) > > Then you can say > > callout_foo(34 * DURSEC) > callout_foo(2400 * DURMSEC) > or > callout_foo(500 * DURNSEC) only thing, we must be careful with the parentheses For instance, in your macro, DURNSEC evaluates to 0 and so does any multiple of it. We should define them as #define DURNSEC DURSEC / 10000000000 ... so DURNSEC is still 0 and 500*DURNSEC gives 214 I am curious that Bruce did not mention this :) (btw the typedef is swapped, should be "typedef int64_t dur_t") cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:37:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61D7AF3; Wed, 19 Dec 2012 15:37:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E77A28FC12; Wed, 19 Dec 2012 15:37:30 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5BF5489EAF; Wed, 19 Dec 2012 15:37:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJFbSun017058; Wed, 19 Dec 2012 15:37:28 GMT (envelope-from phk@phk.freebsd.dk) To: Luigi Rizzo Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <20121219150809.GA98673@onelab2.iet.unipi.it> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219150809.GA98673@onelab2.iet.unipi.it> Date: Wed, 19 Dec 2012 15:37:28 +0000 Message-ID: <17057.1355931448@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:37:31 -0000 -------- In message <20121219150809.GA98673@onelab2.iet.unipi.it>, Luigi Rizzo writes: >> typedef dur_t int64_t; /* signed for bug catching */ >> #define DURSEC ((dur_t)1 << 32) >> #define DURMIN (DURSEC * 60) >> #define DURMSEC (DURSEC / 1000) >> #define DURUSEC (DURSEC / 10000000) >> #define DURNSEC (DURSEC / 10000000000) >only thing, we must be careful with the parentheses Actually, it's more impportant to be careful with zeros, if you adjust the above to the correct number of zeros, DURNSEC is 4, which is within seven percent of the correct value. >(btw the typedef is swapped, should be "typedef int64_t dur_t") Yes, I'm trying to find out of people even listen to me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:44:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75623646; Wed, 19 Dec 2012 15:44:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by mx1.freebsd.org (Postfix) with ESMTP id 92A7B8FC14; Wed, 19 Dec 2012 15:44:30 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id jf3so1077931bkc.23 for ; Wed, 19 Dec 2012 07:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q+HCfy6mvCBs/gmeiWofRAlvBBzh+GP4niu6XB1oumw=; b=Bb800yhX0+Ylcu5xxGH736OvrPQxaTW7f8srbZb4a1C7lqeWm2RWZYe1LaIKTkVsPm S1DnQo30T4vtlYPCUwR8m59+rjcKlZ020SGCERuY7ha9H8UhnQpur+M9UHS2GP5xwWSk jgN4dp4uPupes0Zc6191o2E4bhxogbM2fKm4B9Xtcz+fh2tD+9uTtKn42m2QY0g68iQ4 0Rqv0wqc3WIykm/BTcagXokSmEX/bF3f6rKfCdofOeiKo+v9MTjDRlBz0yOSG+KQgv5X ZWbg4/vZuG1fbjE7vI/L9NHAu4HNxo6IGe5QcGN4Kadt8+DuzEpMVa0O55QUFXZGFnP3 PShg== X-Received: by 10.204.5.145 with SMTP id 17mr2763593bkv.98.1355931868799; Wed, 19 Dec 2012 07:44:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id o9sm4615748bko.15.2012.12.19.07.44.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 07:44:27 -0800 (PST) Sender: Alexander Motin Message-ID: <50D1E0D8.9070209@FreeBSD.org> Date: Wed, 19 Dec 2012 17:44:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans Subject: Re: API explosion (Re: [RFC/RFT] calloutng) References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <20121220010702.B1675@besplex.bde.org> In-Reply-To: <20121220010702.B1675@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:44:31 -0000 On 19.12.2012 16:20, Bruce Evans wrote: > On Wed, 19 Dec 2012, Davide Italiano wrote: > >> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans >> wrote: > >>> I would have tried a 32 bit format with a variable named 'ticks'. >>> Something like: >>> - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use >>> this. The tick period would be constant but for virtual ticks and >>> not too small. hz = 1000 now makes the period too small, and not a >>> power of 2. So make the period 1/128 second. This gives a 1.24.7 >>> binary format. 2**24 seconds is 194 days. >>> - ticks < 0. The 31 value bits are now a cookie (descriptor) referring >>> to a bintime or whatever. This case should rarely be used. I don't >>> like it that a tickless kernel, which is needed mainly for power >>> saving, has expanded into complications to support short timeouts >>> which should rarely be used. >> >> Bruce, I don't really agree with this. >> The data addressed by cookie should be still stored somewhere, and KBI >> will result broken. This, indeed, is not real problem as long as >> current calloutng code heavily breaks KBI, but if that was your point, >> I don't see how your proposed change could help. > > In the old API, it is an error to pass ticks < 0, so only broken old > callers are affected. Of course, if there are any then it would be > hard to detect their garbage cookies. > > Anywy, it's too later to change to this, and maybe also to a 32.32 > format. It would be late to change this after committing. I would definitely like it to be done earlier to not redo all the tests, but I think we could convert callout and eventtimers code to 32.32 format in several days. The only two questions are: do we really want it (won't there be any reasons to regret about it) and how do we want it to look? For the first question my personal showstopper since eventtimers creation always was the wish to keep consistency. But benefits of 32.32 format are clear, and if there are more votes for it, let's consider. If now it will be decided that full range will never be useful for callout subsystem, then it is obviously not needed for eventtimers also. About the second question, what do you think about such prototypes: typedef int64_t sbintime_t static __inline sbintime_t bintime_shrink(struct bintime *bt) {} static __inline struct bintime bintime_expand(sbintime_t sbt) {} ... int callout_reset_bt(struct callout *, sbintime_t sbt, sbintime_t pr, void (*fn)(void *), void *arg, int flags); , where pr used only for absolute precision, and flags includes: direct execution, absolute/relative time in argument, relative precision in case of relative sbt, flag for aligning to hardclock() to emulate legacy behavior, and potentially flags for reaction on suspend/resume. Another option is to move absolute precision also to flags, using log2() representation, as we tried and as was proposed before. With possibility to use precise relative time there will be few cases requiring absolute value of precision, that should depend on period. Then there will be no extra arguments in the most usual cases. Wrapper for existing API compatibility will look just like this: #define callout_reset(c, ticks, fn, arg) \ callout_reset_bt(c, ticks2sbintime(ticks), -1, \ (fn), (arg), C_HARDCLOCK) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:58:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2386FDA1; Wed, 19 Dec 2012 15:58:15 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2BE8FC13; Wed, 19 Dec 2012 15:58:14 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id b23so2410492vbz.26 for ; Wed, 19 Dec 2012 07:58:08 -0800 (PST) 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=MZwBLAXR5ZQuT6zg0qGkR7r8/PYRwl3fCa5jYWpUoE8=; b=Zrlkhba+OFc6g/mdMC4zHJFh+hTCQV0Vzfxru89bbZy8R6SCg9JrC9Xss2XQMUPqF+ 4o9E/wAMDk0RrkssIWvc7bC1YwOTwAJPwAzcocSmwia46cwbsYC2LfbEfOAu2+uVL8+E 0Xa5O8vivrtuoFb0m6RB1jkvjdvMFQieRJGNyPELZOYctSoerbhiCnwbxDxbrIgyqVOd feJShTg6A5wePTT+mhWzsnu0chfnAw7fOsPAVMwclgLvucOI6s54SY08V2iNMZxt2wJr oFR7eNI+fhHQYT2OJDcjvfceUqzC0emGeIOPeYUbMByFVxdDVgnxnB4/yjsIV2PKRguh IHIg== MIME-Version: 1.0 Received: by 10.220.148.205 with SMTP id q13mr9184719vcv.6.1355928707925; Wed, 19 Dec 2012 06:51:47 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Wed, 19 Dec 2012 06:51:47 -0800 (PST) In-Reply-To: <20121220010702.B1675@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <20121220010702.B1675@besplex.bde.org> Date: Wed, 19 Dec 2012 06:51:47 -0800 X-Google-Sender-Auth: spBVXsoWBq0qXz79KesqcXmg_C8 Message-ID: Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Davide Italiano To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Poul-Henning Kamp , freebsd-current , Alexander Motin , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:58:15 -0000 dropping phk _AT_ onelab2 _DOT_ something from CC as long as it doesn't seem a valid mail address and I'm annoyed mails bounce back. On Wed, Dec 19, 2012 at 6:20 AM, Bruce Evans wrote: > On Wed, 19 Dec 2012, Davide Italiano wrote: > >> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: > > >>> I would have tried a 32 bit format with a variable named 'ticks'. >>> Something like: >>> - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use >>> this. The tick period would be constant but for virtual ticks and >>> not too small. hz = 1000 now makes the period too small, and not a >>> power of 2. So make the period 1/128 second. This gives a 1.24.7 >>> binary format. 2**24 seconds is 194 days. >>> - ticks < 0. The 31 value bits are now a cookie (descriptor) referring >>> to a bintime or whatever. This case should rarely be used. I don't >>> like it that a tickless kernel, which is needed mainly for power >>> saving, has expanded into complications to support short timeouts >>> which should rarely be used. >> >> >> Bruce, I don't really agree with this. >> The data addressed by cookie should be still stored somewhere, and KBI >> will result broken. This, indeed, is not real problem as long as >> current calloutng code heavily breaks KBI, but if that was your point, >> I don't see how your proposed change could help. > > > In the old API, it is an error to pass ticks < 0, so only broken old > callers are affected. Of course, if there are any then it would be > hard to detect their garbage cookies. > > Anywy, it's too later to change to this, and maybe also to a 32.32 > format. > > [32.32 format] It's not too late. What I'd like to do, right now people got interested in the problem is agreeing on the interface used. Following this thread, as I've already discussed to mav@, we would like to decide what of the two is better: - specify precision as additional argument (as we're doing right now) - use 'flags' argument If we allow time argument to be relative and not absolute, as suggested by luigi@, we can easily use relative precision where we had to use ffl() before. >>> >>> This would make a better general format than timevals, timespecs and >>> of course bintimes :-). It is a bit wasteful for timeouts since >>> its extremes are rarely used. Malicious and broken callers can >>> still cause overflow at 68 years, so you have to check for it and >>> handle it. The limit of 194 days is just as good for timeouts. >> >> >> I think the phk's proposal is better. About your overflow objection, >> I think is really unlikely to happen, but better safe than sorry. > > > It's very easy for applications to cause kernel overflow using valid > syscall args like tv_sec = TIME_T_MAX for a relative time in > nanosleep(). Adding TIME_T_MAX to the current time in seconds overflow > for all current times except for the first second after the Epoch. > There is no difference between the overflow for 32-bit and 64-bit > time_t's for this. This is now mostly handled so that the behaviour is > harmless although wrong. E.g., the timeout might become negative, > and then since it is not a cookie it is silently replaced by a timeout > of 1 tick. In nanosleep(), IIRC there are further overflows that result > in returning early instead of retrying the 1-tick timeouts endlessly. > > Bruce Thanks, Davide From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 16:18:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBDCF8B5; Wed, 19 Dec 2012 16:18:43 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id E37578FC13; Wed, 19 Dec 2012 16:18:42 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so1128130eek.7 for ; Wed, 19 Dec 2012 08:18:41 -0800 (PST) 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=xIViPU9CBvgN8soYJD56Hq21FV9fLdRC7/cdE3yQUsk=; b=tcthfqTekjPLVMtY6Kl/0uAMJIVJBABDkvyNQKIGJ9IWFX7nQo/WnQmpSY6bURLzrc fJSl8dbiQFaB6qw9GOiNpLgRcfPbodUPXlSK8GHfA7uToaJhXGRYQQuOfvSghqq5V5oX KZyRtmd+Oi8/x+lvTaSvB+yxd0su06xLLbc5JLfCrzfBAKPABEd7hwLyS6bBDOyNy7BP t78udfSFIBKrXtWXqlkI3iEcVBuQW01re9BKCtRPq4hwDC/APS4ahDsSu82f7Z2FU29V kxQ9AdZepsHPa532RXxVYW0iiXBvIMP2AeG3AKkcbHo0Rd+VyNOeYfQ0nccjSfK3f+VP AamA== MIME-Version: 1.0 Received: by 10.14.225.72 with SMTP id y48mr15124371eep.46.1355933921454; Wed, 19 Dec 2012 08:18:41 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.14.0.2 with HTTP; Wed, 19 Dec 2012 08:18:41 -0800 (PST) In-Reply-To: <17057.1355931448@critter.freebsd.dk> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219150809.GA98673@onelab2.iet.unipi.it> <17057.1355931448@critter.freebsd.dk> Date: Wed, 19 Dec 2012 08:18:41 -0800 X-Google-Sender-Auth: ePNWaUYAQ9S9zl1G8hfm2qQ3X08 Message-ID: Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Luigi Rizzo To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , Ian Lepore , Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:18:44 -0000 On Wed, Dec 19, 2012 at 7:37 AM, Poul-Henning Kamp wrote: > -------- > In message <20121219150809.GA98673@onelab2.iet.unipi.it>, Luigi Rizzo > writes: > > >> typedef dur_t int64_t; /* signed for bug catching */ > >> #define DURSEC ((dur_t)1 << 32) > >> #define DURMIN (DURSEC * 60) > >> #define DURMSEC (DURSEC / 1000) > >> #define DURUSEC (DURSEC / 10000000) > >> #define DURNSEC (DURSEC / 10000000000) > > >only thing, we must be careful with the parentheses > > Actually, it's more impportant to be careful with zeros, if you > adjust the above to the correct number of zeros, DURNSEC is 4, > which is within seven percent of the correct value. > counting digits is impossible for people over 45. But i have a solution for that #define DURNSEC (DURSEC / 1003006009) which is within 0.5% of the desired value. (and of course (1000*1000*1000) might do the job too) cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 16:22:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2699A9A; Wed, 19 Dec 2012 16:22:33 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB788FC14; Wed, 19 Dec 2012 16:22:31 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id qBJGQoRo065793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 17:26:50 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50D1E9C6.2030501@omnilan.de> Date: Wed, 19 Dec 2012 17:22:30 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: [patch] permit fib to be set on interface References: <4DC695FC.3080700@ipfw.ru> In-Reply-To: <4DC695FC.3080700@ipfw.ru> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE59BB3BDCF208BA0ACEC341" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:22:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE59BB3BDCF208BA0ACEC341 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Alexander V. Chernikov am 08.05.2011 15:09 (localtime): > At the moment the only possible way to set packet fib from userland is > ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows > with every fib. > Additionally, there is no way to set packet fib before netgraph > processing: L2 ipfw hook is called after ng_ether_input() > > Those reasons (not mentioning kern/134931) makes it hard to use multipl= e > routing tables. > > The following path: > * adds SIOCGIFIB/SIOCSIFIB ioctl(2) calls to get/set per-interface fib > * adds IFF_CUSTOMFIB interface flags > * adds ifi_fib field to if_data structure > * adds 'fib' keyword for ifconfig(8) > > Example: > 16:42 [0] zfscurr0# ifconfig vlan2 create inet 10.11.12.13/30 fib 15 > vlan 2 vlandev em0 > 16:42 [0] zfscurr0# ifconfig vlan2 > vlan2: flags=3D808843= > metric 0 mtu 1500 fib 15 > options=3D3 > ether 08:00:27:c5:29:d4 > inet 10.11.12.13 netmask 0xfffffffc broadcast 10.11.12.15 > inet6 fe80::a00:27ff:fec5:29d4%vlan2 prefixlen 64 scopeid 0x4 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 2 parent interface: em0 > > > Interface fib is applied on inbound only (for forwarded packets fib > decision should be done on inbound, for locally-originated packets ther= e > is setfib(1)) Could you please help me understanding the design? If I have a multihomed machine, with fib0 defaultrouter via nic0 and fib1 defaultrouter via nic1, and nic1 has fib1 assigned. What should happen if I connect to any service, by default assigned to fib0, but passing nic1? The incoming packet will be tagged with "FIB1", right? But does that affect the answer-path of services not assigned to fib1? If not, why would I want incoming packates tagged? Thanks, -Harry --------------enigEE59BB3BDCF208BA0ACEC341 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlDR6cYACgkQLDqVQ9VXb8gKxgCgg9Tuxin5SIxXGvH+XezafTLM yZUAoIwVBzYFrBYZwfOv3agzzDNcvboL =kKRk -----END PGP SIGNATURE----- --------------enigEE59BB3BDCF208BA0ACEC341-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 14:21:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA4BF480; Wed, 19 Dec 2012 14:21:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8CC8FC17; Wed, 19 Dec 2012 14:21:18 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJELHww025480; Thu, 20 Dec 2012 01:21:17 +1100 Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJEKum1011107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 01:20:57 +1100 Date: Thu, 20 Dec 2012 01:20:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Davide Italiano Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: Message-ID: <20121220010702.B1675@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=L9pF2Jv8 c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=vXJ0KzY1-sXwhEubLOkA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 16:40:46 +0000 Cc: Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:21:19 -0000 On Wed, 19 Dec 2012, Davide Italiano wrote: > On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: >> I would have tried a 32 bit format with a variable named 'ticks'. >> Something like: >> - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use >> this. The tick period would be constant but for virtual ticks and >> not too small. hz = 1000 now makes the period too small, and not a >> power of 2. So make the period 1/128 second. This gives a 1.24.7 >> binary format. 2**24 seconds is 194 days. >> - ticks < 0. The 31 value bits are now a cookie (descriptor) referring >> to a bintime or whatever. This case should rarely be used. I don't >> like it that a tickless kernel, which is needed mainly for power >> saving, has expanded into complications to support short timeouts >> which should rarely be used. > > Bruce, I don't really agree with this. > The data addressed by cookie should be still stored somewhere, and KBI > will result broken. This, indeed, is not real problem as long as > current calloutng code heavily breaks KBI, but if that was your point, > I don't see how your proposed change could help. In the old API, it is an error to pass ticks < 0, so only broken old callers are affected. Of course, if there are any then it would be hard to detect their garbage cookies. Anywy, it's too later to change to this, and maybe also to a 32.32 format. [32.32 format] >> This would make a better general format than timevals, timespecs and >> of course bintimes :-). It is a bit wasteful for timeouts since >> its extremes are rarely used. Malicious and broken callers can >> still cause overflow at 68 years, so you have to check for it and >> handle it. The limit of 194 days is just as good for timeouts. > > I think the phk's proposal is better. About your overflow objection, > I think is really unlikely to happen, but better safe than sorry. It's very easy for applications to cause kernel overflow using valid syscall args like tv_sec = TIME_T_MAX for a relative time in nanosleep(). Adding TIME_T_MAX to the current time in seconds overflow for all current times except for the first second after the Epoch. There is no difference between the overflow for 32-bit and 64-bit time_t's for this. This is now mostly handled so that the behaviour is harmless although wrong. E.g., the timeout might become negative, and then since it is not a cookie it is silently replaced by a timeout of 1 tick. In nanosleep(), IIRC there are further overflows that result in returning early instead of retrying the 1-tick timeouts endlessly. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 14:57:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2161ED86; Wed, 19 Dec 2012 14:57:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE668FC18; Wed, 19 Dec 2012 14:57:19 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJEv5aD027522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 01:57:08 +1100 Date: Thu, 20 Dec 2012 01:57:05 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: <16664.1355926489@critter.freebsd.dk> Message-ID: <20121220012223.F1772@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <16439.1355922282@critter.freebsd.dk> <20121220005706.I1675@besplex.bde.org> <16664.1355926489@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=BrrFWvr5 c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=coF_l0KmdXCzCSlSFisA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 16:50:55 +0000 Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:57:21 -0000 On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > -------- > In message <20121220005706.I1675@besplex.bde.org>, Bruce Evans writes: >> On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > >>> Except that for absolute timescales, we're running out of the 32 bits >>> integer part. >> >> Except 32 bit time_t works until 2106 if it is unsigned. > > That's sort of not an option. I think it is. It is just probably not necessary since 32-bit systems will go away before 2038. > The real problem was that time_t was not defined as a floating > point number. That would be convenient too, but bad for efficiency on some systems. Kernels might not be able to use it, and then would have to use an alternative representation, which they should have done all along. >>> [1] A good addition to C would be a general multi-word integer type >>> where you could ask for any int%d_t or uint%d_t you cared for, and >>> have the compiler DTRT. In difference from using a multiword-library, >>> this would still give these types their natural integer behaviour. >> >> That would be convenient, but bad for efficiency if it were actually >> used much. > > You can say that about anything but CPU-native operations, and I doubt > it would be as inefficient as struct bintime, which does not have access > to the carry bit. Yes, I would say that about non-native. It goes against the spirit of C. OTOH, compilers are getting closer to giving full access to the carry bit. I just checked what clang does in a home-made 128-bit add function: % static void __noinline % uadd(struct u *xup, struct u *yup) % { % unsigned long long t; % % t = xup->w[0] + yup->w[0]; % if (t < xup->w[0]) % xup->w[1]++; % xup->w[0] = t; % xup->w[1] += yup->w[1]; % } % % .align 16, 0x90 % .type uadd,@function % uadd: # @uadd % .cfi_startproc % # BB#0: # %entry % movq (%rdi), %rcx % movq 8(%rdi), %rax % addq (%rsi), %rcx gcc generates an additional cmpq instruction here. % jae .LBB2_2 clang uses the carry bit set by the first addition to avoid the comparison, but still branches. % # BB#1: # %if.then % incq %rax % movq %rax, 8(%rdi) This adds 1 explicitly instead of using adcq, but this is the slow path. % .LBB2_2: # %if.end % movq %rcx, (%rdi) % addq 8(%rsi), %rax This is as efficient as possible except for the extra branch, and the branch is almost perfectly predictable. % movq %rax, 8(%rdi) % ret % .Ltmp22: % .size uadd, .Ltmp22-uadd % .cfi_endproc Bruce From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 16:51:08 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B173968; Wed, 19 Dec 2012 16:51:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C68498FC12; Wed, 19 Dec 2012 16:51:07 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5928B8A3FC; Wed, 19 Dec 2012 16:51:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJGp5O1017237; Wed, 19 Dec 2012 16:51:05 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Motin Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <50D1E0D8.9070209@FreeBSD.org> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <20121220010702.B1675@besplex.bde.org> <50D1E0D8.9070209@FreeBSD.org> Date: Wed, 19 Dec 2012 16:51:05 +0000 Message-ID: <17236.1355935865@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , freebsd-current , Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:51:08 -0000 -------- In message <50D1E0D8.9070209@FreeBSD.org>, Alexander Motin writes: >It would be late to change this after committing. I would definitely >like it to be done earlier to not redo all the tests, but I think we >could convert callout and eventtimers code to 32.32 format in several >days. The only two questions are: do we really want it (won't there be >any reasons to regret about it) and how do we want it to look? As much as it pains me to raise this point, we would regret it if we did not use 32.32, because Linux already went that way. As much as there is to be said for doing things right, we should also try to avoid pointless incompatibilities which will make it needlessly hard for people to move code, particular device drivers forth and back. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:44:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFDA659C; Wed, 19 Dec 2012 15:44:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3428FC13; Wed, 19 Dec 2012 15:44:15 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJFi70F027414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 02:44:08 +1100 Date: Thu, 20 Dec 2012 02:44:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Luigi Rizzo Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: <20121219150809.GA98673@onelab2.iet.unipi.it> Message-ID: <20121220022926.C1961@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219150809.GA98673@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=EvuKNlgA c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=j58EWA6DYnG8U02EjcUA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 16:51:10 +0000 Cc: Davide Italiano , Ian Lepore , Alexander Motin , Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:44:16 -0000 I finally remembered to remove the .it phk :-). On Wed, 19 Dec 2012, Luigi Rizzo wrote: > On Wed, Dec 19, 2012 at 10:51:48AM +0000, Poul-Henning Kamp wrote: >> ... >> As I said in my previous email: >> >> >> typedef dur_t int64_t; /* signed for bug catching */ >> #define DURSEC ((dur_t)1 << 32) >> #define DURMIN (DURSEC * 60) >> #define DURMSEC (DURSEC / 1000) >> #define DURUSEC (DURSEC / 10000000) >> #define DURNSEC (DURSEC / 10000000000) >> >> (Bikeshed the names at your convenience) >> >> Then you can say >> >> callout_foo(34 * DURSEC) >> callout_foo(2400 * DURMSEC) >> or >> callout_foo(500 * DURNSEC) > > only thing, we must be careful with the parentheses > > For instance, in your macro, DURNSEC evaluates to 0 and so > does any multiple of it. > We should define them as > > #define DURNSEC DURSEC / 10000000000 > ... > > so DURNSEC is still 0 and 500*DURNSEC gives 214 > > I am curious that Bruce did not mention this :) Er, he was careful. DURNSEC gives 4, not 0. This is not very accurate, but probably good enough. Your version without parentheses is not so careful and depends on a magic order of operations and no overflow from this. E.g.: 500*DURNSEC = 500*DURSEC / 1000000000 = 500*((dur_t)1 << 32) / 1000000000 This is very accurate and happens not to overflow. But 5 seconds represented a little strangely in nanoseconds would overflow: 5000000000*DURNSEC = 5000000000*((dur_t)1 << 32) / 1000000000 So would 5 billion times DURSEC, but 5 billion seconds is more unreasobable than 5 billion nanoseconds and the format just can't represent that. > > (btw the typedef is swapped, should be "typedef int64_t dur_t") Didn't notice this. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 21:47:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6D5BED6; Wed, 19 Dec 2012 21:47:45 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0428FC0A; Wed, 19 Dec 2012 21:47:44 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id dr13so1169504wgb.13 for ; Wed, 19 Dec 2012 13:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=M0NCw9NwtMMTEMd9v4xwJR+cD6UVyoL5cW/Lz9QON68=; b=RB6pZFfAnn4O2RoyeFScg4xfuIj1HUkOmDoZf3t5g0sLZq3ytlT6soYAxk7Kj3taDi 3LYjSdYGuIfXXgu5YkfnmfLNrxNAdZqg4ib1x04x1M7seeS6QCriooe0U0VAO6nf685t aP7XIUvDswO07pawxtwgwbQp3MBlZs6QSN8Bg7pVDAMlnn76m5T1LO2rt+AfgIsojm1g h1k4BCx/g/zSEtyXay0otVx5fsqyz0nTAqMVY7coyN6u/U58RvwkBBDHG+cSspC4r9bf 3T61oxxN1wqp+cxaHojg72+loJmzFftejkLPFUcbuox1GIMZpyvJk2rhjnhUS9RcYyPd vJ5A== MIME-Version: 1.0 Received: by 10.180.81.39 with SMTP id w7mr13714740wix.15.1355953657738; Wed, 19 Dec 2012 13:47:37 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 19 Dec 2012 13:47:37 -0800 (PST) In-Reply-To: <50D1C553.9060100@wasikowski.net> References: <50D1C553.9060100@wasikowski.net> Date: Wed, 19 Dec 2012 23:47:37 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 21:47:45 -0000 On Wed, Dec 19, 2012 at 3:46 PM, =C5=81ukasz W=C4=85sikowski wrote: > W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: > >>> I wrote a small patch for /etc/network.subr to add support for >>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing >>> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 >>> aliases can be written like: > > [...] > >> Did anyone try my patch? I thought it would be nice to have the >> ipv6_addrs_IF syntax supported to complement the existing >> ipv4_addrs_IF alias syntax. > > Can I use range syntax in it like in ipv4? I mean something like: > > ipv4_addrs_lagg0=3D"x.x.x.10-30/22" > > That feature would be very nice to have for ipv6. > > -- > best regards, > Lukasz Wasikowski I have to admit I overlooked the possibility to use ranges like that. It doesn't look too hard to add that feature as well for ipv6 aliases using the existing code for ipv4 aliases. I'll prepare a new patch and update the PR when I have it working. -Kimmo From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 22:14:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC2E3B7B; Wed, 19 Dec 2012 22:14:59 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id 999158FC12; Wed, 19 Dec 2012 22:14:55 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id gf7so2410962lbb.16 for ; Wed, 19 Dec 2012 14:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5cqss8VNWdM+sz8LiNSNx7E1hUskih7POgfYF6snWHk=; b=uapRz6cXu7WZaOm+fIH76Uw1dWK9WFluWDvPiq9AaFW2aD+enKBXzL5vc7SiIhYdLp 5J0xHTLEXisdjsaN66+I51lwZPdOLiIob4h3AFsWDAqcIGuuQ0Xyf7Ic9d1DJ9CPHLPT 1PIuJO7z5ySzwXjvHjbdhPdhppSU6kchtB4uMJ3HrVH0dPXm3y7Vw2L6FB+DgFmssw8i jcwRbjjqCg2oqYoKolq0cM6P30/bIyUMb+PfFQ3qb/T2AdzDJsiRkWuu/ZL7HuIpmiCK Qxcu2z6SKdPq+s/a/y5nyPCI/3COtv4AR42yxMnrFJcAEjfZBq1JzEK8LD+VjkkFfg9e BN7A== MIME-Version: 1.0 Received: by 10.112.16.69 with SMTP id e5mr2999886lbd.43.1355955294160; Wed, 19 Dec 2012 14:14:54 -0800 (PST) Received: by 10.112.99.70 with HTTP; Wed, 19 Dec 2012 14:14:53 -0800 (PST) In-Reply-To: References: <50B6598B.20200@FreeBSD.org> <50C9BA19.4040504@FreeBSD.org> Date: Wed, 19 Dec 2012 14:14:53 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Garrett Cooper To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , Andriy Gapon , freebsd-zfs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 22:14:59 -0000 On Thu, Dec 13, 2012 at 2:56 PM, Freddie Cash wrote: ... > You could at least point to the FreeBSD Forums version of that post. :) > > https://forums.freebsd.org/showthread.php?t=31662 Andriy, I figured out my problem. It was really, really stupid PEBKAC (copied a KERNCONF from one system that didn't have the appropriate storage driver for the other system and I didn't put the right entries into src.conf). Sorry for the noise >:(. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 22:34:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A4603B9; Wed, 19 Dec 2012 22:34:14 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id BA6008FC0C; Wed, 19 Dec 2012 22:34:12 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm6so3922765wib.3 for ; Wed, 19 Dec 2012 14:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/zSWCbGOnCf6sTEZPWoRVtLZMNZSioB1F/IyerX/OIs=; b=lAgzeLCoJBtEkcMQsmql1AuKSbCByUn+z2Q+cKNKSuuUfRZDXookbjVBs2N9Rxloqd aj+Apih/Xi/2QXFzS+WcKjlAPciBl1zMfqp15QlMoDLD7bhb7XaKB9HTPK5ZwvBrDygr q9GYXHl1jV+rjFQVqyiEsCgSpCwVKYsn6Yj9NJerxbOebspGcjMwI7kixr4MjrqGQsmC Gs/tceQ0veL+8fmhOkQKNNKeAVhC1NlC0hlbabWJwCeAoWXWf1znvTB8/bkEUYOfKRC1 i6e8Lbc307tQjHHF6cMBmRfS6ca4HIUVhFyUzCE0EvxwuVFZGQ2g4wR0V1dNDytHbk/w cChA== MIME-Version: 1.0 Received: by 10.180.81.39 with SMTP id w7mr13868580wix.15.1355956451397; Wed, 19 Dec 2012 14:34:11 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 19 Dec 2012 14:34:11 -0800 (PST) In-Reply-To: <50B6598B.20200@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> Date: Thu, 20 Dec 2012 00:34:11 +0200 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Kimmo Paasiala To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , FreeBSD Stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 22:34:14 -0000 On Wed, Nov 28, 2012 at 8:35 PM, Andriy Gapon wrote: > > Recently some changes were made to how a root pool is opened for root filesystem > mounting. Previously the root pool had to be present in zpool.cache. Now it is > automatically discovered by probing available GEOM providers. > The new scheme is believed to be more flexible. For example, it allows to prepare > a new root pool at one system, then export it and then boot from it on a new > system without doing any extra/magical steps with zpool.cache. It could also be > convenient after zpool split and in some other situations. > > The change was introduced via multiple commits, the latest relevant revision in > head is r243502. The changes are partially MFC-ed, the remaining parts are > scheduled to be MFC-ed soon. > > I have received a report that the change caused a problem with booting on at least > one system. The problem has been identified as an issue in local environment and > has been fixed. Please read on to see if you might be affected when you upgrade, > so that you can avoid any unnecessary surprises. > > You might be affected if you ever had a pool named the same as your current root > pool. And you still have any disks connected to your system that belonged to that > pool (in whole or via some partitions). And that pool was never properly > destroyed using zpool destroy, but merely abandoned (its disks > re-purposed/re-partitioned/reused). > > If all of the above are true, then I recommend that you run 'zdb -l ' for > all suspect disks and their partitions (or just all disks and partitions). If > this command reports at least one valid ZFS label for a disk or a partition that > do not belong to any current pool, then the problem may affect you. > > The best course is to remove the offending labels. > > If you are affected, please follow up to this email. > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Hello, What is the status of the MFC process to 9-STABLE? I'm on 9-STABLE r244407, should I be able to boot from this ZFS pool without zpool.cache? zpool status pool: zwhitezone state: ONLINE scan: scrub repaired 0 in 0h53m with 0 errors on Sat Dec 15 23:41:09 2012 config: NAME STATE READ WRITE CKSUM zwhitezone ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 label/wzdisk0 ONLINE 0 0 0 label/wzdisk1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 label/wzdisk2 ONLINE 0 0 0 label/wzdisk3 ONLINE 0 0 0 errors: No known data errors From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 11:06:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00C23B27; Thu, 20 Dec 2012 11:06:42 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by mx1.freebsd.org (Postfix) with ESMTP id CAD278FC15; Thu, 20 Dec 2012 11:06:41 +0000 (UTC) Received: from [84.44.155.174] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tldpj-0001Kr-4o; Thu, 20 Dec 2012 11:58:35 +0100 Date: Thu, 20 Dec 2012 11:56:29 +0100 From: Fabian Keil To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20121220115629.3379a261@fabiankeil.de> In-Reply-To: <50D03173.9080904@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fkGvS34IKnUI/zs202wNFV9"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:06:43 -0000 --Sig_/fkGvS34IKnUI/zs202wNFV9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexander Motin wrote: > Experiments with dummynet shown ineffective support for very short=20 > tick-based callouts. New version fixes that, allowing to get as many=20 > tick-based callout events as hz value permits, while still be able to=20 > aggregate events and generating minimum of interrupts. >=20 > Also this version modifies system load average calculation to fix some=20 > cases existing in HEAD and 9 branches, that could be fixed with new=20 > direct callout functionality. >=20 > http://people.freebsd.org/~mav/calloutng_12_17.patch With this patch (and the previous one, I didn't test the others) my mouse cursor is occasionally not reacting for short amounts of time (less than a second, but long enough to be noticeable). Every now and then the window manager (i3-wm) changes window focus which could be explained by either phantom keyboard or mouse input, or terminal lines are marked as if the cursor was moved with the left button pressed. The problems happen a couple of times per hour but I haven't been able to intentionally reproduce them. They only seem to occur while I'm moving the cursor, but of course I wouldn't otherwise notice a unresponsive cursor anyway. While the cursor is unresponsive, keyboard input and the rest of the system works as expected as far as I can tell. If I set debug.psm.loglevel=3D4 I get a "psm0: lost interrupt?" message once per second when not moving the mouse, however that also happens without the patch and thus might be unrelated. I'm using moused. I'm not sure what additional information is necessary to debug this, so here a bunch of sysctl values that may or may not be relevant: fk@r500 ~ $sysctl kern.eventtimer kern.timecounter kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(10= 0) kern.eventtimer.singlemul: 2 kern.eventtimer.idletick: 0 kern.eventtimer.activetick: 1 kern.eventtimer.timer: HPET kern.eventtimer.periodic: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 25970 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3963519587 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 7323739 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 454465294 kern.timecounter.tc.TSC.frequency: 1995040520 kern.timecounter.tc.TSC.quality: -1000 kern.timecounter.stepwarnings: 0 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC(-1000) ACPI-fast(900) HPET(950) i8254(0) dummy= (-1000000) kern.timecounter.tick: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 0 The system is a Lenovo R500 with a Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz (1995.04-MHz K8-class CPU) Fabian --Sig_/fkGvS34IKnUI/zs202wNFV9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDS7uAACgkQBYqIVf93VJ2pCACff/7xWSIRPvg5DOxagbqQ+ode bjoAnjGS5O3+ryxDeCo4x1BlsPdhX8Oe =bs7m -----END PGP SIGNATURE----- --Sig_/fkGvS34IKnUI/zs202wNFV9-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 11:09:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E24A8D2D; Thu, 20 Dec 2012 11:09:40 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 47D308FC13; Thu, 20 Dec 2012 11:09:40 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so1065417wib.5 for ; Thu, 20 Dec 2012 03:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=iXiEilyIQV4C+XPhkfHbq/EPS+adrKsmy4Lqkqjr6Gw=; b=l6zvf7jUm0XdmECWmZbcMDNIE+mjti1ka7+4w8JqR4FirsNnfFD4TQCnKHS8zHt6ZR PtrxJS8cd0jGO3XHn3tlcOYDHiAEJo8qcqr17H/GBspQ7gS1oUR+wh7aS4VbjnhA6rh5 rtVGvegRnFMNuOSMxVCyG8Qhq/Qv/1tK/XcqJMvFB7JVwnZXsCm4MBivYdTAzV05/vYW Y9727qgiibJ/asVYytwNe1hEX7XJwqmfesSQVQCkH3R6viK6u6Iio1Y11SBa46YbMbHP YYRxTcZG2dsiVpGUaiq2SRDXpHUiQL2Irps8tZgYjNXN9jaWv9jvB+tI55bCtR6mtQ05 wTpA== MIME-Version: 1.0 Received: by 10.180.103.136 with SMTP id fw8mr8967374wib.27.1356001474162; Thu, 20 Dec 2012 03:04:34 -0800 (PST) Received: by 10.216.172.197 with HTTP; Thu, 20 Dec 2012 03:04:34 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> Date: Thu, 20 Dec 2012 13:04:34 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:09:41 -0000 On Wed, Dec 19, 2012 at 11:47 PM, Kimmo Paasiala wrote= : > On Wed, Dec 19, 2012 at 3:46 PM, =C5=81ukasz W=C4=85sikowski > wrote: >> W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: >> >>>> I wrote a small patch for /etc/network.subr to add support for >>>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing >>>> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 >>>> aliases can be written like: >> >> [...] >> >>> Did anyone try my patch? I thought it would be nice to have the >>> ipv6_addrs_IF syntax supported to complement the existing >>> ipv4_addrs_IF alias syntax. >> >> Can I use range syntax in it like in ipv4? I mean something like: >> >> ipv4_addrs_lagg0=3D"x.x.x.10-30/22" >> >> That feature would be very nice to have for ipv6. >> >> -- >> best regards, >> Lukasz Wasikowski > > I have to admit I overlooked the possibility to use ranges like that. > It doesn't look too hard to add that feature as well for ipv6 aliases > using the existing code for ipv4 aliases. I'll prepare a new patch and > update the PR when I have it working. > > -Kimmo A question related to this for those who have been doing work on the rc(8) scripts. Can I assume that /usr/bin is available when network.subr functions are used? Doing calculations on hexadecimal numbers is going to be very awkward if I can't use for example bc(1). -Kimmo From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 11:18:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCC262FD; Thu, 20 Dec 2012 11:18:40 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7F68FC18; Thu, 20 Dec 2012 11:18:38 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id p9so2724975laa.4 for ; Thu, 20 Dec 2012 03:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:newsgroups :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Scq06wGH4+N8XRTb11tJupcnqwyOiiq4+pzXHZpv9uU=; b=dAl19WSfDOuATP0LFMseLVpIemWi1ar7Iet3yCuEK3rRywmLwwD2KyvLscq9MeTTqP 1JbuNjwCxZKO+kOFUPPBsaTbWMg4PA703jWNwN6eovkRRBzCujFsFCQcgWT4ElBS3ilW je7gWoSvuXlJJnF1iTehU5sdpRM1qDDdzbTMtTF6Ash08pQQ/06q8VU7V+Or+Pol5DrJ bR88o60mjieKlSlNuHQZcL0Qf47Q7TAmakG7/nDr6+B+S08p6OZazG7yDUafOEFqEgJs Pv4QF0x3PTxSSJ0Xb76sTZu+tQ0c44v4pJXiXHMGWr3QVyaSTpvFoC5A2t7nQgvTJIjK xdPg== X-Received: by 10.112.29.229 with SMTP id n5mr3778666lbh.130.1356002317710; Thu, 20 Dec 2012 03:18:37 -0800 (PST) Received: from [192.168.1.130] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id t3sm3265920lbl.17.2012.12.20.03.18.34 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 03:18:36 -0800 (PST) Message-ID: <50D2F3FE.1000509@gmail.com> Date: Thu, 20 Dec 2012 13:18:22 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.devel.file-systems To: Andriy Gapon Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> <50CF16B0.9090104@gmail.com> <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> In-Reply-To: <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:18:40 -0000 18.12.2012 00:20, Andriy Gapon: > It's been already mentioned many times that ZFS works much better on amd64. > It's up to a (potential) user to understand limitations of i386 and to decide > whether to use ZFS, in what situations and how. > > You may want to consider using KSTACK_PAGES=4 in your kernel configuration. For last two fays my system seems stable on kernel compiled with KSTACK_PAGES=4 and WITH_CLANG_IS_CC. -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 11:40:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05227A45 for ; Thu, 20 Dec 2012 11:40:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB618FC14 for ; Thu, 20 Dec 2012 11:40:28 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id w5so1539698bku.25 for ; Thu, 20 Dec 2012 03:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m6PZPmLHops+iefzCen4FzWj9sRv42Ep9u6p4PMbMs4=; b=fqfYaBUh7baysfLpUfIhAjFSmQGtA3+xPWGiKrQqBB6FV21BHVaB99tHZ30ryUh416 atidA5C3yigCg8NX1vkTZfIb+Lgdg2ZiUZy5CwY0JVbMMuQH6JruNSDQI8hlUk/NXKMB wrQ3io2lbtmyWDm4/DaFZHHYKRQSczjKGlTtOwACFbfwrDXrUnoRjoiiFgkIYj8frqis W/0MOFCnk54UTEP9GMa2yXndNxJKp9q5tWbK34Om+cktOHLRCeApVsK97/D4kK2nxpJV AQS59wWkU8RiMqhVHJlcOh4ZuCX4wBP8wNoWSDuOBoAsqhR+NM4Va1x67mO8m82ULy4b N2tg== X-Received: by 10.204.128.148 with SMTP id k20mr4441239bks.107.1356003622378; Thu, 20 Dec 2012 03:40:22 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id i20sm6764739bkw.5.2012.12.20.03.40.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 03:40:21 -0800 (PST) Sender: Alexander Motin Message-ID: <50D2F923.2020303@FreeBSD.org> Date: Thu, 20 Dec 2012 13:40:19 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121220115629.3379a261@fabiankeil.de> In-Reply-To: <20121220115629.3379a261@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:40:30 -0000 On 20.12.2012 12:56, Fabian Keil wrote: > Alexander Motin wrote: > >> Experiments with dummynet shown ineffective support for very short >> tick-based callouts. New version fixes that, allowing to get as many >> tick-based callout events as hz value permits, while still be able to >> aggregate events and generating minimum of interrupts. >> >> Also this version modifies system load average calculation to fix some >> cases existing in HEAD and 9 branches, that could be fixed with new >> direct callout functionality. >> >> http://people.freebsd.org/~mav/calloutng_12_17.patch > > With this patch (and the previous one, I didn't test the others) > my mouse cursor is occasionally not reacting for short amounts of > time (less than a second, but long enough to be noticeable). > > Every now and then the window manager (i3-wm) changes window focus > which could be explained by either phantom keyboard or mouse input, > or terminal lines are marked as if the cursor was moved with the > left button pressed. > > The problems happen a couple of times per hour but I haven't > been able to intentionally reproduce them. They only seem to > occur while I'm moving the cursor, but of course I wouldn't > otherwise notice a unresponsive cursor anyway. > > While the cursor is unresponsive, keyboard input and the rest > of the system works as expected as far as I can tell. > > If I set debug.psm.loglevel=4 I get a "psm0: lost interrupt?" > message once per second when not moving the mouse, however that > also happens without the patch and thus might be unrelated. > > I'm using moused. Could you try to revert part of the patch, related to dev/atkbdc? I am not strong in details of that hardware, but in comments there mention that they are related. May be lost keyboard interrupts (which polling rate was increased to 1 second) cause PS/2 mouse delays. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 13:27:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 795B287B; Thu, 20 Dec 2012 13:27:51 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 0F02D8FC12; Thu, 20 Dec 2012 13:27:51 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 74CB23592F8; Thu, 20 Dec 2012 14:27:50 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 5F3852848C; Thu, 20 Dec 2012 14:27:50 +0100 (CET) Date: Thu, 20 Dec 2012 14:27:50 +0100 From: Jilles Tjoelker To: Kimmo Paasiala Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) Message-ID: <20121220132750.GB99616@stack.nl> References: <50D1C553.9060100@wasikowski.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 13:27:51 -0000 On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: > A question related to this for those who have been doing work on the > rc(8) scripts. Can I assume that /usr/bin is available when > network.subr functions are used? Doing calculations on hexadecimal > numbers is going to be very awkward if I can't use for example bc(1). You cannot assume that /usr/bin is available when setting up the network. It may be that /usr is mounted via NFS. You can use hexadecimal numbers (prefixed with 0x) in $((...)) expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can use; in older versions you can use hexdigit and hexprint from network.subr. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 14:20:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08E1B816; Thu, 20 Dec 2012 14:20:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id 40E038FC13; Thu, 20 Dec 2012 14:20:18 +0000 (UTC) Received: from [84.44.155.174] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tlg97-0004Zw-Mf; Thu, 20 Dec 2012 14:26:45 +0100 Date: Thu, 20 Dec 2012 14:26:00 +0100 From: Fabian Keil To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20121220142600.22c4796a@fabiankeil.de> In-Reply-To: <50D2F923.2020303@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121220115629.3379a261@fabiankeil.de> <50D2F923.2020303@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/uFbUm3EGx7QcS.bD5WwSjDW"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:20:19 -0000 --Sig_/uFbUm3EGx7QcS.bD5WwSjDW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexander Motin wrote: > On 20.12.2012 12:56, Fabian Keil wrote: > > Alexander Motin wrote: > > > >> Experiments with dummynet shown ineffective support for very short > >> tick-based callouts. New version fixes that, allowing to get as many > >> tick-based callout events as hz value permits, while still be able to > >> aggregate events and generating minimum of interrupts. > >> > >> Also this version modifies system load average calculation to fix some > >> cases existing in HEAD and 9 branches, that could be fixed with new > >> direct callout functionality. > >> > >> http://people.freebsd.org/~mav/calloutng_12_17.patch > > > > With this patch (and the previous one, I didn't test the others) > > my mouse cursor is occasionally not reacting for short amounts of > > time (less than a second, but long enough to be noticeable). > > > > Every now and then the window manager (i3-wm) changes window focus > > which could be explained by either phantom keyboard or mouse input, > > or terminal lines are marked as if the cursor was moved with the > > left button pressed. > > > > The problems happen a couple of times per hour but I haven't > > been able to intentionally reproduce them. They only seem to > > occur while I'm moving the cursor, but of course I wouldn't > > otherwise notice a unresponsive cursor anyway. > > > > While the cursor is unresponsive, keyboard input and the rest > > of the system works as expected as far as I can tell. > > > > If I set debug.psm.loglevel=3D4 I get a "psm0: lost interrupt?" > > message once per second when not moving the mouse, however that > > also happens without the patch and thus might be unrelated. > > > > I'm using moused. >=20 > Could you try to revert part of the patch, related to dev/atkbdc? I am=20 > not strong in details of that hardware, but in comments there mention=20 > that they are related. May be lost keyboard interrupts (which polling=20 > rate was increased to 1 second) cause PS/2 mouse delays. =20 I reverted the changes to sys/dev/atkbdc/* about an hour ago and so far it's looking good. I'll report back tomorrow after some more testing. Fabian --Sig_/uFbUm3EGx7QcS.bD5WwSjDW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDTEeoACgkQBYqIVf93VJ230wCfUAzgX3NHWp740rDEI6jL1UAN 8oMAoLCRJeaz0RNq13WmT4wlFWjCg/9s =5VtW -----END PGP SIGNATURE----- --Sig_/uFbUm3EGx7QcS.bD5WwSjDW-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 14:26:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28644B18 for ; Thu, 20 Dec 2012 14:26:45 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by mx1.freebsd.org (Postfix) with ESMTP id 94CFD8FC0A for ; Thu, 20 Dec 2012 14:26:44 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id jf3so1719449bkc.37 for ; Thu, 20 Dec 2012 06:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4wFPZJlgZKWwWtG7MEJHH33h4CsItp8pMDx4LZzhVMw=; b=dQCDJ0S4ziw3MtBTBiQquXVMK3/mTNokDxiZ7H/2Sh2ZUQ9Sv3D96laf9uA9x828hh wmyJ6a4jHGiRElHFB9rRiOM+CsPfQOI5CHhmuwMOd36I+xecNMH90yyXUtBAZWGf45Yg qc3NfCxZLcKdEA1MbsEokgaPGjepjaZBzjyif7Qx9ftQRx10r3eTMAKf9h+2ooL4aM4F P0pmq4sfE9YqCBR4OlfVfeaoQBRxj8wPAAEjwnWCQ/7vZ2bSU2kKgCnSIt67RJUFBY0R 27m7f4ZJTcHEJO9VIW+V3LGhmZGIAKuADFW49NWoGf0Qi1GYb2DRJ2J/8VnpmhSkcyzk UMPQ== X-Received: by 10.204.128.197 with SMTP id l5mr4800655bks.59.1356013602954; Thu, 20 Dec 2012 06:26:42 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id y11sm7299221bkw.8.2012.12.20.06.26.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 06:26:41 -0800 (PST) Sender: Alexander Motin Message-ID: <50D3201F.4080605@FreeBSD.org> Date: Thu, 20 Dec 2012 16:26:39 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121220115629.3379a261@fabiankeil.de> <50D2F923.2020303@FreeBSD.org> <20121220142600.22c4796a@fabiankeil.de> In-Reply-To: <20121220142600.22c4796a@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:26:45 -0000 On 20.12.2012 15:26, Fabian Keil wrote: > Alexander Motin wrote: > >> On 20.12.2012 12:56, Fabian Keil wrote: >>> Alexander Motin wrote: >>> >>>> Experiments with dummynet shown ineffective support for very short >>>> tick-based callouts. New version fixes that, allowing to get as many >>>> tick-based callout events as hz value permits, while still be able to >>>> aggregate events and generating minimum of interrupts. >>>> >>>> Also this version modifies system load average calculation to fix some >>>> cases existing in HEAD and 9 branches, that could be fixed with new >>>> direct callout functionality. >>>> >>>> http://people.freebsd.org/~mav/calloutng_12_17.patch >>> >>> With this patch (and the previous one, I didn't test the others) >>> my mouse cursor is occasionally not reacting for short amounts of >>> time (less than a second, but long enough to be noticeable). >>> >>> Every now and then the window manager (i3-wm) changes window focus >>> which could be explained by either phantom keyboard or mouse input, >>> or terminal lines are marked as if the cursor was moved with the >>> left button pressed. >>> >>> The problems happen a couple of times per hour but I haven't >>> been able to intentionally reproduce them. They only seem to >>> occur while I'm moving the cursor, but of course I wouldn't >>> otherwise notice a unresponsive cursor anyway. >>> >>> While the cursor is unresponsive, keyboard input and the rest >>> of the system works as expected as far as I can tell. >>> >>> If I set debug.psm.loglevel=4 I get a "psm0: lost interrupt?" >>> message once per second when not moving the mouse, however that >>> also happens without the patch and thus might be unrelated. >>> >>> I'm using moused. >> >> Could you try to revert part of the patch, related to dev/atkbdc? I am >> not strong in details of that hardware, but in comments there mention >> that they are related. May be lost keyboard interrupts (which polling >> rate was increased to 1 second) cause PS/2 mouse delays. > > I reverted the changes to sys/dev/atkbdc/* about an hour ago > and so far it's looking good. I'll report back tomorrow after > some more testing. Thank you for the report. If it will be fine. you can try to reapply that part of the patch, just changing line: callout_reset_flags(&sc->callout, hz, atkbdtimeout, dev, C_PRELSET(0)); to the: callout_reset_flags(&sc->callout, hz/10, atkbdtimeout, dev, C_PRELSET(0)); It should about to restore original polling interval, but still make it more flexible then original. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 18:16:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EA4E29; Thu, 20 Dec 2012 18:16:42 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by mx1.freebsd.org (Postfix) with ESMTP id EEE0F8FC12; Thu, 20 Dec 2012 18:16:41 +0000 (UTC) Received: from [84.44.155.174] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tlkfb-0006pb-6K; Thu, 20 Dec 2012 19:16:35 +0100 Date: Thu, 20 Dec 2012 19:12:43 +0100 From: Fabian Keil To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20121220191243.7cd00b2a@fabiankeil.de> In-Reply-To: <50D3201F.4080605@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121220115629.3379a261@fabiankeil.de> <50D2F923.2020303@FreeBSD.org> <20121220142600.22c4796a@fabiankeil.de> <50D3201F.4080605@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/uY3hCL0vVS9LVX6Lk4en9Ol"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:16:42 -0000 --Sig_/uY3hCL0vVS9LVX6Lk4en9Ol Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexander Motin wrote: > On 20.12.2012 15:26, Fabian Keil wrote: > > Alexander Motin wrote: > > > >> On 20.12.2012 12:56, Fabian Keil wrote: > >>> Alexander Motin wrote: > >>> > >>>> Experiments with dummynet shown ineffective support for very short > >>>> tick-based callouts. New version fixes that, allowing to get as many > >>>> tick-based callout events as hz value permits, while still be able to > >>>> aggregate events and generating minimum of interrupts. > >>>> > >>>> Also this version modifies system load average calculation to fix so= me > >>>> cases existing in HEAD and 9 branches, that could be fixed with new > >>>> direct callout functionality. > >>>> > >>>> http://people.freebsd.org/~mav/calloutng_12_17.patch > >>> > >>> With this patch (and the previous one, I didn't test the others) > >>> my mouse cursor is occasionally not reacting for short amounts of > >>> time (less than a second, but long enough to be noticeable). > >> Could you try to revert part of the patch, related to dev/atkbdc? I am > >> not strong in details of that hardware, but in comments there mention > >> that they are related. May be lost keyboard interrupts (which polling > >> rate was increased to 1 second) cause PS/2 mouse delays. > > > > I reverted the changes to sys/dev/atkbdc/* about an hour ago > > and so far it's looking good. I'll report back tomorrow after > > some more testing. > > Thank you for the report. If it will be fine. you can try to reapply=20 > that part of the patch, just changing line: > callout_reset_flags(&sc->callout, hz, atkbdtimeout, dev, C_PRELSET(0)); > to the: > callout_reset_flags(&sc->callout, hz/10, atkbdtimeout, dev, C_PRELSET(0)); >=20 > It should about to restore original polling interval, but still make it=20 > more flexible then original. With this change the mouse stops working completely after moving the cursor a couple of pixels, at which point dmesg shows: =20 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 Using the keyboard frequently causes duplicated characters. I'm aware of a problem in vanilla CURRENT where the mouse stops working with similar looking messages when the cursor is being moved "at the wrong moment", but this happens less than once a week and I haven't been able to track it down yet. It's possible that it's the same bug and your patch just triggers it more reliable (two times in a row). I haven't seen the duplicated-characters issue before, though. Just for kicks I also tried: callout_reset_flags(&sc->callout, hz/100, atkbdtimeout, dev, C_PRELSET(0)); but with this modification I can't even enter my login password and thus can't tell if the mouse would work. Fabian --Sig_/uY3hCL0vVS9LVX6Lk4en9Ol Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDTVR4ACgkQBYqIVf93VJ2KUQCfVKEBwTCsNVDl75Fcxym3gINS mmkAoJSqv6gnvw8lwco6+fdy07vSBE7c =+jbF -----END PGP SIGNATURE----- --Sig_/uY3hCL0vVS9LVX6Lk4en9Ol-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 23:26:50 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B374445 for ; Thu, 20 Dec 2012 23:26:50 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F201B8FC0C for ; Thu, 20 Dec 2012 23:26:49 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 3C4E91A3CE2 for ; Thu, 20 Dec 2012 15:26:43 -0800 (PST) Message-ID: <50D39EB3.2050403@mu.org> Date: Thu, 20 Dec 2012 15:26:43 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help References: <20121215132246.GH69724@acme.spoerlein.net> In-Reply-To: <20121215132246.GH69724@acme.spoerlein.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:26:50 -0000 Ulrich, Are you still hoping for feedback on this? If so I am currently setting up to run your scripts from: http://wiki.freebsd.org/GitWorkflow#History Let me know if that is not needed though because if I don't need to then I can save myself a bunch of work. I'll report back to you on my success or not. -Alfred On 12/15/12 5:22 AM, Ulrich Spörlein wrote: > Bad news everyone, > > tl;dr The git mirror of the source repository needs to be re-rolled to > make the conversion deterministically repeatable, this will change > pretty much all git commit hashes. > > The re-roll will be done January 15, 2013. > > Not affected are the ports and doc repositories, nor is the svn_head > (for use with git-svn) affected. > > > Background > > The converter (svn2git) was handing commits and objects to git's > fast-import in arbitrary order, this makes merge commits have an > arbitrary order of their parent commits and thus these merge commits > have changing commit hashes for each converter run. > > This has been fixed, but requires us to move all the branches over to > this deterministic scheme, which will change all their commit hashes. > None of the contents of these commits change, so rebasing/remerging your > work into these branches is possible without running into any merge > conflicts. > > > We need your help > > A goal of these conversions is to have them repeatable by you (yes, > you!), so the correctness of the conversion can be verified. There are > also no backups of the conversion runs, as they should be repeatable > anyway. > > We need 2-3 volunteers to run these conversions themselves and verify > that the produced commit hashes match the published ones. The necessary > steps to do this are documented on the Wiki under > > http://wiki.freebsd.org/GitWorkflow#History > > Please send me your output of git show-ref in a private mail, thanks. > > Cheers, > Uli > > PS: This re-roll has nothing to do with the recent security incident. From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 03:43:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37104C6B; Fri, 21 Dec 2012 03:43:42 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8D29D8FC0C; Fri, 21 Dec 2012 03:43:41 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id r5so1897081wey.7 for ; Thu, 20 Dec 2012 19:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WL3n/sXOSIEqphq51n9vTF9wrgpVmkDD+BwwU/ixaWY=; b=zP5SxjDCjPN2h/fmAIXqYuCASfdm5LD5anLJxbl2XN9T1RE4vxx9Vn/CEglyjIp+sh lTw9Zf1KhkSWMgMGMcIzVNvak9lQN9regobcH5Yt1EKljfxMpypV24TCiLMTtZTF+I/l ViVhLF+AwU3OEUA7E3YZuQ768ypwQ+eEsdn0SqurtzipaXI4ES12a/gHtuXZwDRfDGHs qxJJtZ+oqUeMgFUsMDx6/uDOv1j1JmbtSq4Fuy+aUjDH9rReICkJ70nL3dz2XpcjxPx6 XL11U9Io+e4+AoxK0b1Nfkldv7dtqikegfE/O76QqVO9UGKWXLkvI8VpUa202YobEtrG +acw== MIME-Version: 1.0 Received: by 10.180.100.197 with SMTP id fa5mr13118031wib.32.1356061414815; Thu, 20 Dec 2012 19:43:34 -0800 (PST) Received: by 10.216.172.197 with HTTP; Thu, 20 Dec 2012 19:43:34 -0800 (PST) In-Reply-To: <20121220132750.GB99616@stack.nl> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> Date: Fri, 21 Dec 2012 05:43:34 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: Jilles Tjoelker Content-Type: multipart/mixed; boundary=f46d04182644ec798b04d154a644 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 03:43:42 -0000 --f46d04182644ec798b04d154a644 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wrote: > On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: >> A question related to this for those who have been doing work on the >> rc(8) scripts. Can I assume that /usr/bin is available when >> network.subr functions are used? Doing calculations on hexadecimal >> numbers is going to be very awkward if I can't use for example bc(1). > > You cannot assume that /usr/bin is available when setting up the > network. It may be that /usr is mounted via NFS. > > You can use hexadecimal numbers (prefixed with 0x) in $((...)) > expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can > use; in older versions you can use hexdigit and hexprint from > network.subr. > > -- > Jilles Tjoelker Thanks, I've rewitten my patch to support ranges. It is attached in this message. Again it's against a very recent 9-STABLE, I still haven't found time to see if it applies to CURRENT. It does allow you to do crazy stuff like ipv6_addrs_re0="2001:db8:1111:2222::1-ffff/64" However I didn't find anything to limit the number of aliases in the ipv4 version of the function either. Please test it :) Then a question about the PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I attach this new patch to it? The submit follow up -button fires up my email client and I'm not so sure how to submit a new patch for the PR in an email in such a way that it appears properly formatted in the PR. Regards, Kimmo Paasiala --f46d04182644ec798b04d154a644 Content-Type: text/plain; charset=US-ASCII; name="network.subr_ipv6_addrs_range.patch.txt" Content-Disposition: attachment; filename="network.subr_ipv6_addrs_range.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hayrqiqv0 SW5kZXg6IG5ldHdvcmsuc3Vicgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBuZXR3b3JrLnN1YnIJKHJldmlzaW9u IDI0NDUyMykKKysrIG5ldHdvcmsuc3Vicgkod29ya2luZyBjb3B5KQpAQCAtNTYyLDYgKzU2Miw3 IEBACiAJZmkKIAogCWlmYWxpYXNfdXAgJHtfaWZ9IGluZXQ2ICYmIF9yZXQ9MAorCWlwdjZfYWRk cnNfY29tbW9uICR7X2lmfSBhbGlhcyAmJiBfcmV0PTAKIAlpcHY2X3ByZWZpeF9ob3N0aWRfYWRk cl9jb21tb24gJHtfaWZ9IGFsaWFzICYmIF9yZXQ9MAogCWlwdjZfYWNjZXB0X3J0YWR2X3VwICR7 X2lmfSAmJiBfcmV0PTAKIApAQCAtNjg0LDYgKzY4NSw0OSBAQAogCXJldHVybiAkX3JldAogfQog CisKK2lwdjZfYWRkcnNfY29tbW9uKCkKK3sKKwlsb2NhbCBfcmV0IF9pZiBfYWN0aW9uIF9pcDZw cmVmaXggX2lwNnByZWZpeGVzCisJbG9jYWwgX2lwNmFkZHIgX3ByZWZpeGxlbgorCWxvY2FsIF9y YW5nZSBfaXA2bmV0IF9pcDZsb3cgX2lwNmhpZ2gKKwlfcmV0PTEKKwlfaWY9JDEKKwlfYWN0aW9u PSQyCisKKyMgZ2V0IHRoZSBwcmVmaXhlcyBmcm9tIGlwdjZfYWRkcnNfSUYgdmFyaWFibGUKKwlf aXA2cHJlZml4ZXM9YGdldF9pZl92YXIgJF9pZiBpcHY2X2FkZHJzX0lGYAorCWZvciBfaXA2cHJl Zml4IGluICR7X2lwNnByZWZpeGVzfTsgZG8KKwkJX2lwNmFkZHI9JHtfaXA2cHJlZml4JSUvKn0K KwkJX3ByZWZpeGxlbj0ke19pcDZwcmVmaXgjIyovfQorCQlfcmFuZ2U9JHtfaXA2YWRkciMjKjp9 CisJCV9pcDZuZXQ9JHtfaXA2YWRkciU6Kn0KKwkJX2lwNmxvdz0ke19yYW5nZSUtKn0KKwkJX2lw NmhpZ2g9JHtfcmFuZ2UjKi19CisKKyMgSWYgZGVsZXRpbmcgYW4gYWxpYXMsIHNldCBfcHJlZml4 bGVuIHRvIG51bGwgc3RyaW5nLgorCQlpZiBbICIke19hY3Rpb259IiA9ICItYWxpYXMiIF07IHRo ZW4KKwkJCV9wcmVmaXhsZW49IiIKKwkJZWxzZQorCQkJX3ByZWZpeGxlbj0icHJlZml4bGVuICRf cHJlZml4bGVuIgorCQlmaQorCisJCV9pcDZoaWdoPSQoKCIweCR7X2lwNmhpZ2h9IikpCisJCV9p cDZjb3VudD0kKCgiMHgke19pcDZsb3d9IikpCisJCXdoaWxlIFsgIiR7X2lwNmNvdW50fSIgLWxl ICIke19pcDZoaWdofSIgIF07IGRvCisgICAgICAgICAgICAjIFJlLXVzZXMgdGhlIF9pcDZhZGRy IHZhcmlhYmxlIGZyb20gYWJvdmUKKwkJCV9pcDZhZGRyPSQocHJpbnRmICIleCIgIiR7X2lwNmNv dW50fSIpCisJCQlldmFsICJpZmNvbmZpZyAke19pZn0gaW5ldDYgJHtfaXA2bmV0fToke19pcDZh ZGRyfSAke19wcmVmaXhsZW59ICR7X2FjdGlvbn0iCisJCQlfaXA2Y291bnQ9JCgoJHtfaXA2Y291 bnR9KzEpKQorCQkJX3JldD0wCisJCWRvbmUKKwlkb25lCisKKwlyZXR1cm4gJF9yZXQKK30KKwor CisKICMgaWZhbGlhc191cCBpZiBhZgogIwlDb25maWd1cmUgYWxpYXNlcyBmb3IgbmV0d29yayBp bnRlcmZhY2UgJGlmLgogIwlJdCByZXR1cm5zIDAgaWYgYXQgbGVhc3Qgb25lIGFsaWFzIHdhcyBj b25maWd1cmVkIG9yCg== --f46d04182644ec798b04d154a644-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 10:47:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDA96172 for ; Fri, 21 Dec 2012 10:47:37 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 894938FC0C for ; Fri, 21 Dec 2012 10:47:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=ifokq4UkO9zaVBTDNuv8AAjb66qF7z8Y28447DvNF+w=; b=QV4oi6b9+b1GiHB7bvEKMdFHskY8eTiuNKMBbQyliqhyEEv9dYd2jXB7JOvMaiFvVW+XtcyPWyvbvyRY9jC5CaQ8YTybIkokpWljGOb7XwFlSD59F+20Twyg4ZxRvX6bge6Ebtef06EfyxsLylNBZSRLtp4dYj4FTeI1fS9OpMo=; Received: from [178.137.138.140] (helo=nonamehost) by fsm1.ukr.net with esmtpsa ID 1Tm08V-000J1G-KP for freebsd-current@freebsd.org; Fri, 21 Dec 2012 12:47:27 +0200 Date: Fri, 21 Dec 2012 12:47:26 +0200 From: Ivan Klymenko To: freebsd-current@freebsd.org Subject: Re: panic: page fault Message-ID: <20121221124726.7e678e11@nonamehost> In-Reply-To: <201208141404.07743.jhb@freebsd.org> References: <20120814122909.4a3213ee@nonamehost> <201208141404.07743.jhb@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/fhlLPOCihZ9mc/Jr/WIoSAG" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 10:47:37 -0000 --MP_/fhlLPOCihZ9mc/Jr/WIoSAG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =D0=92 Tue, 14 Aug 2012 14:04:07 -0400 John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: =20 > > http://privatepaste.com/147286442b =20 >=20 > It is easier to reply if the messages are inline (for future > reference). The panic and relevant bit of backtrace are below. > Sadly, trying to cut and paste this destroyed the formatting, so I've > tried to fix it by hand. :( >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x18 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80933e07 > stack pointer =3D 0x28:0xffffff823025b660 > frame pointer =3D 0x28:0xffffff823025b6c0=20 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 12 (irq256: bce0) > trap number =3D 12 > panic: page fault=20 >=20 > #6 0xffffffff80bb5e53 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff80933e07 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, wait= =3D1) > at /usr/src/sys/kern/uipc_mbuf.c:542 > #8 0xffffffff809f8b76 in ip_fragment (ip=3D0xfffffe004b2f3980, > m_frag=3D0xffffff823025b7c8, mtu=3DVariable "mtu" is not available. ) > at /usr/src/sys/netinet/ip_output.c:822 > #9 0xffffffff809f948a in ip_output (m=3D0xfffffe004b2f3900, > opt=3DVariable "opt" is not available. ) > at /usr/src/sys/netinet/ip_output.c:654 > #10 0xffffffff809f59fa in ip_forward (m=3D0xfffffe004b2f3900, > srcrt=3DVariable "srcrt" is not available. ) > at /usr/src/sys/netinet/ip_input.c:1494=20 > #11 0xffffffff809f6dc6 in ip_input (m=3D0xfffffe004b2f3900) > at /usr/src/sys/netinet/ip_input.c:702 > =20 I apologize for not having answered - no more required files... At that time it was not possible to fulfill your request ... Now I have gained a number of similar panic's and i ready to provide the results. > Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', 'p > m0', and 'p *m0'? > =20 kgdb.log in attach > Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and run > 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? > =20 What kind of shell should I use for this? [root@rt02 /var/crash]# exit root@rt02:/var/crash # csh You have mail. root@rt02:/var/crash # source gdb6 osrelease: Undefined variable. root@rt02:/var/crash # exit root@rt02:/var/crash # bash [root@rt02 /var/crash]# source gdb6 bash: gdb6: line 29: syntax error near unexpected token `(' bash: gdb6: line 29: `set $P_STOPPED =3D ($P_STOPPED_SIG | $P_STOPPED_TRACE | $P_STOPPED_SINGLE)' [root@rt02 /var/crash]# exit root@rt02:/var/crash # tcsh You have mail. root@rt02:/var/crash # so sockstat soelim sort source =20 root@rt02:/var/crash # source gdb6 osrelease: Undefined variable. root@rt02:/var/crash # ls bounds core.txt.3 dot.gdbinit.paths info.1 info.5 vmcore.2 core.txt.0 core.txt.4 gdb6 info.2 minfree vmcore.3 core.txt.1 core.txt.5 gdb6.amd64 info.3 vmcore.0 vmcore.4 core.txt.2 dot.gdbinit.kernel info.0 info.4 vmcore.1 vmcore.5 Thanks. --MP_/fhlLPOCihZ9mc/Jr/WIoSAG Content-Type: application/octet-stream; name=core.txt.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=core.txt.0 Z3cwMS5uZXZvc29mdC5sb2NhbCBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29yZS4w CgpXZWQgRGVjIDE5IDE4OjM0OjU0IE1TSyAyMDEyCgpGcmVlQlNEIG5vbmFtZWhvc3QubG9jYWwg OS4xLVJFTEVBU0UgRnJlZUJTRCA5LjEtUkVMRUFTRSAjMCByMjQzODI1OiBUdWUgRGVjICA0IDA5 OjIzOjEwIFVUQyAyMDEyICAgICByb290QGZhcnJlbGwuY3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2Jq L3Vzci9zcmMvc3lzL0dFTkVSSUMgIGFtZDY0CgpwYW5pYzogcGFnZSBmYXVsdAoKR05VIGdkYiA2 LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJ bmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3Ry aWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlwZSAic2hvdyBj b3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRlbHkgbm8gd2Fy cmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLgpUaGlzIEdE QiB3YXMgY29uZmlndXJlZCBhcyAiYW1kNjQtbWFyY2VsLWZyZWVic2QiLi4uCgpVbnJlYWQgcG9y dGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVmZmVyOgoKCkZhdGFsIHRyYXAgMTI6IHBhZ2Ug ZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSAzOyBhcGljIGlkID0gMDMKZmF1bHQg dmlydHVhbCBhZGRyZXNzCT0gMHgxOApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCBkYXRh LCBwYWdlIG5vdCBwcmVzZW50Cmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4ZmZmZmZmZmY4 MDk0YmM0NwpzdGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODExODJjZDY1MApm cmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODExODJjZDZiMApjb2RlIHNlZ21l bnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQTCAwLCBwcmVz IDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MJPSBpbnRlcnJ1cHQg ZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMApjdXJyZW50IHByb2Nlc3MJCT0gMTIgKGlycTI1Njog YmNlMCkKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSAzCktEQjog c3RhY2sgYmFja3RyYWNlOgojMCAweGZmZmZmZmZmODA5MjA4YTYgYXQga2RiX2JhY2t0cmFjZSsw eDY2CiMxIDB4ZmZmZmZmZmY4MDhlYThiZSBhdCBwYW5pYysweDFjZQojMiAweGZmZmZmZmZmODBi ZDgyNDAgYXQgdHJhcF9mYXRhbCsweDI5MAojMyAweGZmZmZmZmZmODBiZDg1N2QgYXQgdHJhcF9w ZmF1bHQrMHgxZWQKIzQgMHhmZmZmZmZmZjgwYmQ4YjllIGF0IHRyYXArMHgzY2UKIzUgMHhmZmZm ZmZmZjgwYmMzMTVmIGF0IGNhbGx0cmFwKzB4OAojNiAweGZmZmZmZmZmODBhMDY0ZDggYXQgaXBf ZnJhZ21lbnQrMHgxZTgKIzcgMHhmZmZmZmZmZjgwYTA2ZTE0IGF0IGlwX291dHB1dCsweDZmNAoj OCAweGZmZmZmZmZmODBhMDMyNDMgYXQgaXBfZm9yd2FyZCsweDMwMwojOSAweGZmZmZmZmZmODBh MDQ4ZGIgYXQgaXBfaW5wdXQrMHg1YWIKIzEwIDB4ZmZmZmZmZmY4MDlhZGFmYiBhdCBuZXRpc3Jf ZGlzcGF0Y2hfc3JjKzB4MjBiCiMxMSAweGZmZmZmZmZmODA5YTM1Y2QgYXQgZXRoZXJfZGVtdXgr MHgxNGQKIzEyIDB4ZmZmZmZmZmY4MDlhMzhhNCBhdCBldGhlcl9uaF9pbnB1dCsweDFmNAojMTMg MHhmZmZmZmZmZjgwOWFkYWZiIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgyMGIKIzE0IDB4ZmZm ZmZmZmY4MDQzOGZkNyBhdCBiY2VfaW50cisweDQ4NwojMTUgMHhmZmZmZmZmZjgwOGJlOGQ0IGF0 IGludHJfZXZlbnRfZXhlY3V0ZV9oYW5kbGVycysweDEwNAojMTYgMHhmZmZmZmZmZjgwOGMwMDc2 IGF0IGl0aHJlYWRfbG9vcCsweGE2CiMxNyAweGZmZmZmZmZmODA4YmI5ZWYgYXQgZm9ya19leGl0 KzB4MTFmClVwdGltZTogNTNtMThzCkR1bXBpbmcgMzM2IG91dCBvZiA0MDc0IE1COi4uNSUuLjE1 JS4uMjQlLi4zNCUuLjQzJS4uNTMlLi42MiUuLjcyJS4uODElLi45MSUKClJlYWRpbmcgc3ltYm9s cyBmcm9tIC9ib290L2tlcm5lbC9pcGZ3LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qv a2VybmVsL2lwZncua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAv Ym9vdC9rZXJuZWwvaXBmdy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcGYu a28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcGYua28uc3ltYm9scy4uLmRv bmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvcGYua28KUmVhZGluZyBz eW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2lmX2NhcnAua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvaWZfY2FycC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5 bWJvbHMgZm9yIC9ib290L2tlcm5lbC9pZl9jYXJwLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9i b290L2tlcm5lbC9haW8ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWlv LmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVs L2Fpby5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWNjZl9kYXRhLmtvLi4u UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2FjY2ZfZGF0YS5rby5zeW1ib2xzLi4u ZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9hY2NmX2RhdGEua28K UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2FjY2ZfZG5zLmtvLi4uUmVhZGluZyBz eW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2FjY2ZfZG5zLmtvLnN5bWJvbHMuLi5kb25lLgpkb25l LgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2FjY2ZfZG5zLmtvClJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9hY2NmX2h0dHAua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvYWNjZl9odHRwLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQg c3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2FjY2ZfaHR0cC5rbwpSZWFkaW5nIHN5bWJvbHMgZnJv bSAvYm9vdC9rZXJuZWwvZHVtbXluZXQua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9r ZXJuZWwvZHVtbXluZXQua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZv ciAvYm9vdC9rZXJuZWwvZHVtbXluZXQua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2Vy bmVsL2NwdWN0bC5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9jcHVjdGwu a28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwv Y3B1Y3RsLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9pcGwua28uLi5SZWFk aW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvaXBsLmtvLnN5bWJvbHMuLi5kb25lLgpkb25l LgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2lwbC5rbwpSZWFkaW5nIHN5bWJvbHMg ZnJvbSAvYm9vdC9rZXJuZWwvbmdfc29ja2V0LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jv b3Qva2VybmVsL25nX3NvY2tldC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJv bHMgZm9yIC9ib290L2tlcm5lbC9uZ19zb2NrZXQua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jv b3Qva2VybmVsL25ldGdyYXBoLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVs L25ldGdyYXBoLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jv b3Qva2VybmVsL25ldGdyYXBoLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9u Z19tcHBjLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL25nX21wcGMua28u c3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvbmdf bXBwYy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcmM0LmtvLi4uUmVhZGlu ZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3JjNC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4K TG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9yYzQua28KIzAgIGRvYWR1bXAgKHRleHRk dW1wPVZhcmlhYmxlICJ0ZXh0ZHVtcCIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCBwY3B1Lmg6MjI0 CjIyNAlwY3B1Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCglpbiBwY3B1LmgKKGtnZGIp ICMwICBkb2FkdW1wICh0ZXh0ZHVtcD1WYXJpYWJsZSAidGV4dGR1bXAiIGlzIG5vdCBhdmFpbGFi bGUuCikgYXQgcGNwdS5oOjIyNAojMSAgMHhmZmZmZmZmZjgwOGVhM2ExIGluIGtlcm5fcmVib290 IChob3d0bz0yNjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDQ4 CiMyICAweGZmZmZmZmZmODA4ZWE4OTcgaW4gcGFuaWMgKGZtdD0weDEgPEFkZHJlc3MgMHgxIG91 dCBvZiBib3VuZHM+KQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjYz NgojMyAgMHhmZmZmZmZmZjgwYmQ4MjQwIGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4YywgZXZhPVZh cmlhYmxlICJldmEiIGlzIG5vdCBhdmFpbGFibGUuCikKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2 NC9hbWQ2NC90cmFwLmM6ODU3CiM0ICAweGZmZmZmZmZmODBiZDg1N2QgaW4gdHJhcF9wZmF1bHQg KGZyYW1lPTB4ZmZmZmZmODExODJjZDVhMCwgdXNlcm1vZGU9MCkKICAgIGF0IC91c3Ivc3JjL3N5 cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NzczCiM1ICAweGZmZmZmZmZmODBiZDhiOWUgaW4gdHJhcCAo ZnJhbWU9MHhmZmZmZmY4MTE4MmNkNWEwKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0 L3RyYXAuYzo0NTYKIzYgIDB4ZmZmZmZmZmY4MGJjMzE1ZiBpbiBjYWxsdHJhcCAoKQogICAgYXQg L3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjIyOAojNyAgMHhmZmZmZmZmZjgw OTRiYzQ3IGluIG1fY29weW0gKG09MHgwLCBvZmYwPTE1MDAsIGxlbj0xNDgwLCB3YWl0PTEpCiAg ICBhdCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX21idWYuYzo1NDIKIzggIDB4ZmZmZmZmZmY4MGEw NjRkOCBpbiBpcF9mcmFnbWVudCAoaXA9MHhmZmZmZmUwMDI1NWFhMjgwLCAKICAgIG1fZnJhZz0w eGZmZmZmZjgxMTgyY2Q3YjgsIG10dT1WYXJpYWJsZSAibXR1IiBpcyBub3QgYXZhaWxhYmxlLgop IGF0IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jOjgyMgojOSAgMHhmZmZmZmZmZjgw YTA2ZTE0IGluIGlwX291dHB1dCAobT0weGZmZmZmZTAwMjU1YWEyMDAsIG9wdD1WYXJpYWJsZSAi b3B0IiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pcF9v dXRwdXQuYzo2NTMKIzEwIDB4ZmZmZmZmZmY4MGEwMzI0MyBpbiBpcF9mb3J3YXJkIChtPTB4ZmZm ZmZlMDAyNTVhYTIwMCwgc3JjcnQ9VmFyaWFibGUgInNyY3J0IiBpcyBub3QgYXZhaWxhYmxlLgop CiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jOjE0OTQKIzExIDB4ZmZmZmZm ZmY4MGEwNDhkYiBpbiBpcF9pbnB1dCAobT0weGZmZmZmZTAwMjU1YWEyMDApCiAgICBhdCAvdXNy L3NyYy9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jOjcwMgojMTIgMHhmZmZmZmZmZjgwOWFkYWZiIGlu IG5ldGlzcl9kaXNwYXRjaF9zcmMgKHByb3RvPTEsIHNvdXJjZT1WYXJpYWJsZSAic291cmNlIiBp cyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvbmV0L25ldGlzci5jOjEwMTMK IzEzIDB4ZmZmZmZmZmY4MDlhMzVjZCBpbiBldGhlcl9kZW11eCAoaWZwPTB4ZmZmZmZlMDAwMjky MTgwMCwgCiAgICBtPTB4ZmZmZmZlMDAyNTVhYTIwMCkgYXQgL3Vzci9zcmMvc3lzL25ldC9pZl9l dGhlcnN1YnIuYzo5NDAKIzE0IDB4ZmZmZmZmZmY4MDlhMzhhNCBpbiBldGhlcl9uaF9pbnB1dCAo bT1WYXJpYWJsZSAibSIgaXMgbm90IGF2YWlsYWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lzL25l dC9pZl9ldGhlcnN1YnIuYzo3NTkKIzE1IDB4ZmZmZmZmZmY4MDlhZGFmYiBpbiBuZXRpc3JfZGlz cGF0Y2hfc3JjIChwcm90bz05LCBzb3VyY2U9VmFyaWFibGUgInNvdXJjZSIgaXMgbm90IGF2YWls YWJsZS4KKQogICAgYXQgL3Vzci9zcmMvc3lzL25ldC9uZXRpc3IuYzoxMDEzCiMxNiAweGZmZmZm ZmZmODA0MzhmZDcgaW4gYmNlX2ludHIgKHhzYz1WYXJpYWJsZSAieHNjIiBpcyBub3QgYXZhaWxh YmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMvZGV2L2JjZS9pZl9iY2UuYzo2OTAzCiMxNyAweGZm ZmZmZmZmODA4YmU4ZDQgaW4gaW50cl9ldmVudF9leGVjdXRlX2hhbmRsZXJzIChwPVZhcmlhYmxl ICJwIiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2lu dHIuYzoxMjYyCiMxOCAweGZmZmZmZmZmODA4YzAwNzYgaW4gaXRocmVhZF9sb29wIChhcmc9MHhm ZmZmZmUwMDAyZDUyNjYwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTI3 NQojMTkgMHhmZmZmZmZmZjgwOGJiOWVmIGluIGZvcmtfZXhpdCAoCiAgICBjYWxsb3V0PTB4ZmZm ZmZmZmY4MDhiZmZkMCA8aXRocmVhZF9sb29wPiwgYXJnPTB4ZmZmZmZlMDAwMmQ1MjY2MCwgCiAg ICBmcmFtZT0weGZmZmZmZjgxMTgyY2RjNDApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9y ay5jOjk5MgojMjAgMHhmZmZmZmZmZjgwYmMzNjhlIGluIGZvcmtfdHJhbXBvbGluZSAoKQogICAg YXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjYwMgojMjEgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpCiMyMiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzIzIDB4 MDAwMDAwMDAwMDAwMDAwMSBpbiA/PyAoKQojMjQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp CiMyNSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI2IDB4MDAwMDAwMDAwMDAwMDAwMCBp biA/PyAoKQojMjcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyOCAweDAwMDAwMDAwMDAw MDAwMDAgaW4gPz8gKCkKIzI5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzAgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpCiMzMSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzMy IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpCiMzNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzM1IDB4MDAwMDAwMDAwMDAwMDAw MCBpbiA/PyAoKQojMzYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzNyAweDAwMDAwMDAw MDAwMDAwMDAgaW4gPz8gKCkKIzM4IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzkgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiM0MCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkK IzQxIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojNDIgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCiM0MyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQ0IDB4MDAwMDAwMDAwMDAw MDAwMCBpbiA/PyAoKQojNDUgMHgwMDAwMDAwMDAwMDAwMDAzIGluID8/ICgpCiM0NiAweGZmZmZm ZmZmODEyNDI4ODAgaW4gdGRxX2NwdSAoKQojNDcgMHhmZmZmZmUwMDAyOTM0OGUwIGluID8/ICgp CiM0OCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzQ5IDB4ZmZmZmZmODExODJjZGIzMCBp biA/PyAoKQojNTAgMHhmZmZmZmY4MTE4MmNkYWQ4IGluID8/ICgpCiM1MSAweGZmZmZmZTAwMDI5 MTk0NzAgaW4gPz8gKCkKIzUyIDB4ZmZmZmZmZmY4MDkxMzUyZSBpbiBzY2hlZF9zd2l0Y2ggKHRk PTB4MCwgbmV3dGQ9MHhmZmZmZmUwMDAyZDUyNjYwLCAKICAgIGZsYWdzPVZhcmlhYmxlICJmbGFn cyIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzox OTIxClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQoo a2dkYikgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KcHMgLWF4bAoKICBVSUQgIFBJRCBQUElEIENQVSBQUkkg TkkgICBWU1ogUlNTIE1XQ0hBTiAgIFNUQVQgVFQgICAgICBUSU1FIENPTU1BTkQKICAgIDAgICAg MCAgICAwICAgMCAtOTIgIDAgICAgIDAgICAwIC0gICAgICAgIERMcyAgPz8gICAwOjE5LjYwIFtr ZXJuZWxdCiAgICAwICAgIDEgICAgMCAgIDAgIDI0ICAwICA2Mjc2ICAgMCB3YWl0ICAgICBETHMg ID8/ICAgMDowMC4wMSBbaW5pdF0KICAgIDAgICAgMiAgICAwICAgMCAtMTYgIDAgICAgIDAgICAw IGFpZnRoZCAgIERMICAgPz8gICAwOjAwLjAwIFthYWMwYWlmXQogICAgMCAgICAzICAgIDAgICAw IC0xNiAgMCAgICAgMCAgIDAgY3RsX3dvcmsgREwgICA/PyAgIDA6MDAuMDAgW2N0bF90aHJkXQog ICAgMCAgICA0ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgcGZ0bSAgICAgREwgICA/PyAgIDA6 MDAuMDMgW3BmcHVyZ2VdCiAgICAwICAgIDUgICAgMCAgIDAgLTE2ICAwICAgICAwICAgMCB3YWl0 aW5nXyBETCAgID8/ICAgMDowMC4wMCBbc2N0cF9pdGVyYXRvcl0KICAgIDAgICAgNiAgICAwICAg MCAtMTYgIDAgICAgIDAgICAwIGNjYl9zY2FuIERMICAgPz8gICAwOjAwLjAwIFt4cHRfdGhyZF0K ICAgIDAgICAgNyAgICAwICAgMCAtMTYgIDAgICAgIDAgICAwIHBzbGVlcCAgIERMICAgPz8gICAw OjAwLjAxIFtwYWdlZGFlbW9uXQogICAgMCAgICA4ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAg cHNsZWVwICAgREwgICA/PyAgIDA6MDAuMDAgW3ZtZGFlbW9uXQogICAgMCAgICA5ICAgIDAgICAw IDE1NSAgMCAgICAgMCAgIDAgcGd6ZXJvICAgREwgICA/PyAgIDA6MDAuMDAgW3BhZ2V6ZXJvXQog ICAgMCAgIDEwICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgYXVkaXRfd28gREwgICA/PyAgIDA6 MDAuMDAgW2F1ZGl0XQogICAgMCAgIDExICAgIDAgICAwIDE1NSAgMCAgICAgMCAgIDAgLSAgICAg ICAgUkwgICA/PyAgOTY6MzUuNTkgW2lkbGVdCiAgICAwICAgMTIgICAgMCAgIDAgLTg0ICAwICAg ICAwICAgMCAtICAgICAgICBXTCAgID8/ICAgMjo0NC42MSBbaW50cl0KICAgIDAgICAxMyAgICAw ICAgMCAgLTggIDAgICAgIDAgICAwIC0gICAgICAgIERMICAgPz8gICAwOjAwLjA4IFtnZW9tXQog ICAgMCAgIDE0ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgLSAgICAgICAgREwgICA/PyAgIDA6 MTAuMDIgW3lhcnJvd10KICAgIDAgICAxNSAgICAwICAgMCAtNjggIDAgICAgIDAgICAwIC0gICAg ICAgIERMICAgPz8gICAwOjAwLjEwIFt1c2JdCiAgICAwICAgMTYgICAgMCAgIDAgLTE2ICAwICAg ICAwICAgMCBwc2xlZXAgICBETCAgID8/ICAgMDowMC4wMiBbYnVmZGFlbW9uXQogICAgMCAgIDE3 ICAgIDAgICAwIC0xNiAgMCAgICAgMCAgIDAgdmxydXd0ICAgREwgICA/PyAgIDA6MDAuMDMgW3Zu bHJ1XQogICAgMCAgIDE4ICAgIDAgICAwICAxNiAgMCAgICAgMCAgIDAgc3luY2VyICAgREwgICA/ PyAgIDA6MDAuMDYgW3N5bmNlcl0KICAgIDAgICAxOSAgICAwICAgMCAtMTYgIDAgICAgIDAgICAw IHNkZmx1c2ggIERMICAgPz8gICAwOjAwLjA1IFtzb2Z0ZGVwZmx1c2hdCiAgICAwICAxNjAgICAg MSAgIDAgIDUyICAwICA5OTIwICAgMCBwYXVzZSAgICBEcyAgID8/ICAgMDowMC4wMCBbYWRqa2Vy bnR6XQogICAgMCAxNTgxICAgIDEgICAwICAyMCAgMCAxMjA1MiAgIDAgc2VsZWN0ICAgRHMgICA/ PyAgIDA6MDAuMDIgW3N5c2xvZ2RdCiAgIDUzIDE2NjcgICAgMSAgIDAgIDUyICAwIDQ3Mzg0ICAg MCBrcXJlYWQgICBEcyAgID8/ICAgMDowMC4wNSBbbmFtZWRdCiAgICAwIDE3MzQgICAgMSAgIDAg IDUyICAwIDQxNTQ0ICAgMCBzZWxlY3QgICBEcyAgID8/ICAgMDowMC4wMyBbbXBkNV0KICAgIDAg MTc0MCAgICAwICAgMCAtMTYgIDAgICAgIDAgICAwIHNsZWVwICAgIERMICAgPz8gICAwOjAwLjAw IFtuZ19xdWV1ZV0KICAgIDAgMTc0MSAgICAxICAgMCAgMjAgIDAgNDU1MjAgICAwIHNlbGVjdCAg IERzICAgPz8gICAwOjAwLjEwIFtzbm1wdHJhcGRdCiAgICAwIDE3NDUgICAgMSAgIDAgIDIwICAw IDQzNDM2ICAgMCBzZWxlY3QgICBEICAgID8/ICAgMDowMi42MiBbc25tcGRdCiAgICAwIDE3NzQg ICAgMSAgIDAgIDUyICAwIDE3NDUyICAgMCBrcXJlYWQgICBEcyAgID8/ICAgMDowMC4wMCBbbnNj ZF0KICAgIDAgMTc3NyAgICAxICAgMCAgMjAgIDAgMjIxOTYgICAwIHNlbGVjdCAgIERzICAgPz8g ICAwOjAwLjIxIFtudHBkXQogICAgMCAxNzgwICAgIDEgICAwICAyMCAgMCAxMjA1MiAgIDAgc2Vs ZWN0ICAgRHMgICA/PyAgIDA6MDAuNDkgW3Bvd2VyZF0KICAgIDAgMTgwNCAgICAxICAgMCAgMjAg IDAgMjI3MjggICAwIHNlbGVjdCAgIERzICAgPz8gICAwOjAwLjAzIFtvcGVudnBuXQogICAgMCAx ODE2ICAgIDEgICAwICA1MiAgMCAzMTU1MiAgIDAgcGF1c2UgICAgRHMgICA/PyAgIDA6MDAuMDAg W25naW54XQo2NTUzNCAxODE3IDE4MTYgICAwICAyMCAgMCAzMTU1MiAgIDAga3FyZWFkICAgRCAg ICA/PyAgIDA6MDAuMDIgW25naW54XQo2NTUzNCAxODE4IDE4MTYgICAwICAyMCAgMCAzMTU1MiAg IDAga3FyZWFkICAgRCAgICA/PyAgIDA6MDAuMjEgW25naW54XQo2NTUzNCAxODI0ICAgIDEgICAw ICAyMCAgMCAxNDMxMiAgIDAgc2VsZWN0ICAgRHMgICA/PyAgIDA6MDUuMTggW2RhcmtzdGF0XQo2 NTUzNCAxODI1IDE4MjQgICAwICA1MiAgMCAxNDMxMiAgIDAgc2J3YWl0ICAgRHMgICA/PyAgIDA6 MDAuMDAgW2RhcmtzdGF0XQogICAgMCAxODI4ICAgIDEgICAwICAyMCAgMCA1NDMyOCAgIDAgdXdh aXQgICAgRHMgICA/PyAgIDA6MDAuMDEgW2JhY3VsYS1mZF0KICAgIDAgMTgzOSAgICAxICAgMCAg MjAgIDAgMjAyNTIgICAwIHNlbGVjdCAgIERzICAgPz8gICAwOjAwLjA4IFtzZW5kbWFpbF0KICAg MjUgMTg0MiAgICAxICAgMCAgMjAgIDAgMjAyNTIgICAwIHBhdXNlICAgIERzICAgPz8gICAwOjAw LjAwIFtzZW5kbWFpbF0KICAgIDAgMTg0NiAgICAxICAgMCAgMjAgIDAgMTQxMjggICAwIG5hbnNs cCAgIERzICAgPz8gICAwOjAwLjAyIFtjcm9uXQogICAgMCAxODk5ICAgIDEgICAwICA1MiAgMCAx NjIxMiAgIDAgc2VsZWN0ICAgRHMgICA/PyAgIDA6MDAuMDAgW2luZXRkXQogICAgMCAxOTE2ICAg IDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5 XQogICAgMCAxOTE3ICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAg IDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTE4ICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5 aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTE5ICAgIDEgICAwICA1MiAg MCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTIw ICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dl dHR5XQogICAgMCAxOTIxICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/ PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTIyICAgIDEgICAwICA1MiAgMCAxMjA1MiAgIDAg dHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAxOTIzICAgIDEgICAwICA1 MiAgMCAxMjA1MiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDAgW2dldHR5XQogICAgMCAy MDExICAgIDEgICAwICAyMCAgMCA0Njc0NCAgIDAgc2VsZWN0ICAgRHMgICA/PyAgIDA6MDAuMDEg W3NzaGRdCiAgICAwIDIxMTMgICAgMSAgIDAgIDIwICAwIDEwMzc2ICAgMCBzZWxlY3QgICBEcyAg ID8/ICAgMDowMC4wMCBbZGV2ZF0KICAgIDAgMjE1NiAyMDExICAgMCAgMjAgIDAgNjc4ODQgICAw IHNlbGVjdCAgIERzICAgPz8gICAwOjAwLjAwIFtzc2hkXQogICAgMCAyMTU4IDIxNTYgICAwICAy MCAgMCAxNzUzMiAgIDAgdHR5aW4gICAgRHMrICA/PyAgIDA6MDAuMDEgW2NzaF0KCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQp2bXN0YXQgLXMKCiAyNTc5Mjg0MiBjcHUgY29udGV4dCBzd2l0Y2hlcwogMTAwNDU1 MjEgZGV2aWNlIGludGVycnVwdHMKICAzMjUwMjMwIHNvZnR3YXJlIGludGVycnVwdHMKICAgMTk4 OTUxIHRyYXBzCiAgIDU4MTM4MCBzeXN0ZW0gY2FsbHMKICAgICAgIDIwIGtlcm5lbCB0aHJlYWRz IGNyZWF0ZWQKICAgICAyMDk0ICBmb3JrKCkgY2FsbHMKICAgICAgIDUwIHZmb3JrKCkgY2FsbHMK ICAgICAgICAwIHJmb3JrKCkgY2FsbHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZWlucwogICAg ICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAgICAgIDAgc3dhcCBwYWdlciBwYWdl b3V0cwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBvdXQKICAgICAgODkyIHZub2Rl IHBhZ2VyIHBhZ2VpbnMKICAgICA3NjQxIHZub2RlIHBhZ2VyIHBhZ2VzIHBhZ2VkIGluCiAgICAg ICAgMCB2bm9kZSBwYWdlciBwYWdlb3V0cwogICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZXMgcGFn ZWQgb3V0CiAgICAgICAgMCBwYWdlIGRhZW1vbiB3YWtldXBzCiAgICAgICAgMCBwYWdlcyBleGFt aW5lZCBieSB0aGUgcGFnZSBkYWVtb24KICAgICAgNTM2IHBhZ2VzIHJlYWN0aXZhdGVkCiAgICA2 NTI1MiBjb3B5LW9uLXdyaXRlIGZhdWx0cwogICAgICAzOTYgY29weS1vbi13cml0ZSBvcHRpbWl6 ZWQgZmF1bHRzCiAgICA2ODM1NiB6ZXJvIGZpbGwgcGFnZXMgemVyb2VkCiAgICAgICAgMCB6ZXJv IGZpbGwgcGFnZXMgcHJlemVyb2VkCiAgICAgICAgMyBpbnRyYW5zaXQgYmxvY2tpbmcgcGFnZSBm YXVsdHMKICAgMjAyMTY2IHRvdGFsIFZNIGZhdWx0cyB0YWtlbgogICAgICAgIDAgcGFnZXMgYWZm ZWN0ZWQgYnkga2VybmVsIHRocmVhZCBjcmVhdGlvbgogIDEwNjE1MjIgcGFnZXMgYWZmZWN0ZWQg YnkgIGZvcmsoKQogICAgMjI3NTcgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAgICAgIDAg cGFnZXMgYWZmZWN0ZWQgYnkgcmZvcmsoKQogICAgICAgIDAgcGFnZXMgY2FjaGVkCiAgIDIwMDk3 NyBwYWdlcyBmcmVlZAogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgICAgICAgMCBw YWdlcyBmcmVlZCBieSBleGl0aW5nIHByb2Nlc3NlcwogICAgMTAwNDEgcGFnZXMgYWN0aXZlCiAg ICAgNjY0NCBwYWdlcyBpbmFjdGl2ZQogICAgICAgMTUgcGFnZXMgaW4gVk0gY2FjaGUKICAgIDQy MjI2IHBhZ2VzIHdpcmVkIGRvd24KICAgOTQ1NTg5IHBhZ2VzIGZyZWUKICAgICA0MDk2IGJ5dGVz IHBlciBwYWdlCiAgICA3ODU0NCB0b3RhbCBuYW1lIGxvb2t1cHMKICAgICAgICAgIGNhY2hlIGhp dHMgKDg4JSBwb3MgKyA1JSBuZWcpIHN5c3RlbSAwJSBwZXItZGlyZWN0b3J5CiAgICAgICAgICBk ZWxldGlvbnMgMCUsIGZhbHNlaGl0cyAwJSwgdG9vbG9uZyAwJQoKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZt c3RhdCAtbQoKICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6 ZShzKQpDQU0gZGV2IHF1ZXVlICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxMjgKICBt ZF9zaWlfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxMSAgNTEyCiAgICAgIENBTSBY UFQgICAgMzEgICAgMTRLICAgICAgIC0gICAgICAgNzQgIDMyLDY0LDEyOCwxMDI0LDIwNDgKICAg ICAgIGlzYWRldiAgICAgOSAgICAgMksgICAgICAgLSAgICAgICAgOSAgMTI4CiAgICAgICBhYWNi dWYgICAyNDEgICAgNzJLICAgICAgIC0gICAgICAyNDEgIDY0LDEyOAogICAgIGFjcGlpbnRyICAg ICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NAogICAgICAgICBjZGV2ICAgICA4ICAgICAy SyAgICAgICAtICAgICAgICA4ICAyNTYKICAgICAgIGFjcGljYSAgMTM3NCAgIDE0N0sgICAgICAg LSAgICAzNzI2NiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICBz aWdpbyAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgNjQKICAgICBmaWxlZGVzYyAgICA2 MSAgICA1NksgICAgICAgLSAgICAgMjE5MiAgMTYsMzIsNjQsMTI4LDUxMiwxMDI0LDIwNDgsNDA5 NgogICAgICAgICBrZW52ICAgIDczICAgIDExSyAgICAgICAtICAgICAgIDc5ICAxNiwzMiw2NCwx MjgKICAgICAgIGtxdWV1ZSAgICAgOCAgICAxNUsgICAgICAgLSAgICAgICA1OSAgMjU2LDUxMiwy MDQ4CiAgICBwcm9jLWFyZ3MgICAgMzMgICAgIDNLICAgICAgIC0gICAgIDE1NDUgIDE2LDMyLDY0 LDEyOCwyNTYKICAgICAgICBoaG9vayAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4 CiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKICAgICAg aXRocmVhZCAgICA3NSAgICAxM0sgICAgICAgLSAgICAgICA3NSAgMzIsMTI4LDI1NgogICAgQ0FN IHF1ZXVlICAgIDExICAgICAxSyAgICAgICAtICAgICAgIDM5ICAxNiwzMgogICAgICAgS1RSQUNF ICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgKICAgICAgIGxpbmtlciAgIDI4NyAg IDEyMksgICAgICAgLSAgICAgIDMzMSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQw OTYKICAgICAgICBsb2NrZiAgICAyOSAgICAgM0sgICAgICAgLSAgICAgICA3MyAgNjQsMTI4CiAg IGxvZ2luY2xhc3MgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgMjEgIDY0CiAgICAgICBpcDZu ZHAgICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTkgIDY0LDEyOAogICAgICAgICB0ZW1wIDEx ODQ2ICA0MDE5SyAgICAgICAtICAgMTkyMDk5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIw NDgsNDA5NgogICAgICAgZGV2YnVmIDI0MTAzIDY3NTY5SyAgICAgICAtICAgIDI0NDkxICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgbW9kdWxlICAgNDk2ICAgIDYy SyAgICAgICAtICAgICAgNDk2ICAxMjgKICAgICBtdHhfcG9vbCAgICAgMiAgICAxNksgICAgICAg LSAgICAgICAgMiAgCiAgICAgICBVU0JkZXYgICAgMjUgICAgIDRLICAgICAgIC0gICAgICAgMjUg IDY0LDEyOCw1MTIKICAgICAgICAgIFVTQiAgICAzOCAgIDEwOEsgICAgICAgLSAgICAgICAzOSAg MTYsMzIsNjQsMTI4LDI1NiwyMDQ4CiAgICAgcG1jaG9va3MgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDEyOAogICAgICBzdWJwcm9jICAgMTQyICAgMjU3SyAgICAgICAtICAgICAyMjU1 ICA1MTIsNDA5NgogICAgICAgICBwcm9jICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAK ICAgICAgc2Vzc2lvbiAgICAzMSAgICAgNEsgICAgICAgLSAgICAgICA1OCAgMTI4CiAgICAgICAg IHBncnAgICAgMzEgICAgIDRLICAgICAgIC0gICAgICAgOTEgIDEyOAogICAgICAgICBjcmVkICAg IDQ2ICAgICA4SyAgICAgICAtICAgICA5MzEyICA2NCwyNTYKICAgICAgdWlkaW5mbyAgICAgNSAg ICAgM0sgICAgICAgLSAgICAgICAyNiAgMTI4LDIwNDgKICAgICAgIHBsaW1pdCAgICAxNSAgICAg NEsgICAgICAgLSAgICAgIDM5NyAgMjU2CiAgICAgIGF0YV9wY2kgICAgIDEgICAgIDFLICAgICAg IC0gICAgICAgIDEgIDY0CiAgICAgIHNjc2lfY2QgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg MTAgIDE2CiAgICBzeXNjdGx0bXAgICAgIDAgICAgIDBLICAgICAgIC0gICAgICA0MTUgIDE2LDMy LDY0LDEyOCw0MDk2CiAgICBzeXNjdGxvaWQgIDQxNzEgICAyMTFLICAgICAgIC0gICAgIDQyNzUg IDE2LDMyLDY0LDEyOAogICAgICAgc3lzY3RsICAgICAwICAgICAwSyAgICAgICAtICAgICAyMjUx ICAxNiwzMiw2NAogICAgICB0aWRoYXNoICAgICAxICAgIDE2SyAgICAgICAtICAgICAgICAxICAK ICAgICAgY2FsbG91dCAgICAgMyAgMTUzNksgICAgICAgLSAgICAgICAgMyAgCiAgICAgICAgIHVt dHggICAzOTAgICAgNDlLICAgICAgIC0gICAgICAzOTAgIDEyOAogICAgIHAxMDAzLjFiICAgICAx ICAgICAxSyAgICAgICAtICAgICAgICAxICAxNgogICAgICAgICBTV0FQICAgICAyICAgNTQ5SyAg ICAgICAtICAgICAgICAyICA2NAogICAgICAgYnVzLXNjICAgIDkzICAgNjMxSyAgICAgICAtICAg ICA0NjU3ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgICAgYnVz ICAxMjQ0ICAgMTA0SyAgICAgICAtICAgICA3MjQ4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0 CiAgICAgIGRldnN0YXQgICAgIDYgICAgMTNLICAgICAgIC0gICAgICAgIDYgIDMyLDQwOTYKIGV2 ZW50aGFuZGxlciAgICA5NCAgICAgOEsgICAgICAgLSAgICAgICA5NCAgNjQsMTI4CiAgICAgIGFj cGlzZW0gICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTYgIDEyOAogICAgICAgICBrb2JqICAg MzI5ICAxMzE2SyAgICAgICAtICAgICAgNDg3ICA0MDk2CiAgICAgIENBTSBTSU0gICAgIDMgICAg IDFLICAgICAgIC0gICAgICAgIDMgIDI1NgogICAgICBQZXItY3B1ICAgICAxICAgICAxSyAgICAg ICAtICAgICAgICAxICAzMgogICBDQU0gcGVyaXBoICAgICA0ICAgICAxSyAgICAgICAtICAgICAg IDE4ICAxNiwzMiw2NCwxMjgsMjU2CiAgICAgICAgIHJtYW4gICAyMDggICAgMjJLICAgICAgIC0g ICAgICA1NjYgIDE2LDMyLDEyOAogICAgICAgICBzYnVmICAgICAwICAgICAwSyAgICAgICAtICAg ICAgNjk4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICBlbnRyb3B5 ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAogICAgICAgY3RsbWVtICA1MDYyIDEw MTEzSyAgICAgICAtICAgICA1MDYyICAxMjgsMjA0OAogICAgICAgIHN0YWNrICAgICAwICAgICAw SyAgICAgICAtICAgICAgICAyICAyNTYKICAgIHRhc2txdWV1ZSAgICAxOSAgICAgMksgICAgICAg LSAgICAgICAxOSAgMTYsMzIsMTI4CiAgICAgICBVbml0bm8gICAgMTUgICAgIDFLICAgICAgIC0g ICAgICA1MzMgIDMyLDY0CiAgICAgICAgICBpb3YgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDEy NTAgIDE2LDY0LDEyOCwyNTYsNTEyCiAgICAgICBzZWxlY3QgICAgMzIgICAgIDRLICAgICAgIC0g ICAgICAgMzIgIDEyOAogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICAgIDI3MTk4 ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBtc2cgICAgIDQgICAgMzBLICAg ICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2VtICAgICA0ICAgMTA2SyAgICAg ICAtICAgICAgICA0ICAyMDQ4LDQwOTYKICAgICAgICAgIHNobSAgICAgMSAgICAyMEsgICAgICAg LSAgICAgICAgMSAgCiAgICAgICAgICB0dHkgICAgMjAgICAgMjBLICAgICAgIC0gICAgICAgMjYg IDEwMjQsMjA0OAogICAgICAgICAgcHRzICAgICAxICAgICAxSyAgICAgICAtICAgICAgICA1ICAy NTYKICAgICAgICAgYWNjZiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgNjQKICAgICBt YnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgMzA5MSAgMzIKICAgICAgICBzaG1mZCAg ICAgMSAgICAgOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgICAgICBwY2IgICAgMzYgICAxNThL ICAgICAgIC0gICAgICAxMzggIDE2LDMyLDY0LDEyOCwxMDI0LDIwNDgsNDA5NgogICAgICAgc29u YW1lICAgICA2ICAgICAxSyAgICAgICAtICAgICAxNjU4ICAxNiwzMiwxMjgKICAgICB2ZnNjYWNo ZSAgICAgMSAgMjA0OEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgdmZzX2hhc2ggICAgIDEgIDEw MjRLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgREVWRlMxICAgMTAwICAgIDUwSyAgICAgICAt ICAgICAgMTExICA1MTIKICAgICAgIHZub2RlcyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAg NCAgNjQsMjU2CiAgICAgICBERVZGUzMgICAyMzMgICAgNTlLICAgICAgIC0gICAgICAyNTQgIDI1 NgogICAgICAgIG1vdW50ICAgIDI5ICAgICAySyAgICAgICAtICAgICAgMTMyICAxNiwzMiw2NCwx MjgsMjU2CiAgdm5vZGVtYXJrZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAzMTYgIDUxMgog ICAgICAgICAgQlBGICAgIDE3ICAxMDI3SyAgICAgICAtICAgICAgIDIxICAxNiwxMjgsNTEyCiAg ZXRoZXJfbXVsdGkgICAgNzMgICAgIDRLICAgICAgIC0gICAgICAgODQgIDE2LDMyLDY0CiAgICAg ICBpZmFkZHIgICAxMzQgICAgMzRLICAgICAgIC0gICAgICAxMzQgIDMyLDY0LDEyOCwyNTYsNTEy LDIwNDgsNDA5NgogICAgICAgIGlmbmV0ICAgIDEzICAgIDI1SyAgICAgICAtICAgICAgIDEzICAx MjgsMjA0OAogICAgICAgREVWRlMyICAgIDk4ICAgICAySyAgICAgICAtICAgICAgIDk4ICAxNgog ICAgICAgIGNsb25lICAgICA3ICAgIDI4SyAgICAgICAtICAgICAgICA3ICA0MDk2CiAgICAgICBh cnBjb20gICAgIDYgICAgIDFLICAgICAgIC0gICAgICAgIDYgIDE2CiAgICAgIGxsdGFibGUgICAg NzUgICAgMjVLICAgICAgIC0gICAgICAgODAgIDI1Niw1MTIKICAgICAgICAgIHR1biAgICAgMSAg ICAgMUsgICAgICAgLSAgICAgICAgMSAgMjU2CiAgICAgICAgIHZsYW4gICAgIDUgICAgIDFLICAg ICAgIC0gICAgICAgIDUgIDY0LDEyOAogICBERVZGU19SVUxFICAgIDU1ICAgIDI2SyAgICAgICAt ICAgICAgIDU1ICA2NCw1MTIKICAgICAgICBERVZGUyAgICAzNCAgICAgMUsgICAgICAgLSAgICAg ICAzNyAgMTYsMTI4CiAgICAgICBERVZGU1AgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDIg IDY0CiAgICAgcm91dGV0YmwgICAgNjEgICAgIDhLICAgICAgIC0gICAgMTUxOTQgIDMyLDY0LDEy OCwyNTYsNTEyCiAgICAgICAgIGlnbXAgICAgMTIgICAgIDNLICAgICAgIC0gICAgICAgMTIgIDI1 NgogICAgIGluX211bHRpICAgICA1ICAgICAySyAgICAgICAtICAgICAgICA1ICAyNTYKICAgIHNj dHBfaXRlciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNyAgMjU2CiAgICAgc2N0cF9pZm4g ICAgIDUgICAgIDFLICAgICAgIC0gICAgICAgIDUgIDEyOAogICAgIHNjdHBfaWZhICAgICA5ICAg ICAySyAgICAgICAtICAgICAgICA5ICAxMjgKICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgICAgMSAgNjQKICAgIHNjdHBfYV9pdCAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICAgNyAgMTYKICAgIGhvc3RjYWNoZSAgICAgMSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAg ICAgc3luY2FjaGUgICAgIDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIAogICAgaW42X211bHRp ICAgIDM2ICAgICA1SyAgICAgICAtICAgICAgIDM2ICAzMiwyNTYKICAgICAgICAgIG1sZCAgICAx MiAgICAgMksgICAgICAgLSAgICAgICAxMiAgMTI4CiAgICAgICAgICBycGMgICAgIDIgICAgIDFL ICAgICAgIC0gICAgICAgIDIgIDI1NgphdWRpdF9ldmNsYXNzICAgMTc5ICAgICA2SyAgICAgICAt ICAgICAgMjE4ICAzMgogICAgICBqYmxvY2tzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAy ICAxMjgsMjU2CiAgICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMzggIDI1 NgogICAgICAgIHNiZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDM4ICA2NAogICAgICBq c2VnZGVwICAgICAwICAgICAwSyAgICAgICAtICAgICAgNDYxICA2NAogICAgICAgICBqc2VnICAg ICAwICAgICAwSyAgICAgICAtICAgICAgIDU2ICAxMjgKICAgIGpmcmVlZnJhZyAgICAgMCAgICAg MEsgICAgICAgLSAgICAgICAgNSAgMTI4CiAgICAgIGpuZXdibGsgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAxNTYgIDEyOAogICAgICBqcmVtcmVmICAgICAwICAgICAwSyAgICAgICAtICAgICAg MTQwICAxMjgKICAgICAgamFkZHJlZiAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDE2MCAgMTI4 CiAgICAgZnJlZXdvcmsgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAxMjEgIDY0LDEyOAogICAg bmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA3ICA2NAogICAgICAgZGlycmVt ICAgICAwICAgICAwSyAgICAgICAtICAgICAgMTM2ICAxMjgKICAgICAgICBta2RpciAgICAgMCAg ICAgMEsgICAgICAgLSAgICAgICAxNCAgMTI4CiAgICAgICBkaXJhZGQgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICAxNDYgIDEyOAogICAgIGZyZWVmaWxlICAgICAwICAgICAwSyAgICAgICAtICAg ICAgIDkxICA2NAogICAgIGZyZWVibGtzICAgICAwICAgICAwSyAgICAgICAtICAgICAgMTE3ICAx MjgKICAgICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNSAgMTI4CiAgICAg ICBuZXdibGsgICAgIDEgICAxMjhLICAgICAgIC0gICAgICAxNTcgIDI1NgogICAgYm1zYWZlbWFw ICAgICAxICAgICA4SyAgICAgICAtICAgICAgMTMxICAyNTYKICAgICBpbm9kZWRlcCAgICAgMiAg MTAyNUsgICAgICAgLSAgICAgIDI1MiAgNTEyCiAgICAgIHBhZ2VkZXAgICAgIDEgICAxMjhLICAg ICAgIC0gICAgICAgMzYgIDI1NgogIHVmc19kaXJoYXNoICAgIDM5ICAgICA4SyAgICAgICAtICAg ICAgIDM5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgdWZzX21vdW50ICAgICAzICAgIDM3SyAg ICAgICAtICAgICAgICA0ICA1MTIsNDA5NgogICAgdm1fcGdkYXRhICAgICAyICAgMTI5SyAgICAg ICAtICAgICAgICAyICAxMjgKICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAg ICAgMSAgNDA5NgogICAgIGF0a2JkZGV2ICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICA2 NAogICAgcGZzX25vZGVzICAgIDIxICAgICA2SyAgICAgICAtICAgICAgIDIxICAyNTYKICAgICAg IGN0bGJsayAgIDIwMCAgMTYwMEsgICAgICAgLSAgICAgIDIwMCAgCiAgICAgICAgIEdFT00gICAg NTEgICAgMTFLICAgICAgIC0gICAgICA0NzkgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OAogICAgICByYW1kaXNrICAgICAxICA0MDk2SyAgICAgICAtICAgICAgICAxICAKICAgICAgYWNw aWRldiAgICAyOCAgICAgMksgICAgICAgLSAgICAgICAyOCAgNjQKICAgICAgY3RscG9vbCAgIDUz MiAgIDE0MksgICAgICAgLSAgICAgIDUzMiAgMzIsNTEyCiAgICAgICBrYmRtdXggICAgIDcgICAg MThLICAgICAgIC0gICAgICAgIDcgIDE2LDUxMiwxMDI0LDIwNDgKICAgICAgIGFwbWRldiAgICAg MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4CiAgIG1hZHRfdGFibGUgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAgIDEgIDQwOTYKICAgICAgIGZlZWRlciAgICAgNyAgICAgMUsgICAgICAg LSAgICAgICAgNyAgMzIKICAgICBwY2lfbGluayAgICAxMyAgICAgMksgICAgICAgLSAgICAgICAx MyAgMTYsMTI4CiAgICByYWlkX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNzIgIDMy LDEyOCwyNTYKICAgICAgaW9fYXBpYyAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0 OAogICAgICAgICAgTUNBICAgICA2ICAgICAxSyAgICAgICAtICAgICAgICA2ICAxMjgKICAgICAg ICAgIG1zaSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgbmV4dXNkZXYg ICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2Cm1kX252aWRpYV9kYXRhICAgICAwICAg ICAwSyAgICAgICAtICAgICAgIDExICA1MTIKICBJcEZ3L0lwQWNjdCAgICAgOSAgICAgM0sgICAg ICAgLSAgICAgICAxMyAgMTYsMzIsNjQsMTI4LDEwMjQKICAgICBpcGZ3X3RibCAgICAxNCAgICAg NEsgICAgICAgLSAgICAgICAxNCAgMjU2CiAgICAgICAgIENBUlAgICAgIDQgICAgIDJLICAgICAg IC0gICAgICAgIDQgIDY0LDI1NiwxMDI0CiAgICAgZHVtbXluZXQgICAgIDMgICAgIDNLICAgICAg IC0gICAgICAgIDMgIDUxMiwxMDI0CiAgICAgICBjcHVjdGwgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAgIDEgIDMyCiBuZXRncmFwaF9tc2cgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDUg IDY0LDEyOCwyNTYKbmV0Z3JhcGhfbm9kZSAgICAgNSAgICAgMUsgICAgICAgLSAgICAgICAgNyAg MTI4LDI1NgpuZXRncmFwaF9ob29rICAgICAwICAgICAwSyAgICAgICAtICAgICAgICAyICAxMjgK bmV0Z3JhcGhfc29jayAgICAgNiAgICAgMUsgICAgICAgLSAgICAgICAgOSAgMzIsMTI4Cm5ldGdy YXBoX3BhdGggICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDE2Cm5ldGdyYXBoX21wcGMg ICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDEwMjQKCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0 YXQgLXoKCklURU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZS RUUgICAgICBSRVEgRkFJTCBTTEVFUAoKVU1BIEtlZ3M6ICAgICAgICAgICAgICAgMjA4LCAgICAg IDAsICAgICAxMTIsICAgICAgIDcsICAgICAxMTIsICAgMCwgICAwClVNQSBab25lczogICAgICAg ICAgICAgIDg5NiwgICAgICAwLCAgICAgMTEyLCAgICAgICAwLCAgICAgMTEyLCAgIDAsICAgMApV TUEgU2xhYnM6ICAgICAgICAgICAgICA1NjgsICAgICAgMCwgICAgMzk5NSwgICAgICAgMiwgICAg NTc4NCwgICAwLCAgIDAKVU1BIFJDbnRTbGFiczogICAgICAgICAgNTY4LCAgICAgIDAsICAgIDI1 MDAsICAgICAgIDYsICAgIDI1MDAsICAgMCwgICAwClVNQSBIYXNoOiAgICAgICAgICAgICAgIDI1 NiwgICAgICAwLCAgICAgICAzLCAgICAgIDEyLCAgICAgICAzLCAgIDAsICAgMAoxNiBCdWNrZXQ6 ICAgICAgICAgICAgICAxNTIsICAgICAgMCwgICAgIDExOCwgICAgICAgNywgICAgIDExOCwgICAw LCAgIDAKMzIgQnVja2V0OiAgICAgICAgICAgICAgMjgwLCAgICAgIDAsICAgICAxMDEsICAgICAg MTEsICAgICAxMDEsICAgMSwgICAwCjY0IEJ1Y2tldDogICAgICAgICAgICAgIDUzNiwgICAgICAw LCAgICAgIDgyLCAgICAgICAyLCAgICAgIDgyLCAgNTcsICAgMAoxMjggQnVja2V0OiAgICAgICAg ICAgIDEwNDgsICAgICAgMCwgICAgIDE2NywgICAgICAgMSwgICAgIDE2NywgNjI3LCAgIDAKVk0g T0JKRUNUOiAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgIDE1MzQsICAgICAzODYsICAgMjg3 MDEsICAgMCwgICAwCk1BUDogICAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICA3 LCAgICAgIDI1LCAgICAgICA3LCAgIDAsICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAgICAxMjAs IDE1MDI1NywgICAgICA0NywgICAgIDQ4MCwgICAxNTkxNCwgICAwLCAgIDAKTUFQIEVOVFJZOiAg ICAgICAgICAgICAgMTIwLCAgICAgIDAsICAgIDEwMzIsICAgICA3MDQsICAgODEwNzcsICAgMCwg ICAwCmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMAptdF96b25lOiAgICAgICAgICAgICAgIDQxMTIsICAgICAgMCwg ICAgIDM0MiwgICAgICAgMSwgICAgIDM0MiwgICAwLCAgIDAKMTY6ICAgICAgICAgICAgICAgICAg ICAgIDE2LCAgICAgIDAsICAgIDIwNTksICAgICA0NjEsICAgMzE5ODEsICAgMCwgICAwCjMyOiAg ICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICAyNDg5LCAgICAgNjQyLCAgIDIwODEw LCAgIDAsICAgMAo2NDogICAgICAgICAgICAgICAgICAgICAgNjQsICAgICAgMCwgICAxNzM4Nywg ICAgIDgxMywgICA3NzY2NywgICAwLCAgIDAKMTI4OiAgICAgICAgICAgICAgICAgICAgMTI4LCAg ICAgIDAsICAgIDY1MjcsICAgICA0MDQsICAgODE0MDgsICAgMCwgICAwCjI1NjogICAgICAgICAg ICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgNjY3LCAgICAgMTI4LCAgIDIyMjcwLCAgIDAsICAg MAo1MTI6ICAgICAgICAgICAgICAgICAgICA1MTIsICAgICAgMCwgICAgNzY0MCwgICAgMTMzNCwg ICA0Mzg1OCwgICAwLCAgIDAKMTAyNDogICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAg ICAgNDMsICAgICAxOTMsICAgMTE3NTIsICAgMCwgICAwCjIwNDg6ICAgICAgICAgICAgICAgICAg MjA0OCwgICAgICAwLCAgICA1MTA3LCAgICAgNDAzLCAgIDQxMTYxLCAgIDAsICAgMAo0MDk2OiAg ICAgICAgICAgICAgICAgIDQwOTYsICAgICAgMCwgICAgIDQyMSwgICAgICA4NSwgICAgODcyNSwg ICAwLCAgIDAKRmlsZXM6ICAgICAgICAgICAgICAgICAgIDgwLCAgICAgIDAsICAgICAxNDQsICAg ICAyMTYsICAgMjM5MzksICAgMCwgICAwClRVUk5TVElMRTogICAgICAgICAgICAgIDEzNiwgICAg ICAwLCAgICAgMTk2LCAgICAgIDY0LCAgICAgMTk2LCAgIDAsICAgMAp1bXR4IHBpOiAgICAgICAg ICAgICAgICAgOTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK TUFDIGxhYmVsczogICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwClBST0M6ICAgICAgICAgICAgICAgICAgMTE4NCwgICAgICAwLCAgICAg IDUyLCAgICAgIDM1LCAgICAyMTY0LCAgIDAsICAgMApUSFJFQUQ6ICAgICAgICAgICAgICAgIDEx MjgsICAgICAgMCwgICAgIDE1MCwgICAgICA0NSwgICAgIDE1MSwgICAwLCAgIDAKU0xFRVBRVUVV RTogICAgICAgICAgICAgIDgwLCAgICAgIDAsICAgICAxOTYsICAgICAgMzYsICAgICAxOTYsICAg MCwgICAwClZNU1BBQ0U6ICAgICAgICAgICAgICAgIDM5MiwgICAgICAwLCAgICAgIDMzLCAgICAg IDg3LCAgICAyMTQ2LCAgIDAsICAgMApjcHVzZXQ6ICAgICAgICAgICAgICAgICAgNzIsICAgICAg MCwgICAgICA3MCwgICAgICA4MCwgICAgICA3MCwgICAwLCAgIDAKYXVkaXRfcmVjb3JkOiAgICAg ICAgICAgOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1i dWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICA0MDgyLCAgICAgNzkzLCAyNjE3 NTk1LCAgIDAsICAgMAptYnVmOiAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgMTAy NSwgICAgIDkwNiwgOTMxNTkzMywgICAwLCAgIDAKbWJ1Zl9jbHVzdGVyOiAgICAgICAgICAyMDQ4 LCAgNjU1MzYsICAgIDQ4NjQsICAgICAgIDYsICAgIDQ4NjQsICAgMCwgICAwCm1idWZfanVtYm9f cGFnZTogICAgICAgNDA5NiwgIDEyODAwLCAgICAgICAwLCAgICAgIDY1LCAgICAgMTcwLCAgIDAs ICAgMAptYnVmX2p1bWJvXzlrOiAgICAgICAgIDkyMTYsICAxOTIwMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKbWJ1Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAgMTI4MDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1idWZfZXh0X3JlZmNudDogICAg ICAgICAgNCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApnX2Jp bzogICAgICAgICAgICAgICAgICAyMzIsICAgICAgMCwgICAgICAgMCwgICAgIDI3MiwgICAgOTc0 NiwgICAwLCAgIDAKdHR5aW5xOiAgICAgICAgICAgICAgICAgMTYwLCAgICAgIDAsICAgICAxODAs ICAgICAyNTIsICAgICA1NTUsICAgMCwgICAwCnR0eW91dHE6ICAgICAgICAgICAgICAgIDI1Niwg ICAgICAwLCAgICAgIDk1LCAgICAgMTMwLCAgICAgMjkxLCAgIDAsICAgMAphdGFfcmVxdWVzdDog ICAgICAgICAgICAzMjgsICAgICAgMCwgICAgICAgMCwgICAgICAzNiwgICAgICAzMiwgICAwLCAg IDAKYXRhX2NvbXBvc2l0ZTogICAgICAgICAgMzM2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwClZOT0RFOiAgICAgICAgICAgICAgICAgIDQ4MCwgICAgICAwLCAg ICAzNjIwLCAgICAgIDM2LCAgICAzNzIyLCAgIDAsICAgMApWTk9ERVBPTEw6ICAgICAgICAgICAg ICAxMTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTkFNRUk6 ICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAsICAgICAgNDgsICAgMzMwNjIs ICAgMCwgICAwClMgVkZTIENhY2hlOiAgICAgICAgICAgIDEwOCwgICAgICAwLCAgICAzNjc1LCAg ICAgIDg3LCAgICA0ODI1LCAgIDAsICAgMApTVFMgVkZTIENhY2hlOiAgICAgICAgICAxNDgsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTCBWRlMgQ2FjaGU6ICAg ICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw CkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMApESVJIQVNIOiAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAg ICA2NywgICAgICAyOSwgICAgICA2NywgICAwLCAgIDAKTkNMTk9ERTogICAgICAgICAgICAgICAg NTY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBpcGU6ICAg ICAgICAgICAgICAgICAgIDcyOCwgICAgICAwLCAgICAgICA5LCAgICAgIDU2LCAgICAxNDI5LCAg IDAsICAgMApNb3VudHBvaW50czogICAgICAgICAgICA3OTIsICAgICAgMCwgICAgICAgMywgICAg ICAxMiwgICAgICAgMywgICAwLCAgIDAKQUlPOiAgICAgICAgICAgICAgICAgICAgMjA4LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkFJT1A6ICAgICAgICAgICAg ICAgICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApB SU9DQjogICAgICAgICAgICAgICAgICA0ODAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKQUlPTDogICAgICAgICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkFJT0xJTzogICAgICAgICAgICAgICAgIDI3 MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAprc2lnaW5mbzog ICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgICA3NiwgICAgIDk4MCwgICAgIDI3NiwgICAw LCAgIDAKaXRpbWVyOiAgICAgICAgICAgICAgICAgMzQ0LCAgICAgIDAsICAgICAgIDEsICAgICAg MzIsICAgICAgIDIsICAgMCwgICAwCnBmc3JjdHJwbDogICAgICAgICAgICAgIDE1MiwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZnJ1bGVwbDogICAgICAgICAg ICAgICA5MzYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZz dGF0ZXBsOiAgICAgICAgICAgICAgMjg4LCAgMTAwMTAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCnBmc3RhdGVrZXlwbDogICAgICAgICAgIDI4OCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZnN0YXRlaXRlbXBsOiAgICAgICAgICAyODgs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZhbHRxcGw6ICAg ICAgICAgICAgICAgMjQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnBmcG9vbGFkZHJwbDogICAgICAgICAgICA4OCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMApwZnJrdGFibGU6ICAgICAgICAgICAgIDEyOTYsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZya2VudHJ5OiAgICAgICAgICAg ICAgMTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmcmtj b3VudGVyczogICAgICAgICAgICA2NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApwZmZyZW50OiAgICAgICAgICAgICAgICAgMzIsICAgNTA1MCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZmcmFnOiAgICAgICAgICAgICAgICAgIDgwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmZnJjYWNoZTogICAg ICAgICAgICAgICA4MCwgIDEwMDM1LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MApwZmZyY2VudDogICAgICAgICAgICAgICAgMjQsICA1MDAyMiwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKcGZzdGF0ZXNjcnViOiAgICAgICAgICAgIDQwLCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmaWFkZHJwbDogICAgICAgICAgICAg IDEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZm9zcGZl bjogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKcGZvc2ZwOiAgICAgICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCktOT1RFOiAgICAgICAgICAgICAgICAgIDEyOCwgICAg ICAwLCAgICAgIDIxLCAgICAgMTI0LCAgICA2NTYzLCAgIDAsICAgMApzb2NrZXQ6ICAgICAgICAg ICAgICAgICA2ODAsIDIwNDgwNCwgICAgICA1NywgICAgICA3NSwgICAxMzc3NiwgICAwLCAgIDAK aXBxOiAgICAgICAgICAgICAgICAgICAgIDU2LCAgIDIwNzksICAgICAgIDEsICAgICAxMjUsICAg ICAgIDIsICAgMCwgICAwCnVkcF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgMjA0ODAwLCAgICAg IDE1LCAgICAgIDg1LCAgIDEzMzA0LCAgIDAsICAgMAp1ZHBjYjogICAgICAgICAgICAgICAgICAg MTYsIDIwNDk2MCwgICAgICAxNSwgICAgIDY1NywgICAxMzMwNCwgICAwLCAgIDAKdGNwX2lucGNi OiAgICAgICAgICAgICAgMzkyLCAyMDQ4MDAsICAgICAgMTUsICAgICAgNTUsICAgICAgNzIsICAg MCwgICAwCnRjcGNiOiAgICAgICAgICAgICAgICAgIDk3NiwgMjA0ODAwLCAgICAgIDE1LCAgICAg IDMzLCAgICAgIDcyLCAgIDAsICAgMAp0Y3B0dzogICAgICAgICAgICAgICAgICAgNzIsICA0MTAw MCwgICAgICAgMCwgICAgIDEwMCwgICAgICAzNCwgICAwLCAgIDAKc3luY2FjaGU6ICAgICAgICAg ICAgICAgMTUyLCAgMTUzNzUsICAgICAgIDAsICAgICAgNzUsICAgICAgMzgsICAgMCwgICAwCmhv c3RjYWNoZTogICAgICAgICAgICAgIDEzNiwgIDE1MzcyLCAgICAgICAxLCAgICAgIDU1LCAgICAg ICAxLCAgIDAsICAgMAp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAsICAgNDExNiwgICAgICAg MCwgICAgIDE2OCwgICAgICAgOCwgICAwLCAgIDAKc2Fja2hvbGU6ICAgICAgICAgICAgICAgIDMy LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfZXA6ICAg ICAgICAgICAgICAgMTM3NiwgIDI1NjAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMApzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0MDAwMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9sYWRkcjogICAgICAgICAgICAgIDQ4LCAgODAwNjQs ICAgICAgIDAsICAgICAzNjAsICAgICAgIDgsICAgMCwgICAwCnNjdHBfcmFkZHI6ICAgICAgICAg ICAgIDcwNCwgIDgwMDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3Rw X2NodW5rOiAgICAgICAgICAgICAxMzYsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKc2N0cF9yZWFkcTogICAgICAgICAgICAgMTA0LCA0MDAwMzIsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfc3RyZWFtX21zZ19vdXQ6ICAgIDExMiwg NDAwMDI2LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX2FzY29uZjog ICAgICAgICAgICAgNDAsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKc2N0cF9hc2NvbmZfYWNrOiAgICAgICAgIDQ4LCA0MDAwMzIsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnJpcGNiOiAgICAgICAgICAgICAgICAgIDM5MiwgMjA0ODAwLCAg ICAgICAwLCAgICAgIDQwLCAgICAgIDE5LCAgIDAsICAgMAp1bnBjYjogICAgICAgICAgICAgICAg ICAyNDAsIDIwNDgwMCwgICAgICAyMCwgICAgICA2MCwgICAgIDM1NSwgICAwLCAgIDAKcnRlbnRy eTogICAgICAgICAgICAgICAgMjAwLCAgICAgIDAsICAgICAgMzQsICAgICAgNjEsICAgICAgNDAs ICAgMCwgICAwCklQRlcgZHluYW1pYyBydWxlOiAgICAgIDEyMCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgNTYsICAg ICAgMCwgICAgICA4NSwgICAgIDU0NSwgIDEwMjQ5OCwgICAwLCAgIDAKU1dBUE1FVEE6ICAgICAg ICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw CkZGUyBpbm9kZTogICAgICAgICAgICAgIDE2OCwgICAgICAwLCAgICAzNTIyLCAgICAgMTMwLCAg ICAzNjE1LCAgIDAsICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAgICAg MjU2LCAgICAgIDAsICAgIDM1MjIsICAgICAxNTMsICAgIDM2MTUsICAgMCwgICAwCk5ldEdyYXBo IGl0ZW1zOiAgICAgICAgICA3MiwgICA0MTE4LCAgICAgICAwLCAgICAgIDU4LCAgICAgICA3LCAg IDAsICAgMApOZXRHcmFwaCBkYXRhIGl0ZW1zOiAgICAgNzIsICAgIDUyMiwgICAgICAgMCwgICAg ICA1OCwgICAgICAgNCwgICAwLCAgIDAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1pCgppbnRl cnJ1cHQgICAgICAgICAgICAgICAgICAgICAgICAgIHRvdGFsICAgICAgIHJhdGUKaXJxMTQ6IGF0 YTAgICAgICAgICAgICAgICAgICAgICAgICAgICA0MyAgICAgICAgICAxCmlycTE3OiBhYWMwICAg ICAgICAgICAgICAgICAgICAgICAgIDI5MjUgICAgICAgICA5NAppcnEyMDogaHBldDAgICAgICAg ICAgICAgICAgICAgICAzNzExNjY3ICAgICAxMTk3MzEKaXJxMjI6IHVoY2kxICAgICAgICAgICAg ICAgICAgICAgICAgICAyMiAgICAgICAgICAwCmlycTIzOiB1aGNpMCB1aGNpMisgICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgMAppcnEyNTY6IGJjZTAgICAgICAgICAgICAgICAgICAgICAz MTU3ODMzICAgICAxMDE4NjUKaXJxMjU3OiBiY2UxICAgICAgICAgICAgICAgICAgICAgMzE3MzAy OSAgICAgMTAyMzU1ClRvdGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgMTAwNDU1MjEgICAg IDMyNDA0OQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzdGF0IC1UCgoxNDQvMjA0ODAwIGZpbGVzCjBNLzQw OTVNIHN3YXAgc3BhY2UKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtcwoKRGV2aWNlICAgICAgICAg IDUxMi1ibG9ja3MgICAgIFVzZWQgICAgQXZhaWwgQ2FwYWNpdHkKL2Rldi9hYWNkMHAzICAgICAg IDgzODgzNTIgICAgICAgIDAgIDgzODgzNTIgICAgIDAlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaW9zdGF0 Cgppb3N0YXQ6IGt2bV9yZWFkKF90a19uaW4pOiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0 OiBkaXNhYmxpbmcgVFRZIHN0YXRpc3RpY3MKICAgICAgICAgICBhYWNkMCAgICAgICAgICAgICAg Y2QwICAgICAgICAgICAgcGFzczAgICAgICAgICAgICAgY3B1CiAgS0IvdCB0cHMgIE1CL3MgICBL Qi90IHRwcyAgTUIvcyAgIEtCL3QgdHBzICBNQi9zICB1cyBuaSBzeSBpbiBpZAogMzEuMTYgIDk4 ICAyLjk3ICAgMC4wMCAgIDEgIDAuMDAgICAwLjAwICAgMCAgMC4wMCAgIDAgIDAgIDAgIDMgOTYK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQppcGNzIC1hCgpNZXNzYWdlIFF1ZXVlczoKVCAgICAgICAgICAgSUQg ICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdST1VQICAgIENSRUFUT1IgIENHUk9V UCAgICAgICAgICAgICAgICAgQ0JZVEVTICAgICAgICAgICAgICAgICBRTlVNICAgICAgICAgICAg ICAgUUJZVEVTICAgICAgICBMU1BJRCAgICAgICAgTFJQSUQgU1RJTUUgICAgUlRJTUUgICAgQ1RJ TUUgICAKClNoYXJlZCBNZW1vcnk6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAg ICAgICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICBOQVRUQ0ggICAg ICAgIFNFR1NaICAgICAgICAgQ1BJRCAgICAgICAgIExQSUQgQVRJTUUgICAgRFRJTUUgICAgQ1RJ TUUgICAKClNlbWFwaG9yZXM6ClQgICAgICAgICAgIElEICAgICAgICAgIEtFWSBNT0RFICAgICAg ICBPV05FUiAgICBHUk9VUCAgICBDUkVBVE9SICBDR1JPVVAgICAgICAgICAgTlNFTVMgT1RJTUUg ICAgQ1RJTUUgICAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KaXBjcyAtVAoKbXNnaW5mbzoKCW1zZ21heDog ICAgICAgIDE2Mzg0CShtYXggY2hhcmFjdGVycyBpbiBhIG1lc3NhZ2UpCgltc2dtbmk6ICAgICAg ICAgICA0MAkoIyBvZiBtZXNzYWdlIHF1ZXVlcykKCW1zZ21uYjogICAgICAgICAyMDQ4CShtYXgg Y2hhcmFjdGVycyBpbiBhIG1lc3NhZ2UgcXVldWUpCgltc2d0cWw6ICAgICAgICAgICA0MAkobWF4 ICMgb2YgbWVzc2FnZXMgaW4gc3lzdGVtKQoJbXNnc3N6OiAgICAgICAgICAgIDgJKHNpemUgb2Yg YSBtZXNzYWdlIHNlZ21lbnQpCgltc2dzZWc6ICAgICAgICAgMjA0OAkoIyBvZiBtZXNzYWdlIHNl Z21lbnRzIGluIHN5c3RlbSkKCnNobWluZm86CglzaG1tYXg6ICAgIDUzNjg3MDkxMgkobWF4IHNo YXJlZCBtZW1vcnkgc2VnbWVudCBzaXplKQoJc2htbWluOiAgICAgICAgICAgIDEJKG1pbiBzaGFy ZWQgbWVtb3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1uaTogICAgICAgICAgMTkyCShtYXggbnVtYmVy IG9mIHNoYXJlZCBtZW1vcnkgaWRlbnRpZmllcnMpCglzaG1zZWc6ICAgICAgICAgIDEyOAkobWF4 IHNoYXJlZCBtZW1vcnkgc2VnbWVudHMgcGVyIHByb2Nlc3MpCglzaG1hbGw6ICAgICAgIDEzMTA3 MgkobWF4IGFtb3VudCBvZiBzaGFyZWQgbWVtb3J5IGluIHBhZ2VzKQoKc2VtaW5mbzoKCXNlbW1u aTogICAgICAgICAgIDUwCSgjIG9mIHNlbWFwaG9yZSBpZGVudGlmaWVycykKCXNlbW1uczogICAg ICAgICAgMzQwCSgjIG9mIHNlbWFwaG9yZXMgaW4gc3lzdGVtKQoJc2VtbW51OiAgICAgICAgICAx NTAJKCMgb2YgdW5kbyBzdHJ1Y3R1cmVzIGluIHN5c3RlbSkKCXNlbW1zbDogICAgICAgICAgMzQw CShtYXggIyBvZiBzZW1hcGhvcmVzIHBlciBpZCkKCXNlbW9wbTogICAgICAgICAgMTAwCShtYXgg IyBvZiBvcGVyYXRpb25zIHBlciBzZW1vcCBjYWxsKQoJc2VtdW1lOiAgICAgICAgICAgNTAJKG1h eCAjIG9mIHVuZG8gZW50cmllcyBwZXIgcHJvY2VzcykKCXNlbXVzejogICAgICAgICAgNjMyCShz aXplIGluIGJ5dGVzIG9mIHVuZG8gc3RydWN0dXJlKQoJc2Vtdm14OiAgICAgICAgMzI3NjcJKHNl bWFwaG9yZSBtYXhpbXVtIHZhbHVlKQoJc2VtYWVtOiAgICAgICAgMTYzODQJKGFkanVzdCBvbiBl eGl0IG1heCB2YWx1ZSkKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmZzc3RhdAoKQ2xpZW50IEluZm86ClJw YyBDb3VudHM6CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJl YWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAog ICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRp ciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAg IEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAgICAw ICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClJwYyBJbmZvOgogVGltZWRPdXQgICBJbnZh bGlkIFggUmVwbGllcyAgIFJldHJpZXMgIFJlcXVlc3RzCiAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAKQ2FjaGUgSW5mbzoKQXR0ciBIaXRzICAgIE1pc3Nl cyBMa3VwIEhpdHMgICAgTWlzc2VzIEJpb1IgSGl0cyAgICBNaXNzZXMgQmlvVyBIaXRzICAgIE1p c3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwCkJpb1JMSGl0cyAgICBNaXNzZXMgQmlvRCBIaXRz ICAgIE1pc3NlcyBEaXJFIEhpdHMgICAgTWlzc2VzIEFjY3MgSGl0cyAgICBNaXNzZXMKICAgICAg ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAg ICAgICAwICAgICAgICAgMAoKU2VydmVyIEluZm86CiAgR2V0YXR0ciAgIFNldGF0dHIgICAgTG9v a3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRlICAgIENyZWF0ZSAgICBSZW1vdmUKICAg ICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg ICAgICAgICAwICAgICAgICAgMAogICBSZW5hbWUgICAgICBMaW5rICAgU3ltbGluayAgICAgTWtk aXIgICAgIFJtZGlyICAgUmVhZGRpciAgUmRpclBsdXMgICAgQWNjZXNzCiAgICAgICAgMCAgICAg ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAg ICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3RhdCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1p dAogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZl ciBSZXQtRmFpbGVkCiAgICAgICAgICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAgICAgICAg MApTZXJ2ZXIgQ2FjaGUgU3RhdHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVtICAgIE1p c3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2VydmVyIFdyaXRl IEdhdGhlcmluZzoKIFdyaXRlT3BzICBXcml0ZVJQQyAgIE9wc2F2ZWQKICAgICAgICAwICAgICAg ICAgMCAgICAgICAgIDAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1zCgp0Y3A6CgkyNjkwIHBh Y2tldHMgc2VudAoJCTI0NzMgZGF0YSBwYWNrZXRzICg5MDcyODMgYnl0ZXMpCgkJMCBkYXRhIHBh Y2tldHMgKDAgYnl0ZXMpIHJldHJhbnNtaXR0ZWQKCQkwIGRhdGEgcGFja2V0cyB1bm5lY2Vzc2Fy aWx5IHJldHJhbnNtaXR0ZWQKCQkwIHJlc2VuZHMgaW5pdGlhdGVkIGJ5IE1UVSBkaXNjb3ZlcnkK CQkxNzkgYWNrLW9ubHkgcGFja2V0cyAoNzIgZGVsYXllZCkKCQkwIFVSRyBvbmx5IHBhY2tldHMK CQkwIHdpbmRvdyBwcm9iZSBwYWNrZXRzCgkJMCB3aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkzOCBj b250cm9sIHBhY2tldHMKCTExOTQ5IHBhY2tldHMgcmVjZWl2ZWQKCQkyNzQ0IGFja3MgKGZvciA5 MDczNTggYnl0ZXMpCgkJMzAgZHVwbGljYXRlIGFja3MKCQkwIGFja3MgZm9yIHVuc2VudCBkYXRh CgkJMTI0NSBwYWNrZXRzICg2NDkwOCBieXRlcykgcmVjZWl2ZWQgaW4tc2VxdWVuY2UKCQkxIGNv bXBsZXRlbHkgZHVwbGljYXRlIHBhY2tldCAoMCBieXRlcykKCQkwIG9sZCBkdXBsaWNhdGUgcGFj a2V0cwoJCTAgcGFja2V0cyB3aXRoIHNvbWUgZHVwLiBkYXRhICgwIGJ5dGVzIGR1cGVkKQoJCTgg b3V0LW9mLW9yZGVyIHBhY2tldHMgKDMyIGJ5dGVzKQoJCTAgcGFja2V0cyAoMCBieXRlcykgb2Yg ZGF0YSBhZnRlciB3aW5kb3cKCQkwIHdpbmRvdyBwcm9iZXMKCQkwIHdpbmRvdyB1cGRhdGUgcGFj a2V0cwoJCTAgcGFja2V0cyByZWNlaXZlZCBhZnRlciBjbG9zZQoJCTAgZGlzY2FyZGVkIGZvciBi YWQgY2hlY2tzdW1zCgkJMCBkaXNjYXJkZWQgZm9yIGJhZCBoZWFkZXIgb2Zmc2V0IGZpZWxkcwoJ CTAgZGlzY2FyZGVkIGJlY2F1c2UgcGFja2V0IHRvbyBzaG9ydAoJCTAgZGlzY2FyZGVkIGR1ZSB0 byBtZW1vcnkgcHJvYmxlbXMKCTEgY29ubmVjdGlvbiByZXF1ZXN0CgkzOCBjb25uZWN0aW9uIGFj Y2VwdHMKCTAgYmFkIGNvbm5lY3Rpb24gYXR0ZW1wdHMKCTAgbGlzdGVuIHF1ZXVlIG92ZXJmbG93 cwoJMCBpZ25vcmVkIFJTVHMgaW4gdGhlIHdpbmRvd3MKCTM4IGNvbm5lY3Rpb25zIGVzdGFibGlz aGVkIChpbmNsdWRpbmcgYWNjZXB0cykKCTU3IGNvbm5lY3Rpb25zIGNsb3NlZCAoaW5jbHVkaW5n IDEgZHJvcCkKCQkyIGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIFJUVCBvbiBjbG9zZQoJCTIg Y29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgUlRUIHZhcmlhbmNlIG9uIGNsb3NlCgkJMCBjb25u ZWN0aW9ucyB1cGRhdGVkIGNhY2hlZCBzc3RocmVzaCBvbiBjbG9zZQoJMSBlbWJyeW9uaWMgY29u bmVjdGlvbiBkcm9wcGVkCgkyNzE1IHNlZ21lbnRzIHVwZGF0ZWQgcnR0IChvZiAyMzA1IGF0dGVt cHRzKQoJOCByZXRyYW5zbWl0IHRpbWVvdXRzCgkJMCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5IHJl eG1pdCB0aW1lb3V0CgkwIHBlcnNpc3QgdGltZW91dHMKCQkwIGNvbm5lY3Rpb25zIGRyb3BwZWQg YnkgcGVyc2lzdCB0aW1lb3V0CgkwIENvbm5lY3Rpb25zIChmaW5fd2FpdF8yKSBkcm9wcGVkIGJl Y2F1c2Ugb2YgdGltZW91dAoJMSBrZWVwYWxpdmUgdGltZW91dAoJCTAga2VlcGFsaXZlIHByb2Jl cyBzZW50CgkJMSBjb25uZWN0aW9uIGRyb3BwZWQgYnkga2VlcGFsaXZlCgkyMDM0IGNvcnJlY3Qg QUNLIGhlYWRlciBwcmVkaWN0aW9ucwoJODM0IGNvcnJlY3QgZGF0YSBwYWNrZXQgaGVhZGVyIHBy ZWRpY3Rpb25zCgkzOCBzeW5jYWNoZSBlbnRyaWVzIGFkZGVkCgkJMCByZXRyYW5zbWl0dGVkCgkJ MCBkdXBzeW4KCQkwIGRyb3BwZWQKCQkzOCBjb21wbGV0ZWQKCQkwIGJ1Y2tldCBvdmVyZmxvdwoJ CTAgY2FjaGUgb3ZlcmZsb3cKCQkwIHJlc2V0CgkJMCBzdGFsZQoJCTAgYWJvcnRlZAoJCTAgYmFk YWNrCgkJMCB1bnJlYWNoCgkJMCB6b25lIGZhaWx1cmVzCgkzOCBjb29raWVzIHNlbnQKCTAgY29v a2llcyByZWNlaXZlZAoJMSBob3N0Y2FjaGUgZW50cmllIGFkZGVkCgkJMCBidWNrZXQgb3ZlcmZs b3cKCTAgU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMCBzZWdtZW50IHJleG1pdHMgaW4gU0FDSyBy ZWNvdmVyeSBlcGlzb2RlcwoJMCBieXRlIHJleG1pdHMgaW4gU0FDSyByZWNvdmVyeSBlcGlzb2Rl cwoJMCBTQUNLIG9wdGlvbnMgKFNBQ0sgYmxvY2tzKSByZWNlaXZlZAoJMCBTQUNLIG9wdGlvbnMg KFNBQ0sgYmxvY2tzKSBzZW50CgkwIFNBQ0sgc2NvcmVib2FyZCBvdmVyZmxvdwoJMCBwYWNrZXRz IHdpdGggRUNOIENFIGJpdCBzZXQKCTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMCkgYml0IHNldAoJ MCBwYWNrZXRzIHdpdGggRUNOIEVDVCgxKSBiaXQgc2V0CgkwIHN1Y2Nlc3NmdWwgRUNOIGhhbmRz aGFrZXMKCTAgdGltZXMgRUNOIHJlZHVjZWQgdGhlIGNvbmdlc3Rpb24gd2luZG93CnVkcDoKCTM0 ODE5IGRhdGFncmFtcyByZWNlaXZlZAoJMCB3aXRoIGluY29tcGxldGUgaGVhZGVyCgkwIHdpdGgg YmFkIGRhdGEgbGVuZ3RoIGZpZWxkCgkwIHdpdGggYmFkIGNoZWNrc3VtCgk4MCB3aXRoIG5vIGNo ZWNrc3VtCgkxNTU4NSBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTE5MDU1IGJyb2FkY2FzdC9t dWx0aWNhc3QgZGF0YWdyYW1zIHVuZGVsaXZlcmVkCgkwIGRyb3BwZWQgZHVlIHRvIGZ1bGwgc29j a2V0IGJ1ZmZlcnMKCTAgbm90IGZvciBoYXNoZWQgcGNiCgkxNzkgZGVsaXZlcmVkCgkxOTIgZGF0 YWdyYW1zIG91dHB1dAoJMCB0aW1lcyBtdWx0aWNhc3Qgc291cmNlIGZpbHRlciBtYXRjaGVkCmlw OgoJNDY0OTYzNSB0b3RhbCBwYWNrZXRzIHJlY2VpdmVkCgkwIGJhZCBoZWFkZXIgY2hlY2tzdW1z CgkwIHdpdGggc2l6ZSBzbWFsbGVyIHRoYW4gbWluaW11bQoJMCB3aXRoIGRhdGEgc2l6ZSA8IGRh dGEgbGVuZ3RoCgkwIHdpdGggaXAgbGVuZ3RoID4gbWF4IGlwIHBhY2tldCBzaXplCgkwIHdpdGgg aGVhZGVyIGxlbmd0aCA8IGRhdGEgc2l6ZQoJMCB3aXRoIGRhdGEgbGVuZ3RoIDwgaGVhZGVyIGxl bmd0aAoJMCB3aXRoIGJhZCBvcHRpb25zCgkwIHdpdGggaW5jb3JyZWN0IHZlcnNpb24gbnVtYmVy CgkyIGZyYWdtZW50cyByZWNlaXZlZAoJMCBmcmFnbWVudHMgZHJvcHBlZCAoZHVwIG9yIG91dCBv ZiBzcGFjZSkKCTEgZnJhZ21lbnQgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkwIHBhY2tldHMgcmVh c3NlbWJsZWQgb2sKCTQ2NzcxIHBhY2tldHMgZm9yIHRoaXMgaG9zdAoJOTcyIHBhY2tldHMgZm9y IHVua25vd24vdW5zdXBwb3J0ZWQgcHJvdG9jb2wKCTQ1OTQ1MTggcGFja2V0cyBmb3J3YXJkZWQg KDAgcGFja2V0cyBmYXN0IGZvcndhcmRlZCkKCTczOTYgcGFja2V0cyBub3QgZm9yd2FyZGFibGUK CTAgcGFja2V0cyByZWNlaXZlZCBmb3IgdW5rbm93biBtdWx0aWNhc3QgZ3JvdXAKCTMxMSByZWRp cmVjdHMgc2VudAoJMzIzNSBwYWNrZXRzIHNlbnQgZnJvbSB0aGlzIGhvc3QKCTAgcGFja2V0cyBz ZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0cHV0IHBhY2tldHMgZHJvcHBlZCBk dWUgdG8gbm8gYnVmcywgZXRjLgoJMiBvdXRwdXQgcGFja2V0cyBkaXNjYXJkZWQgZHVlIHRvIG5v IHJvdXRlCgkwIG91dHB1dCBkYXRhZ3JhbXMgZnJhZ21lbnRlZAoJMCBmcmFnbWVudHMgY3JlYXRl ZAoJMCBkYXRhZ3JhbXMgdGhhdCBjYW4ndCBiZSBmcmFnbWVudGVkCgkwIHR1bm5lbGluZyBwYWNr ZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgZGF0YWdyYW1zIHdpdGggYmFkIGFkZHJlc3MgaW4g aGVhZGVyCmljbXA6CgkyNyBjYWxscyB0byBpY21wX2Vycm9yCgkwIGVycm9ycyBub3QgZ2VuZXJh dGVkIGluIHJlc3BvbnNlIHRvIGFuIGljbXAgbWVzc2FnZQoJT3V0cHV0IGhpc3RvZ3JhbToKCQll Y2hvIHJlcGx5OiAxCgkJZGVzdGluYXRpb24gdW5yZWFjaGFibGU6IDMKCQlyb3V0aW5nIHJlZGly ZWN0OiAzMTEKCQl0aW1lIGV4Y2VlZGVkOiAyNAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjb2RlIGZp ZWxkcwoJMCBtZXNzYWdlcyBsZXNzIHRoYW4gdGhlIG1pbmltdW0gbGVuZ3RoCgkwIG1lc3NhZ2Vz IHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGxlbmd0aAoJMCBtdWx0aWNh c3QgZWNobyByZXF1ZXN0cyBpZ25vcmVkCgkwIG11bHRpY2FzdCB0aW1lc3RhbXAgcmVxdWVzdHMg aWdub3JlZAoJSW5wdXQgaGlzdG9ncmFtOgoJCWRlc3RpbmF0aW9uIHVucmVhY2hhYmxlOiAzOTQK CQllY2hvOiAxCgkxIG1lc3NhZ2UgcmVzcG9uc2UgZ2VuZXJhdGVkCgkwIGludmFsaWQgcmV0dXJu IGFkZHJlc3NlcwoJMCBubyByZXR1cm4gcm91dGVzCmlnbXA6Cgk1NzggbWVzc2FnZXMgcmVjZWl2 ZWQKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCB0b28gZmV3IGJ5dGVzCgkwIG1lc3NhZ2VzIHJl Y2VpdmVkIHdpdGggd3JvbmcgVFRMCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdpdGggYmFkIGNoZWNr c3VtCgk1MCBWMS9WMiBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgVjMgbWVtYmVyc2hp cCBxdWVyaWVzIHJlY2VpdmVkCgkwIG1lbWJlcnNoaXAgcXVlcmllcyByZWNlaXZlZCB3aXRoIGlu dmFsaWQgZmllbGQocykKCTUwIGdlbmVyYWwgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cCBxdWVy aWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNvdXJjZSBxdWVyaWVzIHJlY2VpdmVkCgkwIGdyb3VwLXNv dXJjZSBxdWVyaWVzIGRyb3BwZWQKCTUwNSBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQKCTAg bWVtYmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIHdpdGggaW52YWxpZCBmaWVsZChzKQoJMzkgbWVt YmVyc2hpcCByZXBvcnRzIHJlY2VpdmVkIGZvciBncm91cHMgdG8gd2hpY2ggd2UgYmVsb25nCgkw IFYzIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aG91dCBSb3V0ZXIgQWxlcnQKCTEzIG1lbWJlcnNoaXAg cmVwb3J0cyBzZW50CmFycDoKCTM3IEFSUCByZXF1ZXN0cyBzZW50CgkxNzY3IEFSUCByZXBsaWVz IHNlbnQKCTIzNzYwIEFSUCByZXF1ZXN0cyByZWNlaXZlZAoJMzQgQVJQIHJlcGxpZXMgcmVjZWl2 ZWQKCTQ2MDE4IEFSUCBwYWNrZXRzIHJlY2VpdmVkCgkyIHRvdGFsIHBhY2tldHMgZHJvcHBlZCBk dWUgdG8gbm8gQVJQIGVudHJ5Cgk0IEFSUCBlbnRyeXMgdGltZWQgb3V0CgkwIER1cGxpY2F0ZSBJ UHMgc2VlbgppcDY6CgkwIHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgd2l0aCBzaXplIHNtYWxs ZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAgd2l0aCBi YWQgb3B0aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJlcgoJMCBmcmFnbWVudHMg cmVjZWl2ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBvdXQgb2Ygc3BhY2UpCgkwIGZy YWdtZW50cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgZnJhZ21lbnRzIHRoYXQgZXhjZWVkZWQg bGltaXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJMCBwYWNrZXRzIGZvciB0aGlzIGhvc3QK CTAgcGFja2V0cyBmb3J3YXJkZWQKCTAgcGFja2V0cyBub3QgZm9yd2FyZGFibGUKCTAgcmVkaXJl Y3RzIHNlbnQKCTEzIHBhY2tldHMgc2VudCBmcm9tIHRoaXMgaG9zdAoJMCBwYWNrZXRzIHNlbnQg d2l0aCBmYWJyaWNhdGVkIGlwIGhlYWRlcgoJMCBvdXRwdXQgcGFja2V0cyBkcm9wcGVkIGR1ZSB0 byBubyBidWZzLCBldGMuCgk2IG91dHB1dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91 dGUKCTAgb3V0cHV0IGRhdGFncmFtcyBmcmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVkCgkw IGRhdGFncmFtcyB0aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQKCTAgcGFja2V0cyB0aGF0IHZpb2xh dGVkIHNjb3BlIHJ1bGVzCgkwIG11bHRpY2FzdCBwYWNrZXRzIHdoaWNoIHdlIGRvbid0IGpvaW4K CU1idWYgc3RhdGlzdGljczoKCQkyNDc2IG9uZSBtYnVmCgkJdHdvIG9yIG1vcmUgbWJ1ZjoKCQkJ YmNlMD0gNDQxMQoJCTAgb25lIGV4dCBtYnVmCgkJMCB0d28gb3IgbW9yZSBleHQgbWJ1ZgoJMCBw YWNrZXRzIHdob3NlIGhlYWRlcnMgYXJlIG5vdCBjb250aWd1b3VzCgkwIHR1bm5lbGluZyBwYWNr ZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgcGFja2V0cyBkaXNjYXJkZWQgYmVjYXVzZSBvZiB0 b28gbWFueSBoZWFkZXJzCgkwIGZhaWx1cmVzIG9mIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbgoJ U291cmNlIGFkZHJlc3NlcyBzZWxlY3Rpb24gcnVsZSBhcHBsaWVkOgppY21wNjoKCTAgY2FsbHMg dG8gaWNtcDZfZXJyb3IKCTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4g aWNtcDYgbWVzc2FnZQoJMCBlcnJvcnMgbm90IGdlbmVyYXRlZCBiZWNhdXNlIG9mIHJhdGUgbGlt aXRhdGlvbgoJT3V0cHV0IGhpc3RvZ3JhbToKCQluZWlnaGJvciBzb2xpY2l0YXRpb246IDMKCQlN TER2MiBsaXN0ZW5lciByZXBvcnQ6IDQKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMK CTAgbWVzc2FnZXMgPCBtaW5pbXVtIGxlbmd0aAoJMCBiYWQgY2hlY2tzdW1zCgkwIG1lc3NhZ2Vz IHdpdGggYmFkIGxlbmd0aAoJSGlzdG9ncmFtIG9mIGVycm9yIG1lc3NhZ2VzIHRvIGJlIGdlbmVy YXRlZDoKCQkwIG5vIHJvdXRlCgkJMCBhZG1pbmlzdHJhdGl2ZWx5IHByb2hpYml0ZWQKCQkwIGJl eW9uZCBzY29wZQoJCTAgYWRkcmVzcyB1bnJlYWNoYWJsZQoJCTAgcG9ydCB1bnJlYWNoYWJsZQoJ CTAgcGFja2V0IHRvbyBiaWcKCQkwIHRpbWUgZXhjZWVkIHRyYW5zaXQKCQkwIHRpbWUgZXhjZWVk IHJlYXNzZW1ibHkKCQkwIGVycm9uZW91cyBoZWFkZXIgZmllbGQKCQkwIHVucmVjb2duaXplZCBu ZXh0IGhlYWRlcgoJCTAgdW5yZWNvZ25pemVkIG9wdGlvbgoJCTAgcmVkaXJlY3QKCQkwIHVua25v d24KCTAgbWVzc2FnZSByZXNwb25zZXMgZ2VuZXJhdGVkCgkwIG1lc3NhZ2VzIHdpdGggdG9vIG1h bnkgTkQgb3B0aW9ucwoJMCBtZXNzYWdlcyB3aXRoIGJhZCBORCBvcHRpb25zCgkwIGJhZCBuZWln aGJvciBzb2xpY2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIG5laWdoYm9yIGFkdmVydGlzZW1lbnQg bWVzc2FnZXMKCTAgYmFkIHJvdXRlciBzb2xpY2l0YXRpb24gbWVzc2FnZXMKCTAgYmFkIHJvdXRl ciBhZHZlcnRpc2VtZW50IG1lc3NhZ2VzCgkwIGJhZCByZWRpcmVjdCBtZXNzYWdlcwoJMCBwYXRo IE1UVSBjaGFuZ2VzCnJpcDY6CgkwIG1lc3NhZ2VzIHJlY2VpdmVkCgkwIGNoZWNrc3VtIGNhbGN1 bGF0aW9ucyBvbiBpbmJvdW5kCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3Nh Z2VzIGRyb3BwZWQgZHVlIHRvIG5vIHNvY2tldAoJMCBtdWx0aWNhc3QgbWVzc2FnZXMgZHJvcHBl ZCBkdWUgdG8gbm8gc29ja2V0CgkwIG1lc3NhZ2VzIGRyb3BwZWQgZHVlIHRvIGZ1bGwgc29ja2V0 IGJ1ZmZlcnMKCTAgZGVsaXZlcmVkCgkwIGRhdGFncmFtcyBvdXRwdXQKCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQpuZXRzdGF0IC1tCgo1MTA3LzE2OTkvNjgwNiBtYnVmcyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUv dG90YWwpCjQwNzEvNzk5LzQ4NzAvNjU1MzYgbWJ1ZiBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQv Y2FjaGUvdG90YWwvbWF4KQo0MDgyLzc5MyBtYnVmK2NsdXN0ZXJzIG91dCBvZiBwYWNrZXQgc2Vj b25kYXJ5IHpvbmUgaW4gdXNlIChjdXJyZW50L2NhY2hlKQowLzY1LzY1LzEyODAwIDRrIChwYWdl IHNpemUpIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAv MC8wLzE5MjAwIDlrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9t YXgpCjAvMC8wLzEyODAwIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUv dG90YWwvbWF4KQo5NDE4Sy8yMjgySy8xMTcwMUsgYnl0ZXMgYWxsb2NhdGVkIHRvIG5ldHdvcmsg KGN1cnJlbnQvY2FjaGUvdG90YWwpCjAvMC8wIHJlcXVlc3RzIGZvciBtYnVmcyBkZW5pZWQgKG1i dWZzL2NsdXN0ZXJzL21idWYrY2x1c3RlcnMpCjAvMC8wIHJlcXVlc3RzIGZvciBqdW1ibyBjbHVz dGVycyBkZW5pZWQgKDRrLzlrLzE2aykKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRlbmllZAowIHJl cXVlc3RzIGZvciBzZmJ1ZnMgZGVsYXllZAowIHJlcXVlc3RzIGZvciBJL08gaW5pdGlhdGVkIGJ5 IHNlbmRmaWxlCjAgY2FsbHMgdG8gcHJvdG9jb2wgZHJhaW4gcm91dGluZXMKCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpuZXRzdGF0IC1pZAoKTmFtZSAgICBNdHUgTmV0d29yayAgICAgICBBZGRyZXNzICAgICAg ICAgICAgICBJcGt0cyBJZXJycyBJZHJvcCAgICBPcGt0cyBPZXJycyAgQ29sbCBEcm9wCmJjZTAg ICAxNTAwIDxMaW5rIzE+ICAgICAgWFg6WFg6WFg6WFg6WFg6WFggIDE5OTMyNTkgICAgIDAgICAg IDAgIDI2NjQzNDUgICAgIDAgICAgIDAgICAgMCAKYmNlMCAgIDE1MDAgWFhYWDo6WFhYOlhYWCBY WFhYOjpYWFg6WFhYWDpYWCAgICAgICAgMCAgICAgLSAgICAgLSAgICAgICAgMCAgICAgLSAgICAg LSAgICAtIApiY2UwICAgMTUwMCBYWFguWFhYLlhYWC5YWFggICAgWFhYLlhYWC5YWFguWFhYICAg ICAgICAgICAxMTAwOCAgICAgLSAgICAgLSAgICAgNjE3OCAgICAgLSAgICAgLSAgICAtIApiY2Ux ICAgMTUwMCA8TGluayMyPiAgICAgIFhYOlhYOlhYOlhYOlhYOlhYICAyNzE0NDYyICAgICAwICAg ICAwICAxOTM4MTMxICAgICAwICAgICAwICAgIDAgCmJjZTEgICAxNTAwIFhYWFg6OlhYWDpYWFgg WFhYWDo6WFhYOlhYWFg6WFggICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDEgICAgIC0gICAg IC0gICAgLSAKdXNidXMgICAgIDAgPExpbmsjMz4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIAp1c2J1cyAgICAgMCA8 TGluayM0PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAg ICAwICAgICAwICAgICAwICAgIDAgCnVzYnVzICAgICAwIDxMaW5rIzU+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAK dXNidXMgICAgIDAgPExpbmsjNj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAg MCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIAppcGZ3MCA2NTUzNiA8TGluayM3PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAgICAwICAgICAw ICAgICAwICAgIDAgCmxvMCAgIDE2Mzg0IDxMaW5rIzg+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKbG8wICAgMTYz ODQgbG9jYWxob3N0ICAgICA6OjEgICAgICAgICAgICAgICAgICAgICAgMCAgICAgLSAgICAgLSAg ICAgICAgMCAgICAgLSAgICAgLSAgICAtIApsbzAgICAxNjM4NCBmZTgwOjoxJWxvMCAgIGZlODA6 OjEgICAgICAgICAgICAgICAgICAwICAgICAtICAgICAtICAgICAgICAwICAgICAtICAgICAtICAg IC0gCmxvMCAgIDE2Mzg0IHlvdXItbmV0ICAgICAgbG9jYWxob3N0ICAgICAgICAgICAgICAgIDAg ICAgIC0gICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAKdmxhbjEgIDE1MDAgPExpbmsj OT4gICAgICBYWDpYWDpYWDpYWDpYWDpYWCAgMjY3OTczNSAgICAgMCAgICAgMCAgMTkzODEzMSAg ICAgMCAgICAgMCAgICAwIAp2bGFuMSAgMTUwMCBYWFguWFhYLlhYWC5YWFggWVlZWVlZWVlZWVlZ WVlZWS4gICAgMjQyMDAgICAgIC0gICAgIC0gICAgICAyNTMgICAgIC0gICAgIC0gICAgLSAKdmxh bjIgIDE1MDAgPExpbmsjMTA+ICAgICAwMDowMDowMDowMDowMDowMCAgICAgICAgMCAgICAgMCAg ICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIApjYXJwMCAgMTUwMCA8TGluayMxMT4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAwICAgICAwICAgICAzMDYwICAgICAwICAg ICAwICAgIDAgCmNhcnAwICAxNTAwIFhYWC5YWFguWFhYLlhYWCAgICBsb2dzICAgICAgICAgICAg ICAgICAgIDI5NyAgICAgLSAgICAgLSAgICAgICAgMCAgICAgLSAgICAgLSAgICAtIAp0dW4wICAg MTUwMCA8TGluayMxMj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAw ICAgICAgMjcyICAgICAwICAgICAwICAgIDAgCnR1bjAgICAxNTAwIFhYWFg6OlhYWDpYWFggWFhY WDo6WFhYOlhYWFg6WFggICAgICAgIDAgICAgIC0gICAgIC0gICAgICAgIDIgICAgIC0gICAgIC0g ICAgLSAKdHVuMCAgIDE1MDAgWC5YLlguWC8zMiAgIFguWC5YLlggICAgICAgICAgICAgICAgIDAg ICAgIC0gICAgIC0gICAgICAgIDAgICAgIC0gICAgIC0gICAgLSAKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpu ZXRzdGF0IC1hbnIKClJvdXRpbmcgdGFibGVzCgpJbnRlcm5ldDoKRGVzdGluYXRpb24gICAgICAg IEdhdGV3YXkgICAgICAgICAgICBGbGFncyAgICBSZWZzICAgICAgVXNlICBOZXRpZiBFeHBpcmUK ZGVmYXVsdCAgICAgICAgICAgIHh4eC54eHgueHh4LjQ5ICAgICBVR1MgICAgICAgICAxICAxOTM4 MDM2IHZsYW4xMQoxMC41LjAuMC8yNCAgICAgICAgMTAuNS4wLjIgICAgICAgICAgIFVHUyAgICAg ICAgIDAgICAgICAyNjcgICB0dW4wCjEwLjUuMC4xICAgICAgICAgICBsaW5rIzEyICAgICAgICAg ICAgVUhTICAgICAgICAgMCAgICAgICAgMCAgICBsbzAKMTAuNS4wLjIgICAgICAgICAgIGxpbmsj MTIgICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICAwICAgdHVuMAoxMjcuMC4wLjEgICAg ICAgICAgbGluayM4ICAgICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDAgICAgbG8wCnh4 eC54eHguMC4wLzE2ICAgICAgbGluayMxICAgICAgICAgICAgIFUgICAgICAgICAgIDAgIDI2NTkx NzAgICBiY2UwCnh4eC54eHguMS4yICAgICAgICAgbGluayMxICAgICAgICAgICAgIFVIUyAgICAg ICAgIDAgICAgICAgIDAgICAgbG8wCnh4eC54eHguMS4zICAgICAgICAgbGluayMxMSAgICAgICAg ICAgIFVIICAgICAgICAgIDAgICAgICAgIDAgIGNhcnAwCjE5Mi4xNjguMTcuMC8yNCAgICB4eHgu eHh4LjEuMTAgICAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgICBiY2UwCjE5Mi4xNjguMTgu MC8yNCAgICB4eHgueHh4LjEuMjAgICAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgICBiY2Uw Cnh4eC54eHgueHh4LjQ4LzI5ICBsaW5rIzkgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICAg ICA4OSB2bGFuMTEKeHh4Lnh4eC54eHguNTIgICAgIGxpbmsjOSAgICAgICAgICAgICBVSFMgICAg ICAgICAwICAgICAgICAwICAgIGxvMAp4eHgueHh4Lnh4eC41NCAgICAgeHh4Lnh4eC4xLjExMCAg ICAgICBVR0hTICAgICAgICAwICAgICAgMzExICAgYmNlMAoKSW50ZXJuZXQ2OgpEZXN0aW5hdGlv biAgICAgICAgICAgICAgICAgICAgICAgR2F0ZXdheSAgICAgICAgICAgICAgICAgICAgICAgRmxh Z3MgICAgICBOZXRpZiBFeHBpcmUKOjovOTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDo6 MSAgICAgICAgICAgICAgICAgICAgICAgICAgIFVHUlMgICAgICAgIGxvMAo6OjEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbGluayM4ICAgICAgICAgICAgICAgICAgICAgICAgVUggICAg ICAgICAgbG8wCjo6ZmZmZjowLjAuMC4wLzk2ICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAg ICAgICAgICAgICAgICAgICBVR1JTICAgICAgICBsbzAKZmU4MDo6LzEwICAgICAgICAgICAgICAg ICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAgICAgICAgICAgIFVHUlMgICAgICAgIGxvMApm ZTgwOjolYmNlMC82NCAgICAgICAgICAgICAgICAgICAgbGluayMxICAgICAgICAgICAgICAgICAg ICAgICAgVSAgICAgICAgICBiY2UwCnh4eHg6Onh4eDp4eHh4Onh4eHg6ZWMyYSViY2UwICAgICBs aW5rIzEgICAgICAgICAgICAgICAgICAgICAgICBVSFMgICAgICAgICBsbzAKZmU4MDo6JWJjZTEv NjQgICAgICAgICAgICAgICAgICAgIGxpbmsjMiAgICAgICAgICAgICAgICAgICAgICAgIFUgICAg ICAgICAgYmNlMQp4eHh4Ojp4eHg6eHh4eDp4eHh4OmVjMmMlYmNlMSAgICAgbGluayMyICAgICAg ICAgICAgICAgICAgICAgICAgVUhTICAgICAgICAgbG8wCmZlODA6OiVsbzAvNjQgICAgICAgICAg ICAgICAgICAgICBsaW5rIzggICAgICAgICAgICAgICAgICAgICAgICBVICAgICAgICAgICBsbzAK ZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAgICAgICAgIGxpbmsjOCAgICAgICAgICAgICAgICAg ICAgICAgIFVIUyAgICAgICAgIGxvMApmZTgwOjolMTIvNjQgICAgICAgICAgICAgICAgICAgICAg bGluayMxMiAgICAgICAgICAgICAgICAgICAgICAgVSAgICAgICAgICB0dW4wCnh4eHg6Onh4eDp4 eHh4Onh4eHg6ZWMyYSUxMiAgICAgICBsaW5rIzEyICAgICAgICAgICAgICAgICAgICAgICBVSFMg ICAgICAgICBsbzAKZmYwMTo6JWJjZTAvMzIgICAgICAgICAgICAgICAgICAgIHh4eHg6Onh4eDp4 eHh4Onh4eHg6ZWMyYSViY2UwIFUgICAgICAgICAgYmNlMApmZjAxOjolYmNlMS8zMiAgICAgICAg ICAgICAgICAgICAgeHh4eDo6eHh4Onh4eHg6eHh4eDplYzJjJWJjZTEgVSAgICAgICAgICBiY2Ux CmZmMDE6OiVsbzAvMzIgICAgICAgICAgICAgICAgICAgICA6OjEgICAgICAgICAgICAgICAgICAg ICAgICAgICBVICAgICAgICAgICBsbzAKZmYwMTo6JTEyLzMyICAgICAgICAgICAgICAgICAgICAg IHh4eHg6Onh4eDp4eHh4Onh4eHg6ZWMyYSUxMiAgIFUgICAgICAgICAgdHVuMApmZjAyOjovMTYg ICAgICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAgICAgICAgICAgICAgVUdS UyAgICAgICAgbG8wCmZmMDI6OiViY2UwLzMyICAgICAgICAgICAgICAgICAgICB4eHh4Ojp4eHg6 eHh4eDp4eHh4OmVjMmElYmNlMCBVICAgICAgICAgIGJjZTAKZmYwMjo6JWJjZTEvMzIgICAgICAg ICAgICAgICAgICAgIHh4eHg6Onh4eDp4eHh4Onh4eHg6ZWMyYyViY2UxIFUgICAgICAgICAgYmNl MQpmZjAyOjolbG8wLzMyICAgICAgICAgICAgICAgICAgICAgOjoxICAgICAgICAgICAgICAgICAg ICAgICAgICAgVSAgICAgICAgICAgbG8wCmZmMDI6OiUxMi8zMiAgICAgICAgICAgICAgICAgICAg ICB4eHh4Ojp4eHg6eHh4eDp4eHh4OmVjMmElMTIgICBVICAgICAgICAgIHR1bjAKCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpuZXRzdGF0IC1hbkEKCkFjdGl2ZSBJbnRlcm5ldCBjb25uZWN0aW9ucyAoaW5jbHVk aW5nIHNlcnZlcnMpClRjcGNiICAgICAgICAgICAgUHJvdG8gUmVjdi1RIFNlbmQtUSBMb2NhbCBB ZGRyZXNzICAgICAgRm9yZWlnbiBBZGRyZXNzICAgIChzdGF0ZSkKZmZmZmZlMDAyNTA2NzNkMCB0 Y3A0ICAgICAgIDAgICAgICAwIHh4eC54eHguMS4yLjIyMjIyICAgeHh4Lnh4eC4zLjIwLjQ3MzAw ICBFU1RBQkxJU0hFRApmZmZmZmUwMDI1M2RhN2EwIHRjcDQgICAgICAgMCAgICAgIDAgKi4yMjIy MiAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZlMDAyNTNkYWI3MCB0 Y3A2ICAgICAgIDAgICAgICAwICouMjIyMjIgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAg TElTVEVOCmZmZmZmZTAwMjUxY2U3YTAgdGNwNCAgICAgICAwICAgICAgMCAqLjM3ICAgICAgICAg ICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUwMDI1M2RiM2QwIHRjcDQgICAg ICAgMCAgICAgIDAgMTI3LjAuMC4xLjI1ICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4K ZmZmZmZlMDAyNTIzNGI3MCB0Y3A0ICAgICAgIDAgICAgICAwICouOTEwMiAgICAgICAgICAgICAq LiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMjUyMzUwMDAgdGNwNCAgICAgICAwICAg ICAgMCB4eHgueHh4LjEuMi42NjcgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZl MDAyNTA2NzAwMCB0Y3A0ICAgICAgIDAgICAgICAwICouNDQzICAgICAgICAgICAgICAqLiogICAg ICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMjUwNjZiNzAgdGNwNCAgICAgICAwICAgICAgMCAq LjgwICAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUwMDI1MjM1 M2QwIHRjcDQgICAgICAgMCAgICAgIDAgKi4xOTkgICAgICAgICAgICAgICouKiAgICAgICAgICAg ICAgICBMSVNURU4KZmZmZmZlMDAyNTFjZTAwMCB0Y3A0ICAgICAgIDAgICAgICAwICouMTcyMyAg ICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwMjUxY2UzZDAgdGNw NCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuNTAwNSAgICAgKi4qICAgICAgICAgICAgICAgIExJ U1RFTgpmZmZmZmUwMDI1MDY2N2EwIHRjcDYgICAgICAgMCAgICAgIDAgOjoxLjk1MyAgICAgICAg ICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZlMDAyNTA2NjAwMCB0Y3A0ICAgICAg IDAgICAgICAwIDEyNy4wLjAuMS45NTMgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZm ZmZmZTAwMjUwNjYzZDAgdGNwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuNTMgICAgICAgKi4q ICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmUwMDExNDE1MzEwIHVkcDQgICAgICAgMCAgICAg IDAgMTAuNS4wLjEuMTIzICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZlMDAxMTQyNTkz MCB1ZHA0ICAgICAgIDAgICAgICAwIHh4eC54eHgueHh4LjUyLjUwMCAqLiogICAgICAgICAgICAg ICAgCmZmZmZmZTAwMTE0MjUwMDAgdWRwNCAgICAgICAwICAgICAgMCB4eHgueHh4LjEuMy4xMjMg ICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZlMDAxMTQyNTMxMCB1ZHA0ICAgICAgIDAgICAg ICAwIHh4eC54eHgueHh4LjUyLjEyMyAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0MTVj NDAgdWRwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuMTIzICAgICAgKi4qICAgICAgICAgICAg ICAgIApmZmZmZmUwMDExNDE1N2E4IHVkcDYgICAgICAgMCAgICAgIDAgZmU4MDo4OjoxLjEyMyAg ICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZlMDAxMTQxNTE4OCB1ZHA2ICAgICAgIDAgICAg ICAwIDo6MS4xMjMgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0MTU0 OTggdWRwNiAgICAgICAwICAgICAgMCB4eHh4Ong6Onh4eDp4eHhmLjEgKi4qICAgICAgICAgICAg ICAgIApmZmZmZmUwMDExNDE1NjIwIHVkcDQgICAgICAgMCAgICAgIDAgeHh4Lnh4eC4xLjIuMTIz ICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0MTU5MzAgdWRwNiAgICAgICAwICAg ICAgMCB4eHh4Ong6Onh4eDp4eHhmLjEgKi4qICAgICAgICAgICAgICAgIApmZmZmZmUwMDExNDE1 YWI4IHVkcDYgICAgICAgMCAgICAgIDAgKi4xMjMgICAgICAgICAgICAgICouKiAgICAgICAgICAg ICAgICAKZmZmZmZlMDAxMTQxNWRjOCB1ZHA0ICAgICAgIDAgICAgICAwICouMTIzICAgICAgICAg ICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZTAwMTE0NTk0OTggdWRwNCAgICAgICAwICAg ICAgMCAqLjE2MSAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmUwMDExNDI1 NjIwIHVkcDQgICAgICAgMCAgICAgIDAgeHh4Lnh4eC4xLjIuMTYyICAgICAqLiogICAgICAgICAg ICAgICAgCmZmZmZmZTAwMTE0MjUxODggdWRwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuNTMg ICAgICAgKi4qICAgICAgICAgICAgICAgIApBY3RpdmUgVU5JWCBkb21haW4gc29ja2V0cwpBZGRy ZXNzICBUeXBlICAgUmVjdi1RIFNlbmQtUSAgICBJbm9kZSAgICAgQ29ubiAgICAgUmVmcyAgTmV4 dHJlZiBBZGRyCmZmZmZmZTAwMTFmMmQzYzAgc3RyZWFtICAgICAgMCAgICAgIDAgZmZmZmZlMDAy NWNjODFlMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9kZXZkLnBpcGUKZmZm ZmZlMDAxMTlhM2E1MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDExOWEz YjQwICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMTE5YTNiNDAgc3RyZWFtICAgICAgMCAgICAg IDAgICAgICAgIDAgZmZmZmZlMDAxMTlhM2E1MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDEx ZjE0YzMwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMTFmMTRkMjAgICAg ICAgIDAgICAgICAgIDAKZmZmZmZlMDAxMWYxNGQyMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAg ICAgMCBmZmZmZmUwMDExZjE0YzMwICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMTFmMTRlMTAg c3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYyZDAwMCAgICAgICAgMCAg ICAgICAgMApmZmZmZmUwMDExZjJkMDAwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZm ZmZmZTAwMTFmMTRlMTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZlMDAxMWYxNDAwMCBzdHJlYW0g ICAgICAwICAgICAgMCBmZmZmZmUwMDExNDMzNzgwICAgICAgICAwICAgICAgICAwICAgICAgICAw IC92YXIvcnVuL25zY2QKZmZmZmZlMDAxMTQyN2QyMCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAg ICAgMCBmZmZmZmUwMDExZjEyOTYwICAgICAgICAwIGZmZmZmZTAwMTE0MjdlMTAKZmZmZmZlMDAx MWYxNGI0MCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDExZjEyODcwICAg ICAgICAwICAgICAgICAwCmZmZmZmZTAwMTE0MjdlMTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAg ICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCBmZmZmZmUwMDExZjJkMWUwCmZmZmZmZTAw MTFmMmQxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAg ICAgICAgMCBmZmZmZmUwMDExZjJkMmQwCmZmZmZmZTAwMTFmMmQyZDAgZGdyYW0gICAgICAgMCAg ICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCBmZmZmZmUwMDExZjEyNWEw CmZmZmZmZTAwMTFmMTI1YTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAx MWYxMjk2MCAgICAgICAgMCBmZmZmZmUwMDExZjE0MGYwCmZmZmZmZTAwMTFmMTQwZjAgZGdyYW0g ICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCBmZmZmZmUw MDExZjE0MWUwCmZmZmZmZTAwMTFmMTQxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgICAgICAgIDAg ZmZmZmZlMDAxMWYxMjk2MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDExZjEyNzgwIGRncmFt ICAgICAgIDAgICAgICAwIGZmZmZmZTAwMTFmMmYzYzAgICAgICAgIDAgICAgICAgIDAgICAgICAg IDAgL3Zhci9uYW1lZC92YXIvcnVuL2xvZwpmZmZmZmUwMDExZjEyODcwIGRncmFtICAgICAgIDAg ICAgICAwIGZmZmZmZTAwMTFmMmY3ODAgICAgICAgIDAgZmZmZmZlMDAxMWYxNGI0MCAgICAgICAg MCAvdmFyL3J1bi9sb2cKZmZmZmZlMDAxMWYxMjk2MCBkZ3JhbSAgICAgICAwICAgICAgMCBmZmZm ZmUwMDExZjJmOTYwICAgICAgICAwIGZmZmZmZTAwMTE0MjdkMjAgICAgICAgIDAgL3Zhci9ydW4v bG9ncHJpdgpmZmZmZmUwMDExZjEyYTUwIGRncmFtICAgICAgIDAgICAgICAwIGZmZmZmZTAwMTFm MmZiNDAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vbG9nCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KbmV0c3RhdCAtYUwKCkN1cnJlbnQgbGlzdGVuIHF1ZXVlIHNpemVzIChxbGVuL2luY3Fs ZW4vbWF4cWxlbikKUHJvdG8gTGlzdGVuICAgICAgICAgTG9jYWwgQWRkcmVzcyAgICAgICAgIAp0 Y3A0ICAwLzAvMTI4ICAgICAgICAqLjIyMjIyICAgICAgICAgICAgICAgIAp0Y3A2ICAwLzAvMTI4 ICAgICAgICAqLjIyMjIyICAgICAgICAgICAgICAgIAp0Y3A0ICAwLzAvNjQgICAgICAgICAqLnRp bWUgICAgICAgICAgICAgICAgIAp0Y3A0ICAwLzAvMTAgICAgICAgICBsb2NhbGhvc3Quc210cCAg ICAgICAgIAp0Y3A0ICAwLzAvNTAgICAgICAgICAqLmJhY3VsYS1mZCAgICAgICAgICAgIAp0Y3A0 ICAwLzAvNDA5NiAgICAgICB4eHgueHh4LjEuMi5kaXNjbG9zZSAgICAKdGNwNCAgMC8wLzQwOTYg ICAgICAgKi5odHRwcyAgICAgICAgICAgICAgICAKdGNwNCAgMC8wLzQwOTYgICAgICAgKi5odHRw ICAgICAgICAgICAgICAgICAKdGNwNCAgMC8wLzEyOCAgICAgICAgKi5zbXV4ICAgICAgICAgICAg ICAgICAKdGNwNCAgMC8wLzIgICAgICAgICAgKi5wcHRwICAgICAgICAgICAgICAgICAKdGNwNCAg MC8wLzIgICAgICAgICAgbG9jYWxob3N0LjUwMDUgICAgICAgICAKdGNwNiAgMC8wLzEyOCAgICAg ICAgbG9jYWxob3N0LnJuZGMgICAgICAgICAKdGNwNCAgMC8wLzEyOCAgICAgICAgbG9jYWxob3N0 LnJuZGMgICAgICAgICAKdGNwNCAgMC8wLzMgICAgICAgICAgbG9jYWxob3N0LmRvbWFpbiAgICAg ICAKdW5peCAgMC8wLzQgICAgICAgICAgL3Zhci9ydW4vZGV2ZC5waXBlCnVuaXggIDAvMC80MDk2 ICAgICAgIC92YXIvcnVuL25zY2QKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpmc3RhdAoKVVNFUiAgICAgQ01E ICAgICAgICAgIFBJRCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9X CnJvb3QgICAgIGNzaCAgICAgICAgIDIxNTggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAxMDI0ICByCnJvb3QgICAgIGNzaCAgICAgICAgIDIxNTggICB3ZCAvICAgICAgICA5NTk4 NjE3NiBkcnd4ci14ci14ICAgICA1MTIgIHIKcm9vdCAgICAgY3NoICAgICAgICAgMjE1OCB0ZXh0 IC8gICAgICAgIDcxMDI2NjA1IC1yLXhyLXhyLXggIDM4MjI0OCAgcgpyb290ICAgICBjc2ggICAg ICAgICAyMTU4IGN0dHkgL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290 ICAgICBjc2ggICAgICAgICAyMTU4ICAgMTUgL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBw dHMvMCBydwpyb290ICAgICBjc2ggICAgICAgICAyMTU4ICAgMTYgL2RldiAgICAgICAgMTEyIGNy dy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgICAyMTU4ICAgMTcgL2RldiAg ICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2ggICAgICAgICAyMTU4 ICAgMTggL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpyb290ICAgICBjc2gg ICAgICAgICAyMTU4ICAgMTkgL2RldiAgICAgICAgMTEyIGNydy0tdy0tLS0gICBwdHMvMCBydwpy b290ICAgICBzc2hkICAgICAgICAyMTU2IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXgg ICAgMTAyNCAgcgpyb290ICAgICBzc2hkICAgICAgICAyMTU2ICAgd2QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBzc2hkICAgICAgICAyMTU2IHRleHQgLyAg ICAgICAgNTQzNDQzMzcgLXIteHIteHIteCAgMjY5NTQ0ICByCnJvb3QgICAgIHNzaGQgICAgICAg IDIxNTYgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAg IHNzaGQgICAgICAgIDIxNTYgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDIxNTYgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3 LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHNzaGQgICAgICAgIDIxNTYgICAgMyogaW50ZXJuZXQg c3RyZWFtIHRjcCBmZmZmZmUwMDI1MDY3M2QwCnJvb3QgICAgIHNzaGQgICAgICAgIDIxNTYgICAg NCogcGlwZSBmZmZmZmUwMDA3ZGM4ODg4IDwtPiBmZmZmZmUwMDA3ZGM4OWUwICAgICAgMCBydwpy b290ICAgICBzc2hkICAgICAgICAyMTU2ICAgIDUqIHBpcGUgZmZmZmZlMDAwN2RjODllMCA8LT4g ZmZmZmZlMDAwN2RjODg4OCAgICAgIDAgcncKcm9vdCAgICAgc3NoZCAgICAgICAgMjE1NiAgICA2 KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRzLzAgcncKcm9vdCAgICAgc3NoZCAgICAg ICAgMjE1NiAgICA4KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRzLzAgcncKcm9vdCAg ICAgc3NoZCAgICAgICAgMjE1NiAgICA5KiBwc2V1ZG8tdGVybWluYWwgbWFzdGVyICAgICAgcHRz LzAgcncKcm9vdCAgICAgZGV2ZCAgICAgICAgMjExMyByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMjExMyAgIHdkIC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMjExMyB0 ZXh0IC8gICAgICAgIDg0NjcwMTg4IC1yLXhyLXhyLXggIDQ1NDE4NCAgcgpyb290ICAgICBkZXZk ICAgICAgICAyMTEzICAgIDAgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpy b290ICAgICBkZXZkICAgICAgICAyMTEzICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0g ICAgbnVsbCBydwpyb290ICAgICBkZXZkICAgICAgICAyMTEzICAgIDIgL2RldiAgICAgICAgIDIy IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBkZXZkICAgICAgICAyMTEzICAgIDMgL2Rl diAgICAgICAgICA0IGNydy0tLS0tLS0gIGRldmN0bCAgcgpyb290ICAgICBkZXZkICAgICAgICAy MTEzICAgIDQqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExZjJkM2MwCnJvb3QgICAgIGRldmQgICAg ICAgIDIxMTMgICAgNSAvICAgICAgICAyMzQ0NDM4NyAtcnctLS0tLS0tICAgICAgIDQgIHcKcm9v dCAgICAgc3NoZCAgICAgICAgMjAxMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgc3NoZCAgICAgICAgMjAxMSAgIHdkIC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc3NoZCAgICAgICAgMjAxMSB0ZXh0IC8gICAg ICAgIDU0MzQ0MzM3IC1yLXhyLXhyLXggIDI2OTU0NCAgcgpyb290ICAgICBzc2hkICAgICAgICAy MDExICAgIDAgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBz c2hkICAgICAgICAyMDExICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBzc2hkICAgICAgICAyMDExICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1y dy0gICAgbnVsbCBydwpyb290ICAgICBzc2hkICAgICAgICAyMDExICAgIDMqIGludGVybmV0NiBz dHJlYW0gdGNwIGZmZmZmZTAwMjUzZGFiNzAKcm9vdCAgICAgc3NoZCAgICAgICAgMjAxMSAgICA0 KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAwMjUzZGE3YTAKcm9vdCAgICAgZ2V0dHkgICAg ICAgMTkyMyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMTkyMyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEw MjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMyB0ZXh0IC8gICAgICAgIDU0MzQ0MDYxIC1y LXhyLXhyLXggICAyODAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTIzIGN0dHkgL2RldiAg ICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIz ICAgIDAgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0 eSAgICAgICAxOTIzICAgIDEgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0gICB0dHl2NyBydwpy b290ICAgICBnZXR0eSAgICAgICAxOTIzICAgIDIgL2RldiAgICAgICAgIDUwIGNydy0tLS0tLS0g ICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIyIHJvb3QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTIyICAgd2QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAx OTIyIHRleHQgLyAgICAgICAgNTQzNDQwNjEgLXIteHIteHIteCAgIDI4MDI0ICByCnJvb3QgICAg IGdldHR5ICAgICAgIDE5MjIgY3R0eSAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXY2 IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjIgICAgMCAvZGV2ICAgICAgICAgNDkgY3J3LS0t LS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjIgICAgMSAvZGV2ICAgICAg ICAgNDkgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjIgICAg MiAvZGV2ICAgICAgICAgNDkgY3J3LS0tLS0tLSAgIHR0eXY2IHJ3CnJvb3QgICAgIGdldHR5ICAg ICAgIDE5MjEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5MjEgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAx MDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5MjEgdGV4dCAvICAgICAgICA1NDM0NDA2MSAt ci14ci14ci14ICAgMjgwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMSBjdHR5IC9kZXYg ICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTky MSAgICAwIC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djUgcncKcm9vdCAgICAgZ2V0 dHkgICAgICAgMTkyMSAgICAxIC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0tICAgdHR5djUgcncK cm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMSAgICAyIC9kZXYgICAgICAgICA0OCBjcnctLS0tLS0t ICAgdHR5djUgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMCByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkyMCAgIHdkIC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAg MTkyMCB0ZXh0IC8gICAgICAgIDU0MzQ0MDYxIC1yLXhyLXhyLXggICAyODAyNCAgcgpyb290ICAg ICBnZXR0eSAgICAgICAxOTIwIGN0dHkgL2RldiAgICAgICAgIDQ3IGNydy0tLS0tLS0gICB0dHl2 NCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIwICAgIDAgL2RldiAgICAgICAgIDQ3IGNydy0t LS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIwICAgIDEgL2RldiAgICAg ICAgIDQ3IGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTIwICAg IDIgL2RldiAgICAgICAgIDQ3IGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAg ICAgICAxOTE5IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290 ICAgICBnZXR0eSAgICAgICAxOTE5ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg MTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTE5IHRleHQgLyAgICAgICAgNTQzNDQwNjEg LXIteHIteHIteCAgIDI4MDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTkgY3R0eSAvZGV2 ICAgICAgICAgNDYgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5 MTkgICAgMCAvZGV2ICAgICAgICAgNDYgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdl dHR5ICAgICAgIDE5MTkgICAgMSAvZGV2ICAgICAgICAgNDYgY3J3LS0tLS0tLSAgIHR0eXYzIHJ3 CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTkgICAgMiAvZGV2ICAgICAgICAgNDYgY3J3LS0tLS0t LSAgIHR0eXYzIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTggcm9vdCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTggICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGdldHR5ICAgICAg IDE5MTggdGV4dCAvICAgICAgICA1NDM0NDA2MSAtci14ci14ci14ICAgMjgwMjQgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMTkxOCBjdHR5IC9kZXYgICAgICAgICA0NSBjcnctLS0tLS0tICAgdHR5 djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxOCAgICAwIC9kZXYgICAgICAgICA0NSBjcnct LS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxOCAgICAxIC9kZXYgICAg ICAgICA0NSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxOCAg ICAyIC9kZXYgICAgICAgICA0NSBjcnctLS0tLS0tICAgdHR5djIgcncKcm9vdCAgICAgZ2V0dHkg ICAgICAgMTkxNyByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9v dCAgICAgZ2V0dHkgICAgICAgMTkxNyAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMTkxNyB0ZXh0IC8gICAgICAgIDU0MzQ0MDYx IC1yLXhyLXhyLXggICAyODAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTE3IGN0dHkgL2Rl diAgICAgICAgIDQ0IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAx OTE3ICAgIDAgL2RldiAgICAgICAgIDQ0IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBn ZXR0eSAgICAgICAxOTE3ICAgIDEgL2RldiAgICAgICAgIDQ0IGNydy0tLS0tLS0gICB0dHl2MSBy dwpyb290ICAgICBnZXR0eSAgICAgICAxOTE3ICAgIDIgL2RldiAgICAgICAgIDQ0IGNydy0tLS0t LS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAxOTE2IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAgICAxOTE2ICAgd2Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBnZXR0eSAgICAg ICAxOTE2IHRleHQgLyAgICAgICAgNTQzNDQwNjEgLXIteHIteHIteCAgIDI4MDI0ICByCnJvb3Qg ICAgIGdldHR5ICAgICAgIDE5MTYgY3R0eSAvZGV2ICAgICAgICAgNDMgY3J3LS0tLS0tLSAgIHR0 eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTYgICAgMCAvZGV2ICAgICAgICAgNDMgY3J3 LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTYgICAgMSAvZGV2ICAg ICAgICAgNDMgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDE5MTYg ICAgMiAvZGV2ICAgICAgICAgNDMgY3J3LS0tLS0tLSAgIHR0eXYwIHJ3CnJvb3QgICAgIGluZXRk ICAgICAgIDE4OTkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJv b3QgICAgIGluZXRkICAgICAgIDE4OTkgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIGluZXRkICAgICAgIDE4OTkgdGV4dCAvICAgICAgICA1NDM0NDIw NiAtci14ci14ci14ICAgNDk3NzYgIHIKcm9vdCAgICAgaW5ldGQgICAgICAgMTg5OSAgICAwIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgaW5ldGQgICAgICAg MTg5OSAgICAxIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg aW5ldGQgICAgICAgMTg5OSAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgaW5ldGQgICAgICAgMTg5OSAgICAzIC8gICAgICAgIDIzNDQ0Mzk5IC1ydy0t LS0tLS0gICAgICAgNCAgdwpyb290ICAgICBpbmV0ZCAgICAgICAxODk5ICAgIDQqIHBpcGUgZmZm ZmZlMDAwN2RiNjJkOCA8LT4gZmZmZmZlMDAwN2RiNjQzMCAgICAgIDAgcncKcm9vdCAgICAgaW5l dGQgICAgICAgMTg5OSAgICA1KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAwMjUxY2U3YTAK cm9vdCAgICAgaW5ldGQgICAgICAgMTg5OSAgICA2KiBwaXBlIGZmZmZmZTAwMDdkYjY0MzAgPC0+ IGZmZmZmZTAwMDdkYjYyZDggICAgICAwIHJ3CnJvb3QgICAgIGNyb24gICAgICAgIDE4NDYgcm9v dCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGNyb24gICAg ICAgIDE4NDYgICB3ZCAvICAgICAgICAyMzQzNDc1OSBkcnd4ci14LS0tICAgICA1MTIgIHIKcm9v dCAgICAgY3JvbiAgICAgICAgMTg0NiB0ZXh0IC8gICAgICAgIDU0MzQ0MTUxIC1yLXhyLXhyLXgg ICA0MTQ0OCAgcgpyb290ICAgICBjcm9uICAgICAgICAxODQ2ICAgIDAgL2RldiAgICAgICAgIDIy IGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAxODQ2ICAgIDEgL2Rl diAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBjcm9uICAgICAgICAx ODQ2ICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBj cm9uICAgICAgICAxODQ2ICAgIDMgLyAgICAgICAgMjM0NDQzOTggLXJ3LS0tLS0tLSAgICAgICA0 ICB3CnJvb3QgICAgIGNyb24gICAgICAgIDE4NDYgICAgNSogbG9jYWwgZGdyYW0gZmZmZmZlMDAx MTQyN2QyMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApzbW1zcCAgICBzZW5kbWFpbCAgICAxODQyIHJv b3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpzbW1zcCAgICBzZW5kbWFp bCAgICAxODQyICAgd2QgLyAgICAgICAgMjM0MzQ3ODIgZHJ3eHJ3eC0tLSAgICAgNTEyICByCnNt bXNwICAgIHNlbmRtYWlsICAgIDE4NDIgdGV4dCAvICAgICAgICA1NDM0NDA5NiAtci14ci1zci14 ICA3MTkyNTYgIHIKc21tc3AgICAgc2VuZG1haWwgICAgMTg0MiAgICAwIC9kZXYgICAgICAgICAy MiBjcnctcnctcnctICAgIG51bGwgIHIKc21tc3AgICAgc2VuZG1haWwgICAgMTg0MiAgICAxIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHcKc21tc3AgICAgc2VuZG1haWwgICAg MTg0MiAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHcKc21tc3AgICAg c2VuZG1haWwgICAgMTg0MiAgICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDExZjE0YjQwIDwtPiBm ZmZmZmUwMDExZjEyODcwCnNtbXNwICAgIHNlbmRtYWlsICAgIDE4NDIgICAgNCAvICAgICAgICAy MzQ0NDM1MyAtcnctLS0tLS0tICAgICAgNTAgIHcKcm9vdCAgICAgc2VuZG1haWwgICAgMTgzOSBy b290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc2VuZG1h aWwgICAgMTgzOSAgIHdkIC8gICAgICAgIDIzNDM0Nzc5IGRyd3hyLXhyLXggICAgIDUxMiAgcgpy b290ICAgICBzZW5kbWFpbCAgICAxODM5IHRleHQgLyAgICAgICAgNTQzNDQwOTYgLXIteHItc3It eCAgNzE5MjU2ICByCnJvb3QgICAgIHNlbmRtYWlsICAgIDE4MzkgICAgMCAvZGV2ICAgICAgICAg MjIgY3J3LXJ3LXJ3LSAgICBudWxsICByCnJvb3QgICAgIHNlbmRtYWlsICAgIDE4MzkgICAgMSAv ZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsICB3CnJvb3QgICAgIHNlbmRtYWlsICAg IDE4MzkgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsICB3CnJvb3QgICAg IHNlbmRtYWlsICAgIDE4MzkgICAgMyogaW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1M2Ri M2QwCnJvb3QgICAgIHNlbmRtYWlsICAgIDE4MzkgICAgNCogbG9jYWwgZGdyYW0gZmZmZmZlMDAx MTQyN2UxMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApyb290ICAgICBzZW5kbWFpbCAgICAxODM5ICAg IDUgLyAgICAgICAgMjM0MzQ4NTQgLXJ3LS0tLS0tLSAgICAgIDc5ICB3CnJvb3QgICAgIGJhY3Vs YS1mZCAgIDE4Mjggcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJv b3QgICAgIGJhY3VsYS1mZCAgIDE4MjggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIGJhY3VsYS1mZCAgIDE4MjggdGV4dCAvICAgICAgICA1NDQxMzYz NyAtcnd4ci14ci14ICAyMDA4MDIgIHIKcm9vdCAgICAgYmFjdWxhLWZkICAgMTgyOCAgICAwIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHIKcm9vdCAgICAgYmFjdWxhLWZkICAg MTgyOCAgICAxIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHIKcm9vdCAgICAg YmFjdWxhLWZkICAgMTgyOCAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwg IHIKcm9vdCAgICAgYmFjdWxhLWZkICAgMTgyOCAgICAzKiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZm ZmZmZTAwMjUyMzRiNzAKbm9ib2R5ICAgZGFya3N0YXQgICAgMTgyNSByb290IC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKbm9ib2R5ICAgZGFya3N0YXQgICAgMTgyNSAgIHdk IC8gICAgICAgIDIzNTE1MDE2IGRyd3hyLXhyLXggICAgIDUxMiAgcgpub2JvZHkgICBkYXJrc3Rh dCAgICAxODI1IHRleHQgLyAgICAgICAgNTQ0MTQxNTUgLXIteHIteHIteCAgMTE5MDc1ICByCm5v Ym9keSAgIGRhcmtzdGF0ICAgIDE4MjUgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3Cm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjUgICAgMSAvZGV2ICAgICAgICAgMjIg Y3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjUgICAgMiAvZGV2 ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4 MjUgICAgMyogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMTE5YTNiNDAgPC0+IGZmZmZmZTAwMTE5YTNh NTAKbm9ib2R5ICAgZGFya3N0YXQgICAgMTgyNCByb290IC8gICAgICAgIDIzNTE1MDE2IGRyd3hy LXhyLXggICAgIDUxMiAgcgpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgd2QgLyAgICAgICAg MjM1MTUwMTYgZHJ3eHIteHIteCAgICAgNTEyICByCm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjQg amFpbCAvICAgICAgICAyMzUxNTAxNiBkcnd4ci14ci14ICAgICA1MTIgIHIKbm9ib2R5ICAgZGFy a3N0YXQgICAgMTgyNCB0ZXh0IC8gICAgICAgIDU0NDE0MTU1IC1yLXhyLXhyLXggIDExOTA3NSAg cgpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgIDAgL2RldiAgICAgICAgIDIyIGNydy1ydy1y dy0gICAgbnVsbCBydwpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgIDEgL2RldiAgICAgICAg IDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpub2JvZHkgICBkYXJrc3RhdCAgICAxODI0ICAgIDIg L2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpub2JvZHkgICBkYXJrc3RhdCAg ICAxODI0ICAgIDMgL2RldiAgICAgICAgIDExIGNydy0tLS0tLS0gICAgIGJwZiBydwpub2JvZHkg ICBkYXJrc3RhdCAgICAxODI0ICAgIDcqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExOWEzYTUwIDwt PiBmZmZmZmUwMDExOWEzYjQwCm5vYm9keSAgIGRhcmtzdGF0ICAgIDE4MjQgICAgOCogaW50ZXJu ZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1MjM1MDAwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTgg cm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCm5vYm9keSAgIG5naW54 ICAgICAgIDE4MTggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCm5v Ym9keSAgIG5naW54ICAgICAgIDE4MTggdGV4dCAvICAgICAgICA1NDQyNzI0NyAtci14ci14ci14 ICA2NzEwNDAgIHIKbm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgICAwIC9kZXYgICAgICAgICAy MiBjcnctcnctcnctICAgIG51bGwgcncKbm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgICAxIC9k ZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKbm9ib2R5ICAgbmdpbnggICAgICAg MTgxOCAgICAyIC8gICAgICAgIDIzNDM0OTMwIC1ydy1yLS1yLS0gICAgICAgMCAgdwpub2JvZHkg ICBuZ2lueCAgICAgICAxODE4ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExZjJkMDAwIDwt PiBmZmZmZmUwMDExZjE0ZTEwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTggICAgNCAvICAgICAg ICAyMzQzNDkzMCAtcnctci0tci0tICAgICAgIDAgIHcKbm9ib2R5ICAgbmdpbnggICAgICAgMTgx OCAgICA1IC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgIHcKbm9ib2R5ICAgbmdp bnggICAgICAgMTgxOCAgICA2KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZmZTAwMjUwNjZiNzAK bm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgICA3KiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZm ZTAwMjUwNjcwMDAKbm9ib2R5ICAgbmdpbnggICAgICAgMTgxOCAgIDEwKiBsb2NhbCBzdHJlYW0g ZmZmZmZlMDAxMWYxNGMzMCA8LT4gZmZmZmZlMDAxMWYxNGQyMApub2JvZHkgICBuZ2lueCAgICAg ICAxODE3IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpub2JvZHkg ICBuZ2lueCAgICAgICAxODE3ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAy NCAgcgpub2JvZHkgICBuZ2lueCAgICAgICAxODE3IHRleHQgLyAgICAgICAgNTQ0MjcyNDcgLXIt eHIteHIteCAgNjcxMDQwICByCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcgICAgMCAvZGV2ICAg ICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcg ICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm5vYm9keSAgIG5naW54 ICAgICAgIDE4MTcgICAgMiAvICAgICAgICAyMzQzNDkzMCAtcnctci0tci0tICAgICAgIDAgIHcK bm9ib2R5ICAgbmdpbnggICAgICAgMTgxNyAgICAzKiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAxMWYx NGQyMCA8LT4gZmZmZmZlMDAxMWYxNGMzMApub2JvZHkgICBuZ2lueCAgICAgICAxODE3ICAgIDQg LyAgICAgICAgMjM0MzQ5MzAgLXJ3LXItLXItLSAgICAgICAwICB3Cm5vYm9keSAgIG5naW54ICAg ICAgIDE4MTcgICAgNSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsICB3Cm5vYm9k eSAgIG5naW54ICAgICAgIDE4MTcgICAgNiogaW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1 MDY2YjcwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcgICAgNyogaW50ZXJuZXQgc3RyZWFtIHRj cCBmZmZmZmUwMDI1MDY3MDAwCm5vYm9keSAgIG5naW54ICAgICAgIDE4MTcgICAgOCogbG9jYWwg c3RyZWFtIGZmZmZmZTAwMTFmMTRlMTAgPC0+IGZmZmZmZTAwMTFmMmQwMDAKcm9vdCAgICAgbmdp bnggICAgICAgMTgxNiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK cm9vdCAgICAgbmdpbnggICAgICAgMTgxNiAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgIDEwMjQgIHIKcm9vdCAgICAgbmdpbnggICAgICAgMTgxNiB0ZXh0IC8gICAgICAgIDU0NDI3 MjQ3IC1yLXhyLXhyLXggIDY3MTA0MCAgcgpyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDAg L2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBuZ2lueCAgICAg ICAxODE2ICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAg ICBuZ2lueCAgICAgICAxODE2ICAgIDIgLyAgICAgICAgMjM0MzQ5MzAgLXJ3LXItLXItLSAgICAg ICAwICB3CnJvb3QgICAgIG5naW54ICAgICAgIDE4MTYgICAgMyogbG9jYWwgc3RyZWFtIGZmZmZm ZTAwMTFmMmQwMDAgPC0+IGZmZmZmZTAwMTFmMTRlMTAKcm9vdCAgICAgbmdpbnggICAgICAgMTgx NiAgICA0IC8gICAgICAgIDIzNDM0OTMwIC1ydy1yLS1yLS0gICAgICAgMCAgdwpyb290ICAgICBu Z2lueCAgICAgICAxODE2ICAgIDUgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCAg dwpyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDYqIGludGVybmV0IHN0cmVhbSB0Y3AgZmZm ZmZlMDAyNTA2NmI3MApyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDcqIGludGVybmV0IHN0 cmVhbSB0Y3AgZmZmZmZlMDAyNTA2NzAwMApyb290ICAgICBuZ2lueCAgICAgICAxODE2ICAgIDgq IGxvY2FsIHN0cmVhbSBmZmZmZmUwMDExZjE0ZTEwIDwtPiBmZmZmZmUwMDExZjJkMDAwCnJvb3Qg ICAgIG5naW54ICAgICAgIDE4MTYgICAgOSogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMTFmMTRkMjAg PC0+IGZmZmZmZTAwMTFmMTRjMzAKcm9vdCAgICAgbmdpbnggICAgICAgMTgxNiAgIDEwKiBsb2Nh bCBzdHJlYW0gZmZmZmZlMDAxMWYxNGMzMCA8LT4gZmZmZmZlMDAxMWYxNGQyMApyb290ICAgICBv cGVudnBuICAgICAxODA0IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAg cgpyb290ICAgICBvcGVudnBuICAgICAxODA0ICAgd2QgLyAgICAgICAgNTQ1NzQyOTQgZHJ3eHJ3 eHJ3eCAgICAgNTEyICByCnJvb3QgICAgIG9wZW52cG4gICAgIDE4MDQgdGV4dCAvICAgICAgICA1 NDQyNjk1NiAtci14ci14ci14ICA1MTU4MDggIHIKcm9vdCAgICAgb3BlbnZwbiAgICAgMTgwNCAg ICAwIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgb3BlbnZw biAgICAgMTgwNCAgICAxIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAgb3Bl bnZwbiAgICAgMTgwNCAgICAyIC0gICAgICAgICAtICAgICAgICAgYmFkICAgIC0Kcm9vdCAgICAg b3BlbnZwbiAgICAgMTgwNCAgICAzKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQyNTkz MApyb290ICAgICBvcGVudnBuICAgICAxODA0ICAgIDQqIGxvY2FsIGRncmFtIGZmZmZmZTAwMTFm MmQxZTAgPC0+IGZmZmZmZTAwMTFmMTI5NjAKcm9vdCAgICAgb3BlbnZwbiAgICAgMTgwNCAgICA1 IC9kZXYgICAgICAgIDExMSBjcnctLS0tLS0tICAgIHR1bjAgcncKcm9vdCAgICAgcG93ZXJkICAg ICAgMTc4MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgcG93ZXJkICAgICAgMTc4MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEw MjQgIHIKcm9vdCAgICAgcG93ZXJkICAgICAgMTc4MCB0ZXh0IC8gICAgICAgIDU0MzQ0MjkwIC1y LXhyLXhyLXggICAxNTYxNiAgcgpyb290ICAgICBwb3dlcmQgICAgICAxNzgwICAgIDAgL2RldiAg ICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb3dlcmQgICAgICAxNzgw ICAgIDEgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb3dl cmQgICAgICAxNzgwICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpy b290ICAgICBwb3dlcmQgICAgICAxNzgwICAgIDMgLyAgICAgICAgMjM0MzQ4MjUgLXJ3LS0tLS0t LSAgICAgICA0ICB3CnJvb3QgICAgIG50cGQgICAgICAgIDE3Nzcgcm9vdCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIG50cGQgICAgICAgIDE3NzcgICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIG50cGQgICAgICAg IDE3NzcgdGV4dCAvICAgICAgICA1NDM0NDI3MSAtci14ci14ci14ICAzOTI0NzIgIHIKcm9vdCAg ICAgbnRwZCAgICAgICAgMTc3NyAgICAwIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51 bGwgcncKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgICAxIC9kZXYgICAgICAgICAyMiBjcnct cnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgICAyIC9kZXYgICAg ICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAg ICAzKiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDExZjJkMmQwIDwtPiBmZmZmZmUwMDExZjEyOTYwCnJv b3QgICAgIG50cGQgICAgICAgIDE3NzcgICAyMCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZTAw MTE0MTVkYzgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgIDIxKiBpbnRlcm5ldDYgZGdyYW0g dWRwIGZmZmZmZTAwMTE0MTVhYjgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgIDIyKiBpbnRl cm5ldDYgZGdyYW0gdWRwIGZmZmZmZTAwMTE0MTU5MzAKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3 NyAgIDIzKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQxNTYyMApyb290ICAgICBudHBk ICAgICAgICAxNzc3ICAgMjQqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQxNTQ5OApy b290ICAgICBudHBkICAgICAgICAxNzc3ICAgMjUqIGludGVybmV0NiBkZ3JhbSB1ZHAgZmZmZmZl MDAxMTQxNTE4OApyb290ICAgICBudHBkICAgICAgICAxNzc3ICAgMjYqIGludGVybmV0NiBkZ3Jh bSB1ZHAgZmZmZmZlMDAxMTQxNTdhOApyb290ICAgICBudHBkICAgICAgICAxNzc3ICAgMjcqIGlu dGVybmV0IGRncmFtIHVkcCBmZmZmZmUwMDExNDE1YzQwCnJvb3QgICAgIG50cGQgICAgICAgIDE3 NzcgICAyOCogaW50ZXJuZXQgZGdyYW0gdWRwIGZmZmZmZTAwMTE0MjUzMTAKcm9vdCAgICAgbnRw ZCAgICAgICAgMTc3NyAgIDI5KiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZmZmZlMDAxMTQyNTAwMApy b290ICAgICBudHBkICAgICAgICAxNzc3ICAgMzAqIHJvdXRlIHJhdyAwIGZmZmZmZTAwMjUyMzgy YTgKcm9vdCAgICAgbnRwZCAgICAgICAgMTc3NyAgIDMxKiBpbnRlcm5ldCBkZ3JhbSB1ZHAgZmZm ZmZlMDAxMTQxNTMxMApyb290ICAgICBuc2NkICAgICAgICAxNzc0IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBuc2NkICAgICAgICAxNzc0ICAgd2Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBuc2NkICAgICAg ICAxNzc0IHRleHQgLyAgICAgICAgNTQzNDQyNjggLXIteHIteHIteCAgIDc1NzI4ICByCnJvb3Qg ICAgIG5zY2QgICAgICAgIDE3NzQgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBu dWxsIHJ3CnJvb3QgICAgIG5zY2QgICAgICAgIDE3NzQgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3 LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG5zY2QgICAgICAgIDE3NzQgICAgMiAvZGV2ICAg ICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG5zY2QgICAgICAgIDE3NzQg ICAgMyAvICAgICAgICAyMzQzNDgwMyAtcnctci0tci0tICAgICAgIDQgIHcKcm9vdCAgICAgbnNj ZCAgICAgICAgMTc3NCAgICA0KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAxMWYxNDAwMApyb290ICAg ICBzbm1wZCAgICAgICAxNzQ1IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAy NCAgcgpyb290ICAgICBzbm1wZCAgICAgICAxNzQ1ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgMTAyNCAgcgpyb290ICAgICBzbm1wZCAgICAgICAxNzQ1IHRleHQgLyAgICAgICAg NTQ0MTM5OTEgLXJ3eHIteHIteCAgIDI5MTIwICByCnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUg ICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHNubXBk ICAgICAgIDE3NDUgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJv b3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgMyAvICAgICAgICAyMzQzNDk0 MSAtcnctci0tci0tICAgIDYwMzQgIHcKcm9vdCAgICAgc25tcGQgICAgICAgMTc0NSAgICA0IC9k ZXYgICAgICAgICAxNiBjcnctci0tLS0tICAgICBtZW0gIHIKcm9vdCAgICAgc25tcGQgICAgICAg MTc0NSAgICA1IC9kZXYgICAgICAgICAxNyBjcnctci0tLS0tICAgIGttZW0gIHIKcm9vdCAgICAg c25tcGQgICAgICAgMTc0NSAgICA2KiBwaXBlIGZmZmZmZTAwMDdkYzgyZDggPC0+IGZmZmZmZTAw MDdkYzg0MzAgICAgICAwIHJ3CnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgNyogcGlwZSBm ZmZmZmUwMDA3ZGM4NDMwIDwtPiBmZmZmZmUwMDA3ZGM4MmQ4ICAgICAgMCBydwpyb290ICAgICBz bm1wZCAgICAgICAxNzQ1ICAgIDggLyAgICAgICAgMjM0MzQ4MjIgLXJ3LXItLS0tLSAgICAxNDQ4 ICByCnJvb3QgICAgIHNubXBkICAgICAgIDE3NDUgICAgOSogaW50ZXJuZXQgZGdyYW0gdWRwIGZm ZmZmZTAwMTE0NTk0OTgKcm9vdCAgICAgc25tcGQgICAgICAgMTc0NSAgIDEwKiBpbnRlcm5ldCBz dHJlYW0gdGNwIGZmZmZmZTAwMjUyMzUzZDAKcm9vdCAgICAgc25tcHRyYXBkICAgMTc0MSByb290 IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgc25tcHRyYXBk ICAgMTc0MSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAg ICAgc25tcHRyYXBkICAgMTc0MSB0ZXh0IC8gICAgICAgIDU0NDEzOTkzIC1yd3hyLXhyLXggICAy ODkwNCAgcgpyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDAgL2RldiAgICAgICAgIDIyIGNy dy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDEgL2RldiAg ICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzbm1wdHJhcGQgICAxNzQx ICAgIDIgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBzbm1w dHJhcGQgICAxNzQxICAgIDMgL2RldiAgICAgICAgIDE2IGNydy1yLS0tLS0gICAgIG1lbSAgcgpy b290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDQgL2RldiAgICAgICAgIDE3IGNydy1yLS0tLS0g ICAga21lbSAgcgpyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgIDUqIHBpcGUgZmZmZmZlMDAw N2Q5NjViMCA8LT4gZmZmZmZlMDAwN2Q5NjcwOCAgICAgIDAgcncKcm9vdCAgICAgc25tcHRyYXBk ICAgMTc0MSAgICA2KiBwaXBlIGZmZmZmZTAwMDdkOTY3MDggPC0+IGZmZmZmZTAwMDdkOTY1YjAg ICAgICAwIHJ3CnJvb3QgICAgIHNubXB0cmFwZCAgIDE3NDEgICAgNyogcGlwZSBmZmZmZmUwMDA3 ZDIxYjYwIDwtPiBmZmZmZmUwMDA3ZDIxY2I4ICAgICAgMCBydwpyb290ICAgICBzbm1wdHJhcGQg ICAxNzQxICAgIDgqIHBpcGUgZmZmZmZlMDAwN2QyMWNiOCA8LT4gZmZmZmZlMDAwN2QyMWI2MCAg ICAgIDAgcncKcm9vdCAgICAgc25tcHRyYXBkICAgMTc0MSAgICA5KiBpbnRlcm5ldCBkZ3JhbSB1 ZHAgZmZmZmZlMDAxMTQyNTYyMApyb290ICAgICBzbm1wdHJhcGQgICAxNzQxICAgMTAqIGxvY2Fs IGRncmFtIGZmZmZmZTAwMTFmMTI1YTAgPC0+IGZmZmZmZTAwMTFmMTI5NjAKcm9vdCAgICAgbmdf cXVldWUgICAgMTc0MCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIK cm9vdCAgICAgbmdfcXVldWUgICAgMTc0MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgIDEwMjQgIHIKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAgIHdkIC8g ICAgICAgIDU0NTc1MjA5IGRyd3hyLXhyLXggICAgIDUxMiAgcgpyb290ICAgICBtcGQ1ICAgICAg ICAxNzM0IHRleHQgLyAgICAgICAgNTQ0MjY5NTggLXIteHIteHIteCAgNjQ5NzQ0ICByCnJvb3Qg ICAgIG1wZDUgICAgICAgIDE3MzQgICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBu dWxsIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3 LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgMiAvZGV2ICAg ICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQg ICAgMyogbG9jYWwgZGdyYW0gZmZmZmZlMDAxMWYxNDBmMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApy b290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgIDQgLyAgICAgICAgMjM0MzQ4MDAgLXJ3LXItLXIt LSAgICAgICA1IHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgNSogbmV0Z3JhcGggZGdy YW0gMiBmZmZmZmUwMDExNDRhNTUwCnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAgNiogbmV0 Z3JhcGggZGdyYW0gMSBmZmZmZmUwMDExNDRhYWEwCnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQg ICAgNyogcGlwZSBmZmZmZmUwMDA3ZDk2MmQ4IDwtPiBmZmZmZmUwMDA3ZDk2NDMwICAgICAgMCBy dwpyb290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgIDgqIHBpcGUgZmZmZmZlMDAwN2Q5NjQzMCA8 LT4gZmZmZmZlMDAwN2Q5NjJkOCAgICAgIDAgcncKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAg ICA5KiBuZXRncmFwaCBkZ3JhbSAyIGZmZmZmZTAwMTE0MjQ3ZjgKcm9vdCAgICAgbXBkNSAgICAg ICAgMTczNCAgIDEwKiBuZXRncmFwaCBkZ3JhbSAxIGZmZmZmZTAwMTE0NGFkNDgKcm9vdCAgICAg bXBkNSAgICAgICAgMTczNCAgIDExKiBuZXRncmFwaCBkZ3JhbSAyIGZmZmZmZTAwMTE0NTg1NTAK cm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAgIDEyKiBuZXRncmFwaCBkZ3JhbSAxIGZmZmZmZTAw MTE0NTg3ZjgKcm9vdCAgICAgbXBkNSAgICAgICAgMTczNCAgIDEzKiBwaXBlIGZmZmZmZTAwMDdk ODdiNjAgPC0+IGZmZmZmZTAwMDdkODdjYjggICAgICAwIHJ3CnJvb3QgICAgIG1wZDUgICAgICAg IDE3MzQgICAxNCogcGlwZSBmZmZmZmUwMDA3ZDg3Y2I4IDwtPiBmZmZmZmUwMDA3ZDg3YjYwICAg ICAgMCBydwpyb290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgMTYqIGludGVybmV0IHN0cmVhbSB0 Y3AgZmZmZmZlMDAyNTFjZTNkMApyb290ICAgICBtcGQ1ICAgICAgICAxNzM0ICAgMTgqIHBpcGUg ZmZmZmZlMDAwN2Q4Nzg4OCA8LT4gZmZmZmZlMDAwN2Q4NzllMCAgICAgIDAgcncKcm9vdCAgICAg bXBkNSAgICAgICAgMTczNCAgIDE5KiBwaXBlIGZmZmZmZTAwMDdkODc5ZTAgPC0+IGZmZmZmZTAw MDdkODc4ODggICAgICAwIHJ3CnJvb3QgICAgIG1wZDUgICAgICAgIDE3MzQgICAyMCogaW50ZXJu ZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1MWNlMDAwCmJpbmQgICAgIG5hbWVkICAgICAgIDE2Njcg cm9vdCAvICAgICAgICAyMzQzNDc2NyBkcnd4ci14ci14ICAgICA1MTIgIHIKYmluZCAgICAgbmFt ZWQgICAgICAgMTY2NyAgIHdkIC8gICAgICAgIDIzNDM0Nzk5IGRyd3hyLXhyLXggICAgIDUxMiAg cgpiaW5kICAgICBuYW1lZCAgICAgICAxNjY3IGphaWwgLyAgICAgICAgMjM0MzQ3NjcgZHJ3eHIt eHIteCAgICAgNTEyICByCmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgdGV4dCAvICAgICAgICA1 NDM0NDIzMCAtci14ci14ci14ICAyMjMxNjk2ICByCmJpbmQgICAgIG5hbWVkICAgICAgIDE2Njcg ICAgMCAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CmJpbmQgICAgIG5hbWVk ICAgICAgIDE2NjcgICAgMSAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CmJp bmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAgMiAvZGV2ICAgICAgICAgMjIgY3J3LXJ3LXJ3LSAg ICBudWxsIHJ3CmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAgMyogbG9jYWwgZGdyYW0gZmZm ZmZlMDAxMWYxNDFlMCA8LT4gZmZmZmZlMDAxMWYxMjk2MApiaW5kICAgICBuYW1lZCAgICAgICAx NjY3ICAgIDQgL2RldiAgICAgICAgIDIyIGNydy1ydy1ydy0gICAgbnVsbCBydwpiaW5kICAgICBu YW1lZCAgICAgICAxNjY3ICAgIDYqIHBpcGUgZmZmZmZlMDAwN2QyMDg4OCA8LT4gZmZmZmZlMDAw N2QyMDllMCAgICAgIDAgcncKYmluZCAgICAgbmFtZWQgICAgICAgMTY2NyAgICA4KiBwaXBlIGZm ZmZmZTAwMDdkMjA5ZTAgPC0+IGZmZmZmZTAwMDdkMjA4ODggICAgICAwIHJ3CmJpbmQgICAgIG5h bWVkICAgICAgIDE2NjcgICAxMCAvdmFyL25hbWVkL2RldiAgICAgMjYgY3J3LXJ3LXJ3LSAgcmFu ZG9tICByCmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAyMCogaW50ZXJuZXQgc3RyZWFtIHRj cCBmZmZmZmUwMDI1MDY2M2QwCmJpbmQgICAgIG5hbWVkICAgICAgIDE2NjcgICAyMSogaW50ZXJu ZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDI1MDY2MDAwCmJpbmQgICAgIG5hbWVkICAgICAgIDE2Njcg ICAyMiogaW50ZXJuZXQ2IHN0cmVhbSB0Y3AgZmZmZmZlMDAyNTA2NjdhMApiaW5kICAgICBuYW1l ZCAgICAgICAxNjY3ICA1MTIqIGludGVybmV0IGRncmFtIHVkcCBmZmZmZmUwMDExNDI1MTg4CnJv b3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAxMDI0ICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgICB3ZCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgdGV4dCAvICAg ICAgICA1NDM0NDMzOSAtci14ci14ci14ICAgNDA2ODAgIHIKcm9vdCAgICAgc3lzbG9nZCAgICAg MTU4MSAgICAwIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAg c3lzbG9nZCAgICAgMTU4MSAgICAxIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgICAyIC9kZXYgICAgICAgICAyMiBjcnctcnct cnctICAgIG51bGwgcncKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgICAzIC8gICAgICAgIDIz NDQ0MzkxIC1ydy0tLS0tLS0gICAgICAgNCAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTgxICAg IDQqIGxvY2FsIGRncmFtIGZmZmZmZTAwMTFmMTJhNTAKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4 MSAgICA1KiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDExZjEyOTYwCnJvb3QgICAgIHN5c2xvZ2QgICAg IDE1ODEgICAgNiogbG9jYWwgZGdyYW0gZmZmZmZlMDAxMWYxMjg3MApyb290ICAgICBzeXNsb2dk ICAgICAxNTgxICAgIDcqIGxvY2FsIGRncmFtIGZmZmZmZTAwMTFmMTI3ODAKcm9vdCAgICAgc3lz bG9nZCAgICAgMTU4MSAgICA4IC9kZXYgICAgICAgICAgOSBjcnctLS0tLS0tICAgIGtsb2cgIHIK cm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDEwIC9kZXYgICAgICAgICAgNSBjcnctLS0tLS0t ICBjb25zb2xlICB3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgICAxMSAvICAgICAgICAyMzQz NDg0NiAtcnctci0tci0tICAgICAzMjAgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDEy IC8gICAgICAgIDIzNDM0ODMzIC1ydy0tLS0tLS0gICAgICA1OSAgdwpyb290ICAgICBzeXNsb2dk ICAgICAxNTgxICAgMTMgLyAgICAgICAgMjM0MzQ4MjYgLXJ3LS0tLS0tLSAgIDMzODIzICB3CnJv b3QgICAgIHN5c2xvZ2QgICAgIDE1ODEgICAxNCAvICAgICAgICAyMzQzNDg4OCAtcnctci0tLS0t ICAgIDM0MzYgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDE1IC8gICAgICAgIDIzNDM0 ODI5IC1ydy1yLS1yLS0gICAgICA1OSAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTgxICAgMTYg LyAgICAgICAgMjM0MzQ4MzQgLXJ3LS0tLS0tLSAgICAgIDU5ICB3CnJvb3QgICAgIHN5c2xvZ2Qg ICAgIDE1ODEgICAxNyAvICAgICAgICAyMzQzNDgzNiAtcnctLS0tLS0tICAgNzYxMDAgIHcKcm9v dCAgICAgc3lzbG9nZCAgICAgMTU4MSAgIDE4IC8gICAgICAgIDIzNDM0ODI4IC1ydy0tLS0tLS0g ICAgICA1OSAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNTgxICAgMTkgLyAgICAgICAgMjM0MzQ4 MzIgLXJ3LXItLS0tLSAgICAgIDU5ICB3CnJvb3QgICAgIGFkamtlcm50eiAgICAxNjAgcm9vdCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAgIGFkamtlcm50eiAg ICAxNjAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAxMDI0ICByCnJvb3QgICAg IGFkamtlcm50eiAgICAxNjAgdGV4dCAvICAgICAgICA4NDY3MDE3NyAtci14ci14ci14ICAgIDky NDggIHIKcm9vdCAgICAgYWRqa2VybnR6ICAgIDE2MCAgICAwIC9kZXYgICAgICAgICAyMiBjcnct cnctcnctICAgIG51bGwgcncKcm9vdCAgICAgYWRqa2VybnR6ICAgIDE2MCAgICAxIC9kZXYgICAg ICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgYWRqa2VybnR6ICAgIDE2MCAg ICAyIC9kZXYgICAgICAgICAyMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgaW5pdCAg ICAgICAgICAgMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgIDEwMjQgIHIKcm9v dCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg IDEwMjQgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSB0ZXh0IC8gICAgICAgIDg0NjcwMjE0 IC1yLXhyLXhyLXggIDc5MTM4NCAgcgpyb290ICAgICBrZXJuZWwgICAgICAgICAwIHJvb3QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgpyb290ICAgICBrZXJuZWwgICAgICAg ICAwICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgMTAyNCAgcgoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCmRtZXNnCgpDb3B5cmlnaHQgKGMpIDE5OTItMjAxMiBUaGUgRnJlZUJTRCBQcm9qZWN0 LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEs IDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlm b3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRl bWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDkuMS1SRUxFQVNFICMwIHIy NDM4MjU6IFR1ZSBEZWMgIDQgMDk6MjM6MTAgVVRDIDIwMTIKICAgIHJvb3RAZmFycmVsbC5jc2Uu YnVmZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQyBhbWQ2NApDUFU6IEludGVs KFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNTQwNSAgQCAyLjAwR0h6ICgxOTk1LjA0LU1IeiBL OC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgxMDY3NiAgRmFt aWx5ID0gNiAgTW9kZWwgPSAxNyAgU3RlcHBpbmcgPSA2CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxG UFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxD TU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxU TSxQQkU+CiAgRmVhdHVyZXMyPTB4Y2UzM2Q8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxWTVgsVE0y LFNTU0UzLENYMTYseFRQUixQRENNLERDQSxTU0U0LjE+CiAgQU1EIEZlYXR1cmVzPTB4MjAwMDA4 MDA8U1lTQ0FMTCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBp bnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5 NiAoNDA5NiBNQikKYXZhaWwgbWVtb3J5ID0gNDA4NDYyOTUwNCAoMzg5NSBNQikKRXZlbnQgdGlt ZXIgIkxBUElDIiBxdWFsaXR5IDQwMApBQ1BJIEFQSUMgVGFibGU6IDxJQk0gICAgU0VSREVGTlQ+ CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpGcmVl QlNEL1NNUDogMSBwYWNrYWdlKHMpIHggNCBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAg MAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElEOiAgMgogY3B1MyAo QVApOiBBUElDIElEOiAgMwppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhl cmJvYXJkCmtiZDEgYXQga2JkbXV4MAphY3BpMDogPElCTSBTRVJERUZOVD4gb24gbW90aGVyYm9h cmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6 IDxBQ1BJIENQVT4gb24gYWNwaTAKYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMg aXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5 IDEwMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzMgaXJxIDggb24g YWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApocGV0 MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAz ZmYgb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFs aXR5IDk1MApFdmVudCB0aW1lciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkg NDUwCkV2ZW50IHRpbWVyICJIUEVUMSIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQw CkV2ZW50IHRpbWVyICJIUEVUMiIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDQwClRp bWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFj cGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NTg4LTB4NThi IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaWIwOiBM ZW5ndGggbWlzbWF0Y2ggZm9yIDMgcmFuZ2U6IGMwMDAwMDAwIHZzIGZmZmZmZmZmYzAwMDAwMDAK cGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKcGNpMTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBj aWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2kxNgpwY2kxNzog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTE3CnBjaTE5OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMTcKcGNpMTg6IDxBQ1BJ IFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDAuMyBvbiBwY2kxNgpwY2kyMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpYjY6IDxQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaTM1OiA8UENJIGJ1cz4gb24gcGNp YjYKcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNC4wIG9uIHBjaTAKcGNp NzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpYjg6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDUuMCBvbiBwY2kwCnBjaTM0OiA8UENJIGJ1cz4gb24gcGNpYjgKcGNpYjk6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNi4wIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjkKcGNpYjEwOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24gcGNpMwpw Y2k0OiA8UENJIGJ1cz4gb24gcGNpYjEwCmJjZTA6IDxCcm9hZGNvbSBOZXRYdHJlbWUgSUkgQkNN NTcwOCAxMDAwQmFzZS1UIChCMik+IG1lbSAweGM4MDAwMDAwLTB4YzlmZmZmZmYgaXJxIDE4IGF0 IGRldmljZSAwLjAgb24gcGNpNAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmNlMApicmdwaHkwOiA8 QkNNNTcwOEMgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKYnJn cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEw MDBiYXNlVCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1t YXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpiY2UwOiBFdGhlcm5ldCBhZGRyZXNzOiB4eDp4eDp4eDp4 eDp4eDoyYQpiY2UwOiBBU0lDICgweDU3MDgxMDIwKTsgUmV2IChCMik7IEJ1cyAoUENJLVgsIDY0 LWJpdCwgMTMzTUh6KTsgQi9DICg0LjAuMyk7IEJ1ZnMgKFJYOjI7VFg6MjtQRzo4KTsgRmxhZ3Mg KFNQTFR8TVNJfE1GVyk7IE1GVyAoaXBtcyAxLjYuMCkKQ29hbCAoUlg6Niw2LDE4LDE4OyBUWDoy MCwyMCw4MCw4MCkKcGNpYjExOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBv biBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMQphYWMwOiA8SUJNIFNlcnZlUkFJ RC04az4gcG9ydCAweDQwMDAtMHg0MGZmIG1lbSAweGNjZTAwMDAwLTB4Y2NmZmZmZmYsMHhjYWZl MDAwMC0weGNhZmZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYWFjMDogRW5hYmxp bmcgNjQtYml0IGFkZHJlc3Mgc3VwcG9ydAphYWMwOiBFbmFibGUgUmF3IEkvTwphYWMwOiBFbmFi bGUgNjQtYml0IGFycmF5CmFhYzA6IE5ldyBjb21tLiBpbnRlcmZhY2UgZW5hYmxlZAphYWMwOiBT ZXJ2ZVJBSUQgOGstbCAgLCBhYWMgZHJpdmVyIDIuMS45LTEKcGNpMDogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDguMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMTI6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMTIKcGNpYjEzOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24g cGNpNQpwY2k2OiA8UENJIGJ1cz4gb24gcGNpYjEzCmJjZTE6IDxCcm9hZGNvbSBOZXRYdHJlbWUg SUkgQkNNNTcwOCAxMDAwQmFzZS1UIChCMik+IG1lbSAweGNlMDAwMDAwLTB4Y2ZmZmZmZmYgaXJx IDE2IGF0IGRldmljZSAwLjAgb24gcGNpNgptaWlidXMxOiA8TUlJIGJ1cz4gb24gYmNlMQpicmdw aHkxOiA8QkNNNTcwOEMgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1 czEKYnJncGh5MTogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1G RFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VU LUZEWC1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpiY2UxOiBFdGhlcm5ldCBhZGRyZXNzOiB4eDp4 eDp4eDp4eDp4eDoyYwpiY2UxOiBBU0lDICgweDU3MDgxMDIwKTsgUmV2IChCMik7IEJ1cyAoUENJ LVgsIDY0LWJpdCwgMTMzTUh6KTsgQi9DICg0LjAuMyk7IEJ1ZnMgKFJYOjI7VFg6MjtQRzo4KTsg RmxhZ3MgKFNQTFR8TVNJfE1GVyk7IE1GVyAoaXBtcyAxLjYuMCkKQ29hbCAoUlg6Niw2LDE4LDE4 OyBUWDoyMCwyMCw4MCw4MCkKdWhjaTA6IDxJbnRlbCA2MzFYRVNCLzYzMlhFU0IvMzEwMCBVU0Ig Y29udHJvbGxlciBVU0ItMT4gcG9ydCAweDIyMDAtMHgyMjFmIGlycSAyMyBhdCBkZXZpY2UgMjku MCBvbiBwY2kwCnVzYnVzMCBvbiB1aGNpMAp1aGNpMTogPEludGVsIDYzMVhFU0IvNjMyWEVTQi8z MTAwIFVTQiBjb250cm9sbGVyIFVTQi0yPiBwb3J0IDB4MjYwMC0weDI2MWYgaXJxIDIyIGF0IGRl dmljZSAyOS4xIG9uIHBjaTAKdXNidXMxIG9uIHVoY2kxCnVoY2kyOiA8SW50ZWwgNjMxWEVTQi82 MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTM+IHBvcnQgMHgyYTAwLTB4MmExZiBpcnEg MjMgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1c2J1czIgb24gdWhjaTIKZWhjaTA6IDxJbnRlbCA2 M1hYRVNCIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjkwMDAwMDAtMHhmOTAwMDNmZiBpcnEg MjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMz IG9uIGVoY2kwCnBjaWIxNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9u IHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjE0CnZnYXBjaTA6IDxWR0EtY29tcGF0 aWJsZSBkaXNwbGF5PiBwb3J0IDB4MzAwMC0weDMwZmYgbWVtIDB4ZDAwMDAwMDAtMHhkN2ZmZmZm ZiwweGRmZmYwMDAwLTB4ZGZmZmZmZmYgaXJxIDIyIGF0IGRldmljZSAxLjAgb24gcGNpMQppc2Fi MDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVz PiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgNjNYWEVTQjIgVURNQTEwMCBjb250cm9sbGVyPiBw b3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4NDgwLTB4NDhmIGF0IGRl dmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYXRh cGNpMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIg YXR0YWNoZWQpCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjYWZm ZiwweGNiMDAwLTB4Y2ZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+ CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g YXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IGNhbm5v dCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmN0bDogQ0FNIFRhcmdldCBMYXllciBsb2FkZWQKcDR0 Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKcDR0Y2MxOiA8Q1BV IEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5j eSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTIKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFs IENvbnRyb2w+IG9uIGNwdTMKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpJUCBG aWx0ZXI6IHY0LjEuMjggaW5pdGlhbGl6ZWQuICBEZWZhdWx0ID0gcGFzcyBhbGwsIExvZ2dpbmcg PSBlbmFibGVkCmlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBsb2FkYWJsZSwgbmF0 IGxvYWRhYmxlLCBydWxlLWJhc2VkIGZvcndhcmRpbmcgZGlzYWJsZWQsIGRlZmF1bHQgdG8gYWNj ZXB0LCBsb2dnaW5nIGRpc2FibGVkCkRVTU1ZTkVUIDAgd2l0aCBJUHY2IGluaXRpYWxpemVkICgx MDA0MDkpCmxvYWRfZG5fc2NoZWQgZG5fc2NoZWQgRklGTyBsb2FkZWQKbG9hZF9kbl9zY2hlZCBk bl9zY2hlZCBRRlEgbG9hZGVkCmxvYWRfZG5fc2NoZWQgZG5fc2NoZWQgUlIgbG9hZGVkCmxvYWRf ZG5fc2NoZWQgZG5fc2NoZWQgV0YyUSsgbG9hZGVkCmxvYWRfZG5fc2NoZWQgZG5fc2NoZWQgUFJJ TyBsb2FkZWQKYWFjZDAgb24gYWFjMAphYWNkMDogOTUzNjg5TUIgKDE5NTMxNTUwNzIgc2VjdG9y cykKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMz OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAK dWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwg VUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz MQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPElu dGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVo dWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApjZDAgYXQgYXRhMCBi dXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8TUFUU0hJVEEgVUpEQTc4MCBEVkQvQ0RS VyBDQTIxPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMzMuMzAwTUIvcyB0 cmFuc2ZlcnMgKFVETUEyLCBBVEFQSSAxMmJ5dGVzLCBQSU8gNjU1MzRieXRlcykKY2QwOiBBdHRl bXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHBy ZXNlbnQgLSB0cmF5IGNsb3NlZApTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKU01QOiBBUCBDUFUg IzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpUaW1lY291bnRlciAiVFNDLWxv dyIgZnJlcXVlbmN5IDE1NTg2MjM4IEh6IHF1YWxpdHkgMTAwMApUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L2FhY2QwcDIgW3J3XS4uLgpXQVJOSU5HOiAvIHdhcyBub3QgcHJvcGVy bHkgZGlzbW91bnRlZApXQVJOSU5HOiAvOiBtb3VudCBwZW5kaW5nIGVycm9yOiBibG9ja3MgMCBm aWxlcyA4ClNldHRpbmcgaG9zdHV1aWQ6IDZmZTNkODRmLTgxOTItMzFjNi04MmExLWFmOTRiNGU1 MDc5ZC4KU2V0dGluZyBob3N0aWQ6IDB4M2JlZTkxMTAuCkVudHJvcHkgaGFydmVzdGluZzogaW50 ZXJydXB0cyBldGhlcm5ldCBwb2ludF90b19wb2ludCBraWNrc3RhcnQuClN0YXJ0aW5nIGZpbGUg c3lzdGVtIGNoZWNrczoKdWdlbjEuMjogPHZlbmRvciAweDA5ZGE+IGF0IHVzYnVzMQp1a2JkMDog PHZlbmRvciAweDA5ZGEgVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzIuNTAsIGFk ZHIgMj4gb24gdXNidXMxCioqIFNVK0ogUmVjb3ZlcmluZyAvZGV2L2FhY2QwcDIKKiogUmVhZGlu ZyAzMzU1NDQzMiBieXRlIGpvdXJuYWwgZnJvbSBpbm9kZSA0LgprYmQyIGF0IHVrYmQwCnVoaWQw OiA8dmVuZG9yIDB4MDlkYSBVU0IgS2V5Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMi41MCwg YWRkciAyPiBvbiB1c2J1czEKKiogQnVpbGRpbmcgcmVjb3ZlcnkgdGFibGUuCioqIFJlc29sdmlu ZyB1bnJlZmVyZW5jZWQgaW5vZGUgbGlzdC4KKiogUHJvY2Vzc2luZyBqb3VybmFsIGVudHJpZXMu CioqIDEyNiBqb3VybmFsIHJlY29yZHMgaW4gODcwNCBieXRlcyBmb3IgNDYuMzIlIHV0aWxpemF0 aW9uCioqIEZyZWVkIDEzIGlub2RlcyAoOSBkaXJzKSAwIGJsb2NrcywgYW5kIDQgZnJhZ3MuCgoq KioqKiBGSUxFIFNZU1RFTSBNQVJLRUQgQ0xFQU4gKioqKioKTW91bnRpbmcgbG9jYWwgZmlsZSBz eXN0ZW1zOi4KU2V0dGluZyBob3N0bmFtZTogbm9uYW1laG9zdC5sb2NhbC4KQWRkaXRpb25hbCBU Q1AvSVAgb3B0aW9uczogZHJvcCBTWU4rRklOIHBhY2tldHM9WUVTLgpJbnN0YWxsaW5nIE5BVCBy dWxlcy4KMCBlbnRyaWVzIGZsdXNoZWQgZnJvbSBOQVQgdGFibGUKMCBlbnRyaWVzIGZsdXNoZWQg ZnJvbSBOQVQgbGlzdApTdGFydGluZyBOZXR3b3JrOiBsbzAgYmNlMCBiY2UxIGlwZncwIHZsYW4x MSB2bGFuMjIgY2FycDAuCmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJ Q0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0CglvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhDU1VNLFJY Q1NVTV9JUFY2LFRYQ1NVTV9JUFY2PgoJaW5ldDYgOjoxIHByZWZpeGxlbiAxMjggCglpbmV0NiBm ZTgwOjoxJWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDggCglpbmV0IDEyNy4wLjAuMSBuZXRt YXNrIDB4ZmYwMDAwMDAgCgluZDYgb3B0aW9ucz0yMTxQRVJGT1JNTlVELEFVVE9fTElOS0xPQ0FM PgpiY2UwOiBmbGFncz04OTQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFBST01JU0MsU0lNUExFWCxN VUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0s VkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9I V1RTTyxMSU5LU1RBVEU+CglldGhlciB4eDp4eDp4eDp4eDp4eDoyYQoJaW5ldDYgeHh4eDo6eHh4 Onh4eHg6eHh4eDplYzJhJWJjZTAgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlkIDB4MSAK CWluZXQgeHh4Lnh4eC4xLjIgbmV0bWFzayAweGZmZmYwMDAwIGJyb2FkY2FzdCB4eHgueHh4LjI1 NS4yNTUKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NB TD4KCW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0IChub25lKQoJc3RhdHVzOiBubyBjYXJyaWVy CmJjZTE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+ IG1ldHJpYyAwIG10dSAxNTAwCglvcHRpb25zPWMwMWJiPFJYQ1NVTSxUWENTVU0sVkxBTl9NVFUs VkxBTl9IV1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQsVkxBTl9IV1RTTyxMSU5L U1RBVEU+CglldGhlciB4eDp4eDp4eDp4eDp4eDoyYwoJaW5ldDYgeHh4eDo6eHh4Onh4eHg6eHh4 eDplYzJjJWJjZTEgcHJlZml4bGVuIDY0IHRlbnRhdGl2ZSBzY29wZWlkIDB4MiAKCW5kNiBvcHRp b25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCW1lZGlhOiBFdGhl cm5ldCBhdXRvc2VsZWN0IChub25lKQoJc3RhdHVzOiBubyBjYXJyaWVyCmlwZncwOiBmbGFncz04 ODAxPFVQLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgNjU1MzYKCW5kNiBvcHRpb25z PTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KdmxhbjExOiBmbGFncz04 ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUg MTUwMAoJb3B0aW9ucz0xMDM8UlhDU1VNLFRYQ1NVTSxUU080PgoJZXRoZXIgeHg6eHg6eHg6eHg6 eHg6MmMKCWluZXQgeHh4Lnh4eC54eHguNTIgbmV0bWFzayAweGZmZmZmZmY4IGJyb2FkY2FzdCB4 eHgueHh4Lnh4eC41NQoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9f TElOS0xPQ0FMPgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpCglzdGF0dXM6IG5v IGNhcnJpZXIKCXZsYW46IDExIHBhcmVudCBpbnRlcmZhY2U6IGJjZTEKdmxhbjIyOiBmbGFncz04 MDAyPEJST0FEQ0FTVCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglldGhlciAwMDowMDow MDowMDowMDowMAoJbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElO S0xPQ0FMPgoJdmxhbjogMCBwYXJlbnQgaW50ZXJmYWNlOiA8bm9uZT4KY2FycDA6IGZsYWdzPTg8 TE9PUEJBQ0s+IG1ldHJpYyAwIG10dSAxNTAwCglpbmV0IHh4eC54eHguMS4zIG5ldG1hc2sgMHhm ZmZmMDAwMCAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJTktM T0NBTD4KCWNhcnA6IElOSVQgdmhpZCAxIGFkdmJhc2UgMSBhZHZza2V3IDEwClN0YXJ0aW5nIGRl dmQuClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMC4KU3RhcnRpbmcgTmV0d29yazogdXNidXMxLgpT dGFydGluZyBOZXR3b3JrOiB1c2J1czIuClN0YXJ0aW5nIE5ldHdvcms6IHVzYnVzMy4KU3RhcnRp bmcgTmV0d29yazogdmxhbjIyLgp2bGFuMjI6IGZsYWdzPTgwMDI8QlJPQURDQVNULE1VTFRJQ0FT VD4gbWV0cmljIDAgbXR1IDE1MDAKCWV0aGVyIDAwOjAwOjAwOjAwOjAwOjAwCgluZDYgb3B0aW9u cz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+Cgl2bGFuOiAwIHBhcmVu dCBpbnRlcmZhY2U6IDxub25lPgpTdGFydGluZyBOZXR3b3JrOiBjYXJwMC4KY2FycDA6IGZsYWdz PTg8TE9PUEJBQ0s+IG1ldHJpYyAwIG10dSAxNTAwCglpbmV0IHh4eC54eHguMS4zIG5ldG1hc2sg MHhmZmZmMDAwMCAKCW5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJ TktMT0NBTD4KCWNhcnA6IElOSVQgdmhpZCAxIGFkdmJhc2UgMSBhZHZza2V3IDEwCmFkZCBuZXQg ZGVmYXVsdDogZ2F0ZXdheSB4eHgueHh4Lnh4eC40OQphZGQgbmV0IDE5Mi4xNjguMTcuMDogZ2F0 ZXdheSB4eHgueHh4LjEuMTAKYWRkIGhvc3QgeHh4Lnh4eC54eHguNTQ6IGdhdGV3YXkgeHh4Lnh4 eC4xLjExMAphZGQgbmV0IDE5Mi4xNjguMTguMDogZ2F0ZXdheSB4eHgueHh4LjEuMjAKcm91dGU6 IHdyaXRpbmcgdG8gcm91dGluZyBzb2NrZXQ6IEZpbGUgZXhpc3RzCmFkZCBuZXQgZGVmYXVsdDog Z2F0ZXdheSB4eHgueHh4Lnh4eC40OTogcm91dGUgYWxyZWFkeSBpbiB0YWJsZQpyb3V0ZTogd3Jp dGluZyB0byByb3V0aW5nIHNvY2tldDogRmlsZSBleGlzdHMKYWRkIG5ldCAxOTIuMTY4LjE3LjA6 IGdhdGV3YXkgeHh4Lnh4eC4xLjEwOiByb3V0ZSBhbHJlYWR5IGluIHRhYmxlCnJvdXRlOiB3cml0 aW5nIHRvIHJvdXRpbmcgc29ja2V0OiBGaWxlIGV4aXN0cwphZGQgaG9zdCB4eHgueHh4Lnh4eC41 NDogZ2F0ZXdheSB4eHgueHh4LjEuMTEwOiByb3V0ZSBhbHJlYWR5IGluIHRhYmxlCnJvdXRlOiB3 cml0aW5nIHRvIHJvdXRpbmcgc29ja2V0OiBGaWxlIGV4aXN0cwphZGQgbmV0IDE5Mi4xNjguMTgu MDogZ2F0ZXdheSB4eHgueHh4LjEuMjA6IHJvdXRlIGFscmVhZHkgaW4gdGFibGUKQWRkaXRpb25h bCBpbmV0IHJvdXRpbmcgb3B0aW9uczogaWdub3JlIElDTVAgcmVkaXJlY3Q9WUVTIGxvZyBJQ01Q IHJlZGlyZWN0PVlFUyBnYXRld2F5PVlFUy4KYWRkIG5ldCA6OmZmZmY6MC4wLjAuMDogZ2F0ZXdh eSA6OjEKYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgZmU4MDo6OiBnYXRl d2F5IDo6MQphZGQgbmV0IGZmMDI6OjogZ2F0ZXdheSA6OjEKRmlyZXdhbGwgcnVsZXMgbG9hZGVk LgpFTEYgbGRjb25maWcgcGF0aDogL2xpYiAvdXNyL2xpYiAvdXNyL2xpYi9jb21wYXQgL3Vzci9s b2NhbC9saWIKMzItYml0IGNvbXBhdGliaWxpdHkgbGRjb25maWcgcGF0aDogL3Vzci9saWIzMgpD cmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9nIGZpbGVzLgpTdGFydGluZyBzeXNsb2dkLgpTdGFy dGluZyBuYW1lZC4KU2V0dGluZyBkYXRlIHZpYSBudHAuCmNhcnAwOiBJTklUIC0+IEJBQ0tVUApi Y2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKY2FycDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0 byBET1dOCmJjZTA6IEdpZ2FiaXQgbGluayB1cCEKYmNlMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQCnZsYW4xMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmJjZTE6IEdpZ2FiaXQgbGluayB1 cCEKY2FycDA6IEJBQ0tVUCAtPiBNQVNURVIgKHByZWVtcHRpbmcgYSBzbG93ZXIgbWFzdGVyKQpj YXJwMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCjE5IERlYyAxNzozOToxMyBudHBkYXRlWzE2 NzBdOiBubyBzZXJ2ZXIgc3VpdGFibGUgZm9yIHN5bmNocm9uaXphdGlvbiBmb3VuZApDbGVhcmlu ZyAvdG1wLgpTdGFydGluZyBtcGQ1LgpTdGFydGluZyBzbm1wdHJhcGQuCldBUk5JTkc6IGF0dGVt cHQgdG8gZG9tYWluX2FkZChuZXRncmFwaCkgYWZ0ZXIgZG9tYWluZmluYWxpemUoKQpTdGFydGlu ZyBzbm1wZC4KVXBkYXRpbmcgbW90ZDouClN0YXJ0aW5nIG5zY2QuClN0YXJ0aW5nIG50cGQuClN0 YXJ0aW5nIHBvd2VyZC4KU3RhcnRpbmcgcnN5bmNkLgpTdGFydGluZyBvcGVudnBuLgp0dW4wOiBs aW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKYWRkIG5ldCAxMC41LjAuMDogZ2F0ZXdheSAxMC41LjAu MgpQZXJmb3JtaW5nIHNhbml0eSBjaGVjayBvbiBuZ2lueCBjb25maWd1cmF0aW9uOgpuZ2lueDog dGhlIGNvbmZpZ3VyYXRpb24gZmlsZSAvdXNyL2xvY2FsL2V0Yy9uZ2lueC9uZ2lueC5jb25mIHN5 bnRheCBpcyBvawpuZ2lueDogY29uZmlndXJhdGlvbiBmaWxlIC91c3IvbG9jYWwvZXRjL25naW54 L25naW54LmNvbmYgdGVzdCBpcyBzdWNjZXNzZnVsClN0YXJ0aW5nIG5naW54LgpTdGFydGluZyBk YXJrc3RhdC4KIDE4MjQ6IHdhcm5pbmc6IGNhbid0IGltcG9ydCBmcm9tICJkYXJrc3RhdC5kYiI6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKU3RhcnRpbmcgYmFjdWxhX2ZkLgpDb25maWd1cmlu ZyBzeXNjb25zOiBibGFua3RpbWUuClN0YXJ0aW5nIHNzaGQuClN0YXJ0aW5nIGNyb24uCi9ldGMv cmMuZC9zeXNjdGw6IFdBUk5JTkc6IHN5c2N0bCA8PDw8PDw8IGRvZXMgbm90IGV4aXN0LgovZXRj L3JjLmQvc3lzY3RsOiBXQVJOSU5HOiBzeXNjdGwgPT09PT09IGRvZXMgbm90IGV4aXN0LgovZXRj L3JjLmQvc3lzY3RsOiBXQVJOSU5HOiBzeXNjdGwgPj4+Pj4+PiBkb2VzIG5vdCBleGlzdC4KU3Rh cnRpbmcgaW5ldGQuCgpXZWQgRGVjIDE5IDE3OjM5OjE1IE1TSyAyMDEyCmFycF9wcm94eTogaWdu b3JpbmcgcmVxdWVzdCBmcm9tIDAuMC4wLjAgdmlhIGJjZTAsIGV4cGVjdGluZyB2bGFuMTEKYXJw X3Byb3h5OiBpZ25vcmluZyByZXF1ZXN0IGZyb20gMC4wLjAuMCB2aWEgYmNlMCwgZXhwZWN0aW5n IHZsYW4xMQphcnBfcHJveHk6IGlnbm9yaW5nIHJlcXVlc3QgZnJvbSAwLjAuMC4wIHZpYSBiY2Uw LCBleHBlY3RpbmcgdmxhbjExCmFycF9wcm94eTogaWdub3JpbmcgcmVxdWVzdCBmcm9tIDAuMC4w LjAgdmlhIGJjZTAsIGV4cGVjdGluZyB2bGFuMTEKCgpGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0 IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMzsgYXBpYyBpZCA9IDAzCmZhdWx0IHZpcnR1 YWwgYWRkcmVzcwk9IDB4MTgKZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJlYWQgZGF0YSwgcGFn ZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGZmZmZmZmZmODA5NGJj NDcKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgxMTgyY2Q2NTAKZnJhbWUg cG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgxMTgyY2Q2YjAKY29kZSBzZWdtZW50CQk9 IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBs b25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJs ZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9IDEyIChpcnEyNTY6IGJjZTAp CnRyYXAgbnVtYmVyCQk9IDEyCnBhbmljOiBwYWdlIGZhdWx0CmNwdWlkID0gMwpLREI6IHN0YWNr IGJhY2t0cmFjZToKIzAgMHhmZmZmZmZmZjgwOTIwOGE2IGF0IGtkYl9iYWNrdHJhY2UrMHg2Ngoj MSAweGZmZmZmZmZmODA4ZWE4YmUgYXQgcGFuaWMrMHgxY2UKIzIgMHhmZmZmZmZmZjgwYmQ4MjQw IGF0IHRyYXBfZmF0YWwrMHgyOTAKIzMgMHhmZmZmZmZmZjgwYmQ4NTdkIGF0IHRyYXBfcGZhdWx0 KzB4MWVkCiM0IDB4ZmZmZmZmZmY4MGJkOGI5ZSBhdCB0cmFwKzB4M2NlCiM1IDB4ZmZmZmZmZmY4 MGJjMzE1ZiBhdCBjYWxsdHJhcCsweDgKIzYgMHhmZmZmZmZmZjgwYTA2NGQ4IGF0IGlwX2ZyYWdt ZW50KzB4MWU4CiM3IDB4ZmZmZmZmZmY4MGEwNmUxNCBhdCBpcF9vdXRwdXQrMHg2ZjQKIzggMHhm ZmZmZmZmZjgwYTAzMjQzIGF0IGlwX2ZvcndhcmQrMHgzMDMKIzkgMHhmZmZmZmZmZjgwYTA0OGRi IGF0IGlwX2lucHV0KzB4NWFiCiMxMCAweGZmZmZmZmZmODA5YWRhZmIgYXQgbmV0aXNyX2Rpc3Bh dGNoX3NyYysweDIwYgojMTEgMHhmZmZmZmZmZjgwOWEzNWNkIGF0IGV0aGVyX2RlbXV4KzB4MTRk CiMxMiAweGZmZmZmZmZmODA5YTM4YTQgYXQgZXRoZXJfbmhfaW5wdXQrMHgxZjQKIzEzIDB4ZmZm ZmZmZmY4MDlhZGFmYiBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4MjBiCiMxNCAweGZmZmZmZmZm ODA0MzhmZDcgYXQgYmNlX2ludHIrMHg0ODcKIzE1IDB4ZmZmZmZmZmY4MDhiZThkNCBhdCBpbnRy X2V2ZW50X2V4ZWN1dGVfaGFuZGxlcnMrMHgxMDQKIzE2IDB4ZmZmZmZmZmY4MDhjMDA3NiBhdCBp dGhyZWFkX2xvb3ArMHhhNgojMTcgMHhmZmZmZmZmZjgwOGJiOWVmIGF0IGZvcmtfZXhpdCsweDEx ZgpVcHRpbWU6IDUzbTE4cwpEdW1waW5nIDMzNiBvdXQgb2YgNDA3NCBNQjouLjUlLi4xNSUuLjI0 JS4uMzQlLi40MyUuLjUzJS4uNjIlLi43MiUuLjgxJS4uOTElCgotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Ka2Vy bmVsIGNvbmZpZwoKb3B0aW9ucwlDT05GSUdfQVVUT0dFTkVSQVRFRAppZGVudAlHRU5FUklDCm1h Y2hpbmUJYW1kNjQKY3B1CUhBTU1FUgptYWtlb3B0aW9ucwlERUJVRz0tZwpvcHRpb25zCVVTQl9E RUJVRwpvcHRpb25zCUFIX1NVUFBPUlRfQVI1NDE2Cm9wdGlvbnMJSUVFRTgwMjExX1NVUFBPUlRf TUVTSApvcHRpb25zCUlFRUU4MDIxMV9BTVBEVV9BR0UKb3B0aW9ucwlJRUVFODAyMTFfREVCVUcK b3B0aW9ucwlTQ19QSVhFTF9NT0RFCm9wdGlvbnMJVkVTQQpvcHRpb25zCUFIRF9SRUdfUFJFVFRZ X1BSSU5UCm9wdGlvbnMJQUhDX1JFR19QUkVUVFlfUFJJTlQKb3B0aW9ucwlBVEFfU1RBVElDX0lE Cm9wdGlvbnMJQVRBX0NBTQpvcHRpb25zCVNNUApvcHRpb25zCUtEQl9UUkFDRQpvcHRpb25zCUtE QgpvcHRpb25zCUlOQ0xVREVfQ09ORklHX0ZJTEUKb3B0aW9ucwlNQUMKb3B0aW9ucwlBVURJVApv cHRpb25zCUhXUE1DX0hPT0tTCm9wdGlvbnMJS0JEX0lOU1RBTExfQ0RFVgpvcHRpb25zCVBSSU5U Rl9CVUZSX1NJWkU9MTI4Cm9wdGlvbnMJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HCm9wdGlv bnMJU1lTVlNFTQpvcHRpb25zCVNZU1ZNU0cKb3B0aW9ucwlTWVNWU0hNCm9wdGlvbnMJU1RBQ0sK b3B0aW9ucwlLVFJBQ0UKb3B0aW9ucwlTQ1NJX0RFTEFZPTUwMDAKb3B0aW9ucwlDT01QQVRfRlJF RUJTRDcKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDYKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDUKb3B0 aW9ucwlDT01QQVRfRlJFRUJTRDQKb3B0aW9ucwlDT01QQVRfRlJFRUJTRDMyCm9wdGlvbnMJR0VP TV9MQUJFTApvcHRpb25zCUdFT01fUkFJRApvcHRpb25zCUdFT01fUEFSVF9HUFQKb3B0aW9ucwlQ U0VVRE9GUwpvcHRpb25zCVBST0NGUwpvcHRpb25zCUNEOTY2MApvcHRpb25zCU1TRE9TRlMKb3B0 aW9ucwlORlNfUk9PVApvcHRpb25zCU5GU0xPQ0tECm9wdGlvbnMJTkZTRApvcHRpb25zCU5GU0NM Cm9wdGlvbnMJTURfUk9PVApvcHRpb25zCVVGU19HSk9VUk5BTApvcHRpb25zCVVGU19ESVJIQVNI Cm9wdGlvbnMJVUZTX0FDTApvcHRpb25zCVNPRlRVUERBVEVTCm9wdGlvbnMJRkZTCm9wdGlvbnMJ U0NUUApvcHRpb25zCUlORVQ2Cm9wdGlvbnMJSU5FVApvcHRpb25zCVBSRUVNUFRJT04Kb3B0aW9u cwlTQ0hFRF9VTEUKb3B0aW9ucwlORVdfUENJQgpvcHRpb25zCUdFT01fUEFSVF9NQlIKb3B0aW9u cwlHRU9NX1BBUlRfRUJSX0NPTVBBVApvcHRpb25zCUdFT01fUEFSVF9FQlIKb3B0aW9ucwlHRU9N X1BBUlRfQlNECmRldmljZQlpc2EKZGV2aWNlCW1lbQpkZXZpY2UJaW8KZGV2aWNlCXVhcnRfbnM4 MjUwCmRldmljZQljcHVmcmVxCmRldmljZQlhY3BpCmRldmljZQlwY2kKZGV2aWNlCWZkYwpkZXZp Y2UJYWhjaQpkZXZpY2UJYXRhCmRldmljZQltdnMKZGV2aWNlCXNpaXMKZGV2aWNlCWFoYwpkZXZp Y2UJYWhkCmRldmljZQllc3AKZGV2aWNlCWhwdGlvcApkZXZpY2UJaXNwCmRldmljZQltcHQKZGV2 aWNlCW1wcwpkZXZpY2UJc3ltCmRldmljZQl0cm0KZGV2aWNlCWFkdgpkZXZpY2UJYWR3CmRldmlj ZQlhaWMKZGV2aWNlCWJ0CmRldmljZQlpc2NpCmRldmljZQlzY2J1cwpkZXZpY2UJY2gKZGV2aWNl CWRhCmRldmljZQlzYQpkZXZpY2UJY2QKZGV2aWNlCXBhc3MKZGV2aWNlCXNlcwpkZXZpY2UJY3Rs CmRldmljZQlhbXIKZGV2aWNlCWFyY21zcgpkZXZpY2UJY2lzcwpkZXZpY2UJZHB0CmRldmljZQlo cHRtdgpkZXZpY2UJaHB0cnIKZGV2aWNlCWlpcgpkZXZpY2UJaXBzCmRldmljZQltbHkKZGV2aWNl CXR3YQpkZXZpY2UJdHdzCmRldmljZQlhYWMKZGV2aWNlCWFhY3AKZGV2aWNlCWlkYQpkZXZpY2UJ bWZpCmRldmljZQltbHgKZGV2aWNlCXR3ZQpkZXZpY2UJYXRrYmRjCmRldmljZQlhdGtiZApkZXZp Y2UJcHNtCmRldmljZQlrYmRtdXgKZGV2aWNlCXZnYQpkZXZpY2UJc3BsYXNoCmRldmljZQlzYwpk ZXZpY2UJYWdwCmRldmljZQljYmIKZGV2aWNlCXBjY2FyZApkZXZpY2UJY2FyZGJ1cwpkZXZpY2UJ dWFydApkZXZpY2UJcHBjCmRldmljZQlwcGJ1cwpkZXZpY2UJbHB0CmRldmljZQlwbGlwCmRldmlj ZQlwcGkKZGV2aWNlCXB1YwpkZXZpY2UJYnhlCmRldmljZQlkZQpkZXZpY2UJZW0KZGV2aWNlCWln YgpkZXZpY2UJaXhnYmUKZGV2aWNlCWxlCmRldmljZQl0aQpkZXZpY2UJdHhwCmRldmljZQl2eApk ZXZpY2UJbWlpYnVzCmRldmljZQlhZQpkZXZpY2UJYWdlCmRldmljZQlhbGMKZGV2aWNlCWFsZQpk ZXZpY2UJYmNlCmRldmljZQliZmUKZGV2aWNlCWJnZQpkZXZpY2UJY2FzCmRldmljZQlkYwpkZXZp Y2UJZXQKZGV2aWNlCWZ4cApkZXZpY2UJZ2VtCmRldmljZQlobWUKZGV2aWNlCWptZQpkZXZpY2UJ bGdlCmRldmljZQltc2sKZGV2aWNlCW5mZQpkZXZpY2UJbmdlCmRldmljZQlwY24KZGV2aWNlCXJl CmRldmljZQlybApkZXZpY2UJc2YKZGV2aWNlCXNnZQpkZXZpY2UJc2lzCmRldmljZQlzawpkZXZp Y2UJc3RlCmRldmljZQlzdGdlCmRldmljZQl0bApkZXZpY2UJdHgKZGV2aWNlCXZnZQpkZXZpY2UJ dnIKZGV2aWNlCXdiCmRldmljZQl4bApkZXZpY2UJY3MKZGV2aWNlCWVkCmRldmljZQlleApkZXZp Y2UJZXAKZGV2aWNlCWZlCmRldmljZQlzbgpkZXZpY2UJeGUKZGV2aWNlCXdsYW4KZGV2aWNlCXds YW5fd2VwCmRldmljZQl3bGFuX2NjbXAKZGV2aWNlCXdsYW5fdGtpcApkZXZpY2UJd2xhbl9hbXJy CmRldmljZQlhbgpkZXZpY2UJYXRoCmRldmljZQlhdGhfcGNpCmRldmljZQlhdGhfaGFsCmRldmlj ZQlhdGhfcmF0ZV9zYW1wbGUKZGV2aWNlCWlwdwpkZXZpY2UJaXdpCmRldmljZQlpd24KZGV2aWNl CW1hbG8KZGV2aWNlCW13bApkZXZpY2UJcmFsCmRldmljZQl3aQpkZXZpY2UJd3BpCmRldmljZQls b29wCmRldmljZQlyYW5kb20KZGV2aWNlCWV0aGVyCmRldmljZQl2bGFuCmRldmljZQl0dW4KZGV2 aWNlCXB0eQpkZXZpY2UJbWQKZGV2aWNlCWdpZgpkZXZpY2UJZmFpdGgKZGV2aWNlCWZpcm13YXJl CmRldmljZQlicGYKZGV2aWNlCXVoY2kKZGV2aWNlCW9oY2kKZGV2aWNlCWVoY2kKZGV2aWNlCXho Y2kKZGV2aWNlCXVzYgpkZXZpY2UJdWhpZApkZXZpY2UJdWtiZApkZXZpY2UJdWxwdApkZXZpY2UJ dW1hc3MKZGV2aWNlCXVtcwpkZXZpY2UJdXJpbwpkZXZpY2UJdTNnCmRldmljZQl1YXJrCmRldmlj ZQl1YnNhCmRldmljZQl1ZnRkaQpkZXZpY2UJdWlwYXEKZGV2aWNlCXVwbGNvbQpkZXZpY2UJdXNs Y29tCmRldmljZQl1dmlzb3IKZGV2aWNlCXV2c2NvbQpkZXZpY2UJYXVlCmRldmljZQlheGUKZGV2 aWNlCWNkY2UKZGV2aWNlCWN1ZQpkZXZpY2UJa3VlCmRldmljZQlydWUKZGV2aWNlCXVkYXYKZGV2 aWNlCXJ1bQpkZXZpY2UJcnVuCmRldmljZQl1YXRoCmRldmljZQl1cGd0CmRldmljZQl1cmFsCmRl dmljZQl1cnR3CmRldmljZQl6eWQKZGV2aWNlCWZpcmV3aXJlCmRldmljZQlmd2UKZGV2aWNlCWZ3 aXAKZGV2aWNlCWRjb25zCmRldmljZQlkY29uc19jcm9tCmRldmljZQlzb3VuZApkZXZpY2UJc25k X2NtaQpkZXZpY2UJc25kX2NzYQpkZXZpY2UJc25kX2VtdTEwa3gKZGV2aWNlCXNuZF9lczEzN3gK ZGV2aWNlCXNuZF9oZGEKZGV2aWNlCXNuZF9pY2gKZGV2aWNlCXNuZF91YXVkaW8KZGV2aWNlCXNu ZF92aWE4MjMzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGRiIGNhcHR1cmUgYnVmZmVyCgpkZGI6IGRkYl9j YXB0dXJlOiBrdm1fbmxpc3QK --MP_/fhlLPOCihZ9mc/Jr/WIoSAG-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 12:23:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84E073E0; Fri, 21 Dec 2012 12:23:37 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id DAC348FC13; Fri, 21 Dec 2012 12:23:36 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id o1so2694236wic.0 for ; Fri, 21 Dec 2012 04:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GXRIYJ5xA8NqL4NYr35RlFC2L+TTt/WICCTTVJn097k=; b=lOKdJwGe/33Fio8m7ZA1zij7vUXSZHPyriLby/znDUYLCiGU4JCWvMpobfEmky4Sv9 mq/xuZazo2e4ZAfPiTCnMMwUhGoiKvGlNTzt9MgOT5haup8H++e6oGbyoCkTpFc289T3 Z6ut7tRMuyCisNTcQpX4NaS+02WsEY0X9ZuS19zq/Kim0BDFn/1aP3Vlr3SKsgOSM1Tq 82rNjPF4meqw2j60VgxPu5KLSQTme9Xjhq1w08NNxDo0bRpgU7jS/CXEaE8UMCebIxYh Fb10GI90BqRqO1QE1kcnltRB4DYuCn3h81wQ+JSyzhU6kIFjKf44pr8/c0vaf82W08sg ypmQ== MIME-Version: 1.0 Received: by 10.194.23.37 with SMTP id j5mr23310987wjf.28.1356092610360; Fri, 21 Dec 2012 04:23:30 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 21 Dec 2012 04:23:30 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> Date: Fri, 21 Dec 2012 14:23:30 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 12:23:37 -0000 On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala wrote: > On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wrote: >> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: >>> A question related to this for those who have been doing work on the >>> rc(8) scripts. Can I assume that /usr/bin is available when >>> network.subr functions are used? Doing calculations on hexadecimal >>> numbers is going to be very awkward if I can't use for example bc(1). >> >> You cannot assume that /usr/bin is available when setting up the >> network. It may be that /usr is mounted via NFS. >> >> You can use hexadecimal numbers (prefixed with 0x) in $((...)) >> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can >> use; in older versions you can use hexdigit and hexprint from >> network.subr. >> >> -- >> Jilles Tjoelker > > Thanks, I've rewitten my patch to support ranges. It is attached in > this message. > > Again it's against a very recent 9-STABLE, I still haven't found time > to see if it applies to CURRENT. > > It does allow you to do crazy stuff like > > ipv6_addrs_re0="2001:db8:1111:2222::1-ffff/64" > > However I didn't find anything to limit the number of aliases in the > ipv4 version of the function either. > > Please test it :) > > > Then a question about the PR > (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I > attach this new patch to it? The submit follow up -button fires up my > email client and I'm not so sure how to submit a new patch for the PR > in an email in such a way that it appears properly formatted in the > PR. > > Regards, > > Kimmo Paasiala PR updated with the new patch. -Kimmo From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 12:45:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D502A42; Fri, 21 Dec 2012 12:45:37 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by mx1.freebsd.org (Postfix) with ESMTP id 787B78FC0A; Fri, 21 Dec 2012 12:45:36 +0000 (UTC) Received: from [78.35.147.221] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tm1Wu-0004fP-Cf; Fri, 21 Dec 2012 13:16:44 +0100 Date: Fri, 21 Dec 2012 13:16:01 +0100 From: Fabian Keil To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20121221131601.0d3ce382@fabiankeil.de> In-Reply-To: <20121220191243.7cd00b2a@fabiankeil.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121220115629.3379a261@fabiankeil.de> <50D2F923.2020303@FreeBSD.org> <20121220142600.22c4796a@fabiankeil.de> <50D3201F.4080605@FreeBSD.org> <20121220191243.7cd00b2a@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ADMzy2tP=AV.Rx=uP+P_esH"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 12:45:37 -0000 --Sig_/ADMzy2tP=AV.Rx=uP+P_esH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Alexander Motin wrote: >=20 > > On 20.12.2012 15:26, Fabian Keil wrote: > > > Alexander Motin wrote: > > > > > >> On 20.12.2012 12:56, Fabian Keil wrote: > > >>> Alexander Motin wrote: > > >>> > > >>>> Experiments with dummynet shown ineffective support for very short > > >>>> tick-based callouts. New version fixes that, allowing to get as ma= ny > > >>>> tick-based callout events as hz value permits, while still be able= to > > >>>> aggregate events and generating minimum of interrupts. > > >>>> > > >>>> Also this version modifies system load average calculation to fix = some > > >>>> cases existing in HEAD and 9 branches, that could be fixed with new > > >>>> direct callout functionality. > > >>>> > > >>>> http://people.freebsd.org/~mav/calloutng_12_17.patch > > >>> > > >>> With this patch (and the previous one, I didn't test the others) > > >>> my mouse cursor is occasionally not reacting for short amounts of > > >>> time (less than a second, but long enough to be noticeable). >=20 > > >> Could you try to revert part of the patch, related to dev/atkbdc? I = am > > >> not strong in details of that hardware, but in comments there mention > > >> that they are related. May be lost keyboard interrupts (which polling > > >> rate was increased to 1 second) cause PS/2 mouse delays. > > > > > > I reverted the changes to sys/dev/atkbdc/* about an hour ago > > > and so far it's looking good. I'll report back tomorrow after > > > some more testing. Still looking good. Fabian --Sig_/ADMzy2tP=AV.Rx=uP+P_esH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDUUwYACgkQBYqIVf93VJ0bNACfTRQgBDvh1iQ/kF+IdFhWkY0p QOsAnjpjpIR36kDbWqeUS1rnCwhIfGFg =3YML -----END PGP SIGNATURE----- --Sig_/ADMzy2tP=AV.Rx=uP+P_esH-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 12:56:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 078D9C3F for ; Fri, 21 Dec 2012 12:56:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0558FC0C for ; Fri, 21 Dec 2012 12:56:10 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id w11so2335622bku.17 for ; Fri, 21 Dec 2012 04:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KPJvhCeBNi6grvwIp5vCfKpKKc2KfOlqY+uWoH38ScM=; b=ADHSR2oqUT/DbVh/X+1FFnifAaFAuuJRc8oKzte+onVsNmQ5/2hrAU2BTYBK/KQkIU RnZUdAnZkDChj8KvzvEXHx+cdVk+Ll8oofqSx053H3kYVOo3zP1YJPtYtzXVxnEaetce IPabCAOtdsRPIGmAeILkjiypFKy4wwQ/IgihbJdQwsmHROGtXT8u41A2VCMXHmIg1RAc 5x2oQt2ZS3XWEaQHCTbCMg6oI05nYN75FPuqiQ3seQwkwceTFamrqXZdqqOkLq6Txesq Mhd9cEhJma73g3lFWmQguVO2ZV/AXkP3HxTq2l7hRooioiPyRtSI1cqQ8Ic0MtOVtXBq w7LQ== X-Received: by 10.204.3.220 with SMTP id 28mr6286368bko.50.1356094160078; Fri, 21 Dec 2012 04:49:20 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id o7sm9856877bkv.13.2012.12.21.04.49.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 04:49:19 -0800 (PST) Sender: Alexander Motin Message-ID: <50D45ACC.40608@FreeBSD.org> Date: Fri, 21 Dec 2012 14:49:16 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabian Keil Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121220115629.3379a261@fabiankeil.de> <50D2F923.2020303@FreeBSD.org> <20121220142600.22c4796a@fabiankeil.de> <50D3201F.4080605@FreeBSD.org> <20121220191243.7cd00b2a@fabiankeil.de> <20121221131601.0d3ce382@fabiankeil.de> In-Reply-To: <20121221131601.0d3ce382@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 12:56:11 -0000 On 21.12.2012 14:16, Fabian Keil wrote: > Fabian Keil wrote: > >> Alexander Motin wrote: >> >>> On 20.12.2012 15:26, Fabian Keil wrote: >>>> Alexander Motin wrote: >>>> >>>>> On 20.12.2012 12:56, Fabian Keil wrote: >>>>>> Alexander Motin wrote: >>>>>> >>>>>>> Experiments with dummynet shown ineffective support for very short >>>>>>> tick-based callouts. New version fixes that, allowing to get as many >>>>>>> tick-based callout events as hz value permits, while still be able to >>>>>>> aggregate events and generating minimum of interrupts. >>>>>>> >>>>>>> Also this version modifies system load average calculation to fix some >>>>>>> cases existing in HEAD and 9 branches, that could be fixed with new >>>>>>> direct callout functionality. >>>>>>> >>>>>>> http://people.freebsd.org/~mav/calloutng_12_17.patch >>>>>> >>>>>> With this patch (and the previous one, I didn't test the others) >>>>>> my mouse cursor is occasionally not reacting for short amounts of >>>>>> time (less than a second, but long enough to be noticeable). >> >>>>> Could you try to revert part of the patch, related to dev/atkbdc? I am >>>>> not strong in details of that hardware, but in comments there mention >>>>> that they are related. May be lost keyboard interrupts (which polling >>>>> rate was increased to 1 second) cause PS/2 mouse delays. >>>> >>>> I reverted the changes to sys/dev/atkbdc/* about an hour ago >>>> and so far it's looking good. I'll report back tomorrow after >>>> some more testing. > > Still looking good. Thank you. I think it may be some locking issue in atkbdc code. I'll revert that part of the patch until somebody rewrite it properly. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 16:36:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A997BB0; Fri, 21 Dec 2012 16:36:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7F88FC0C; Fri, 21 Dec 2012 16:36:40 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 359678462; Fri, 21 Dec 2012 17:36:33 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: clang compiled kernel panic when mounting zfs root on i386 Date: Fri, 21 Dec 2012 17:38:08 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> <50D2F3FE.1000509@gmail.com> In-Reply-To: <50D2F3FE.1000509@gmail.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212211738.08781.hselasky@c2i.net> Cc: Volodymyr Kostyrko , Dimitry Andric , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:36:42 -0000 On Thursday 20 December 2012 12:18:22 Volodymyr Kostyrko wrote: > 18.12.2012 00:20, Andriy Gapon: > > It's been already mentioned many times that ZFS works much better on > > amd64. It's up to a (potential) user to understand limitations of i386 > > and to decide whether to use ZFS, in what situations and how. > > > > You may want to consider using KSTACK_PAGES=4 in your kernel > > configuration. > > For last two fays my system seems stable on kernel compiled with > KSTACK_PAGES=4 and WITH_CLANG_IS_CC. Hi, I've built a 10-current i386 kernel as of today, and I see double fault when USB audio is allocating memory. Anyone knows why? I'm on #bsdusb on EF-net for 30 more minutes if someone has any quick suggestions. kdb_enter() vpanic() panic() dblfault_handler() vm_map_lookup() vm_fault_hold() vm_fault() vm_fault_wire() vm_map_wire() kmem_alloc_attr(xxx, 0x4000,2,0,0xffffffff) bus_dmamem_alloc() usb_pc_alloc_mem() --HPS From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 18:05:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59E99DC5 for ; Fri, 21 Dec 2012 18:05:33 +0000 (UTC) (envelope-from ma.zoon@quicknet.nl) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) by mx1.freebsd.org (Postfix) with ESMTP id EF35E8FC0A for ; Fri, 21 Dec 2012 18:05:32 +0000 (UTC) Received: from [212.54.42.133] (helo=smtp2.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Tm668-0002hM-Bb for freebsd-current@freebsd.org; Fri, 21 Dec 2012 18:09:24 +0100 Received: from 5ed3f892.cm-7-4d.dynamic.ziggo.nl ([94.211.248.146] helo=PC01) by smtp2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Tm668-0005jD-4P for freebsd-current@freebsd.org; Fri, 21 Dec 2012 18:09:24 +0100 From: "Michael Zoon" To: Subject: ports/shells/bash upgrade to patch level 39 Date: Fri, 21 Dec 2012 18:09:23 +0100 Message-ID: <000301cddf9d$ec9a7f20$c5cf7d60$@quicknet.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01CDDFA6.4E5F3540" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3fnJFIsKJcHE59R/GL+GFtHFg3Yw== Content-Language: nl X-Ziggo-spambar: -- X-Ziggo-spamscore: -2.1 X-Ziggo-spamreport: ALL_TRUSTED=-1, BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FSL_HELO_NON_FQDN_1=0.001, PROLO_TRUST_RDNS=-3, RDNS_DYNAMIC=0.982 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 18:05:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01CDDFA6.4E5F3540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I did update the make and distinfo file for a upgrade of bash 4.2.37 to 4.2.39 It is attached in this message. Regards, Michael ------=_NextPart_000_0004_01CDDFA6.4E5F3540 Content-Type: application/octet-stream; name="distinfo" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="distinfo" SHA256 (bash/bash-4.2.tar.gz) =3D = a27a1179ec9c0830c65c6aa5d7dab60f7ce1a2a608618570f96bfa72e95ab3d8=0A= SIZE (bash/bash-4.2.tar.gz) =3D 7009201=0A= SHA256 (bash/bash42-001) =3D = 8d6ca028576c4af23e660a2fbc2112221a11c8a785c0b37f033967e5cd12b47a=0A= SIZE (bash/bash42-001) =3D 2944=0A= SHA256 (bash/bash42-002) =3D = febac927e199aceeba2004908d971d4afb49b521796c3f42d1166f9fbbfbcef9=0A= SIZE (bash/bash42-002) =3D 1780=0A= SHA256 (bash/bash42-003) =3D = 5a0a7c15018c87348ea87cb0beea14345faf878dbb0e25c17fa70677194cb4cd=0A= SIZE (bash/bash42-003) =3D 6896=0A= SHA256 (bash/bash42-004) =3D = 4e34b0f830d2583d56e14225a66937abc81f45bbafcd2eb49daf61c9462140c1=0A= SIZE (bash/bash42-004) =3D 1686=0A= SHA256 (bash/bash42-005) =3D = a81749e73004b81cfdf0fe075bec365dc1fef756ee5e3fd142821e317d1459a0=0A= SIZE (bash/bash42-005) =3D 3424=0A= SHA256 (bash/bash42-006) =3D = c91148945a2ddafa792682d7c8668c59e7e645eae1334b15b0d5d9ad22634bd1=0A= SIZE (bash/bash42-006) =3D 1187=0A= SHA256 (bash/bash42-007) =3D = 405826acf443dd1084f236a15cb76d7f0ee2dbe5edff45c5fb836db571fb7e95=0A= SIZE (bash/bash42-007) =3D 1394=0A= SHA256 (bash/bash42-008) =3D = 23080d11a60a78941210e2477f6bca066b45db03defa60da86fd765107ba2437=0A= SIZE (bash/bash42-008) =3D 2164=0A= SHA256 (bash/bash42-009) =3D = e7ed5440b4c19765786e90e4f1ded43195d38b3e4d1c4b39fcc23de9a74ccb20=0A= SIZE (bash/bash42-009) =3D 2384=0A= SHA256 (bash/bash42-010) =3D = acfc5482c25e6923116fcf4b4f7f6345b80f75ad7299749db4b736ad67aa43dc=0A= SIZE (bash/bash42-010) =3D 1818=0A= SHA256 (bash/bash42-011) =3D = a491ae359a7ebbd7321aede561728289d71e1fc84777f402766a8afd4d261532=0A= SIZE (bash/bash42-011) =3D 1426=0A= SHA256 (bash/bash42-012) =3D = 354433f1d2da02f1b9652cd20a5b85bbfb5bc2aaf79c42461ebd929d89b9b7b8=0A= SIZE (bash/bash42-012) =3D 4247=0A= SHA256 (bash/bash42-013) =3D = 3412c5c6cbbce6c88592604aec054d8182ce64410038b5ecea69fc3968cf85ea=0A= SIZE (bash/bash42-013) =3D 1340=0A= SHA256 (bash/bash42-014) =3D = b5a678e609858532735f94faedb5fabce00dfd6577a4e9ec5eec85fe682c8b33=0A= SIZE (bash/bash42-014) =3D 1434=0A= SHA256 (bash/bash42-015) =3D = 2d876a8304bdf3d664e87e0a8d73bc4ccc100a9dd8c0d054e8649472d8748a98=0A= SIZE (bash/bash42-015) =3D 1991=0A= SHA256 (bash/bash42-016) =3D = 2895ccbcf7fc98da73a8fa3ba7440aaf2bfaef6c0af8bdd3a9c39403cf03e2a6=0A= SIZE (bash/bash42-016) =3D 1410=0A= SHA256 (bash/bash42-017) =3D = 73552444498c761d6073dd67ccfe043b36ef24bb418c266d91d9750884daee7f=0A= SIZE (bash/bash42-017) =3D 1399=0A= SHA256 (bash/bash42-018) =3D = e2a9457172370d454d31b84bbcba758ee6394316dbe755374553b52aadbb494d=0A= SIZE (bash/bash42-018) =3D 1929=0A= SHA256 (bash/bash42-019) =3D = a8b7cd02207656976016d93cab48e073cb5da002ceb27b7a63fc5ea62007eb56=0A= SIZE (bash/bash42-019) =3D 1415=0A= SHA256 (bash/bash42-020) =3D = 494773f0d0078cb35372d24caa523b00d8fdbbaed71e41dc14c9e47579da3c6f=0A= SIZE (bash/bash42-020) =3D 1825=0A= SHA256 (bash/bash42-021) =3D = a887a97be226575ecf483be2c76655bd6d1edde1cdfe199c27bd2e6baf32badc=0A= SIZE (bash/bash42-021) =3D 1532=0A= SHA256 (bash/bash42-022) =3D = 9dcdf69df7f8cd2ba88d18c45a0d8f55fbe4f0e273411179db94dd6198b85c6b=0A= SIZE (bash/bash42-022) =3D 1395=0A= SHA256 (bash/bash42-023) =3D = 5dc11394f1a6c887373c081396efd4f4cc04492696722c57a4811c207965f0bf=0A= SIZE (bash/bash42-023) =3D 1699=0A= SHA256 (bash/bash42-024) =3D = 99c826bdd33bee281d0a9191550d62a24d0b256cd41c90afd10abd63a66b99e6=0A= SIZE (bash/bash42-024) =3D 1363=0A= SHA256 (bash/bash42-025) =3D = 0db0646fd7a559d5702911192bdd387acbbc61cf3c29a34007c3ec840e275515=0A= SIZE (bash/bash42-025) =3D 3969=0A= SHA256 (bash/bash42-026) =3D = e7e90cfaabbce3b4b9c699994e9d9ea4a2f084fd9f37788a80b0b70b47d323d2=0A= SIZE (bash/bash42-026) =3D 1577=0A= SHA256 (bash/bash42-027) =3D = 0c1f6b7256fcc17f42c05f9bbb4138f8e8bb67e79c622c3485711b6f37f7ed42=0A= SIZE (bash/bash42-027) =3D 1461=0A= SHA256 (bash/bash42-028) =3D = 204226de39ba81aaf3dd5a29cd59de052ec9f648538bb9e7f1c8150852b1ed7a=0A= SIZE (bash/bash42-028) =3D 1834=0A= SHA256 (bash/bash42-029) =3D = d0b08c0817bc5acdb28b466727622a8422ca4d61188313cf162443b7f338f581=0A= SIZE (bash/bash42-029) =3D 16812=0A= SHA256 (bash/bash42-030) =3D = 12594366591a136d8ccdcb8e218010f2ddab6be28a7f96d0ed32ca927e44afae=0A= SIZE (bash/bash42-030) =3D 5046=0A= SHA256 (bash/bash42-031) =3D = 55f38c4d34775fbb063510c4222b195d998dd86f88288b64a6103e3812f8d9f9=0A= SIZE (bash/bash42-031) =3D 2047=0A= SHA256 (bash/bash42-032) =3D = e3a8b563dbb1e5cb7ca85a53515da8b2941213973496d48c4cc5a11c604791ed=0A= SIZE (bash/bash42-032) =3D 2416=0A= SHA256 (bash/bash42-033) =3D = f5d12790d69fdfb2f47ac86fa1ea1ecc088880141570273f38dfd3fa4a46434b=0A= SIZE (bash/bash42-033) =3D 1634=0A= SHA256 (bash/bash42-034) =3D = 01c1f332101389cedf347c7736102966722a3b213900954e5d625bbc2f1e41b8=0A= SIZE (bash/bash42-034) =3D 1345=0A= SHA256 (bash/bash42-035) =3D = cecde463b038b4849635ff0993d9b264fc92403e7ae0accb52c7877aeaed78df=0A= SIZE (bash/bash42-035) =3D 1920=0A= SHA256 (bash/bash42-036) =3D = fe293a1bc92ac4d272ae9b9a0de3afef7c06145a2b52337a09cacccc5305aafa=0A= SIZE (bash/bash42-036) =3D 3123=0A= SHA256 (bash/bash42-037) =3D = c7578cddd3bb2430689c740f58a03403800726dcd1268b28f91bf37f368e1674=0A= SIZE (bash/bash42-037) =3D 3483=0A= SHA256 (bash/bash42-038) =3D = b8c9a81bdf206be58ba491dfad80373b3348af769e80aaf72f7611ddbbbe6d57=0A= SIZE (bash/bash42-038) =3D 1290=0A= SHA256 (bash/bash42-039) =3D = f4f9300a60321a5088ae9e54052a64c4d3e876f9a3a17ca104d58fa38b9c1791=0A= SIZE (bash/bash42-039) =3D 1603=0A= SHA256 (bash/FAQ) =3D IGNORE=0A= ------=_NextPart_000_0004_01CDDFA6.4E5F3540 Content-Type: application/octet-stream; name="Makefile" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Makefile" # ex:ts=3D8=0A= # New ports collection makefile for: bash3=0A= # Date created: 30 Jul 2004=0A= # Whom: Oliver Eikemeier=0A= #=0A= # $FreeBSD: ports/shells/bash/Makefile,v 1.136 2012/11/17 06:01:23 = svnexp Exp $=0A= #=0A= =0A= PORTNAME=3D bash=0A= PATCHLEVEL=3D 39=0A= PORTVERSION=3D 4.2.${PATCHLEVEL:S/^0//g}=0A= PORTREVISION?=3D 0=0A= CATEGORIES=3D shells=0A= MASTER_SITES=3D ${MASTER_SITE_GNU:S/$/:bash/} \=0A= ftp://ftp.cwru.edu/pub/%SUBDIR%/:faq=0A= MASTER_SITE_SUBDIR=3D ${PORTNAME}/:bash,faq=0A= DISTNAME=3D ${PORTNAME}-${PORTVERSION:R}=0A= DISTFILES=3D ${DISTNAME}${EXTRACT_SUFX}:bash=0A= DIST_SUBDIR=3D ${PORTNAME}=0A= EXTRACT_ONLY=3D ${DISTNAME}${EXTRACT_SUFX}=0A= =0A= PATCH_SITES=3D ${MASTER_SITE_GNU} \=0A= ftp://ftp.cwru.edu/pub/%SUBDIR%/=0A= PATCH_SITE_SUBDIR=3D ${PORTNAME}/${DISTNAME}-patches/=0A= PATCHFILES!=3D /usr/bin/jot -s " " -w \=0A= ${PORTNAME}${PORTVERSION:R:S/.//g}-%03d \=0A= ${PATCHLEVEL} 1 ${PATCHLEVEL}=0A= =0A= MAINTAINER=3D obrien@FreeBSD.org=0A= COMMENT=3D The GNU Project's Bourne Again SHell=0A= =0A= IGNOREFILES=3D FAQ=0A= =0A= .if defined(WITH_OPTIONS) || defined(WITH_BASH_OPTIONS)=0A= .include "${.CURDIR}/../bash/options"=0A= .endif=0A= =0A= .include =0A= =0A= .if !defined(WITHOUT_IMPLICITCD)=0A= EXTRA_PATCHES+=3D ${PATCHDIR}/xpatch-implicitcd=0A= .endif=0A= =0A= .if !defined(WITHOUT_COLONBREAKSWORDS)=0A= EXTRA_PATCHES+=3D ${PATCHDIR}/xpatch-colonbreakswords=0A= .endif=0A= =0A= MAN1=3D bash.1 bashbug.1=0A= INFO=3D bash=0A= =0A= MAKE_JOBS_UNSAFE=3D yes=0A= GNU_CONFIGURE=3D yes=0A= USE_BISON=3D build=0A= =0A= .if !defined(NOPORTDOCS)=0A= .if !defined(WITH_INCLUDED_FAQ)=0A= DISTFILES+=3D FAQ:faq=0A= .endif=0A= PORTDOCS=3D FAQ INTRO CHANGES COMPAT NEWS POSIX RBASH=0A= .endif=0A= =0A= CONFIGURE_ARGS=3D --without-bash-malloc \=0A= --disable-rpath \=0A= --enable-disabled-builtins=0A= =0A= .if defined(WITH_STATIC_BASH) || defined(NO_DYNAMICROOT) || = (defined(NOSHARED) && ${NOSHARED:L} !=3D "no")=0A= .if !defined(WITHOUT_NLS)=0A= WITHOUT_NLS=3Dyes=0A= .endif=0A= CONFIGURE_ARGS+=3D --enable-static-link=0A= PKGNAMESUFFIX=3D -static=0A= CONFLICTS+=3D bash-[0-9]* bash3-[0-9]* bash3-static-[0-9]*=0A= .else=0A= CONFIGURE_ARGS+=3D --enable-static-link=3Dno=0A= CONFLICTS+=3D bash-static-[0-9]* bash3-[0-9]* bash3-static-[0-9]*=0A= .endif=0A= =0A= .if defined(WITHOUT_HELP)=0A= CONFIGURE_ARGS+=3D --disable-help-builtin=0A= PLIST_SUB+=3D HELP=3D"@comment "=0A= .elif defined(WITH_INTEGRATED_HELPFILES)=0A= PLIST_SUB+=3D HELP=3D"@comment "=0A= .else=0A= CONFIGURE_ARGS+=3D --enable-separate-helpfiles=0A= PLIST_SUB+=3D HELP=3D""=0A= .endif=0A= =0A= .if defined(WITHOUT_NLS)=0A= CONFIGURE_ARGS+=3D --disable-nls=0A= PLIST_SUB+=3D NLS=3D"@comment "=0A= .else=0A= USE_ICONV=3D yes=0A= USE_GETTEXT=3D yes=0A= PLIST_SUB+=3D NLS=3D""=0A= .endif=0A= =0A= CPPFLAGS+=3D ${PTHREAD_CFLAGS} \=0A= -I${LOCALBASE}/include=0A= LDFLAGS+=3D -L${LOCALBASE}/lib=0A= =0A= CONFIGURE_ENV=3D YACC=3D"bison -y"=0A= =0A= post-patch:=0A= @${REINPLACE_CMD} -e "s|%%PREFIX%%|${PREFIX}|g" ${WRKSRC}/doc/bash.1=0A= .if defined(WITH_SYSLOG)=0A= @${REINPLACE_CMD} \=0A= -e "s|/\*.*#define SYSLOG_HISTORY .*\*/|#define SYSLOG_HISTORY|g" \=0A= ${WRKSRC}/config-top.h=0A= .endif=0A= .if defined(WITHOUT_NLS)=0A= @${REINPLACE_CMD} -e "s|@LIBICONV@||g" ${WRKSRC}/Makefile.in=0A= .endif=0A= =0A= post-configure:=0A= @${FIND} ${WRKSRC} -name Makefile -print0 | ${XARGS} -0 \=0A= ${REINPLACE_CMD} -e "s|^DESTDIR *=3D|& ${DESTDIR}|"=0A= .if defined(WITHOUT_NLS)=0A= @${REINPLACE_CMD} -e "s|#define HAVE_ICONV 1|#undef HAVE_ICONV|g" = ${WRKSRC}/config.h=0A= .endif=0A= =0A= pre-build:=0A= @${ECHO_CMD} $$((${PORTREVISION}-1)) > ${WRKSRC}/.build=0A= =0A= pre-install:=0A= @${SETENV} PKG_PREFIX=3D"${PREFIX}" \=0A= ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL=0A= =0A= post-install:=0A= @cd ${PREFIX}/bin ; ${LN} -sf bash rbash=0A= .if !defined(NOPORTDOCS)=0A= @${MKDIR} ${DOCSDIR}=0A= .if !defined(WITH_INCLUDED_FAQ)=0A= @${INSTALL_DATA} ${DISTDIR}/${DIST_SUBDIR}/FAQ \=0A= ${WRKSRC}/doc/INTRO ${DOCSDIR}=0A= .else=0A= @${INSTALL_DATA} ${WRKSRC}/doc/FAQ \=0A= ${WRKSRC}/doc/INTRO ${DOCSDIR}=0A= .endif=0A= @for d in ${PORTDOCS:NFAQ:NINTRO}; do \=0A= ${INSTALL_DATA} ${WRKSRC}/$${d} ${DOCSDIR}; \=0A= done=0A= .endif=0A= @${SETENV} PKG_PREFIX=3D"${PREFIX}" PKG_DESTDIR=3D"${DESTDIR}" \=0A= ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL=0A= =0A= regress: build=0A= cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${MAKE} ${MAKE_ARGS} test=0A= =0A= ckp:=0A= ${MAKE} -DPATCH_DEBUG clean patch=0A= =0A= cklatest:=0A= @${ECHO} -n "Currently at: "=0A= @${MAKE} -V PATCHLEVEL=0A= -ncftpls \=0A= = ftp://ftp.cwru.edu/pub/${PORTNAME}/${PORTNAME}-${PORTVERSION:C/\.[0-9a-z]= *$//}-patches/ \=0A= | fgrep -v .sig | ${TAIL}=0A= =0A= .include =0A= ------=_NextPart_000_0004_01CDDFA6.4E5F3540-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 18:36:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2728C96C for ; Fri, 21 Dec 2012 18:36:16 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1848FC1C for ; Fri, 21 Dec 2012 18:36:15 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hn14so2952238wib.15 for ; Fri, 21 Dec 2012 10:36:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=q50INIdvrxXpxlMq6aQuYmLbOCC275VxwNmTPC0o9vQ=; b=MmyY09Yb+NPv9mgUnRK9MPMVxXVxziYLPwbLEb3j7C0GuG5ZbJUONEBqRGM0CF919i WdL7YzX1dvwz8UOPjJkDRVyEfT2iFRr+O9oDl0thPCSDJh2Flu+0RSWcmNt/X01nE2VC NjnyCJ1tUKfaLlipJE1ErAMz8fLLpl0gqlJb+RCX8Z6LYSwdtyMKo6oK9RIv6Bj2fq8h aYXjUTs7d+OiPx/wAIlC5eZoH/jUjJOTUsDyn8H0b18Eho4ESkE38VxVOp+XN/PPuucg eY+IdpD7T8mWbrxvuFzraN2ADTvTm0OlUO9agg51Qmrl46Ts9xOucv8EpP3Qa3Plnb4a E31w== Received: by 10.180.73.202 with SMTP id n10mr24933180wiv.17.1356114969372; Fri, 21 Dec 2012 10:36:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.92.105 with HTTP; Fri, 21 Dec 2012 10:35:39 -0800 (PST) In-Reply-To: <20121126150028.GK84121@FreeBSD.org> References: <201211201543.17903.Mark.Martinec+freebsd@ijs.si> <20121121075642.GR67660@FreeBSD.org> <20121121145240.GE67660@glebius.int.ru> <20121126150028.GK84121@FreeBSD.org> From: Maxim Khitrov Date: Fri, 21 Dec 2012 13:35:39 -0500 Message-ID: Subject: Re: Upgrading FreeBSD to use the NEW pf syntax. To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlvORnRkPV7jAFlwoaNQdaeLf1Egk1goRjxrubw9tL4AwqeIMNS2QwrgXt/fTwmAEAxaVVF Cc: freebsd-current@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 18:36:16 -0000 On Mon, Nov 26, 2012 at 10:00 AM, Gleb Smirnoff wrote: > Paul, > > On Sat, Nov 24, 2012 at 02:11:32PM -0000, Paul Webster wrote: > P> I only really need one question answered in honesty; > P> > P> I personally think that by forking our own version of PF we have > P> essentially made something totally different to what everyone wants to > P> use. Which is fine, but because of that development of new features have > P> dropped behind. > P> > P> If we had kept up with OpenBSD's version even if we trailed it by one > P> MAJOR release; at least part of the development would have been done. > P> > P> So now we end up in a situation where we have these firewalls, > P> IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf. > P> So timewise the fork of pf may have actually cost more in time rather than > P> less. > P> > P> I don't however think the 'solution' to the problem is just to say no to > P> the userbase by not even trying to port across the newer pf. I think we > P> should look at bringing it across, slowly and seeing what the uptake is > P> like; in a few MAJOR releases we can start to look at which of the > P> firewalls realistically are not used that much and should be deprecated. > > If you see a large userbase that eagers to see new pf, then you can port > it to FreeBSD, maintain it, catch up with new versions from OpenBSD, > and so on. No one forbids you doing that. Putting aside the issue of new syntax... What is the actual state of pf in the upcoming FreeBSD 9.1-RELEASE? Have there been any changes from 9.0? The most recent list of PRs doesn't look very encouraging. I'm setting up a new office firewall right now. I tried installing OpenBSD 5.2, but it doesn't recognize the Intel X25-E drive in AHCI mode or the Intel X540 10GbE adapter, which should be supported. Maybe I can fix these problems, but I'd much rather see an improvement in the state of FreeBSD firewalls. No one needs three choices, we need one that works and is actively maintained. - Max From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 20:50:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FCEE6C6 for ; Fri, 21 Dec 2012 20:50:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6298FC0A for ; Fri, 21 Dec 2012 20:50:31 +0000 (UTC) Received: by mail-da0-f50.google.com with SMTP id h15so2272796dan.23 for ; Fri, 21 Dec 2012 12:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=19zEaQbxONo+U5FUSv9S1G2DII0FAJOEXl6Stxesbcc=; b=RT3Mw1ZUfbviHPlo0MCHpWoZF0UuH4+8o5aZ5MJY5iway7krKEIK2k/U9MF2Sru8Fx 1L5Ez7ANdGgKwulIEoR7rF+uwH1zfoohyJG9ElaBeLKiXT0H8EPugG0h5YF0j31Vnmxg XZvYtpneugXDHktLID4DXVEBV+/1rSd2bHoM3n2WtW5KEqshQyx4NtToyLufPQ4zj39q xgzFTYRRRC4J+OI98zMw2cwodiLQvAw4/PD86aX0BFP599zjO9VIUpus7V1bmxzY2G4u 7kZkTkgZh6T3B1co0iceZN1dOiApBRNcttzHKAF057u/XeU08XYLM1tbROuO8Y8DFdUB SgJQ== X-Received: by 10.68.189.233 with SMTP id gl9mr42301639pbc.166.1356121456954; Fri, 21 Dec 2012 12:24:16 -0800 (PST) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPS id sy1sm7504184pbc.66.2012.12.21.12.24.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 12:24:16 -0800 (PST) Subject: Re: ports/shells/bash upgrade to patch level 39 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <000301cddf9d$ec9a7f20$c5cf7d60$@quicknet.nl> Date: Fri, 21 Dec 2012 12:24:12 -0800 Content-Transfer-Encoding: 7bit Message-Id: <53DE6340-1121-401C-A51F-2CE182CEDA2A@gmail.com> References: <000301cddf9d$ec9a7f20$c5cf7d60$@quicknet.nl> To: "Michael Zoon" X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 20:50:32 -0000 On Dec 21, 2012, at 9:09 AM, Michael Zoon wrote: > Hi, > I did update the make and distinfo file for a upgrade of bash 4.2.37 to > 4.2.39 > It is attached in this message. Could you please submit a PR for this and CC the maintainer? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 21:02:46 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58FFBAEA for ; Fri, 21 Dec 2012 21:02:46 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id DDF968FC13 for ; Fri, 21 Dec 2012 21:02:44 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id qBLL2bEj064931 for ; Fri, 21 Dec 2012 15:02:37 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id qBLL2blQ064930 for current@freebsd.org; Fri, 21 Dec 2012 15:02:37 -0600 (CST) (envelope-from brooks) Date: Fri, 21 Dec 2012 15:02:37 -0600 From: Brooks Davis To: current@freebsd.org Subject: NetBSD mtree committed Message-ID: <20121221210237.GA47912@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:02:46 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have committed NetBSD's mtree to the tree and am building and installing it as nmtree. I plan to replace our mtree with this version after the following steps: - Add a WITH_NMTREE build option to install nmtree as mtree and the old mtree as omtree. - Switch the default to WITH_NMTREE. - Remove the old mtree. - Rename usr.sbin/nmtree to usr.sbin/mtree. During this process I will also commit patches to switch makefs to use NetBSD's mtree which will make the -F specfile option more useful. As a reminder we are doing this because, we will gain the -C option which produces mtree files compatible with libarchive and makefs (one line per file with full path) and the -N option which allows a stand alone set of passwd and group files. When mated with the -U and -M options to NetBSD's install we will have most of the pieces require to allow installworld to run as a user and then build images containing proper permissions. The new mtree does introduce some incompatibilities, but nearly all can be overcome with small command line changes. With one exception, FreeBSD 9 compatible behavior can be restored by adding the "-F freebsd9" to the command line. In some cases new warnings are generate to aid transition, but the output should otherwise be the same. If you find cases where it is not, please let me know. Known incompatibilities are: - The -u and -U (update) options do not update the modification time or set file flags unless the -t and -i options are passed respectively. - Because the -i option as already take, FreeBSD's option to indent 4 spaces for each directory level is now -j. - The -d (directories only) option does not omit blank lines when entering a new directory or leaving one. The -b option now enables this behavior independently. - The handling of the uname and group keywords when the uid or gid can not be resolved is changed. In the new code, when the uname or group keyword is request and the name can not be found a uid or gid keyword is emitted instead. Historically, mtree would report and error and exit unless the -w option was passed. If that happened then a warning was printed and no keyword was emitted. That resulted in potentially dangerous /set statements. As a result I declined to implement this behavior. Here is an example of the dangerous \set statements: $ ls -l total 0 -rwxr-xr-x 1 root wheel 0 Dec 21 14:13 a -rwsr-xr-x 1 12345 wheel 0 Dec 21 14:13 b $ mtree -c -p . -n -k uname,mode -w > ../mtree.out mtree: Could not get uname for uid=3D12345 $ cat ../mtree.out /set type=3Dfile uname=3Droot mode=3D0755 . type=3Ddir uname=3Dbrooks a =20 b mode=3D04755 .. $ mtree -f ../mtree.out -u -p . b: user (0, 12345, modified) $ ll total 0 -rwxr-xr-x 1 root wheel 0 Dec 21 14:13 a -rwsr-xr-x 1 root wheel 0 Dec 21 14:13 b $ I have heard some requests to MFC the new mtree code. At this time I have no concrete plans to do so. If it were done then I would modify the code to run with -F freebsd9 and would implement full uname/group compatibility. -- Brooks ----- Forwarded message from Brooks Davis ----- =46rom: Brooks Davis Date: Fri, 21 Dec 2012 21:00:01 +0000 (UTC) To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: svn commit: r244562 - in head: contrib/mknod contrib/mtree usr.sbin usr.sbin/nmtree Author: brooks Date: Fri Dec 21 21:00:00 2012 New Revision: 244562 URL: http://svnweb.freebsd.org/changeset/base/244562 Log: Add NetBSD's mtree to the tree and install it as nmtree as the first step towards replacing our mtree. =20 Sponsored by: DARPA, AFRL Thanks to: cristos@NetBSD for reviewing and committing my patches wiz@NetBSD for fixing typos in my patches Added: head/contrib/mknod/ - copied from r244548, vendor/NetBSD/mknod/dist/ head/contrib/mtree/ - copied from r244548, vendor/NetBSD/mtree/dist/ head/usr.sbin/nmtree/ head/usr.sbin/nmtree/Makefile (contents, props changed) Modified: head/usr.sbin/Makefile Modified: head/usr.sbin/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/usr.sbin/Makefile Fri Dec 21 20:50:47 2012 (r244561) +++ head/usr.sbin/Makefile Fri Dec 21 21:00:00 2012 (r244562) @@ -55,6 +55,7 @@ SUBDIR=3D adduser \ nfsdumpstate \ nfsrevoke \ nfsuserd \ + nmtree \ nologin \ pc-sysinstall \ pciconf \ Added: head/usr.sbin/nmtree/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.sbin/nmtree/Makefile Fri Dec 21 21:00:00 2012 (r244562) @@ -0,0 +1,26 @@ +# $FreeBSD$ + +.include + +.PATH: ${.CURDIR}/../../contrib/mtree + +PROG=3D nmtree +MAN=3D nmtree.8 +SRCS=3D compare.c crc.c create.c excludes.c getid.c misc.c mtree.c \ + spec.c specspec.c verify.c +LDADD+=3D -lmd -lutil + +CFLAGS+=3D -I${.CURDIR}/../../contrib/mknod +.PATH: ${.CURDIR}/../../contrib/mknod +SRCS+=3D pack_dev.c + +CFLAGS+=3D -I${.CURDIR}/../../lib/libnetbsd +LIBNETBSDDIR=3D ${.OBJDIR}/../../lib/libnetbsd +LIBNETBSD=3D ${LIBNETBSDDIR}/libnetbsd.a +DPADD+=3D {LIBNETBSD} +LDADD+=3D ${LIBNETBSD} + +nmtree.8: mtree.8 + cp ${.ALLSRC} ${.TARGET} + +.include ----- End forwarded message ----- --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQ1M5sXY6L6fI4GtQRApU4AKCSm0xmK9kS3IT7Q8oDCVeRpZlEFgCg3lnA K0TrycZTJ1AjeaCgM8/5HX0= =V7fF -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 21:39:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5895642 for ; Fri, 21 Dec 2012 21:39:48 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 25C218FC16 for ; Fri, 21 Dec 2012 21:39:47 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jc3so2595110bkc.7 for ; Fri, 21 Dec 2012 13:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EcimVUVGtBfG/GvuHaKDqscDBMPBHGZf92TzkCugBu0=; b=vry2mklgN2PnZO+Nf2nSw4tpzv8EGHDlur/J3KfZf+zaQkKtSGYLSJopmoqQQXv2PA qCZAsa9C7RD8RSRGmPCLW6hv7yOHjMWGQuM3LJx8FvqP5dv03KrykLHUEmQXTvGaTXqu /sVLCIMFCXWzdmXpXlALVj6XwnPHaCqxU4DWbLfP4pGvGLVP6Z9pjxbLeER3F8uJNMNh PMPhM5jn4brhqxzDO/8wnMqeuMRMmG8YEQ/kkCkCwkaFj2Up6pJA7jFEAP6HZDNiLbxh 1jnMR68N9yVsOvny0Uzc4zVdR+Og4m8y6raC6WsgyKUOO85kbavQm5Bui5jiTVeGFCse WOWg== MIME-Version: 1.0 Received: by 10.204.143.147 with SMTP id v19mr6948045bku.32.1356125986748; Fri, 21 Dec 2012 13:39:46 -0800 (PST) Received: by 10.204.167.71 with HTTP; Fri, 21 Dec 2012 13:39:46 -0800 (PST) Received: by 10.204.167.71 with HTTP; Fri, 21 Dec 2012 13:39:46 -0800 (PST) In-Reply-To: <53DE6340-1121-401C-A51F-2CE182CEDA2A@gmail.com> References: <000301cddf9d$ec9a7f20$c5cf7d60$@quicknet.nl> <53DE6340-1121-401C-A51F-2CE182CEDA2A@gmail.com> Date: Fri, 21 Dec 2012 21:39:46 +0000 Message-ID: Subject: Re: ports/shells/bash upgrade to patch level 39 From: Chris Rees To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current , Michael Zoon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:39:48 -0000 On 21 Dec 2012 20:50, "Garrett Cooper" wrote: > > On Dec 21, 2012, at 9:09 AM, Michael Zoon wrote: > > > Hi, > > I did update the make and distinfo file for a upgrade of bash 4.2.37 to > > 4.2.39 > > It is attached in this message. > > Could you please submit a PR for this and CC the maintainer? Ccing maintainers on PRs is a waste of everyone's time, and I really wish people wouldn't do it. The gnats-aa does a far better job of handling them. Also, please don't send ports issues to -current. Chris From owner-freebsd-current@FreeBSD.ORG Fri Dec 21 23:38:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B66D9FB1; Fri, 21 Dec 2012 23:38:21 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (mail.wasikowski.net [91.204.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF498FC0A; Fri, 21 Dec 2012 23:38:19 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [91.204.91.44]) by bijou.wasikowski.net (Postfix) with ESMTP id D001DF07; Sat, 22 Dec 2012 00:38:10 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (scan.wasikowski.net [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id RQz4ubSMmGvU; Sat, 22 Dec 2012 00:38:10 +0100 (CET) Received: from [192.168.168.2] (89-72-12-251.dynamic.chello.pl [89.72.12.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lukasz@wasikowski.net) by bijou.wasikowski.net (Postfix) with ESMTPSA id 40478F04; Sat, 22 Dec 2012 00:38:10 +0100 (CET) Message-ID: <50D4F2E4.7020600@wasikowski.net> Date: Sat, 22 Dec 2012 00:38:12 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 23:38:21 -0000 W dniu 2012-12-21 13:23, Kimmo Paasiala pisze: > On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala wrote: >> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wrote: >>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: >>>> A question related to this for those who have been doing work on the >>>> rc(8) scripts. Can I assume that /usr/bin is available when >>>> network.subr functions are used? Doing calculations on hexadecimal >>>> numbers is going to be very awkward if I can't use for example bc(1). >>> >>> You cannot assume that /usr/bin is available when setting up the >>> network. It may be that /usr is mounted via NFS. >>> >>> You can use hexadecimal numbers (prefixed with 0x) in $((...)) >>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can >>> use; in older versions you can use hexdigit and hexprint from >>> network.subr. >>> >>> -- >>> Jilles Tjoelker >> >> Thanks, I've rewitten my patch to support ranges. It is attached in >> this message. >> >> Again it's against a very recent 9-STABLE, I still haven't found time >> to see if it applies to CURRENT. >> >> It does allow you to do crazy stuff like >> >> ipv6_addrs_re0="2001:db8:1111:2222::1-ffff/64" >> >> However I didn't find anything to limit the number of aliases in the >> ipv4 version of the function either. >> >> Please test it :) >> >> >> Then a question about the PR >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I >> attach this new patch to it? The submit follow up -button fires up my >> email client and I'm not so sure how to submit a new patch for the PR >> in an email in such a way that it appears properly formatted in the >> PR. >> >> Regards, >> >> Kimmo Paasiala > > PR updated with the new patch. Your patch applied cleanly, but it's not working or I am doing something wrong. root@freebsd:~ # uname -a FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf hostname="freebsd" ifconfig_em0="up" ipv4_addrs_em0="192.168.168.20-24/24" defaultrouter="192.168.168.1" ipv6_activate_all_interfaces="YES" ipv6_addrs_em0="2001:6a0:1cb::1-6/64" ipv6_defaultrouter="2001:6a0:1cb::ffff" sshd_enable="YES" dumpdev="NO" named_enable="YES" root@freebsd:~ # ifconfig em0: flags=8843 metric 0 mtu 1500 options=9b ether 08:00:27:02:83:71 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 inet 192.168.168.20 netmask 0xffffff00 broadcast 192.168.168.255 inet 192.168.168.21 netmask 0xffffffff broadcast 192.168.168.21 inet 192.168.168.22 netmask 0xffffffff broadcast 192.168.168.22 inet 192.168.168.23 netmask 0xffffffff broadcast 192.168.168.23 inet 192.168.168.24 netmask 0xffffffff broadcast 192.168.168.24 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 -- best regards, Lukasz Wasikowski From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 00:21:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 275D3A30; Sat, 22 Dec 2012 00:21:42 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mx1.freebsd.org (Postfix) with ESMTP id A848F8FC13; Sat, 22 Dec 2012 00:21:41 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id vb8so5090378obc.20 for ; Fri, 21 Dec 2012 16:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l6M4TRxaqLLzRP3jTZ8KU7X7i+53/8w+0Zx2scMdSpw=; b=KrX2FbDQgY3TQGCMhud1PjqS6afQh2ijg9ArtCkNBYkJ94JrZiJBXpYijecII2olDL mHXut5frSpPTgw5wefI6fTLGDDQWa4LxX5ySmn4xlRvL+WL/wlveeT1tRuq6jsBsn5Ll WYWB/pHOYp6MFj5YTzmpPGfJqP1mpmVTKYcGVdaU0bdOl3P6Udt4ZXUNXEvHLNJx+qiw tcGS9L+cgPQiw+gDZ+yOQ6OaW/qwbRspl5+PRip6CB10XnCK3hw32WWd+FpqdEvGSoOh MGTmDpY3nY8rItkVrMeQUAPe57IWZTUxb/gG3ZDNTptEezucKlBKC3QM38exmTLkwFvH lM6w== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr629480oeg.17.1356135700963; Fri, 21 Dec 2012 16:21:40 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 16:21:40 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 16:21:40 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 00:21:42 -0000 On Mon, Dec 10, 2012 at 3:18 PM, wrote: > On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >> after it's finalised/freed. >> >> I have a similar bug showing up on ath(4) RX. :( > > Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > vm.memguard.desc to the name of the UMA zone used for the 9216 byte > allocations, mbuf_jumbo_9k. This should cause a panic when the memory > is touched after free. Tada (dang, that's nifty stuff)! # sysctl vm.memguard.desc=mbuf_jumbo_9k vm.memguard.descM: -> mbuf_jumboem_9k # ory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 Memory modified after free 0xffffff8000405000(9216) val=0 @ 0xffffff8000405000 Memory modified after free 0xffffff8000409000(9216) val=5a5a5a5a @ 0xffffff8000409000 Fatal trap 1: privileged instruction fault while in kernel mode Fatal trap 1: privileged instruction fault while in kernel mode Memory modified after free 0xffffff800040d000(9216) val=5a5a5a5a @ 0xffffff800040d000 Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 3; cpuid = 1; apic id = 02 cpuid = 0; apic id = 06 apic id = 00 instruction pointer = 0x20:0xffffffff80af5099 instruction pointer = 0x20:0xffffffff80af5099 instruction pointer = 0x20:0xffffffff80af5099 Fatal trap 1: privileged instruction fault while in kernel mode stack pointer = 0x28:0xffffff8496fff880 stack pointer = 0x28:0xffffff8496fe1880 cpuid = 2; frame pointer = 0x28:0xffffff8496fff8b0 frame pointer = 0x28:0xffffff8496fe18b0 stack pointer = 0x28:0xffffff849705d880 code segment = base 0x0, limit 0xfffff, type 0x1b frame pointer = 0x28:0xffffff849705d8b0 apic id = 04 code segment = base 0x0, limit 0xfffff, type 0x1b code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 = DPL 0, pres 1, long 1, def32 0, gran 1 instruction pointer = 0x20:0xffffffff80af5099 processor eflags = = DPL 0, pres 1, long 1, def32 0, gran 1 interrupt enabled, processor eflags = stack pointer = 0x28:0xffffff8497067880 interrupt enabled, resume, resume, frame pointer = 0x28:0xffffff84970678b0 IOPL = 0 code segment = base 0x0, limit 0xfffff, type 0x1b current process = = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = 12 (irq280: ix0:que 3) ilock order reversal: (Giant after non-sleepable) 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fff320 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff450 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 trap() at trap+0x836/frame 0xffffff8496fff7c0 calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fff880, rbp = 0xffffff8496fff8b0 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496fff8e0 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496fff960 m_getjcl() at m_getjcl+0xce/frame 0xffffff8496fff9a0 ixgbe_refresh_mbufs() at ixgbe_refresh_mbufs+0x77/frame 0xffffff8496fffa20 ixgbe_rxeof() at ixgbe_rxeof+0x5ce/frame 0xffffff8496fffad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff8496fffb20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8496fffb60 ithread_loop() at ithread_loop+0x161/frame 0xffffff8496fffbb0 fork_exit() at fork_exit+0x84/frame 0xffffff8496fffbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496fffbf0 --- trap 0, rip = 0, rsp = 0xffffff8496fffcb0, rbp = 0 --- [ thread pid 12 tid 100218 ] Stopped at uma_find_refcnt+0x79: db> This looks interesting: $ git diff sys/dev/ixgbe/ixgbe.c diff --git a/sys/dev/ixgbe/ixgbe.c b/sys/dev/ixgbe/ixgbe.c index 40f5488..19f842b 100644 --- a/sys/dev/ixgbe/ixgbe.c +++ b/sys/dev/ixgbe/ixgbe.c @@ -897,8 +897,10 @@ ixgbe_qflush(struct ifnet *ifp) for (int i = 0; i < adapter->num_queues; i++, txr++) { IXGBE_TX_LOCK(txr); - while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) + while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) { m_freem(m); + m = NULL; + } IXGBE_TX_UNLOCK(txr); } if_qflush(ifp); I'm going to recompile the driver and restart the network a few times (that's the sticking point) and see what happens. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 00:53:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9721EF17; Sat, 22 Dec 2012 00:53:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2610F8FC12; Sat, 22 Dec 2012 00:53:23 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n16so5328724oag.9 for ; Fri, 21 Dec 2012 16:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9JgngyOvVeZLjeXc+y1V73qebFBp1j080brh42f/4EY=; b=EGqaWcI1YF9ewIqArYO3liNyUd1QCmOzNsXS6HnsB9y4NZqt+PPxgpdyT3pDKr0h2w r/lHO1yNsD6l3v7aY5PJTMQ551d3Rzb2FuHOYlgrLqSVZrOuNofUwYbseMF8Z1kY1j7y to9yA6s3nneX4ro2Owe5vhiuyMGfbWMZRIkntPVd3kBPXvrqijI+w+KG0Q2bRmqSjqfg xvhgjR1U6e3YesjGDwH3JqLw8iskYBFj1CmZ4Vy28rawis0e9nyyKSc8gUI0FCDnSRQ3 rVLCE7x5YKYKqi26UBXClqfFMCbRC3pY83XOOzN96CjjndS40MU7sqgaVEJF9KiTjs2z oSzw== MIME-Version: 1.0 Received: by 10.60.6.226 with SMTP id e2mr1074515oea.56.1356137236378; Fri, 21 Dec 2012 16:47:16 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 16:47:15 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 16:47:15 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 00:53:24 -0000 On Fri, Dec 21, 2012 at 4:21 PM, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 3:18 PM, wrote: >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >>> after it's finalised/freed. >>> >>> I have a similar bug showing up on ath(4) RX. :( >> >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory >> is touched after free. > > Tada (dang, that's nifty stuff)! > > # sysctl vm.memguard.desc=mbuf_jumbo_9k > vm.memguard.descM: -> mbuf_jumboem_9k > # ory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 > Memory modified after free 0xffffff8000405000(9216) val=0 @ 0xffffff8000405000 > Memory modified after free 0xffffff8000409000(9216) val=5a5a5a5a @ > 0xffffff8000409000 > > > > > > > Fatal trap 1: privileged instruction fault while in kernel mode > Fatal trap 1: privileged instruction fault while in kernel mode > Memory modified after free 0xffffff800040d000(9216) val=5a5a5a5a @ > 0xffffff800040d000 > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 3; > cpuid = 1; > apic id = 02 > cpuid = 0; apic id = 06 > apic id = 00 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > Fatal trap 1: privileged instruction fault while in kernel mode > stack pointer = 0x28:0xffffff8496fff880 > stack pointer = 0x28:0xffffff8496fe1880 > cpuid = 2; frame pointer = 0x28:0xffffff8496fff8b0 > frame pointer = 0x28:0xffffff8496fe18b0 > stack pointer = 0x28:0xffffff849705d880 > code segment = base 0x0, limit 0xfffff, type 0x1b > frame pointer = 0x28:0xffffff849705d8b0 > apic id = 04 > code segment = base 0x0, limit 0xfffff, type 0x1b > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > = DPL 0, pres 1, long 1, def32 0, gran 1 > instruction pointer = 0x20:0xffffffff80af5099 > processor eflags = = DPL 0, pres 1, long > 1, def32 0, gran 1 > interrupt enabled, processor eflags = stack pointer = > 0x28:0xffffff8497067880 > interrupt enabled, resume, resume, frame pointer = > 0x28:0xffffff84970678b0 > IOPL = 0 > code segment = base 0x0, limit 0xfffff, type 0x1b > current process = = DPL 0, pres 1, long > 1, def32 0, gran 1 > processor eflags = 12 (irq280: ix0:que 3) > ilock order reversal: (Giant after non-sleepable) > 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fff320 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 > witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff450 > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 > ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 > cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 > kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 > trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 > trap() at trap+0x836/frame 0xffffff8496fff7c0 > calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 > --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fff880, rbp > = 0xffffff8496fff8b0 --- > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 > mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496fff8e0 > uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496fff960 > m_getjcl() at m_getjcl+0xce/frame 0xffffff8496fff9a0 > ixgbe_refresh_mbufs() at ixgbe_refresh_mbufs+0x77/frame 0xffffff8496fffa20 > ixgbe_rxeof() at ixgbe_rxeof+0x5ce/frame 0xffffff8496fffad0 > ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff8496fffb20 > intr_event_execute_handlers() at > intr_event_execute_handlers+0x90/frame 0xffffff8496fffb60 > ithread_loop() at ithread_loop+0x161/frame 0xffffff8496fffbb0 > fork_exit() at fork_exit+0x84/frame 0xffffff8496fffbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496fffbf0 > --- trap 0, rip = 0, rsp = 0xffffff8496fffcb0, rbp = 0 --- > [ thread pid 12 tid 100218 ] > Stopped at uma_find_refcnt+0x79: > db> > > This looks interesting: > > $ git diff sys/dev/ixgbe/ixgbe.c > diff --git a/sys/dev/ixgbe/ixgbe.c b/sys/dev/ixgbe/ixgbe.c > index 40f5488..19f842b 100644 > --- a/sys/dev/ixgbe/ixgbe.c > +++ b/sys/dev/ixgbe/ixgbe.c > @@ -897,8 +897,10 @@ ixgbe_qflush(struct ifnet *ifp) > > for (int i = 0; i < adapter->num_queues; i++, txr++) { > IXGBE_TX_LOCK(txr); > - while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) > + while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) { > m_freem(m); > + m = NULL; > + } > IXGBE_TX_UNLOCK(txr); > } > if_qflush(ifp); > > I'm going to recompile the driver and restart the network a few > times (that's the sticking point) and see what happens. Now the T4 is angry: ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^CMemory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80af5099 stack pointer = 0x28:0xffffff8496f41910 frame pointer ^C = 0x28:0xffffff8496f41940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq265: t4nex0:1.0) lock order reversal: (Giant after non-sleepable) 1st 0xfffffe00790eb690 cxgbe1 rxq0-fl (cxgbe1 rxq0-fl) @ /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_sge.c:1008 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496f413b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496f41460 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496f414e0 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496f41520 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496f41540 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496f41560 cngrab() at cngrab+0x35/frame 0xffffff8496f41580 kdb_trap() at kdb_trap+0x124/frame 0xffffff8496f415e0 trap_fatal() at trap_fatal+0x345/frame 0xffffff8496f41640 trap() at trap+0x836/frame 0xffffff8496f41850 calltrap() at calltrap+0x8/frame 0xffffff8496f41850 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496f41910, rbp = 0xffffff8496f41940 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496f41940 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496f41970 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496f419f0 refill_fl() at refill_fl+0x28f/frame 0xffffff8496f41a60 service_iq() at service_iq+0x821/frame 0xffffff8496f41b00 t4_intr() at t4_intr+0x2e/frame 0xffffff8496f41b20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8496f41b60 ithread_loop() at ithread_loop+0x161/frame 0xffffff8496f41bb0 fork_exit() at fork_exit+0x84/frame 0xffffff8496f41bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496f41bf0 --- trap 0, rip = 0, rsp = 0xffffff8496f41cb0, rbp = 0 --- [ thread pid 12 tid 100196 ] Stopped at uma_find_refcnt+0x79: Guess I'll rebuild the modules with the changes that np@ just made today and see if that changes anything... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 01:19:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D755833; Sat, 22 Dec 2012 01:19:11 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id E63F08FC0A; Sat, 22 Dec 2012 01:19:10 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2444417wgh.7 for ; Fri, 21 Dec 2012 17:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ut/w7+iVHkzT0sIfQg7yNnCLhjDQB2XVNJmjzu3MDTk=; b=0+uTwBExZfhEKiU/81woBqqxuRstlxW2o/jcx17qGaHopaShvlIfEBV1S7v1055/v4 URZQmF4U8+jHpgRjIsu9x7Z77fqt/sJCVsJIdZL0/+XCV6TI0ddHLCNc0MPampBIQPXD i54+CmBxy695Ggcm1WIm1lWbq7yHJfluvwcr+NoRGDlSkNfQBNTV8jeIR9RcOrOSn3zE gGfpUstPUnNEeMK0ifijMNfwInpxck256tdf9V/KmJ2c+ar2B0vkgDYJ+w17OJ1B5PkM ZLq4dLQLXRH1vtYnGxB2DHN4wZI+lPgmZiOUkzbFusTi818Y5mcdeZ0zDYmazbNaOpEM 0Wyg== MIME-Version: 1.0 Received: by 10.180.100.197 with SMTP id fa5mr18259087wib.32.1356139149805; Fri, 21 Dec 2012 17:19:09 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 21 Dec 2012 17:19:09 -0800 (PST) In-Reply-To: <50D4F2E4.7020600@wasikowski.net> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> Date: Sat, 22 Dec 2012 03:19:09 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 01:19:11 -0000 On Sat, Dec 22, 2012 at 1:38 AM, =C5=81ukasz W=C4=85sikowski wrote: > W dniu 2012-12-21 13:23, Kimmo Paasiala pisze: >> On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala wro= te: >>> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wrot= e: >>>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: >>>>> A question related to this for those who have been doing work on the >>>>> rc(8) scripts. Can I assume that /usr/bin is available when >>>>> network.subr functions are used? Doing calculations on hexadecimal >>>>> numbers is going to be very awkward if I can't use for example bc(1). >>>> >>>> You cannot assume that /usr/bin is available when setting up the >>>> network. It may be that /usr is mounted via NFS. >>>> >>>> You can use hexadecimal numbers (prefixed with 0x) in $((...)) >>>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can >>>> use; in older versions you can use hexdigit and hexprint from >>>> network.subr. >>>> >>>> -- >>>> Jilles Tjoelker >>> >>> Thanks, I've rewitten my patch to support ranges. It is attached in >>> this message. >>> >>> Again it's against a very recent 9-STABLE, I still haven't found time >>> to see if it applies to CURRENT. >>> >>> It does allow you to do crazy stuff like >>> >>> ipv6_addrs_re0=3D"2001:db8:1111:2222::1-ffff/64" >>> >>> However I didn't find anything to limit the number of aliases in the >>> ipv4 version of the function either. >>> >>> Please test it :) >>> >>> >>> Then a question about the PR >>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174225) I wrote, how can = I >>> attach this new patch to it? The submit follow up -button fires up my >>> email client and I'm not so sure how to submit a new patch for the PR >>> in an email in such a way that it appears properly formatted in the >>> PR. >>> >>> Regards, >>> >>> Kimmo Paasiala >> >> PR updated with the new patch. > > Your patch applied cleanly, but it's not working or I am doing something > wrong. > > root@freebsd:~ # uname -a > FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri > Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC > amd64 > > root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf > hostname=3D"freebsd" > ifconfig_em0=3D"up" > ipv4_addrs_em0=3D"192.168.168.20-24/24" > defaultrouter=3D"192.168.168.1" > ipv6_activate_all_interfaces=3D"YES" > ipv6_addrs_em0=3D"2001:6a0:1cb::1-6/64" > ipv6_defaultrouter=3D"2001:6a0:1cb::ffff" > sshd_enable=3D"YES" > dumpdev=3D"NO" > named_enable=3D"YES" > > root@freebsd:~ # ifconfig > em0: flags=3D8843 metric 0 mtu 15= 00 > options=3D9b > ether 08:00:27:02:83:71 > inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 > inet 192.168.168.20 netmask 0xffffff00 broadcast 192.168.168.255 > inet 192.168.168.21 netmask 0xffffffff broadcast 192.168.168.21 > inet 192.168.168.22 netmask 0xffffffff broadcast 192.168.168.22 > inet 192.168.168.23 netmask 0xffffffff broadcast 192.168.168.23 > inet 192.168.168.24 netmask 0xffffffff broadcast 192.168.168.24 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 > > -- > best regards, > Lukasz Wasikowski You need to first add a single ipv6 address using the ifconfig_em0_ipv6 -syntax. ifconfig_em0_ipv6=3D"2001:6a0:1cb::1/64" And then this should add the rest of the addresses ipv6_addrs_em0=3D"2001:6a0:1cb::2-6/64" It looks like the reason for the difference to ipv4_addrs_IF is that the "alias" parameter for ifconfig(8) operates differently for IPv6 addresses, the first address of an interface can't be added with "alias", for IPv4 it does not care. I'll have to dig deeper but that's what the problem seems to be. -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 01:34:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65993B84; Sat, 22 Dec 2012 01:34:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id 10A078FC0A; Sat, 22 Dec 2012 01:34:42 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id oi10so5079927obb.40 for ; Fri, 21 Dec 2012 17:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AuDKPsfPfAyYcLQXT7JSW//5g/py7FRN7WgfwBaFrXo=; b=wNPWLRiz+sf9dVWledFKaB1QsGNTllHxVHHYXLij/56vCm50TkqN2lMvv9AXa6oO9u 8fvQ015AXA33c9YPOAEVCiT8A0tk4xRzfOM14CtpIzrAs2pNPqVk0N+AlbPaoerezcXS TRuqs8hxsmhj7KenDTIJ6Fi2Io2+0KXB5k+2rSuhSelh5Crk6tUVr7sC5Td/E589VkHj ysNAvQ+y0gQFWrNm/9/wjzBdd1hEQpEKQNJAvlj/LtiweBoPMbNAlZw42AyTCD4swSim JZBVsvz/AuaJiIXekWCEi5AgmOq/cT1iYuMQgoqNzd2vr33w3QsiQHONfz0X6V4W/s9t Epzw== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr716801oeb.24.1356140082417; Fri, 21 Dec 2012 17:34:42 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 17:34:42 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 17:34:42 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 01:34:43 -0000 (clipping off mdf and adrian so they don't get directly spammed :)..) Crud. Continuing the processor after panic didn't work, so it might be a case of cxgbe "shot the sheriff" or something else in the stack is doing something wonky: db> c Memory modified after free 0xffffff8000405000(9216) val=0 @ 0xffffff8000405000 Memory modified after free 0xffffff800040d000(9216) val=0 @ 0xffffff800040d000 Fatal trap 1: privileged instruction fault while in kernel mode Memory modified after free 0xffffff8000409000(9216) val=0 @ 0xffffff8000409000 cpuid = 0; Fatal trap 1: privileged instruction fault while in kernel mode apic id = 00 cpuid = 1; Fatal trap 1: privileged instruction fault while in kernel mode instruction pointer = 0x20:0xffffffff80af5099 cpuid = 2; stack pointer = 0x28:0xffffff8496f41910 apic id = 04 apic id = 02 instruction pointer = 0x20:0xffffffff80af5099 instruction pointer = 0x20:0xffffffff80af5099 stack pointer = 0x28:0xffffff849705d880 frame pointer = 0x28:0xffffff8496f41940 stack pointer = 0x28:0xffffff8497067880 code segment = base 0x0, limit 0xfffff, type 0x1b frame pointer = 0x28:0xffffff849705d8b0 = DPL 0, pres 1, long 1, def32 0, gran 1 frame pointer = 0x28:0xffffff84970678b0 Fatal trap 1: privileged instruction fault while in kernel mode code segment = base 0x0, limit 0xfffff, type 0x1b code segment = base 0x0, limit 0xfffff, type 0x1b processor eflags = = DPL 0, pres 1, long 1, def32 0, gran 1 = DPL 0, pres 1, long 1, def32 0, gran 1 cpuid = 3; interrupt enabled, processor eflags = processor eflags = resume, interrupt enabled, apic id = 06 interrupt enabled, instruction pointer = 0x20:0xffffffff80af5099 resume, resume, stack pointer = 0x28:0xffffff8497071880 IOPL = 0 frame pointer = 0x28:0xffffff84970718b0 IOPL = 0 current process = code segment = base 0x0, limit 0xfffff, type 0x1b 12 (irq283: ix1:que 1) Ilock order reversal: (Giant after non-sleepable) 1st 0xfffffe009a295918 ix1:rx(1) (ix1:rx(1)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4298 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff849705d320 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff849705d3d0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff849705d450 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff849705d490 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff849705d4b0 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff849705d4d0 cngrab() at cngrab+0x35/frame 0xffffff849705d4f0 kdb_trap() at kdb_trap+0x124/frame 0xffffff849705d550 trap_fatal() at trap_fatal+0x345/frame 0xffffff849705d5b0 trap() at trap+0x836/frame 0xffffff849705d7c0 calltrap() at calltrap+0x8/frame 0xffffff849705d7c0 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff849705d880, rbp = 0xffffff849705d8b0 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff849705d8b0 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff849705d8e0 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff849705d960 m_getjcl() at m_getjcl+0xce/frame 0xffffff849705d9a0 ixgbe_refresh_mbufs() at ixgbe_refresh_mbufs+0x77/frame 0xffffff849705da20 ixgbe_rxeof() at ixgbe_rxeof+0x4e9/frame 0xffffff849705dad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff849705db20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff849705db60 ithread_loop() at ithread_loop+0x161/frame 0xffffff849705dbb0 fork_exit() at fork_exit+0x84/frame 0xffffff849705dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff849705dbf0 --- trap 0, rip = 0, rsp = 0xffffff849705dcb0, rbp = 0 --- [ thread pid 12 tid 100224 ] Stopped at uma_find_refcnt+0x79: I setup asymmetric MTUs to see if I can narrow down whether the issue is a jumbo frame or cxgbe/ixgbe issue and so far so good. Trying again with jumbo frames paniced on boot when loading the module (really...?): # Memory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 1; apic id = 02 instruction pointer = 0x20:0xffffffff80af5099 stack pointer = 0x28:0xffffff8496fc9750 frame pointer = 0x28:0xffffff8496fc9780 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3280 (ifconfig) lock order reversal: (Giant after non-sleepable) 1st 0xfffffe00462f7808 ix0:rx(0) (ix0:rx(0)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:3938 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fc91f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fc92a0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fc9320 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fc9360 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fc9380 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fc93a0 cngrab() at cngrab+0x35/frame 0xffffff8496fc93c0 kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fc9420 trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fc9480 trap() at trap+0x836/frame 0xffffff8496fc9690 calltrap() at calltrap+0x8/frame 0xffffff8496fc9690 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fc9750, rbp = 0xffffff8496fc9780 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fc9780 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496fc97b0 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496fc9830 m_getjcl() at m_getjcl+0xce/frame 0xffffff8496fc9870 ixgbe_init_locked() at ixgbe_init_locked+0x62c/frame 0xffffff8496fc9930 ixgbe_ioctl() at ixgbe_ioctl+0x32d/frame 0xffffff8496fc9980 ifioctl() at ifioctl+0xc84/frame 0xffffff8496fc9a40 kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff8496fc9a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff8496fc9ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8496fc9bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8496fc9bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80118481a, rsp = 0x7fffffffd488, rbp = 0x7fffffffd4a0 --- [ thread pid 3280 tid 100220 ] Stopped at uma_find_refcnt+0x79: Setting the MTU exhibits the same problem... just with smaller mbufs: Memory modified after free 0xfffffe014ce86800(2048) val=cc0c0001 @ 0xfffffe014ce86800 Memory modified after free 0xfffffe00bd86f000(2048) val=cc0c0001 @ 0xfffffe00bd86f000 Memory modified after free 0xfffffe00bd3a4000(2048) val=cc0c0001 @ 0xfffffe00bd3a4000 Memory modified after free 0xfffffe011a55c000(2048) val=2d290c00 @ 0xfffffe011a55c000 Memory modified after free 0xfffffe011a5fa800(2048) val=cc0c0001 @ 0xfffffe011a5fa800 Memory modified after free 0xfffffe00bd018800(2048) val=ffffffff @ 0xfffffe00bd018800 Memory modified after free 0xfffffe00bd1c4000(2048) val=7f565000 @ 0xfffffe00bd1c4000 Memory modified after free 0xfffffe011a521800(2048) val=529c0a00 @ 0xfffffe011a521800 Memory modified after free 0xfffffe011a521800(2048) val=cc0c0001 @ 0xfffffe011a521800 Memory modified after free 0xfffffe00bd0ce800(2048) val=cc0c0001 @ 0xfffffe00bd0ce800 Memory modified after free 0xfffffe00bd9a3000(2048) val=ffffffff @ 0xfffffe00bd9a3000 Memory modified after free 0xfffffe00bd8b6800(2048) val=cc0c0001 @ 0xfffffe00bd8b6800 Memory modified after free 0xfffffe00bd923000(2048) val=cc0c0001 @ 0xfffffe00bd923000 Memory modified after free 0xfffffe0188f70800(2048) val=2d290c00 @ 0xfffffe0188f70800 Memory modified after free 0xfffffe0180452000(2048) val=ffffffff @ 0xfffffe0180452000 Memory modified after free 0xfffffe014cd6b800(2048) val=cc0c0001 @ 0xfffffe014cd6b800 Memory modified after free 0xfffffe014c967800(2048) val=cc0c0001 @ 0xfffffe014c967800 Memory modified after free 0xfffffe01800d1000(2048) val=cc0c0001 @ 0xfffffe01800d1000 Memory modified after free 0xfffffe014c967800(2048) val=cc0c0001 @ 0xfffffe014c967800 Memory modified after free 0xfffffe0188fdf000(2048) val=cc0c0001 @ 0xfffffe0188fdf000 Memory modified after free 0xfffffe0188fdf000(2048) val=cc0c0001 @ 0xfffffe0188fdf000 Memory modified after free 0xfffffe00bd9a3000(2048) val=cc0c0001 @ 0xfffffe00bd9a3000 Memory modified after free 0xfffffe011a6cb000(2048) val=cc0c0001 @ 0xfffffe011a6cb000 Setting sysctl vm.memguard.desc=mbuf sends the kernel into a spiral of "use-after-frees". FWIW, I was able to repro the issue with ixgbe kldloading the module after boot sometimes, so I'm thinking that the locking/memory management in the recent set of changes is potentially off. Thanks, -Garrett PS Thanks np for the recent fix for cxgbe :). From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 03:09:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8332853; Sat, 22 Dec 2012 03:09:38 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1A82C8FC12; Sat, 22 Dec 2012 03:09:37 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so1800713wgb.3 for ; Fri, 21 Dec 2012 19:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VUCcoyDmAc5VKJhJ/A4Xyz/kRTo1tVY12xQ6a361qk4=; b=SQwjZTm3PYnOKZp3O2YF1mzJZLS1NQX/xJozJo0mL40X4tmbXOFphGK2OrmT4phhOZ sh/LPIRoi+oxSifVMRqjT/f4bS/K88gVwd75rwPiuH6iB3zPW/lSYGaGRTMwWR31sTP2 Qw3ZwVAXgTTasJ3t6pu+rFOnqPGCh9z9CoWmmmbaIeXuGjTcah1MGnwuYSWh1AQDmzN/ FG3aNVlcC/1jDvreRxrMIAoXSSkdGzhcX37KkG5nrvfZwPC2LWBChrQ0nmzXmv0+kvLA 1zBFIHNndv5lbEPqmTBf2CxtowwB48LMoLhoqUrfz//rODhNRY9RAO0fRD3Xkbazvjl6 8ojg== MIME-Version: 1.0 Received: by 10.180.100.197 with SMTP id fa5mr18502783wib.32.1356145777012; Fri, 21 Dec 2012 19:09:37 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 21 Dec 2012 19:09:36 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> Date: Sat, 22 Dec 2012 05:09:36 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:09:38 -0000 On Sat, Dec 22, 2012 at 3:19 AM, Kimmo Paasiala wrote: > On Sat, Dec 22, 2012 at 1:38 AM, =C5=81ukasz W=C4=85sikowski > wrote: >> W dniu 2012-12-21 13:23, Kimmo Paasiala pisze: >>> On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala wr= ote: >>>> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wro= te: >>>>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: >>>>>> A question related to this for those who have been doing work on the >>>>>> rc(8) scripts. Can I assume that /usr/bin is available when >>>>>> network.subr functions are used? Doing calculations on hexadecimal >>>>>> numbers is going to be very awkward if I can't use for example bc(1)= . >>>>> >>>>> You cannot assume that /usr/bin is available when setting up the >>>>> network. It may be that /usr is mounted via NFS. >>>>> >>>>> You can use hexadecimal numbers (prefixed with 0x) in $((...)) >>>>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can >>>>> use; in older versions you can use hexdigit and hexprint from >>>>> network.subr. >>>>> >>>>> -- >>>>> Jilles Tjoelker >>>> >>>> Thanks, I've rewitten my patch to support ranges. It is attached in >>>> this message. >>>> >>>> Again it's against a very recent 9-STABLE, I still haven't found time >>>> to see if it applies to CURRENT. >>>> >>>> It does allow you to do crazy stuff like >>>> >>>> ipv6_addrs_re0=3D"2001:db8:1111:2222::1-ffff/64" >>>> >>>> However I didn't find anything to limit the number of aliases in the >>>> ipv4 version of the function either. >>>> >>>> Please test it :) >>>> >>>> >>>> Then a question about the PR >>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174225) I wrote, how can= I >>>> attach this new patch to it? The submit follow up -button fires up my >>>> email client and I'm not so sure how to submit a new patch for the PR >>>> in an email in such a way that it appears properly formatted in the >>>> PR. >>>> >>>> Regards, >>>> >>>> Kimmo Paasiala >>> >>> PR updated with the new patch. >> >> Your patch applied cleanly, but it's not working or I am doing something >> wrong. >> >> root@freebsd:~ # uname -a >> FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri >> Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf >> hostname=3D"freebsd" >> ifconfig_em0=3D"up" >> ipv4_addrs_em0=3D"192.168.168.20-24/24" >> defaultrouter=3D"192.168.168.1" >> ipv6_activate_all_interfaces=3D"YES" >> ipv6_addrs_em0=3D"2001:6a0:1cb::1-6/64" >> ipv6_defaultrouter=3D"2001:6a0:1cb::ffff" >> sshd_enable=3D"YES" >> dumpdev=3D"NO" >> named_enable=3D"YES" >> >> root@freebsd:~ # ifconfig >> em0: flags=3D8843 metric 0 mtu 1= 500 >> options=3D9b >> ether 08:00:27:02:83:71 >> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 >> inet 192.168.168.20 netmask 0xffffff00 broadcast 192.168.168.255 >> inet 192.168.168.21 netmask 0xffffffff broadcast 192.168.168.21 >> inet 192.168.168.22 netmask 0xffffffff broadcast 192.168.168.22 >> inet 192.168.168.23 netmask 0xffffffff broadcast 192.168.168.23 >> inet 192.168.168.24 netmask 0xffffffff broadcast 192.168.168.24 >> nd6 options=3D21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=3D21 >> >> -- >> best regards, >> Lukasz Wasikowski > > You need to first add a single ipv6 address using the > ifconfig_em0_ipv6 -syntax. > > ifconfig_em0_ipv6=3D"2001:6a0:1cb::1/64" > > And then this should add the rest of the addresses > > ipv6_addrs_em0=3D"2001:6a0:1cb::2-6/64" > > It looks like the reason for the difference to ipv4_addrs_IF is that > the "alias" parameter for ifconfig(8) operates differently for IPv6 > addresses, the first address of an interface can't be added with > "alias", for IPv4 it does not care. I'll have to dig deeper but that's > what the problem seems to be. > > -Kimmo The 'alias' parameter of ifconfig(8) is not the problem on the first ipv6 address, I have verified that. However, there's probably something in network.subr or /etc/rc.d/netif that I have overlooked and causes my code to be skipped if there's no ifconfig_IF_ipv6 variable defined in rc.conf(5). -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 03:41:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C513DB1; Sat, 22 Dec 2012 03:41:53 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id ABF0A8FC0A; Sat, 22 Dec 2012 03:41:52 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so2432872wge.10 for ; Fri, 21 Dec 2012 19:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JnEv2UmG5YY4s3cu8lkYfkUjgEBe9ZXPJSCQ1NZy+Hg=; b=el5n1uflRX9SJ6ZkH4EqCjyjLYvs1SiaU7VuePvio5DyXhMdqXGipljlsYmyP9U6LG lQTdG1REi5kQvi2wgb7/mtI2bS0HzW9oIsJUCf+juxkFFqntvFeBeyv+XcqiSSip5IT7 rHZldtgC7i87BV5LyTwZDZ25ZgliTJB7S67/8tbNtoE3QMTcjizZ55cABghYTRvwhus4 O+tmX5FzsL+Dced5azrrA6Q/fpfQZsmMdB1rWmX/zlD8KGqQkOaILoIzaR1wJD6qCkl9 b6JRvy+qThUV4LDWYHDJc8qAUCpnsHmmxfH6ctGA0atYZupPFTA5JCgvq1jo8R9fUP44 N0AA== MIME-Version: 1.0 Received: by 10.194.9.162 with SMTP id a2mr26722957wjb.33.1356147711297; Fri, 21 Dec 2012 19:41:51 -0800 (PST) Received: by 10.216.172.197 with HTTP; Fri, 21 Dec 2012 19:41:51 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> Date: Sat, 22 Dec 2012 05:41:51 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:41:53 -0000 On Sat, Dec 22, 2012 at 5:09 AM, Kimmo Paasiala wrote: > On Sat, Dec 22, 2012 at 3:19 AM, Kimmo Paasiala wrot= e: >> On Sat, Dec 22, 2012 at 1:38 AM, =C5=81ukasz W=C4=85sikowski >> wrote: >>> W dniu 2012-12-21 13:23, Kimmo Paasiala pisze: >>>> On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala w= rote: >>>>> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wr= ote: >>>>>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: >>>>>>> A question related to this for those who have been doing work on th= e >>>>>>> rc(8) scripts. Can I assume that /usr/bin is available when >>>>>>> network.subr functions are used? Doing calculations on hexadecimal >>>>>>> numbers is going to be very awkward if I can't use for example bc(1= ). >>>>>> >>>>>> You cannot assume that /usr/bin is available when setting up the >>>>>> network. It may be that /usr is mounted via NFS. >>>>>> >>>>>> You can use hexadecimal numbers (prefixed with 0x) in $((...)) >>>>>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you ca= n >>>>>> use; in older versions you can use hexdigit and hexprint from >>>>>> network.subr. >>>>>> >>>>>> -- >>>>>> Jilles Tjoelker >>>>> >>>>> Thanks, I've rewitten my patch to support ranges. It is attached in >>>>> this message. >>>>> >>>>> Again it's against a very recent 9-STABLE, I still haven't found time >>>>> to see if it applies to CURRENT. >>>>> >>>>> It does allow you to do crazy stuff like >>>>> >>>>> ipv6_addrs_re0=3D"2001:db8:1111:2222::1-ffff/64" >>>>> >>>>> However I didn't find anything to limit the number of aliases in the >>>>> ipv4 version of the function either. >>>>> >>>>> Please test it :) >>>>> >>>>> >>>>> Then a question about the PR >>>>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174225) I wrote, how ca= n I >>>>> attach this new patch to it? The submit follow up -button fires up my >>>>> email client and I'm not so sure how to submit a new patch for the PR >>>>> in an email in such a way that it appears properly formatted in the >>>>> PR. >>>>> >>>>> Regards, >>>>> >>>>> Kimmo Paasiala >>>> >>>> PR updated with the new patch. >>> >>> Your patch applied cleanly, but it's not working or I am doing somethin= g >>> wrong. >>> >>> root@freebsd:~ # uname -a >>> FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri >>> Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC >>> amd64 >>> >>> root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf >>> hostname=3D"freebsd" >>> ifconfig_em0=3D"up" >>> ipv4_addrs_em0=3D"192.168.168.20-24/24" >>> defaultrouter=3D"192.168.168.1" >>> ipv6_activate_all_interfaces=3D"YES" >>> ipv6_addrs_em0=3D"2001:6a0:1cb::1-6/64" >>> ipv6_defaultrouter=3D"2001:6a0:1cb::ffff" >>> sshd_enable=3D"YES" >>> dumpdev=3D"NO" >>> named_enable=3D"YES" >>> >>> root@freebsd:~ # ifconfig >>> em0: flags=3D8843 metric 0 mtu = 1500 >>> options=3D9b >>> ether 08:00:27:02:83:71 >>> inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 >>> inet 192.168.168.20 netmask 0xffffff00 broadcast 192.168.168.25= 5 >>> inet 192.168.168.21 netmask 0xffffffff broadcast 192.168.168.21 >>> inet 192.168.168.22 netmask 0xffffffff broadcast 192.168.168.22 >>> inet 192.168.168.23 netmask 0xffffffff broadcast 192.168.168.23 >>> inet 192.168.168.24 netmask 0xffffffff broadcast 192.168.168.24 >>> nd6 options=3D21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D600003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>> inet 127.0.0.1 netmask 0xff000000 >>> nd6 options=3D21 >>> >>> -- >>> best regards, >>> Lukasz Wasikowski >> >> You need to first add a single ipv6 address using the >> ifconfig_em0_ipv6 -syntax. >> >> ifconfig_em0_ipv6=3D"2001:6a0:1cb::1/64" >> >> And then this should add the rest of the addresses >> >> ipv6_addrs_em0=3D"2001:6a0:1cb::2-6/64" >> >> It looks like the reason for the difference to ipv4_addrs_IF is that >> the "alias" parameter for ifconfig(8) operates differently for IPv6 >> addresses, the first address of an interface can't be added with >> "alias", for IPv4 it does not care. I'll have to dig deeper but that's >> what the problem seems to be. >> >> -Kimmo > > The 'alias' parameter of ifconfig(8) is not the problem on the first > ipv6 address, I have verified that. However, there's probably > something in network.subr or /etc/rc.d/netif that I have overlooked > and causes my code to be skipped if there's no ifconfig_IF_ipv6 > variable defined in rc.conf(5). > > -Kimmo Yeah, this is problem in network.subr. An interface is not recognized as IPv6 capable if the interface is not in "ipv6_network_interfaces" and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it "just works" because the interface is always assumed to be IPv4 capable. -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 11:08:24 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63129288; Sat, 22 Dec 2012 11:08:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 57AE48FC14; Sat, 22 Dec 2012 11:08:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18035; Sat, 22 Dec 2012 13:08:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmMw9-000E0e-3s; Sat, 22 Dec 2012 13:08:13 +0200 Message-ID: <50D5949A.1060505@FreeBSD.org> Date: Sat, 22 Dec 2012 13:08:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Fatal trap 1 [Was: "Memory modified after free" - by whom?] References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 11:08:24 -0000 on 22/12/2012 02:21 Garrett Cooper said the following: > Fatal trap 1: privileged instruction fault while in kernel mode > Fatal trap 1: privileged instruction fault while in kernel mode Unrelated to the original topic - this looks very weird. I mean all the CPUs getting this unusual trap... Could you please do 'disassemble 0xffffffff80af5099' in kgdb with the same kernel. Or if you have a different kernel now, please use "instruction pointer" value from a trap with that kernel. > Memory modified after free 0xffffff800040d000(9216) val=5a5a5a5a @ > 0xffffff800040d000 > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 3; > cpuid = 1; > apic id = 02 > cpuid = 0; apic id = 06 > apic id = 00 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > Fatal trap 1: privileged instruction fault while in kernel mode > stack pointer = 0x28:0xffffff8496fff880 > stack pointer = 0x28:0xffffff8496fe1880 > cpuid = 2; frame pointer = 0x28:0xffffff8496fff8b0 > frame pointer = 0x28:0xffffff8496fe18b0 > stack pointer = 0x28:0xffffff849705d880 > code segment = base 0x0, limit 0xfffff, type 0x1b > frame pointer = 0x28:0xffffff849705d8b0 > apic id = 04 > code segment = base 0x0, limit 0xfffff, type 0x1b > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > = DPL 0, pres 1, long 1, def32 0, gran 1 > instruction pointer = 0x20:0xffffffff80af5099 > processor eflags = = DPL 0, pres 1, long > 1, def32 0, gran 1 > interrupt enabled, processor eflags = stack pointer = > 0x28:0xffffff8497067880 > interrupt enabled, resume, resume, frame pointer = > 0x28:0xffffff84970678b0 > IOPL = 0 > code segment = base 0x0, limit 0xfffff, type 0x1b > current process = = DPL 0, pres 1, long > 1, def32 0, gran 1 > processor eflags = 12 (irq280: ix0:que 3) > ilock order reversal: (Giant after non-sleepable) > 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fff320 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 > witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff450 > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 > ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 > cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 > kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 > trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 > trap() at trap+0x836/frame 0xffffff8496fff7c0 > calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 > --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fff880, rbp > = 0xffffff8496fff8b0 --- > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 11:11:16 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03805452 for ; Sat, 22 Dec 2012 11:11:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 44D788FC0C for ; Sat, 22 Dec 2012 11:11:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18088; Sat, 22 Dec 2012 13:11:10 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmMz0-000E0w-Ir; Sat, 22 Dec 2012 13:11:10 +0200 Message-ID: <50D5954D.5090509@FreeBSD.org> Date: Sat, 22 Dec 2012 13:11:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hans Petter Selasky Subject: double fault [Was: clang compiled kernel panic when mounting zfs root on i386] References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> <50D2F3FE.1000509@gmail.com> <201212211738.08781.hselasky@c2i.net> In-Reply-To: <201212211738.08781.hselasky@c2i.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 11:11:16 -0000 on 21/12/2012 18:38 Hans Petter Selasky said the following: > I've built a 10-current i386 kernel as of today, and I see double fault when > USB audio is allocating memory. Anyone knows why? > > kdb_enter() > vpanic() > panic() > dblfault_handler() > vm_map_lookup() > vm_fault_hold() > vm_fault() > vm_fault_wire() > vm_map_wire() > kmem_alloc_attr(xxx, 0x4000,2,0,0xffffffff) > bus_dmamem_alloc() > usb_pc_alloc_mem() I suspect that this double fault may have nothing to do with the thread to which you followed up. You need to obtain full debug information to answer your question. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 11:21:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1304A659; Sat, 22 Dec 2012 11:21:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7535E8FC17; Sat, 22 Dec 2012 11:21:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBMBLO3s056016; Sat, 22 Dec 2012 13:21:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBMBLO3s056016 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBMBLOib056015; Sat, 22 Dec 2012 13:21:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2012 13:21:24 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Fatal trap 1 [Was: "Memory modified after free" - by whom?] Message-ID: <20121222112124.GN53644@kib.kiev.ua> References: <50D5949A.1060505@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zbynv6TNPa9FrOf6" Content-Disposition: inline In-Reply-To: <50D5949A.1060505@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Garrett Cooper , freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 11:21:32 -0000 --Zbynv6TNPa9FrOf6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2012 at 01:08:10PM +0200, Andriy Gapon wrote: > on 22/12/2012 02:21 Garrett Cooper said the following: > > Fatal trap 1: privileged instruction fault while in kernel mode > > Fatal trap 1: privileged instruction fault while in kernel mode >=20 > Unrelated to the original topic - this looks very weird. > I mean all the CPUs getting this unusual trap... > Could you please do 'disassemble 0xffffffff80af5099' in kgdb with the same > kernel. Or if you have a different kernel now, please use "instruction p= ointer" > value from a trap with that kernel. >=20 This is due to the vtoslab() returning NULL. Since slabref is dereferenced later, clang tries to be helpful as usual and converts the !(p->flags & PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() result is NULL. So instead of KASSERT triggering the next line, you see this improvement. > > Memory modified after free 0xffffff800040d000(9216) val=3D5a5a5a5a @ > > 0xffffff800040d000 > > Fatal trap 1: privileged instruction fault while in kernel mode > > cpuid =3D 3; > > cpuid =3D 1; > > apic id =3D 02 > > cpuid =3D 0; apic id =3D 06 > > apic id =3D 00 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > Fatal trap 1: privileged instruction fault while in kernel mode > > stack pointer =3D 0x28:0xffffff8496fff880 > > stack pointer =3D 0x28:0xffffff8496fe1880 > > cpuid =3D 2; frame pointer =3D 0x28:0xffffff8496fff8b0 > > frame pointer =3D 0x28:0xffffff8496fe18b0 > > stack pointer =3D 0x28:0xffffff849705d880 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > frame pointer =3D 0x28:0xffffff849705d8b0 > > apic id =3D 04 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > processor eflags =3D =3D DPL 0, pres 1, lo= ng > > 1, def32 0, gran 1 > > interrupt enabled, processor eflags =3D stack pointer =3D > > 0x28:0xffffff8497067880 > > interrupt enabled, resume, resume, frame pointer =3D > > 0x28:0xffffff84970678b0 > > IOPL =3D 0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > current process =3D =3D DPL 0, pres 1, lo= ng > > 1, def32 0, gran 1 > > processor eflags =3D 12 (irq280: ix0:que 3) > > ilock order reversal: (Giant after non-sleepable) > > 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > > 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd= =2Ec:1946 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff849= 6fff320 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 > > witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff4= 50 > > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 > > ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 > > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 > > cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 > > kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 > > trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 > > trap() at trap+0x836/frame 0xffffff8496fff7c0 > > calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 > > --- trap 0x1, rip =3D 0xffffffff80af5099, rsp =3D 0xffffff8496fff880, r= bp > > =3D 0xffffff8496fff8b0 --- > > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Zbynv6TNPa9FrOf6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDVl7QACgkQC3+MBN1Mb4i/AACcDPDRTKUrOx+7sGBKr/uDvlWe guAAnAkEl1FAAovlA4oWmJZKvjbHSVs2 =0QM1 -----END PGP SIGNATURE----- --Zbynv6TNPa9FrOf6-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 11:44:55 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1031A91A; Sat, 22 Dec 2012 11:44:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1C88FC12; Sat, 22 Dec 2012 11:44:53 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18206; Sat, 22 Dec 2012 13:44:51 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmNVa-000E2o-Un; Sat, 22 Dec 2012 13:44:50 +0200 Message-ID: <50D59D31.6010302@FreeBSD.org> Date: Sat, 22 Dec 2012 13:44:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Fatal trap 1 References: <50D5949A.1060505@FreeBSD.org> <20121222112124.GN53644@kib.kiev.ua> In-Reply-To: <20121222112124.GN53644@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-net@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 11:44:55 -0000 on 22/12/2012 13:21 Konstantin Belousov said the following: > This is due to the vtoslab() returning NULL. Since slabref is dereferenced > later, clang tries to be helpful as usual and converts the !(p->flags & > PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() > result is NULL. > > So instead of KASSERT triggering the next line, you see this improvement. Interesting. Thank you for the explanation. But looking at the code I think that slabref->us_keg access _before_ KASSERT is the culprit? I.e. even with GCC we could get a page fault before the KASSERT is reached (modulo reordering)? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 11:49:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6DE8BEB; Sat, 22 Dec 2012 11:49:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 15E9D8FC0C; Sat, 22 Dec 2012 11:49:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBMBn5wm058431; Sat, 22 Dec 2012 13:49:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBMBn5wm058431 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBMBn4Ba058430; Sat, 22 Dec 2012 13:49:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2012 13:49:04 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Fatal trap 1 Message-ID: <20121222114904.GO53644@kib.kiev.ua> References: <50D5949A.1060505@FreeBSD.org> <20121222112124.GN53644@kib.kiev.ua> <50D59D31.6010302@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hOh8F6DNH/RZBSFD" Content-Disposition: inline In-Reply-To: <50D59D31.6010302@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Garrett Cooper , freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 11:49:09 -0000 --hOh8F6DNH/RZBSFD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2012 at 01:44:49PM +0200, Andriy Gapon wrote: > on 22/12/2012 13:21 Konstantin Belousov said the following: > > This is due to the vtoslab() returning NULL. Since slabref is dereferen= ced > > later, clang tries to be helpful as usual and converts the !(p->flags & > > PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtosla= b() > > result is NULL. > >=20 > > So instead of KASSERT triggering the next line, you see this improvemen= t. >=20 > Interesting. Thank you for the explanation. >=20 > But looking at the code I think that slabref->us_keg access _before_ KASS= ERT > is the culprit? I.e. even with GCC we could get a page fault before the > KASSERT is reached (modulo reordering)? May be, but I do not think it is matter. Because KASSERT() now can return, even if you reorder the assert and deref, I think that compiler authors still find an excuse. --hOh8F6DNH/RZBSFD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDVnjAACgkQC3+MBN1Mb4gW7wCgn9j92ij2YpljHo9NIj6IneHW 0pAAn1POvHv9NRfsLFExGGFpWzEmkN2a =vH3G -----END PGP SIGNATURE----- --hOh8F6DNH/RZBSFD-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 12:59:06 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85FC5CC7; Sat, 22 Dec 2012 12:59:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 42C6D8FC12; Sat, 22 Dec 2012 12:59:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:84e5:2627:88f9:e626] (unknown [IPv6:2001:7b8:3a7:0:84e5:2627:88f9:e626]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9B7165C5A; Sat, 22 Dec 2012 13:59:05 +0100 (CET) Message-ID: <50D5AE9F.10801@FreeBSD.org> Date: Sat, 22 Dec 2012 13:59:11 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: double fault [Was: clang compiled kernel panic when mounting zfs root on i386] References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> <50D2F3FE.1000509@gmail.com> <201212211738.08781.hselasky@c2i.net> <50D5954D.5090509@FreeBSD.org> In-Reply-To: <50D5954D.5090509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 12:59:06 -0000 On 2012-12-22 12:11, Andriy Gapon wrote: > on 21/12/2012 18:38 Hans Petter Selasky said the following: >> I've built a 10-current i386 kernel as of today, and I see double fault when >> USB audio is allocating memory. Anyone knows why? >> >> kdb_enter() >> vpanic() >> panic() >> dblfault_handler() >> vm_map_lookup() >> vm_fault_hold() >> vm_fault() >> vm_fault_wire() >> vm_map_wire() >> kmem_alloc_attr(xxx, 0x4000,2,0,0xffffffff) >> bus_dmamem_alloc() >> usb_pc_alloc_mem() > > I suspect that this double fault may have nothing to do with the thread to which > you followed up. > > You need to obtain full debug information to answer your question. Specifically interesting are the stack frame addresses, which Kostik has added recently. From these, you can easily see whether the double fault is due to stack exhaustion (which seems unlikely with such a small call stack), or to something else. From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 14:25:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0F54F73; Sat, 22 Dec 2012 14:25:57 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (mail.wasikowski.net [91.204.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE608FC12; Sat, 22 Dec 2012 14:25:56 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [91.204.91.44]) by bijou.wasikowski.net (Postfix) with ESMTP id 036DF285; Sat, 22 Dec 2012 15:25:53 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([91.204.91.44]) by mail.wasikowski.net (scan.wasikowski.net [91.204.91.44]) (amavisd-new, port 10026) with ESMTP id jIf-VeKOLtqN; Sat, 22 Dec 2012 15:25:52 +0100 (CET) Received: from [192.168.168.2] (89-72-12-251.dynamic.chello.pl [89.72.12.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lukasz@wasikowski.net) by bijou.wasikowski.net (Postfix) with ESMTPSA id 7E27E282; Sat, 22 Dec 2012 15:25:52 +0100 (CET) Message-ID: <50D5C2F4.1070104@wasikowski.net> Date: Sat, 22 Dec 2012 15:25:56 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 14:25:57 -0000 W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >>> It looks like the reason for the difference to ipv4_addrs_IF is that >>> the "alias" parameter for ifconfig(8) operates differently for IPv6 >>> addresses, the first address of an interface can't be added with >>> "alias", for IPv4 it does not care. I'll have to dig deeper but that's >>> what the problem seems to be. >>> >>> -Kimmo >> >> The 'alias' parameter of ifconfig(8) is not the problem on the first >> ipv6 address, I have verified that. However, there's probably >> something in network.subr or /etc/rc.d/netif that I have overlooked >> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >> variable defined in rc.conf(5). >> >> -Kimmo > > Yeah, this is problem in network.subr. An interface is not recognized > as IPv6 capable if the interface is not in "ipv6_network_interfaces" > and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it > "just works" because the interface is always assumed to be IPv4 > capable. Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: ipv6_activate_all_interfaces="NO" ipv6_network_interfaces="em0" ifconfig_em0_ipv6="up" ipv6_addrs_em0="2001:6a0:1cb::1-ff/64" ipv6_defaultrouter="2001:6a0:1cb::ffff" Good job, thank you! :) -- best regards, Lukasz Wasikowski From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 15:29:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 351564D0; Sat, 22 Dec 2012 15:29:50 +0000 (UTC) (envelope-from kpaasial@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 824498FC0A; Sat, 22 Dec 2012 15:29:49 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id o1so5715100wic.11 for ; Sat, 22 Dec 2012 07:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4+Nrvn/SUsFo3ljulo5BoP2PQ8ylsjJy++kP3tolr3M=; b=e5wklcWNZPwAStw3i1cYcP+A2z4UB5wyQTU2yBeDvmJuvYnd6BRtK/OcmB0Qby0puX Oc65W5pjkKKu0S1G8PGv6rZW4XeTwtG8tQEWokAscfGd87iCMBx6nWRaIEVzk7b9CptK TEuQqS/ts66lG9WCn7sLQoxz+j3ABiHHIVRpN/UDsPmkiy81z+/OCj42qq2lyLTHRGiR HROSsk3K+Cut5rKMBG6dUR75ZspuKD5DvCQNYk2rKDY88KGXIKa7DaNSOPqWF0h2mqou uefcPf2Sb2pv/hlF5a5Q/0s3NmqSWYAMWwfjmVd1AYHJUS8Zubg6iFwBwOvRVFfVP4Al +/Bw== MIME-Version: 1.0 Received: by 10.180.24.198 with SMTP id w6mr20494243wif.27.1356190182237; Sat, 22 Dec 2012 07:29:42 -0800 (PST) Received: by 10.216.172.197 with HTTP; Sat, 22 Dec 2012 07:29:42 -0800 (PST) In-Reply-To: <50D5C2F4.1070104@wasikowski.net> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <50D5C2F4.1070104@wasikowski.net> Date: Sat, 22 Dec 2012 17:29:42 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: =?UTF-8?Q?=C5=81ukasz_W=C4=85sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 15:29:50 -0000 On Sat, Dec 22, 2012 at 4:25 PM, =C5=81ukasz W=C4=85sikowski wrote: > W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: > >>>> It looks like the reason for the difference to ipv4_addrs_IF is that >>>> the "alias" parameter for ifconfig(8) operates differently for IPv6 >>>> addresses, the first address of an interface can't be added with >>>> "alias", for IPv4 it does not care. I'll have to dig deeper but that's >>>> what the problem seems to be. >>>> >>>> -Kimmo >>> >>> The 'alias' parameter of ifconfig(8) is not the problem on the first >>> ipv6 address, I have verified that. However, there's probably >>> something in network.subr or /etc/rc.d/netif that I have overlooked >>> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >>> variable defined in rc.conf(5). >>> >>> -Kimmo >> >> Yeah, this is problem in network.subr. An interface is not recognized >> as IPv6 capable if the interface is not in "ipv6_network_interfaces" >> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it >> "just works" because the interface is always assumed to be IPv4 >> capable. > > Ok, I used ifconfig_em0_ipv6=3D"up" and it worked. So it looks like this: > > ipv6_activate_all_interfaces=3D"NO" > ipv6_network_interfaces=3D"em0" > ifconfig_em0_ipv6=3D"up" > ipv6_addrs_em0=3D"2001:6a0:1cb::1-ff/64" > ipv6_defaultrouter=3D"2001:6a0:1cb::ffff" > > Good job, thank you! :) > > -- > best regards, > Lukasz Wasikowski I'm looking into fixing the issue so you could just have the ipv6_addrs_em0 line in rc.conf. However I don't want to flood the PR and this mailing list with different versions of the patch. I want to get it right next time. Stay tuned. -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 20:48:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2A96387; Sat, 22 Dec 2012 20:48:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9098FC0A; Sat, 22 Dec 2012 20:48:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:84e5:2627:88f9:e626] (unknown [IPv6:2001:7b8:3a7:0:84e5:2627:88f9:e626]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 364525C5A; Sat, 22 Dec 2012 21:48:44 +0100 (CET) Message-ID: <50D61CB0.1050506@FreeBSD.org> Date: Sat, 22 Dec 2012 21:48:48 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: George Liaskos Subject: Re: protoc crash in libstdc++ References: <50D05FD6.7080008@freebsd.org> <50D0CE37.3000306@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , Roman Divacky , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 20:48:46 -0000 On 2012-12-18 22:12, George Liaskos wrote: >> Try removing --gc-sections from the link flags for protoc, that should >> solve it for now. I am still looking at the root cause, which seems to >> be something in our ld; it does not seem to be related to either clang >> or libstdc++. > > Whoa, thank you! Removing --gc-sections from the link flags solves the > issue indeed! I have committed the real bugfix for ld --gc-sections in r244600. I will also MFC it in a week. From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 22:50:28 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9802952C; Sat, 22 Dec 2012 22:50:28 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 298398FC0A; Sat, 22 Dec 2012 22:50:26 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5F7793592D9; Sat, 22 Dec 2012 23:50:25 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 479B62848C; Sat, 22 Dec 2012 23:50:25 +0100 (CET) Date: Sat, 22 Dec 2012 23:50:25 +0100 From: Jilles Tjoelker To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121222225025.GA46583@stack.nl> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <50D192E8.3020704@FreeBSD.org> <15947.1355914806@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15947.1355914806@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , Ian Lepore , Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 22:50:28 -0000 On Wed, Dec 19, 2012 at 11:00:06AM +0000, Poul-Henning Kamp wrote: > -------- > In message <50D192E8.3020704@FreeBSD.org>, Alexander Motin writes: > >Linux uses 32.32 format in their eventtimers code. > (And that is no accident, I know who they got the number from :-) > >But if at some point we want to be able to > >handle absolute wall time, [...] > Then you have other problems, including but not limited to clock > being stepped, leap-seconds, suspend/resume and frequency stability. > If you want to support callouts of the type ("At 14:00 UTC tomorrow") > (disregarding the time-zone issue), you need to catch all significant > changes to our UTC estimate and recalibrate your callout based on > that. > It is not obvious that we have applications for such an API that > warrant the complexity. > Either way, such a facility should be layered on top of the callout > facility, which should always run in "elapsed time"[1] with no attention > paid to what NTPD might do to the UTC estimate. POSIX specifies functions that assume such a facility exists, although applications may not care much if we implement them incorrectly. For example, pthread_mutex_timedlock() and sem_timedwait() shall time out when the CLOCK_REALTIME clock reaches the given value, and pthread_cond_timedwait() and clock_nanosleep() (with TIMER_ABSTIME) shall time out when the specified clock reaches the given value. > So summary: 32.32 is the right format. > Poul-Henning > [1] Notice that "elapsed time" needs a firm definition with respect > to suspend/resume, and that this decision has big implications > for the API use and code duplication. > I think it prudent to specify a flag to callouts, to tell what > should happen on suspend/resume, something like: > SR_CANCEL /* Cancel the callout on S/R */ > /* no flag* /* Toll this callout only when system is running */ > SR_IGNORE /* Toll suspended time from callout */ > If you get this right, callouts from device drivers will just "DTRT", > if you get it wrong, all device drivers will need boilerplate code > to handle S/R Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC vs CLOCK_UPTIME. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sat Dec 22 22:58:02 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4BC6837; Sat, 22 Dec 2012 22:58:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 522EA8FC0C; Sat, 22 Dec 2012 22:58:02 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1EFD88A512; Sat, 22 Dec 2012 22:57:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBMMvsts002072; Sat, 22 Dec 2012 22:57:54 GMT (envelope-from phk@phk.freebsd.dk) To: Jilles Tjoelker Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: <20121222225025.GA46583@stack.nl> From: "Poul-Henning Kamp" References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <50D192E8.3020704@FreeBSD.org> <15947.1355914806@critter.freebsd.dk> <20121222225025.GA46583@stack.nl> Date: Sat, 22 Dec 2012 22:57:54 +0000 Message-ID: <2071.1356217074@critter.freebsd.dk> Cc: Davide Italiano , Ian Lepore , Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 22:58:02 -0000 -------- In message <20121222225025.GA46583@stack.nl>, Jilles Tjoelker writes: >> Either way, such a facility should be layered on top of the callout >> facility, which should always run in "elapsed time"[1] with no attention >> paid to what NTPD might do to the UTC estimate. > >POSIX specifies functions that assume such a facility exists, although >applications may not care much if we implement them incorrectly. It should still be implemented op top of callouts, not as part of: it is an entirely different thing to try to do right. >> I think it prudent to specify a flag to callouts, to tell what >> should happen on suspend/resume, something like: > >> SR_CANCEL /* Cancel the callout on S/R */ >> /* no flag* /* Toll this callout only when system is running */ >> SR_IGNORE /* Toll suspended time from callout */ > >> If you get this right, callouts from device drivers will just "DTRT", >> if you get it wrong, all device drivers will need boilerplate code >> to handle S/R > >Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC >vs CLOCK_UPTIME. I have _no_ idea what you are trying to say here... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.